Walkee

App móvil para pasear perros

Alexandre Calle Millán

Fecha de la defensa: 29 de febrero de 2019Directora: María José Casany Guerrero

Dpto: Ingeniería de Servicios y Sistemas de Información (ESSI)Centro: Facultat d’Informàtica de Barcelona (FIB)

Resum

L’estil de vida accelerat que portem ens limita el temps que podem dedicar alsnostres gossos. Aquest projecte, que pretén millorar la qualitat de vida d’aquests,planteja una solució comuna i sense ànim de lucre mitjançant una app per a pro-pietaris, protectores d’animals i gent amb temps lliure. La solució proposada enaquest treball permetrà gestionar els passejos diaris de gossos tant de particularscom de gosssos sense amo.

Resumen

El estilo de vida acelerado que llevamos nos limita el tiempo que podemos dedi-car a nuestros perros. Este proyecto, que pretende mejorar la calidad de vida deéstos, plantea una solución común y sin ánimo de lucro mediante una app parapropietarios, protectoras de animales y gente con tiempo libre. La solución pro-puesta en este trabajo permitirá gestionar los paseos diarios de perros tanto comode particulares como de los perros sin dueño.

Abstract

The fast-paced lifestyle that we lead limits the time that we can devote to our dogs.This project, that intends to improve their quality of life, proposes a common non-profit solution through an app for owners, animal protection organizations andpeople with free time. This work’s proposed solution will allow to manage dailywalks of dogs of individuals and homeless dogs.

Acrónimos y siglas

API Application Programming Interface 43, 45, 62, 66, 67, 69, 71–73, 79

CDN Content Delivery System 43

csv Comma Separated Values 73

ftp File Transfer Protocol 59

GPS Global Positioning System 17

HRQOL Health Related Quality of Life 13

html HyperText Markup Language 70

HTTPS Hypertext Transfer Protocol Secure 64, 65

IDE Integrated Development Environment 58

IETF Internet Engineering Task Force 60

IP Internet Protocol Address 59, 70

JSON JavaScript Object Notation 44, 45

JWT JSON Web Token 60, 62

LOPD Ley Orgánica de Protección de Datos de Carácter Personal 42, 80

MVC Modelo-Vista-Controlador 45

ORM Object Relational Mapping 44

OWASP Open Web Application Security Project 65, 79

pdf Portable Document Format 70

PPP Perro Potencialmente Peligroso 86

QL Query Language 71

REST Representational State Transfer 79

SGBD Sistema de Gestión de Base de Datos 44, 57, 67

SQL Structured Query Language 79

ssh Secure Shell 59, 79

SSL Secure Sockets Layer 59, 61, 79

TDD Test Driven Development 18

TFG Trabajo de Fin de Grado 36

TIC Tecnologías de la Información y Comunicación 33

UML Unified Modeling Language 46

URL Uniform Resource Locator 60, 66

WCAG Web Content Accessibility Guidelines 47

XML Extensible Markup Language 44, 45

Glosario

Agile Conjunto de metodologías para el desarrollo de proyectos que precisan derapidez y flexibilidad para adaptarse a condiciones cambiantes del sector omercado, aprovechando dichos cambios para proporcionar ventaja compe-titiva. Es decir, el proyecto se divide en pequeñas partes que tienen quecompletarse y entregarse en pocas semanas. 18, 19

Android Sistema operativo diseñado, en principio, para móviles (pero usado enmás tipos de dispositivos). 14, 16, 22, 24, 42, 57, 58, 69, 70, 78

API key Cadena de caracteres incluida en una llamada a una API para que elservidor autorice/identifique el origen de la llamada. 69

Array Zona de almacenamiento contiguo que contiene una serie de elementos delmismo tipo, los elementos de la matriz. 73

Backend Parte de una aplicación que se encarga de gestionar la lógica de negocioy de proveer información al frontend, por eso decimos que el backend estáen el lado del servidor, corresponde a la capa de acceso a datos. 16, 19–21,23–25, 44, 45, 63, 65, 68, 71, 75, 78–80

Base de datos relacional Base de datos que cumple con el modelo relacional,es decir, que enlaza datos almacenados en tablas diferentes. 44

Binding Sustitución de un valor en un programa después de que éste haya sidocompilado. 71

Bitmap Estructura de datos de matriz que almacena de forma compacta los bits(valores 1 o 0). Se puede utilizar para implementar una estructura de datosde conjunto simple. 71

Blog Página web, generalmente de carácter personal, con una estructura crono-lógica que se actualiza regularmente y que se suele dedicar a tratar un temaconcreto. 17

Bounding Box Cuadro con la medida más pequeña dentro de la cual se encuen-tran todos los puntos de una figura. 71

Caché Información que permanece de manera temporal en la computadora y queayuda a la adquisición de velocidad y eficiencia cuando es necesario recurrira determinado tipo de datos. 70

Callback Función que se pasa a otra función como un argumento, que luego seinvoca dentro de la función externa para completar algún tipo de rutina oacción. 63

Casa de acogida Acogida temporal en una casa, para mascotas que están enbúsqueda activa de hogar, en el caso de las protectoras por falta de espacioy en las perreras por evitar el sacrificio. 82, 90

Checkbox Elemento de interacción de la interfaz gráfica de usuario que permitea éste hacer selecciones múltiples de un conjunto de opciones. 71

Clave Primaria Campo o a una combinación de campos que identifica de formaúnica a cada fila de una tabla. 74

Cortisol Hormona que se libera como respuesta al estrés. 12

Crowdfunding Mecanismo colaborativo de financiación de proyectos. 34

Database Seeding Proceso en el que un conjunto de información se inserta enla base de datos a la hora de ser creada, es muy útil cuando queremos llenarla base de datos con datos con que queremos probar durante el desarrollo.72, 73

Denial of service Cualquier tipo de ataque donde los atacantes busquen inutili-zar una máquina o red de máquinas mediante grandes cantidades de tráfico.66

Diagrama de Gantt Herramienta gráfica cuyo objetivo es exponer el tiempode dedicación previsto para diferentes tareas o actividades a lo largo de untiempo total determinado. 21, 23

Directory traversal Explotación de una seguridad insuficiente en la validacióno sanitización de rutas de fichero proporcionadas por usuario que permiteacceder a archivos del servidor. 66

Dominio Nombre único y exclusivo que se le da a un sitio web en Internet paraque cualquiera pueda visitarlo. 43, 59

Endpoint Direcciones web que reciben o retornan información de un Web API.63, 64, 67–69, 74, 75

Escalabilidad Propiedad deseable de un sistema, una red o un proceso, que indicasu habilidad para reaccionar y adaptarse sin perder calidad, o bien manejar elcrecimiento continuo de trabajo de manera fluida, o bien para estar preparadopara hacerse más grande. 34, 43, 67, 81

Estado del arte Apartado académico que describe, compara y contrasta solucio-nes existentes del mercado con la que propone un proyecto, contextualizandosu área. 8

Experiencia de usuario Conjunto de factores y elementos relativos a la inter-acción del usuario cuyo resultado es la generación de una percepción positivao negativa de dicho servicio, producto o dispositivo. En general, busca medirel nivel de satisfacción de los usuarios. 17, 20, 69

Feedback Acto de ofrecer información sobre el resultado de un proceso o de partede un proceso. Puede involucrar desde consejos, comentarios y evaluaciones.18, 19, 40, 81

Framework Conjunto estandarizado de conceptos, prácticas y criterios para en-focar un tipo de problemática particular que sirve como referencia, paraenfrentar y resolver nuevos problemas de índole similar. 44, 57, 58

Frontend Parte de una aplicación que interactúa con los usuarios, por eso decimosque está del lado del cliente, corresponde a la capa de presentación. 20–23,25, 44, 45

Hardware Conjunto de elementos físicos o materiales que constituyen una compu-tadora o un sistema informático. 23, 28, 30, 32, 58

Historia de usuario Pequeña descripción del requerimiento de un cliente. 16,19, 21, 22, 24, 37, 59, 75, 78

Huella ecológica Indicador del impacto ambiental generado por la demanda hu-mana 36

Iteración Es un ciclo de tiempo que se va repitiendo. Tras cada iteración, elproducto o servicio gana valor. Este se revisa hasta que el cliente quedaconforme, por lo que es frecuente facturar por iteración. 18, 19

JavaScript Lenguaje de programación interpretado, dialecto del estándar EC-

MAScript. Se define como orientado a objetos, basado en prototipos, impe-rativo, débilmente tipado y dinámico. 73

Kanban Metodología que se centra en la mejora de la visibilidad del flujo detrabajo utilizando un tablero y limitando el trabajo en curso. 18

LaTeX Sistema de preparación de documentos muy personalizable que permitela inclusión de paquetes para propósitos específicos, normalmente orientadosal ámbito técnico-científico. 23, 58

Layout Archivo, concretamente en Android en formato XML, que representa laestructura visual de una interfaz gráfica, es decir, la distribución de elementosen la pantalla. 71

Librería Conjunto de implementaciones funcionales, codificadas en un lenguajede programación, que ofrece una interfaz bien definida para la funcionalidadque se invoca. 61, 63, 64, 67

Migración Pequeño cambio a tablas y columnas que, en conjunto, se acumulanhasta formar un esquema de una base de datos. 46

Monkey Testing Técnica donde un desarrollador prueba una aplicación o siste-ma mediante miles de entradas aleatorias, mientras se comprueba el compor-tamiento, y se mira si la aplicación o sistema crashea o no. 76

Overhead En informática, coste adicional indeseado que supone la realización deuna operación. 67

Partida de contingencia Fondos destinados al plan o modelo sistemático de ac-tuación que tiene por objeto anticiparse a situaciones en las que esté próximoun daño o en que exista la posibilidad de que éste suceda o no. 31, 32

Patrón Esqueleto de una solución a un problema común en el desarrollo de soft-ware. 44–46

Perrera Centro municipal, subvencionado por un ayuntamiento, que está obliga-dos a recoger a los perros y gatos del municipio durante un cierto tiempo,después de éste, suelen ser sacrificados. 12, 17, 35

Pet sharing Acto de proveer o intercambiar gratuitamente los cuidados de unamascota. 84, 87, 90

Polling Proceso por el cual, en un programa, se consulta activamente el estadode un recurso externo de forma síncrona. 68

Prepared Statement Técnica usada para ejecutar la misma (o similar) sentenciaSQL repetidamente de forma muy eficiente, precompilándola. Los parámetros

se integran mediante binds. 79

Protectora de animales Asociación que recoge a todos los animales abandona-dos de forma indefinida, ofreciéndoles refugio y cuidados hasta que encuen-tran un hogar. No es lo mismo que una perrera. 2, 8–10, 12, 15–17, 69,81–90

Scrum Scrum es un proceso en el que se aplican de manera regular un conjuntode buenas prácticas para trabajar colaborativamente, en equipo, y obtenerel mejor resultado posible de un proyecto. 18

Shell upload Explotación de una seguridad insuficiente en la subida de ficheros,pudiendo subir un fichero con comandos de shell que será interpretado porel servidor. 66

Socket Método para la comunicación entre un programa del cliente y un programadel servidor en una red, se define, por tanto, como el punto final en unaconexión. 68

Software Soporte lógico de un sistema informático, que comprende el conjunto delos componentes lógicos necesarios que hacen posible la realización de tareasespecíficas. 18, 19, 28, 30, 32, 58

SQL Injection Técnica maliciosa donde un atacante crea o altera comandos SQLexistentes para exponer datos ocultos, sobrescribir los valiosos, o peor aún,ejecutar comandos peligrosos a nivel de sistema en el equipo que hospeda labase de datos. 79

Stakeholder Persona, organización o empresa que tiene interés en un proyecto.9

String Secuencia ordenada y limitada de caracteres que se suele utilizar pararepresentar texto. 71, 73, 74

Teaming Mecanismo colaborativo basado en la idea de que si varias personadonan una cantidad simbólica al mes (en Europa 1e al mes), pueden ayudarmucho a causas. 34

Test de estrés Test donde se pone a prueba de forma deliberada a una aplicacióno sistema para determinar su estabilidad. 76

Testing Proceso empírico para encontrar bugs o fallos en un programa, ya seamanualmente o automáticamente. 19, 20, 74

Unit Testing Tipo de testing basado en múltiples métodos o funciones que pue-den invocar a los códigos que queremos probar, para luego determinar si los

resultados obtenidos son los esperados. Si son iguales, entonces las pruebasson exitosas, y si no, es que alguna ha fallado. 18, 19, 80

Unix Timestamp Cantidad de segundos transcurridos desde la medianoche UTCdel 1 de enero de 1970, sin contar segundos intercalares. 68

Usabilidad Es la medida de la calidad de la experiencia que tiene un usuariocuando interactúa con un producto o sistema. 22, 31

Índice

1. Contexto 7

2. Formulación del problema 8

3. Stakeholders 93.1. Propietarios de perros . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1. Personas con vidas laborales restrictivas . . . . . . . . . . . 93.1.2. Personas con discapacidades o lesiones . . . . . . . . . . . . 93.1.3. Personas mayores . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2. Paseadores de perros . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.1. Personas con tiempo libre . . . . . . . . . . . . . . . . . . . 103.2.2. Personas que se plantean adquirir un can . . . . . . . . . . . 10

3.3. Protectoras de animales . . . . . . . . . . . . . . . . . . . . . . . . 103.4. Desarrollador del proyecto . . . . . . . . . . . . . . . . . . . . . . . 103.5. Directora del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 11

4. Estado del arte 124.1. Preámbulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2. Necesidades físicas y psicológicas de los perros . . . . . . . . . . . . 12

4.2.1. Compañía . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.2. Socialización . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.3. Ejercicio físico . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3. Aplicaciones similares . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3.1. Dogbuddy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3.2. PaseaPerros.com . . . . . . . . . . . . . . . . . . . . . . . . 144.3.3. Iamvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5. Alcance 165.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.1.1. Objetivo del proyecto . . . . . . . . . . . . . . . . . . . . . . 165.1.2. Subobjetivos del proyecto . . . . . . . . . . . . . . . . . . . 165.1.3. Objetivos sociales de la aplicación . . . . . . . . . . . . . . . 165.1.4. Objetivos fuera del ámbito del proyecto . . . . . . . . . . . . 175.1.5. Posibles objetivos después del proyecto . . . . . . . . . . . . 17

5.2. Posibles obstáculos . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2.1. Falta de recursos en las protectoras . . . . . . . . . . . . . . 175.2.2. Usabilidad en personas mayores . . . . . . . . . . . . . . . . 17

1

6. Metodología y rigor 186.1. Agile Solo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186.2. Método de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.3. Herramientas de seguimiento . . . . . . . . . . . . . . . . . . . . . . 196.4. Método de validación . . . . . . . . . . . . . . . . . . . . . . . . . . 19

7. Planificación temporal 217.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217.2. Valoración de las alternativas y plan de acción . . . . . . . . . . . . 22

7.2.1. Posibles desviaciones en el desarrollo . . . . . . . . . . . . . 227.2.2. Implicaciones de las desviaciones . . . . . . . . . . . . . . . 227.2.3. Posibles soluciones y/o alternativas . . . . . . . . . . . . . . 22

7.3. Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237.3.1. Recursos personales . . . . . . . . . . . . . . . . . . . . . . . 237.3.2. Recursos materiales . . . . . . . . . . . . . . . . . . . . . . . 23

7.4. Descripción de las tareas . . . . . . . . . . . . . . . . . . . . . . . . 247.4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . 247.4.2. Descripciones . . . . . . . . . . . . . . . . . . . . . . . . . . 24

8. Gestión económica 288.1. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

8.1.1. Presupuesto en Recursos Humanos . . . . . . . . . . . . . . 288.1.2. Costes indirectos . . . . . . . . . . . . . . . . . . . . . . . . 30

8.1.2.1. Presupuesto en Hardware . . . . . . . . . . . . . . 308.1.2.2. Presupuesto en Software . . . . . . . . . . . . . . . 308.1.2.3. Otros costes indirectos . . . . . . . . . . . . . . . . 31

8.1.3. Plan de contingencia . . . . . . . . . . . . . . . . . . . . . . 318.1.4. Costes de imprevistos . . . . . . . . . . . . . . . . . . . . . . 318.1.5. Presupuesto total . . . . . . . . . . . . . . . . . . . . . . . . 32

8.2. Control del presupuesto . . . . . . . . . . . . . . . . . . . . . . . . 32

9. Sostenibilidad 339.1. Autovaluación de sostenibilidad . . . . . . . . . . . . . . . . . . . . 339.2. Dimensión económica . . . . . . . . . . . . . . . . . . . . . . . . . . 34

9.2.1. Proyecto puesto en producción . . . . . . . . . . . . . . . . . 349.2.2. Vida útil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349.2.3. Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

9.3. Dimensión social . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359.3.1. Proyecto puesto en producción . . . . . . . . . . . . . . . . . 359.3.2. Vida útil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359.3.3. Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2

9.4. Dimensión ambiental . . . . . . . . . . . . . . . . . . . . . . . . . . 369.4.1. Proyecto puesto en producción . . . . . . . . . . . . . . . . . 369.4.2. Vida útil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369.4.3. Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

10.Especificación de requisitos 3710.1. Proceso de obtención . . . . . . . . . . . . . . . . . . . . . . . . . . 3710.2. Listado y clasificación . . . . . . . . . . . . . . . . . . . . . . . . . 38

10.2.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . 3810.2.1.1. De temática: acceso . . . . . . . . . . . . . . . . . 3810.2.1.2. De temática: perros . . . . . . . . . . . . . . . . . 3910.2.1.3. De temática: usuarios . . . . . . . . . . . . . . . . 4010.2.1.4. De temática: chat . . . . . . . . . . . . . . . . . . . 4110.2.1.5. De temática: informativa . . . . . . . . . . . . . . . 41

10.2.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . 42

11.Arquitectura del sistema 4311.1. Visión general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4311.2. Patrones implicados . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

11.2.1. Active Record . . . . . . . . . . . . . . . . . . . . . . . . . . 4411.2.2. Adaptador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4411.2.3. Modelo-Vista-Controlador (MVC) . . . . . . . . . . . . . . . 4511.2.4. Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

11.3. Esquema conceptual de la base de datos . . . . . . . . . . . . . . . 4611.4. Diseño de la interfaz gráfica . . . . . . . . . . . . . . . . . . . . . . 47

11.4.1. Consideraciones generales . . . . . . . . . . . . . . . . . . . 4711.4.1.1. Contraste . . . . . . . . . . . . . . . . . . . . . . . 4711.4.1.2. Navegación . . . . . . . . . . . . . . . . . . . . . . 47

11.4.2. Capturas de la aplicación . . . . . . . . . . . . . . . . . . . . 48

12.Desarrollo 5612.1. Recursos utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

12.1.1. Lenguajes de programación . . . . . . . . . . . . . . . . . . 5612.1.1.1. Ruby . . . . . . . . . . . . . . . . . . . . . . . . . 5612.1.1.2. Java . . . . . . . . . . . . . . . . . . . . . . . . . . 56

12.1.2. Tecnologías usadas . . . . . . . . . . . . . . . . . . . . . . . 5712.1.2.1. Android . . . . . . . . . . . . . . . . . . . . . . . . 5712.1.2.2. Ruby on Rails . . . . . . . . . . . . . . . . . . . . 5712.1.2.3. PostgreSQL . . . . . . . . . . . . . . . . . . . . . . 57

12.1.3. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . 5812.1.3.1. Android Studio . . . . . . . . . . . . . . . . . . . . 58

3

12.1.3.2. Visual Studio Code . . . . . . . . . . . . . . . . . . 5812.1.3.3. Overleaf . . . . . . . . . . . . . . . . . . . . . . . . 58

12.2. Implementación de las historias de usuario . . . . . . . . . . . . . . 5912.2.1. Instalación y configuración de herramientas . . . . . . . . . 5912.2.2. Inicio de sesión . . . . . . . . . . . . . . . . . . . . . . . . . 60

12.2.2.1. Planteamiento . . . . . . . . . . . . . . . . . . . . 6012.2.2.2. Inicio de sesión con Google . . . . . . . . . . . . . 6212.2.2.3. Inicio de sesión con Twitter . . . . . . . . . . . . . 6312.2.2.4. Inicio de sesión con email . . . . . . . . . . . . . . 64

12.2.3. Registro de usuario . . . . . . . . . . . . . . . . . . . . . . . 6412.2.4. Reseteo de contraseña . . . . . . . . . . . . . . . . . . . . . 6512.2.5. Subida de imágenes . . . . . . . . . . . . . . . . . . . . . . . 6612.2.6. Listar perros cercanos . . . . . . . . . . . . . . . . . . . . . 6712.2.7. Chatear con otro usuario . . . . . . . . . . . . . . . . . . . . 6812.2.8. Añadir perro . . . . . . . . . . . . . . . . . . . . . . . . . . 6912.2.9. Ver ubicación en mapa . . . . . . . . . . . . . . . . . . . . . 6912.2.10.Ver leyes y regulaciones . . . . . . . . . . . . . . . . . . . . 7012.2.11.Ver/establecer calendario de disponibilidad . . . . . . . . . . 7112.2.12.Listar parques y fuentes de agua cercanas . . . . . . . . . . 71

12.3. Seeding de la base de datos . . . . . . . . . . . . . . . . . . . . . . 72

13.Pruebas 7413.1. Pruebas del backend . . . . . . . . . . . . . . . . . . . . . . . . . . 74

13.1.1. Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7413.1.2. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

13.2. Pruebas del frontend . . . . . . . . . . . . . . . . . . . . . . . . . . 7613.2.1. Monkey testing . . . . . . . . . . . . . . . . . . . . . . . . . 7613.2.2. Pruebas con usuarios reales . . . . . . . . . . . . . . . . . . 76

14.Planificación final y desviaciones 77

15.Conclusiones 7815.1. Satisfacción de los objetivos iniciales . . . . . . . . . . . . . . . . . 7815.2. Satisfacción de las competencias técnicas . . . . . . . . . . . . . . . 79

15.2.1. CES1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7915.2.2. CES1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7915.2.3. CES1.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8015.2.4. CES1.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8015.2.5. CES2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

15.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4

Anexo A. Entrevistas a protectoras 82A.1. SOS Animales de Balanegra . . . . . . . . . . . . . . . . . . . . . . 82A.2. Refugio de perros abandonados Bú Bup Parc . . . . . . . . . . . . . 86A.3. Sociedad Protectora de Animales y Plantas de Madrid . . . . . . . 89

Anexo B. Diagrama de Gantt 91

Anexo C. Diagrama de Gantt final 92

Referencias 93

5

Índice de tablas

1. Comparativa de aplicaciones . . . . . . . . . . . . . . . . . . . . . . 152. Horario de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 213. Fases del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214. Planificación a nivel de tarea . . . . . . . . . . . . . . . . . . . . . . 275. Presupuesto en Recursos Humanos . . . . . . . . . . . . . . . . . . 286. Presupuesto por actividades . . . . . . . . . . . . . . . . . . . . . . 297. Presupuesto en Hardware . . . . . . . . . . . . . . . . . . . . . . . 308. Presupuesto en Software . . . . . . . . . . . . . . . . . . . . . . . . 309. Otros costes indirectos . . . . . . . . . . . . . . . . . . . . . . . . . 3110. Presupuesto total . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3211. Resultados del análisis de contraste . . . . . . . . . . . . . . . . . . 4712. Distribución de las pruebas de los modelos . . . . . . . . . . . . . . 7413. Distribución de las pruebas de los endpoints . . . . . . . . . . . . . 7514. Diferencias en la planificación . . . . . . . . . . . . . . . . . . . . . 77

Índice de figuras

1. Visión general del sistema . . . . . . . . . . . . . . . . . . . . . . . 432. Diseño de la base de datos . . . . . . . . . . . . . . . . . . . . . . . 463. Capturas de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . 4811. Logo de Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5612. Logo de Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5613. Logo de Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5714. Logo de Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . . . 5715. Logo de PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . 5716. Logo de Android Studio . . . . . . . . . . . . . . . . . . . . . . . . 5817. Logo de Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . 5818. Logo de Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5819. Diagrama de secuencia de OAuth2 . . . . . . . . . . . . . . . . . . 6120. Diagrama de secuencia del inicio de sesión con Google . . . . . . . . 6221. Diagrama de secuencia del inicio de sesión con Twitter . . . . . . . 6322. Diagrama de secuencia de la subida de imágenes a Cloudinary . . . 6623. Diagrama de secuencia de la visualización de un archivo pdf externo 7024. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . 9125. Diagrama de Gantt final . . . . . . . . . . . . . . . . . . . . . . . . 92

6

1. Contexto

Tener a un perro conlleva una gran responsabilidad: durante miles de años el serhumano ha convivido simbióticamente con estos animales, inicialmente usándoloscomo herramientas (caza, guardia, ganadería, etc.), y finalmente, aun conservandolos propósitos iniciales, se han convertido en miembros indispensables de nuestrasfamilias que saben brindarnos compañía, soporte emocional, bienestar (1) y amorincondicional a sus integrantes.

Desgraciadamente, debido a nuestro estilo de vida contemporáneo, no siemprepodemos darles todo el tiempo que desearíamos para sus paseos, ya que las intensasjornadas laborales de nuestro día a día limitan nuestros, ya de por sí, restrictivoshorarios. El poco tiempo libre que solemos tener lo solemos a dedicar a tareasdel hogar básicas, como por ejemplo: cocinar, hacer la colada, limpiar, entre otrasmuchas. Además, según un estudio telefónico sueco del 2015 (2) (que no se puedeextrapolar directamente a España, pero que nos da una buena referencia), en lamayoría de ocasiones, los propietarios nos vemos mayoritariamente obligados adejar nuestra mascota en casa (73%), o bien llevárnosla al trabajo (16%) y soloel (11%) se plantea darles algún tipo de servicio de cuidado a los canes durante eltiempo que permanecemos sin poder atenderles en nuestro trabajo.

Por otro lado, tenemos a otro grupos de personas, las que afrontan regularmenteproblemas en el cuidado de sus animales domésticos: por ejemplo, la gente mayorque no está en suficiente condición física como para llevar a sus perros (en muchossitios urbanos se está imponiendo el uso de correas en abundantes zonas de lavía pública (3)) y las personas que tienen alguna discapacidad física (lesiones,minusvalías...) y consiguientemente tienen, probablemente, algún tipo de perroguía que les es imprescindible tener, pero difícil cuidar por sí mismos debido a lanaturaleza de su afección.

Adicionalmente, nos encontramos con el grupo de gente que, si bien desearía tenerun perro, no les es posible principalmente por alguno de estos motivos:

No pueden afrontar los gastos económicos de su cuidado.Su lugar de residencia no permite la convivencia con animales.El miedo que les provocaría su pérdida les crea inseguridad.Algún miembro de su unidad familiar es alérgico.

Del grupo anterior distinguimos especialmente las personas que disponen de mu-cho tiempo libre, ya que serán más relevantes una vez hayamos definido toda lainformación necesaria para definir la formulación del problema.

7

2. Formulación del problema

Teniendo en mente toda la información que hemos planteado en la sección anterior,hemos decidido desarrollar una aplicación móvil que permita a los propietarios deperros mejorar la calidad de vida de sus mascotas aumentando sus paseos diarios, olo que es lo mismo, el tiempo que pueden ejercitarse y socializar: reduciendo así elestrés que les ocasiona estar solos en casa (4) durante muchas horas y satisfaciendolas necesidades básicas de los canes.

Así pues, los dueños añadirán sus mascotas en la aplicación para que el resto deusuarios pueda contactar con ellos y establecer una cita puntual para un paseo enun horario que sea, en primer lugar, beneficioso para el dueño (por ejemplo, enhoras extremo en el caso de los dueños que tienen jornadas laborales estrictas oen horas libres del dueño en que no precise del animal en caso de personas condiscapacidad) compatible entre los dos o definirse ya un horario regular para paseoscon esa mascota, según convenga la situación.

Pero nuestra aplicación irá más allá de lo que buscan aplicaciones similares (véaseestado del arte): los usuarios que vayan a pasear a las mascotas, lo harán de formaaltruista y no lucrativa, tomándoselo como un hobby más que como un trabajo porhoras, de esta manera conseguimos dos cosas muy importantes para los propietariosy la calidad de la aplicación:

1. Los paseadores serán personas legítimamente interesadas en el bienestar delos perros, es decir, no serán individuos que solo buscan lucrarse.

2. Al ser una actividad no remunerada, abre las puertas a las protectoras deanimales para la inclusión de sus perros, dándoles soporte y ayuda.

De esta manera, conseguiremos mejorar la calidad de vida de los canes (tanto losque viven en una unidad doméstica, como los que viven en protectoras) y disminuirla preocupación de sus propietarios, hacer que las personas que no puedan teneruno puedan disfrutar de su compañía y beneficiarse de todos los aspectos positivosde los paseos con el animal (5), ayudar a la gente que quiere adquirir uno a empezara entender las responsabilidades que conlleva la posesión de una mascota, reducirla carga de trabajo que realizan los voluntarios en las protectoras y aumentar lacantidad de adopciones en éstas (6), debido al establecimiento de lazos emocionalesentre los paseadores y los animales, que socializan más.

Para ver que, efectivamente, hay una problemática real, podéis consultar las tresentrevistas con protectoras del anexo A. En definitiva, mediante el desarrollo ypuesta en funcionamiento de nuestra app, conseguiríamos solucionar problemas dedueños de perros y satisfacer a las otras personas que hemos estado mencionando.

8

3. Stakeholders

El proyecto conlleva ciertos actores implicados, los cuales serán citados a conti-nuación. Hemos considerado el orden de las secciones (primero la formulación delproblema y ahora stakeholders) para que podáis comprender la aparición de nuevosactores implicados (protectoras y responsables de éstas).

3.1. Propietarios de perros

Estas personas son las que están interesadas en publicar los perfiles de sus canesen la aplicación para que sean visibles a los demás usuarios de la misma, se puedenhacer distinción entre los siguientes tipos de dueños:

3.1.1. Personas con vidas laborales restrictivas

Personas que ya sea debido a la naturaleza de su trabajo, incompatibilidades dehorarios o políticas de empresa, no son capaces de hacer compañía a su mascotay se ven obligados a dejarla sola en casa: lo cual les genera angustia y sienten queno pueden dedicarle tanto tiempo a su mascota como quisieran.

3.1.2. Personas con discapacidades o lesiones

Personas con algún tipo de imposibilidad física, que sienten que no puede darle asu mascota el tiempo de paseo que se merece, por ejemplo, en caso de tener unalesión, les resultaría muy difícil o imposible darles un buen paseo, en el caso deminusvalía con silla de ruedas no motorizada, puede ser que el uso extensivo delos brazos para desplazamiento sea muy agotador.

3.1.3. Personas mayores

Personas que, debido a la edad, no tienen la capacidad física o sienten inseguridadsobre el control de su mascota: es probable que en la zona en la que vivan sehaya declarado obligatorio el uso de correas y por tamaño o peso del animal no sesientan capaces, por ejemplo, de sostenerlos sin caerse al suelo.

9

3.2. Paseadores de perros

Estas personas son las que quieren pasear los perros de la aplicación, se puedenclasificar de forma genérica en las siguientes categorías o grupos:

3.2.1. Personas con tiempo libre

Personas que disponen de mucho tiempo libre (por ejemplo, jubilados, gente enel paro, estudiantes...) y se plantean pasear perros como hobby o para hacer sushabituales paseos más divertidos: es posible que, por algún motivo en concreto, nopuedan tener uno o simplemente no deseen adquirir.

3.2.2. Personas que se plantean adquirir un can

Personas que están evaluando la idea de adquirir un can, es posible que no hayantenido uno durante su vida o que no haya estado únicamente en su cuidado, me-diante la compañía en los paseos podrán hacerse una idea básica de los cuidadosque necesita, con que se tiene que ir con cuidado, etc.

3.3. Protectoras de animales

Son las asociaciones compuestas habitualmente de voluntarios que mantienen aanimales (abandonados o de la calle) y se dedican a proporcionarles una vidaadecuada y a intentar encontrarles una familia para que sean felices y sociablesotra vez: estarían interesadas en el proyecto ya que se mejoraría la calidad devida de los animales y la cantidad de adopciones realizadas. Además, las personasencargadas harían el rol de intermediarios entre la entidad protectora de animalesy la aplicación, publicando todos los perfiles de perros que se encuentren en laprotectora, así como de actualizarlos o eliminarlos según requiera la situación.

3.4. Desarrollador del proyecto

Este proyecto solo tiene un desarrollador, yo mismo: el planteamiento y la rea-lización de éste me darán experiencia sobre proyectos y además me permitirádemostrar mis conocimientos para obtener el título del grado.

10

3.5. Directora del proyecto

Es la principal responsable de guiar, aconsejar y orientar al desarrollador: su papeles clave para saber si el proyecto está bien encaminado y si se está haciendo como sehabía planteado inicialmente y con la calidad adecuada. En particular, la directoradel proyecto es María José Casany Guerrero, del departamento de Ingeniería deServicios y Sistemas de Información.

11

4. Estado del arte

4.1. Preámbulo

En esta sección destacaremos, en primer lugar, las necesidades de los canes, yen segundo lugar, pero no menos importante, buscaremos aplicaciones similaresa la que tenemos en mente para nuestro proyecto, de esta manera conseguimosencontrar posibles mejoras o soluciones que luego podemos incorporar a nuestraaplicación para poder desarrollar un servicio más innovador: mencionaremos losaspectos más importantes de cada una y los procesos que siguen los usuarios cuandoparticipan, finalmente mostraremos en que difiere nuestra app de las demás.

4.2. Necesidades físicas y psicológicas de los perros

4.2.1. Compañía

En el caso de perros residentes en protectoras o perreras, se ha observado unareducción de los niveles de cortisol (una hormona que se libera como respuesta alestrés) durante sesiones de tiempo con interacción humana (7).

En el caso de perros con dueño, es decir, la situación contraria a la que acabamosde mencionar, es obvio que la calidad de vida de los perros domésticos es superiorrespecto a los de las protectoras o perreras.

Los paseos que ofrece nuestra aplicación serían una buena manera para, específi-camente, ayudar a reducir los niveles de cortisol de los perros sin dueño.

4.2.2. Socialización

Para que los perros puedan tener ciertas habilidades sociales, las asociaciones deanimales recomiendan que durante el periodo de socialización de los cachorros(que comienza los 3 meses de vida y termina sobre los 12 a 14 meses), haya ciertainteracción social con personas, animales, objetos y lugares (8).

Una socialización mal estimulada puede causar que los perros adultos tengan pro-blemas de comportamiento, como por ejemplo: miedo y agresiones. Especialmenteel hecho de que no haya socialización con grupos concretos (como otros canes)puede volver al animal incapaz de establecer lazos sociales fuertes con éstos (8).

12

4.2.3. Ejercicio físico

La actividad física de un perro es un factor muy relevante para su salud, éstos sonanimales muy activos que requieren gastar la energía que obtienen de su alimen-tación y, por tanto, un declive de su ejercicio físico conllevará un aumento de pesoconsiderable en el animal.

Se ha demostrado que los perros con un peso saludable tienen, en general, mejorcalidad de vida (basada en un indicador llamado Health Related Quality of Life,o HRQOL) que los perros con sobrepeso u obesidad (9). Además, también hayevidencia empírica que demuestra que la calidad de vida del animal (medida conel mismo indicador que hemos mencionado) con sobrepeso u obesidad aumenta enel caso de que se consiga una pérdida de este exceso de peso (10).

Los paseos que ofrece nuestra aplicación favorecerían la pérdida de peso de loscanes, por tanto, provocarían el beneficio que hemos resaltado.

4.3. Aplicaciones similares

De cara a comparar las aplicaciones similares a la nuestra, hemos hecho una bús-queda exhaustiva para exponer las más relevantes para nuestro proyecto.

4.3.1. Dogbuddy

Dogbuddy es una aplicación que sirve tres necesidades principales: paseo de perros,guardería de día y alojamiento durante vacaciones. Los usuarios pueden registrarsecomo dueños de perros o como canguros (que es una extensión de dueño de perro).En caso de efectuar el registro como dueño de perro, hay que añadir el perro(o perros) y rellenar su perfil con fotos, la raza, edad, género, peso aproximado,si está vacunado, si está castrado, a que horas come, a que ordenes responde y,adicionalmente, se pueden incluir más características como por ejemplo: si tiramucho de la correa, si ladra mucho, si escarba, si salta sobre la gente, se lleva biencon los niños, si tiene microchip o placa identificativa, etc. En caso de registrarsecomo canguro, es necesario rellenar un test de conocimientos para entender comofunciona la app y rellenar tu perfil con elementos básicos, como una descripción,unas cuantas fotos, las tarifas que se cobran, preferencias sobre el peso o género delos animales a pasear, etc. Después de eso hay que validar información de pago parapoder recibir el dinero de los paseos. Se puede evaluar a los paseadores después.

13

4.3.2. PaseaPerros.com

PaseaPerros.com es una aplicación web que permite a sus visitantes buscar trestipos de servicios: paseo de perros, guardería de día y alojamiento durante va-caciones. Los usuarios pueden registrarse como dueños o canguros (el registro dedueño solo sirve para contactar con los canguros, ya que la aplicación no contemplaperfiles de perros ni información acerca de ellos): el registro de canguros implicaindicar que tipo de servicios se quiere ofrecer, entregar datos personales como vie-ne a ser el DNI, número de teléfono, nombre y apellidos, etc. También hay quesubir una foto, una presentación personal, cuanta experiencia con perros tienes, elnúmero máximo de perros que puedes llevar, junto con los pesos de perro que pue-des manejar, la disponibilidad horaria que tienes en formato mañana/tarde/nochey la tarifa que aplicas para los paseos (sobre la que la página añade un 20% decomisión). Cuando se acaba el registro del perfil, hay que esperar 7 días para quese valide y entonces ya se puede publicar un anuncio para ser canguro.

4.3.3. Iamvo

Iamvo es una aplicación que provee los habituales tres servicios: paseo de perros,guardería de día y alojamiento durante vacaciones. Aunque tenga un público bas-tante reducido, provee una idea muy interesante que no se plantea en las otrasapps, se trata del concepto de compartir tu mascota de forma gratuita: un tipo demodelo social en que una persona puede cuidar de una mascota y a su vez, otrodía pueden cuidar de la suya, la app destaca la falta de cariño en las residenciascaninas y tiene como lema “Cuida de mi mascota cuando yo lo necesite, que yocuidaré de la tuya cuando tú lo necesites.”. Aunque no se haya podido evaluar suscaracterísticas de forma completa (presentaba errores en nuestra versión de An-droid), hemos decidido incluirla porque propone un modelo similar al que tenemosen mente para nuestro proyecto: se puede deducir que se puede hacer un perfilmuy básico de mascota y un chat con el que los canguros pueden contactar conlos dueños.

14

4.4. Conclusiones

Queremos enfocar el proyecto de nuestra aplicación de tal manera que sea tancompleta en cuestiones de perfiles como Dogbuddy, es decir, que se pueda espe-cificar el máximo de información sobre las mascotas, los paseadores y los dueños:en concreto, esto es beneficioso para los paseadores, ya que se sienten mucho másseguros paseando perros ajenos si conocen mínimamente el comportamiento y lascaracterísticas de la mascota. Adicionalmente, seguimos el mismo ideal de la appde Iamvo, ya que queremos que los servicios sean gratuitos: la principal diferenciay ventaja de nuestra app respecto a las demás es que, justamente, planteamos lainclusión de los perros de protectoras.

Nuestra aplicación pone como máxima prioridad el bienestar de los perros, quere-mos desacoplar los paseos de los canes del ánimo de lucro (que promueven el restode aplicaciones), para que los beneficiados de la aplicación sean los animales.

A continuación, adjuntamos la tabla 1, donde se comparan todas las aplicacionessimilares mencionadas anteriormente junto con la nuestra.

Aplicación

Mod

elogratuito

Inclusiónde

perros

sindu

eño

Perfil

depe

rrobá

sico

Perfil

depe

rroextend

ido

Perfil

depa

sead

orbá

sico

Perfil

depa

sead

orextend

ido

Program

aciónde

paseos

Segu

imientoGPSde

paseos

Valoraciónde

usua

rios

Cha

tentreusua

rios

Calenda

riode

dispon

ibilida

d

Sistem

ade

medallas

Con

sejosútiles

Regulacionesyleyes

Dogbuddy x x x x x x x x x x xPaseaPerros.com x x x x

Iamvo x x x x xWalkee x x x x x x x x x x x x x

Tabla 1: Comparativa de aplicaciones

15

5. Alcance

5.1. Objetivos

5.1.1. Objetivo del proyecto

El principal objetivo de este proyecto es el diseño e implementación de una aplica-ción de Android (junto con su respectivo backend) que permita, a grandes rasgos,registrar y pasear perros (junto con todas las historias de usuario relacionadas conesos conceptos, por ejemplo: perfiles, valoraciones, etc.).

5.1.2. Subobjetivos del proyecto

Como objetivos alternativos, tenemos funcionalidades como por ejemplo: que lospaseadores puedan encontrar parques y fuentes de agua potable con facilidad, quepuedan visualizar consejos útiles sobre los paseos, que puedan consultar aspectoslegales (como regulaciones y leyes) sobre los perros por la vía urbana, etc.

5.1.3. Objetivos sociales de la aplicación

Los objetivos sociales son los siguientes:

1. Mejorar la calidad de vida de los perros (de los que viven en viviendas y losque viven en las protectoras).

2. Disminuir la preocupación de los propietarios a la hora de dejar a sus mas-cotas solas.

3. Hacer que las personas que no puedan tener una disfruten de su compañía yse beneficien de los aspectos positivos de ella.

4. Ayudar a la gente que quiere adquirir una mascota a entender que responsa-bilidades conlleva.

5. Reducir la carga de trabajo de los voluntarios en protectoras (parte de lospaseos ahora serán realizados por los usuarios).

6. Aumentar la cantidad de adopciones en las protectoras.

16

5.1.4. Objetivos fuera del ámbito del proyecto

No consideraremos como objetivos, aunque algunas aplicaciones similares lo ofrez-can, tareas como pueden ser el alojamiento de mascotas durante las vacaciones(ya que consideramos que tampoco se debería fomentar la separación del perro ysu dueño) o seguimiento por GPS de los paseos: interpretamos esta funcionalidadcomo un indicador de trabajo de las apps donde los paseadores cobran dinero.

5.1.5. Posibles objetivos después del proyecto

Al finalizar el proyecto y según el éxito que pueda conseguir la app, se podríaplantear la posibilidad de añadir una página o blog que contase las experiencias delos usuarios de la aplicación y/o integrarlo con sistemas de protectoras y perreras.

5.2. Posibles obstáculos

5.2.1. Falta de recursos en las protectoras

Las protectoras de animales son asociaciones de voluntarios que se preocupanpor el bienestar de los animales, aun así, son entidades que disponen de recursoslimitados y eso podría provocar que, aunque estuvieran de acuerdo con las ideas delproyecto y les pareciese un buen método para aumentar las adopciones, no tuvieranel personal o tiempo suficiente como para estar constantemente revisando la apppara hablar con los paseadores y actualizándola con la información de los perros: sifinalmente la cantidad de protectoras en nuestra app fuese escasa, le haría perderla esencia del proyecto. De todas formas, creemos que si es una buena oportunidadpara ayudar a los animales, los voluntarios no dudarán en tratar de invertir másde tiempo o reorganizarse para que puedan llevar a cabo esa tarea tan importante.

5.2.2. Usabilidad en personas mayores

Dado que una parte de los usuarios de la aplicación sería gente mayor, es importan-te intentar diseñarla de tal manera que sea lo más usable posible para garantizarlesuna buena experiencia de usuario, si no conseguimos hacerla lo suficientemente in-tuitiva es posible que perdamos parte de este público y eso sería perjudicial paranuestro proyecto. Es necesario mencionar que, muchas veces, estas personas suelenpedir ayuda a familiares si no consiguen hacer alguna cosa, lo que acaba mitigandoy suavizando los efectos mencionados.

17

6. Metodología y rigor

Para llevar a cabo el proyecto, se usará una metodología ágil, aprovecharemos suuso para reforzar los conceptos de Agile aprendidos durante las asignaturas desoftware de la carrera, que seguramente nos serán muy útiles en entornos laboralesde carácter colaborativo, como suele ser habitual.

No obstante, al irnos informando sobre como aplicar metodologías ágiles, nos hemosencontrado con una problemática: la gran mayoría de metodologías ágiles estándiseñadas para ser utilizadas en grupo, hecho que nos genera ciertos obstáculos yconfusiones, ya que nuestro proyecto es implementado por un solo desarrollador.

Por este motivo, y para no modificar abruptamente metodologías como Scrum oKanban, hemos decidido buscar alguna solución concreta para nuestro proyecto,para no tener que diseñarla por nosotros mismos: se trata de una metodologíallamada Agile Solo, que explicaremos en el siguiente apartado.

6.1. Agile Solo

Agile Solo (11) es una metodología ágil diseñada para proyectos software de unsolo desarrollador, tiene origen en la tesis de máster de Anna Nyström. Esta meto-dología fue diseñada, no para reinventar la rueda, sino que para aplicar prácticasy filosofías que ya se aplican actualmente en el mundo, a entornos de un solodesarrollador.

En Agile Solo, el software se presenta semanalmente al supervisor, manager ocliente, en este momento, se actualizan las prioridades de las tareas para que lomás urgente se haga primero, adicionalmente, una versión funcional del softwarees entregada al cliente cada mes para recibir feedback directo de los usuarios.

Es muy importante tener un canal de comunicación para que el cliente puedaproporcionar sus ideas y opiniones, finalmente, hay que ser muy receptivos acercadel feedback del cliente, para que pueda tenerse en cuenta para las siguientesentregas.

Generalmente, la duración de las iteraciones de esta metodología es corta, y paranuestro caso concreto, cada iteración será de una semana.

Nosotros, en concreto, haremos uso de Pseudoagile Solo, ya que esta metodologíaimplica el uso de TDD, y nos hemos decantado por el uso de Unit Testing.

18

6.2. Método de trabajo

Las funcionalidades o historias de usuario se irán implementando de forma conjuntaen el backend y la aplicación móvil: de esta manera podremos comprobar que elbackend se integra correctamente con la app, evitándonos efectos indeseados enel transcurso del proyecto que puedan llegar a perjudicar nuestro rendimiento yplanificación. A la vez, la oportunidad de tener un producto tangible resultará útilpara recibir feedback adicional para la app.

A grandes rasgos, podemos dividir el proyecto en los siguientes procesos (queengloban varias iteraciones):

1. Gestión del proyecto.

2. Inicios de sesión.

3. Funcionalidades de perfiles.

4. Funcionalidades específicas (relacionadas con paseos).

5. Interacción con usuarios (chat, valoraciones).

6. Otras funcionalidades.

Considerando que queremos que las iteraciones duren una semana, habría un totalde 18 iteraciones en el proyecto, que de entrada parecen muchas, pero considerandoque solo hay un desarrollador y que estamos aplicando Agile Solo, tiene sentido.

6.3. Herramientas de seguimiento

Para llevar a cabo el control de versiones del proyecto usaremos GitLab (12) (yaque en algunos aspectos nos parece más flexible que otras plataformas que usanel sistema Git) y para el control del estado del proyecto utilizaremos Trello (13)(un software web para gestionar proyectos en tableros) que nos permitirá definirun espacio de trabajo adecuado para una metodología ágil junto con Clockify (14)(un software web para contar el tiempo dedicado en tareas).

6.4. Método de validación

Para efectuar las validaciones del proyecto, haremos uso de Unit Testing, que esuna práctica habitual en el testing de software, la cual, a grandes rasgos, consisteen escribir pequeñas funciones que comprueben que una parte de un programafuncione de la manera en que se espera que lo haga.

19

Esta práctica, aunque tome tiempo adicional de desarrollo, ayuda a prevenir com-portamientos y/o fallos indeseados en nuestro sistema que podrían causar unamala experiencia de usuario o incluso acarrear problemas de seguridad. Usaremosesta práctica de testing para el backend, de esta manera aseguraremos su correctofuncionamiento y facilitaremos la implementación de nuevas funcionalidades, asícomo la participación de otros desarrolladores en el proyecto en un posible futuro.En el frontend, aplicaremos validaciones mediante, en primer lugar, testeo manualde las funcionalidades, y en segundo lugar, con experimentos diseñados median-te escenarios reales en un grupo reducido de personas, por tal de saber si hanconseguido el objetivo o han tenido algún problema.

Además, durante el desarrollo del proyecto, se irán realizando reuniones de controlpara supervisar que la planificación va al ritmo esperado, y si no fuera el caso,tomar las decisiones oportunas.

20

7. Planificación temporal

7.1. Introducción

El proyecto tiene como fecha de inicio el 14 de agosto de 2018 y como fecha de finel 4 de enero de 2019, es decir, una duración aproximada de 4.5 meses.

Durante este periodo de tiempo, se ha decidido dedicarle al proyecto 24 horassemanales, las cuales han sido repartidas de la siguiente manera:

Día Lunes Martes Miércoles Jueves Viernes Sábado DomingoHoras 3 h 3 h 3 h 3 h 4 h 4 h 4 h

Tabla 2: Horario de trabajo

El motivo por el cual se han repartido de esta forma es porque nuestro horario delunes a jueves es más restrictivo que de viernes a domingo, de ahí que añadamos1 hora más en cada día de este último intervalo.

Finalmente, el cómputo total de trabajo asciende a la cantidad de 495.25 horas,que están repartidas así:

Fase del proyecto Horas dedicadasFamiliarización con las tecnologías implicadas 120 h

Gestión del proyecto 75.25 hDesarrollo del proyecto 288 h

Preparación de la defensa 12 hTotal 495.25 h

Tabla 3: Fases del proyecto

La fase de desarrollo del proyecto está dividida en tareas o historias de usuario:cada tarea incluye el tiempo de documentación asociado a esa funcionalidad, eltiempo de desarrollo de backend y frontend, el tiempo necesario para programarlos tests y el tiempo que gastemos en escribir los apartados de la memoria deltrabajo correspondientes.

Para una representación más visual de las tareas, se puede consultar el diagramade Gantt en la figura 24.

Para ver el desglose de tiempo por cada tarea, podéis consultar la tabla 4.

21

7.2. Valoración de las alternativas y plan de acción

7.2.1. Posibles desviaciones en el desarrollo

Hemos tenido en cuenta que en el desarrollo pueden surgir dos desviaciones:

La primera, es que la complejidad de la interfaz del frontend de la aplicación enAndroid nos acabe obligando a utilizar más tiempo (20 h de desarrollo app) en labúsqueda de documentación asociada, para poder completar algunas partes.

La segunda, que está relacionada con la primera, es que tengamos que mejorar lausabilidad de algunas partes de la aplicación para que a la gente mayor le sea másfácil de usar, lo cual implicaría cierto tiempo en rediseño (15 h de desarrollo app).

7.2.2. Implicaciones de las desviaciones

Las desviaciones que hemos mencionado afectarían a la fase de desarrollo del pro-yecto, concretamente a un cierto subconjunto de las historias de usuario, talesalteraciones afectarían al tiempo total del proyecto aumentando el tiempo emplea-do en el desarrollo de las funcionalidades y, por ende, afectando al cómputo totalde horas del proyecto.

En cuanto al gasto de recursos, no se vería demasiado afectado, el único cambiosignificativo que habría sería el gasto energético del equipamiento.

7.2.3. Posibles soluciones y/o alternativas

Para poder controlar y mitigar estas posibles desviaciones con antelación, hemosdecidido aplicar algunos criterios a la hora de planificar el Gantt, que nos ayudarána suavizar estas adversidades con la mayor facilidad posible.

(a) Sobreestimación de las historias de usuario: hemos sobreestimado unpoco el tiempo necesario para las historias de usuario, por si acaban surgiendoimprevistos que nos requieran utilizar más tiempo.

(b) Tiempo de familiarización con las tecnologías: hemos decidido invertirabundante tiempo antes del proyecto a estudiar las tecnologías que vamos ausar, para que el desarrollo sea lo más fluido posible.

(c) Margen de días: como último recurso, hemos planificado el proyecto de talforma que su fecha de fin sea el 4 de enero de 2019, de esta manera tendremosun margen de 2.5 semanas hasta la lectura.

22

7.3. Recursos

7.3.1. Recursos personales

Un solo desarrollador (backend y frontend) trabajando 24 h a la semana.

7.3.2. Recursos materiales

Recurso Tipo deherramienta Finalidad

Ordenador de sobremesa conprocesador i7 a 4 GHz, 16 GBde RAM y Windows 10 64 bits

Desarrollo Para poder ejecutar todo el softwarenecesario para realizar el proyecto

Servidor Linux con procesadorvirtual a 2.4 GHz, 2 GB deRAM y Ubuntu 16.04 64 bits

Desarrollo

Para poder desacoplar el backend denuestra aplicación del ordenador desobremesa y poder acceder desde la

app móvil consumiendo la API

Smartphone con Android 8.1 Desarrollo Para poder probar la app móvil desdeun dispositivo hardware real

Ruby 2.5.1 y Rails 5.2.1 Desarrollo Para ejecutar el backendAndroid Studio 3.2 Desarrollo Para poder desarrollar la app móvil

Visual Studio Code 1.25.1 Desarrollo Para poder desarrollar el backend

Overleaf (servicio web) Desarrollo Para poder redactar de forma online eldocumento del proyecto en LaTeX

Postman 6.3.0 Desarrollo Para poder probar algunas llamadas ala API del backend

LibreOffice Impress 6.0.3.2 Desarrollo Para poder hacer las diapositivas delas presentaciones

Foxit Reader 9.1 Desarrollo Para poder visualizar documentos pdf

GIMP 2.8.22 Desarrollo Para poder crear gráficos de la appmóvil

Inkscape 0.92.1 Desarrollo Para poder crear el logo y los iconosde la app móvil

Gitlab (servicio web) (y Git) ControlPara poder llevar un control de

versiones de los códigos de nuestrobackend y frontend

Targetprocess (servicio web) Gestión Para poder tener un backlog de tareascon las que ir trabajando

Celoxis (servicio web) Gestión Para poder diseñar el diagrama deGantt de la planificación

Mailbird 2.5.19.0 ComunicaciónPara poder comunicarse con la

directora del proyecto y el profesor degestión de proyectos

23

7.4. Descripción de las tareas

7.4.1. Introducción

Las tareas de la tabla 4 se han ordenado cronológicamente según el transcurso delproyecto (es decir, empezamos por ejemplo con el inicio de sesión en la app).

La planificación de horas del desarrollo del proyecto se ha hecho con granularidadde horas, ya que en este caso estamos trabajando con historias de usuario: notendría demasiado sentido trabajar con días debido a que no es una buena unidadde tiempo para entidades funcionales tan discretas.

Finalmente, en cuanto a las dependencias de precedencia, empiezan por las másobvias: completar los contenidos de las entregas de la gestión del proyecto antes desus respectivas fechas. A continuación, tenemos precedencias asociadas al registrode usuario (no podemos desarrollar funcionalidades como resetear contraseña o verun perfil de usuario sin que hayamos completado la del registro), seguidamente,encontramos que para ver el calendario de disponibilidad de un usuario se tieneque haber implementado la de establecer el calendario y, finalmente, para ver lasvaloraciones de un usuario tenemos que haber programado la funcionalidad devalorar un usuario previamente.

7.4.2. Descripciones

1. Familiarizarse con Ruby/Rails: El desarrollador de backend reunirá losconocimientos necesarios para trabajar con Ruby/Rails.

2. Familiarizarse con Android: El desarrollador de apps móviles reunirá losconocimientos necesarios para trabajar con Android.

3. Alcance y contextualización: El gestor del proyecto redactará toda ladocumentación sobre el alcance y la contextualización del proyecto.

4. Planificación temporal: El gestor del proyecto redactará toda la docu-mentación sobre la planificación temporal del proyecto.

5. Gestión económica y sostenibilidad: El gestor del proyecto redactarátoda la documentación sobre la gestión económica y sostenibilidad del pro-yecto.

6. Pliego de condiciones, presentación oral y documento final: El gestordel proyecto recopilará toda la documentación entregada en un documentofinal, redactará el pliego de condiciones y preparará la presentación oral.

24

7. Preparación de repositorios: Los desarrolladores y el tester prepararánlos repositorios de frontend y backend del proyecto.

8. Instalación y config. de herramientas: Los desarrolladores y el testerinstalarán y configurarán todas las herramientas que vayan a usar.

9. Registro de usuario: Los usuarios podrán añadir una cuenta al sistema dela aplicación.

10. Login con Email: Los usuarios podrán hacer login mediante email a laaplicación.

11. Login con Google: Los usuarios podrán hacer login mediante Google a laaplicación.

12. Reunión de control #1: Se llevará el primer control del estado del pro-yecto.

13. Login con Twitter: Los usuarios podrán hacer login mediante Twitter a laaplicación.

14. Resetear contraseña: Los usuarios podrán resetear su contraseña de acceso(si se han registrado a través de un correo).

15. Ver perfil de perro: Los usuarios podrán ver la información asociado a unperro en concreto.

16. Listar perros cercanos: Los usuarios podrán ver una lista de perros queestén, geográficamente ubicados, cerca de ellos.

17. Reunión de control #2: Se llevará el segundo control del estado del pro-yecto.

18. Ver perfil de usuario: Los usuarios podrán ver la información de su perfilo la de otro usuario.

19. Listar parques y fuentes de agua cercanos: Los usuarios podrán veruna lista de parques y fuentes de agua públicas que estén, geográficamenteubicadas, cerca de ellos.

20. Establecer calendario de disponibilidad: Los usuarios podrán establecersu disponibilidad horaria semanal.

21. Reunión de control #3: Se llevará el tercer control del estado del proyecto.

22. Ver calendario de disponibilidad: Los usuarios podrán ver su disponibi-lidad horaria semanal o la de otro usuario.

25

23. Programar un paseo: Los usuarios podrán programar paseos, previamentehabiéndose acordado con otro usuario.

24. Chatear con otro usuario: Los usuarios podrán conversar entre sí me-diante un chat.

25. Reunión de control #4: Se llevará el cuarto control del estado del pro-yecto.

26. Valorar usuario: Los usuarios podrán valorar al paseador después de unpaseo.

27. Ver valoraciones de usuario: Los usuarios podrán ver las valoracionesque les hayan hecho o las que les tenga otro usuario.

28. Integrar sistema de medallas: Los usuarios recibirán premios por lospaseos, siguiendo un estilo de gamificación.

29. Visualizar consejos útiles de paseos: Los usuarios podrán ver consejosútiles para sus paseos.

30. Visualizar regulaciones y leyes de perros por la calle: Los usuariospodrán ver los aspectos legales relacionados con el paseo de los perros.

31. Última reunión de control #5: Se llevará el quinto y último control delestado del proyecto.

32. Preparación de la defensa: El gestor preparará el proyecto de cara apresentarlo al público y en frente de un tribunal.

26

# TareaTiempoestimado

(h)

Dependenciastemporales

1 Familiarizarse con Ruby/Rails 60 h2 Familiarizarse con Android 60 h3 Alcance y contextualización 30 h4 Planificación temporal 10 h5 Gestión económica y sostenibilidad 12 h

6 Pliego de condiciones, presentaciónoral y documento final 22 h

7 Preparación de repositorios 4 h8 Instalación y config. de herramientas 12 h9 Registro de usuario 12 h10 Login con Email 12 h11 Login con Google 12 h12 Reunión de control #1 0.25 h14 Login con Twitter 12 h15 Resetear contraseña 8 h 916 Ver perfil de perro 20 h17 Listar perros cercanos 22 h 1618 Reunión de control #2 0.25 h19 Ver perfil de usuario 10 h 9

20 Listar parques y fuentes de aguacercanos 30 h

21 Establecer calendario dedisponibilidad 12 h

22 Reunión de control #3 0.25 h23 Ver calendario de disponibilidad 8 h 2124 Programar un paseo 24 h25 Chatear con otro usuario 30 h26 Reunión de control #4 0.25 h27 Valorar usuario 16 h28 Ver valoraciones de usuario 8 h 2729 Integrar sistema de medallas 16 h30 Visualizar consejos útiles de paseos 8 h

31 Visualizar regulaciones y leyes deperros por la calle 12 h

32 Última reunión de control #5 0.25 h33 Preparación de la defensa 12 h

Total 495.25 h

Tabla 4: Planificación a nivel de tarea

27

8. Gestión económica

8.1. Presupuesto

A lo largo del desarrollo del proyecto, utilizaremos los recursos que hemos mencio-nado anteriormente: su uso conllevará ciertos costes para el proyecto.

En este apartado estimaremos los costes asociados al proyecto, para ello tenemosque tener en mente los costes en recursos humanos, hardware y software (ademásde sus respectivas amortizaciones) junto con el resto de los costes indirectos.

8.1.1. Presupuesto en Recursos Humanos

A raíz de que el proyecto está desarrollado solo por una persona, ésta se encargaráde interpretar los cuatro roles necesarios para su correcta puesta en marcha. Latabla 5 (adjuntada a continuación) nos indica las estimaciones de los costes porcada rol ejercido en el transcurso de todo nuestro proyecto. Hemos decidido que el25% del tiempo de la fase de desarrollo corresponde a testeo.

Rol Horas e/h CosteGestor de proyecto (GP) 87.25 h 20 e/h 1745 eDesarrollador web (DW) 168 h 13 e/h 2184 e

Desarrollador de aplicaciones móviles (DA) 168 h 17 e/h 2856 eTester de software (TE) 72 h 13 e/h 936 e

Total 495.25 h 7721 e

Tabla 5: Presupuesto en Recursos Humanos

El cálculo del precio por hora se ha computado para el territorio español con datosdel año 2017, dividiendo el salario anual medio (bruto) de cada empleo en el país(15) entre la media de horas trabajadas por habitante de éste (16).

Para tener una mejor idea de como se distribuyen todos los costes entre las tareasde la planificación, hemos decidido incluir la tabla 6: donde se muestra el desglosede los costes de todas las actividades del proyecto (utilizando de referencia el costepor hora de la tabla 5). Nótese que hemos abreviado los nombre de los roles parasimplificar la lectura de las filas de la tabla.

28

# Tarea Rol Horas Precio/hora Coste1 Familiarizarse con Ruby/Rails DW 60 h 13 e/h 780 e2 Familiarizarse con Android DA 60 h 17 e/h 1020 e3 Alcance y contextualización GP 30 h 20 e/h 600 e4 Planificación temporal GP 10 h 20 e/h 200 e5 Gestión económica y sostenibilidad GP 12 h 20 e/h 240 e6 Pliego de condiciones, presentación oral y documento final GP 22 h 20 e/h 440 e7a Preparación de repositorios DW 1.5 h 13 e/h 19.5 e7b Preparación de repositorios DA 1.5 h 17 e/h 25.5 e7c Preparación de repositorios TE 1 h 13 e/h 13 e8a Instalación y configuración de herramientas DW 4.5 h 13 e/h 58.5 e8b Instalación y configuración de herramientas DA 4.5 h 17 e/h 76.5 e8c Instalación y configuración de herramientas TE 3 h 13 e/h 39 e9a Registro de usuario DW 4.5 h 13 e/h 58.5 e9b Registro de usuario DA 4.5 h 17 e/h 76.5 e9c Registro de usuario TE 3 h 13 e/h 39 e10a Login con Email DW 4.5 h 13 e/h 58.5 e10b Login con Email DA 4.5 h 17 e/h 76.5 e10c Login con Email TE 3 h 13 e/h 39 e11a Login con Google DW 4.5 h 13 e/h 58.5 e11b Login con Google DA 4.5 h 17 e/h 76.5 e11c Login con Google TE 3 h 13 e/h 39 e12 Reunión de control #1 GP 0.25 h 20 e/h 5 e13a Login con Twitter DW 4.5 h 13 e/h 58.5 e13b Login con Twitter DA 4.5 h 17 e/h 76.5 e13c Login con Twitter TE 3 h 13 e/h 39 e14a Resetear contraseña DW 3 h 13 e/h 39 e14b Resetear contraseña DA 3 h 17 e/h 51 e14c Resetear contraseña TE 2 h 13 e/h 26 e15a Ver perfil de perro DW 7.5 h 13 e/h 97.5 e15b Ver perfil de perro DA 7.5 h 17 e/h 127.5 e15c Ver perfil de perro TE 5 h 13 e/h 65 e16a Listar perros cercanos DW 8.25 h 13 e/h 107.25 e16b Listar perros cercanos DA 8.25 h 17 e/h 140.25 e16c Listar perros cercanos TE 5.5 h 13 e/h 71.5 e17 Reunión de control #2 GP 0.25 h 20 e/h 5 e18a Ver perfil de usuario DW 3.75 h 13 e/h 48.75 e18b Ver perfil de usuario DA 3.75 h 17 e/h 63.75 e18c Ver perfil de usuario TE 2.5 h 13 e/h 32.5 e19a Listar parques y fuentes de agua cercanos DW 11.25 h 13 e/h 146.25 e19b Listar parques y fuentes de agua cercanos DA 11.25 h 17 e/h 191.25 e19c Listar parques y fuentes de agua cercano TE 7.5 h 13 e/h 97.5 e20a Establecer calendario de disponibilidad DW 4.5 h 13 e/h 58.5 e20b Establecer calendario de disponibilidad DA 4.5 h 17 e/h 76.5 e20c Establecer calendario de disponibilidad TE 3 h 13 e/h 39 e21 Reunión de control #3 GP 0.25 h 20 e/h 5 e22a Ver calendario de disponibilidad DW 3 h 13 e/h 39 e22b Ver calendario de disponibilidad DA 3 h 17 e/h 51 e22c Ver calendario de disponibilidad TE 2 h 13 e/h 26 e23a Programar un paseo DW 9 h 13 e/h 117 e23b Programar un paseo DA 9 h 17 e/h 153 e23c Programar un paseo TE 6 h 13 e/h 78 e24a Chatear con otro usuario DW 11.25 h 13 e/h 146.25 e24b Chatear con otro usuario DA 11.25 h 17 e/h 191.25 e24c Chatear con otro usuario TE 7.5 h 13 e/h 97.5 e25 Reunión de control #4 GP 0.25 h 20 e/h 5 e26a Valorar usuario DW 6 h 13 e/h 78 e26b Valorar usuario DA 6 h 17 e/h 102 e26c Valorar usuario TE 4 h 13 e/h 52 e27a Ver valoraciones de usuario DW 3 h 13 e/h 39 e27b Ver valoraciones de usuario DA 3 h 17 e/h 51 e27c Ver valoraciones de usuario TE 2 h 13 e/h 26 e28a Integrar sistema de medallas DW 6 h 13 e/h 78 e28b Integrar sistema de medallas DA 6 h 17 e/h 102 e28c Integrar sistema de medallas TE 4 h 13 e/h 52 e30a Visualizar consejos útiles de paseos DW 3 h 13 e/h 39 e30b Visualizar consejos útiles de paseos DA 3 h 17 e/h 51 e30c Visualizar consejos útiles de paseos TE 2 h 13 e/h 26 e31a Visualizar regulaciones y leyes de perros por la calle DW 4.5 h 13 e/h 58.5 e31b Visualizar regulaciones y leyes de perros por la calle DA 4.5 h 17 e/h 76.5 e31c Visualizar regulaciones y leyes de perros por la calle TE 3 h 13 e/h 39 e32 Última reunión de control #5 GP 0.25 h 20 e/h 5 e33 Preparación de la defensa GP 12 h 20 e/h 240 e

Total 495.25 h 7721 e

Tabla 6: Presupuesto por actividades

29

8.1.2. Costes indirectos

8.1.2.1 Presupuesto en Hardware

La tabla 7 nos indica el presupuesto en hardware junto con sus respectivas amor-tizaciones: para el cálculo de la amortización, hemos asumido que los años tienen351 días laborables (recordemos que el sábado y domingo también trabajaremos)y que cada día se trabaja una media de 3.43 h. Para simplificar hemos consideradoque las horas de uso para el hardware equivalen a las de la duración del proyecto.

Producto Unidades Precio Vida útil AmortizaciónOrdenador de sobremesa 1 1500 e 4 años 140.63 eMonitor UltraWide 29" 1 220 e 6 años 13.75 e

Smartphone con Android 8.1 1 250 e 3 años 31.25 eTotal 1970 e ≈ 186 e

Tabla 7: Presupuesto en Hardware

8.1.2.2 Presupuesto en Software

La tabla 8 nos muestra el presupuesto en software junto con sus respectivas amor-tizaciones (hemos utilizado los mismos criterios que en el apartado anterior).

Producto Unidades Precio Vida útil AmortizaciónWindows 10 Pro N 1 259 e 3 años 32.38 eUbuntu 16.04 LTS 1 0 e 3 años 0 e

Ruby 2.5.1 y Rails 5.2.1 1 0 e 3 años 0 eAndroid Studio 3.2 1 0 e 3 años 0 e

Visual Studio Code 1.25.1 1 0 e 3 años 0 eOverleaf (servicio web) 1 0 e 3 años 0 e

Postman 6.3.0 1 0 e 3 años 0 eLibreOffice Impress 6.0.3.2 1 0 e 3 años 0 e

Foxit Reader 9.1 1 0 e 3 años 0 eGIMP 2.8.22 1 0 e 3 años 0 e

Inkscape 0.92.1 1 0 e 3 años 0 eGitlab (servicio web) (y Git) 1 0 e 3 años 0 e

Trello (servicio web) 1 0 e 3 años 0 eClockify (servicio web) 1 0 e 3 años 0 e

Mailbird 2.5.19.0 1 0 e 3 años 0 eTotal 259 e ≈ 32 e

Tabla 8: Presupuesto en Software

30

8.1.2.3 Otros costes indirectos

La tabla 9 estima el resto de costes indirectos (no encajan en las otras categorías).

Producto Unidades Precio Precio estimadoServidor Web 5 meses 3.63 e/mes 18.15 eElectricidad 197.6 kWh 0.125 e/kWh 24.70 e

Impresión de la memoria 6 uds. 4.5 e/ud 27 eAcceso a Internet 5 meses 30 e/mes 150 e

Total ≈ 220 e

Tabla 9: Otros costes indirectos

8.1.3. Plan de contingencia

A la hora de estimar el coste del proyecto, es necesario contar con cierto margenpara las incertezas: hemos decidido que, para cubrir cualquier imprevisto que puedasuceder durante el proyecto, destinaremos una partida de contingencia de 811e (aprox. el coste del 10% de la suma de los costes directos e indirectos). Hemosescogido que sea el 10% ya que creemos que el presupuesto está bien detallado.

8.1.4. Costes de imprevistos

Para poder amortiguar cualquier desviación en el proyecto, hay que reservar unacantidad de dinero proporcional a la probabilidad de que ocurran. En el caso denuestro proyecto podemos identificar dos fuentes de desviación:

1. Que la complejidad de la interfaz de la app nos haga gastar más tiempo (prob.35%, coste de 340 e, 20 h adicionales del desarrollador de apps móviles).

2. Que necesitemos un rediseño de la app para mejorar la usabilidad (prob.10%, coste de 255 e, 15 h adicionales del desarrollador de apps móviles)

En el presupuesto total el proyecto tendremos que computar los costes asociadosteniendo en cuenta cada una de las probabilidades.

31

8.1.5. Presupuesto total

Adjuntamos a continuación la tabla 10 con el presupuesto final del proyecto.

Concepto Coste estimadoRecursos humanos (directos) 7721 eRecursos hardware (indirectos) 186 eRecursos software (indirectos) 32 e

Otros costes indirectos 220 eSubtotal 8159 e

Partida de contingencia (10% del subtotal) 816 eCoste del imprevisto 1 (prob. 35%) 119 eCoste del imprevisto 2 (prob. 10%) 26 e

Total 9120 e

Tabla 10: Presupuesto total

8.2. Control del presupuesto

Como suele ser natural en proyectos de esta naturaleza (y como habíamos mencio-nado), es posible que haya cambios respecto a la planificación que hemos descrito.

Por otro lado, en cuanto a los recursos hardware, difícilmente consideraremos laposibilidad de que necesitemos adquirir más (si hay algún fallo de hardware, lamisma garantía del producto debería cubrirlo), el único caso posible sería si qui-siéramos probar la aplicación en distintos soportes hardware, pero no vamos a serdemasiado exhaustivos en cuanto a compatibilidad absoluta con dispositivos.

Por otra parte, respecto a los recursos software, sí que es posible que nos veamoscon la obligación de trabajar con software que inicialmente no habíamos tenidoen cuenta: en ese caso, nuestro principal enfoque será buscar recursos de códigoabierto para no afectar al presupuesto. En caso de que nos viéramos obligados aadquirir software de pago, utilizaríamos fondos de la partida de imprevistos.

Adicionalmente, llegamos a la conclusión de que lo que más necesitamos controlarson los recursos humanos, si fuera el caso que necesitáramos invertir más horas enalguna tarea de algún rol, consumiríamos los fondos de la partida de contingenciapara pagar esas horas adicionales.

Finalmente, para poder llevar a cabo un control del presupuesto, tendremos quecomparar el trabajo realizado con el trabajo esperado por cada actividad, parapoder así, comparar y evaluar las desviaciones (específicamente, por cada conceptode coste y actividad). Calcularemos entonces, los siguientes indicadores: desvío encoste por tarifa, desvío en eficiencia y desvío en totales.

32

9. Sostenibilidad

9.1. Autovaluación de sostenibilidad

En un mundo cada vez más consciente de la importancia de la sostenibilidad, esvital ponerse a razonar sobre las implicaciones que participan de forma directa eindirecta en nuestros proyectos.

Desde mi punto de vista, ahora, a diferencia de hace unos años, la viabilidad deun proyecto es puesta en duda debido a no cumplir los requisitos de sostenibilidadmínimos: lo cual obliga a los emprendedores a mejorar sus ideas para que sean másrespetuosas ambientalmente, económicamente y socialmente.

En especial, pienso que la parte que tenemos que cuidar más en el mundo de las TICes, justamente, la medioambiental: para mi, una mala gestión de este aspecto acabarepercutiendo directamente en los demás criterios, por ejemplo, en la calidad devida de las personas que viven y trabajan en los vertederos tecnológicos en Ghana,que viven rodeadas de contaminación.

Listemos pues, algunos aspectos positivos que nos aporta la sostenibilidad:

Disminución de la huella ecológica, mejora de la calidad de vida de las per-sonas e incremento del flujo económico.

Belleza social: el hecho de que una empresa dedique muchos recursos a crearproyectos sostenibles aumenta positivamente su percepción social.

A continuación, mencionemos también algunos aspectos negativos:

Incremento del coste de un proyecto: el tiempo y recursos usados en la bús-queda de una alternativa sostenible amplía el coste de diseño.

La alternativas sostenibles no siempre son las más óptimas: por ejemplo, lamayoría de coches eléctricos actuales utilizan baterías de litio, que, de no serrecicladas correctamente ocasionan daños al medio ambiente: sin embargoexiste la batería de hidrógeno (sostenible pero no tan eficaz).

Finalmente, solo nos queda resaltar la siguiente afirmación personal: cuando lasempresas dejen temporalmente a un lado sus intereses económicos, y pongan sobrela mesa los principios sostenibles como los de mayor prioridad, entonces es cuandoserán realmente sostenibles, y será un factor determinante para los clientes.

33

9.2. Dimensión económica

9.2.1. Proyecto puesto en producción

Hemos estimado que el coste total del proyecto sería de unos 9120 e: cierto aspectoque podemos considerar acerca de eso, es que, considerando que hemos sobrestima-do las horas trabajadas, podríamos haber reducido el número de esas horas a costade ceñirnos a restricciones temporales más severas y menos posibilidades de sol-ventar problemas. También es verdad que si hubiera personal más experimentadocon las tecnologías que usaremos, nos hubiéramos ahorrado 120 h de aprendizaje(correspondientes a la cantidad de 1810 e, nada despreciable).

9.2.2. Vida útil

Una vez que el proyecto esté en marcha, no se requerirán muchos costes de mante-nimiento. Lo que tenemos que tener en cuenta más que nada, es que probablementenos encontremos con un problema de escalabilidad (el hardware del servidor webque usaremos es muy discreto y podemos afirmar, con bastante seguridad, quenecesitaremos ampliarlo). Para ello usamos la sistemática de alquiler de servidor aun servicio externo, de esta manera podemos escalar el servicio con más facilidady requeriremos de menos mantenimiento.

9.2.3. Riesgos

En cuanto a la viabilidad económica del proyecto, tenemos que mencionar que elobjetivo principal no es la rentabilidad. Nuestra intención para financiar el proyec-to es convencer a ayuntamientos y a entidades animalistas de las ventajas socialesque podría aportar: dada la naturaleza de la aplicación que estamos desarrollando,está claro que no podemos obtener beneficios económicos de forma directa, aun-que contemplemos los posibles beneficios de medios como podría ser la publicidadadherida, creemos que no sería suficiente y crearía una mala experiencia para losusuarios. Si el proyecto fuera financiado, creemos que los costes de mantenimien-to se cubrirían con relativa facilidad, por ejemplo, con la ayuda de donaciones,crowdfunding, e incluso, teaming.

34

9.3. Dimensión social

9.3.1. Proyecto puesto en producción

Sin duda, el mayor atractivo de este proyecto es el beneficio que aporta a la so-ciedad: durante la realización de éste, he aprendido mucho sobre el estado y lacalidad de vida de los perros en las perreras y protectoras respectivamente.Lo que más me ha sorprendido, es la buena fe y esencia positiva de todas las perso-nas que me han oído hablar del proyecto, especialmente, como me han ayudado ybrindado soporte todas las que apoyan esta causa e incluso participan o han parti-cipado en éstas o muy parecidas, siempre de naturaleza animalista. La experienciade estas personas me ha ayudado a profundizar en ciertos aspectos, que de no serpor sus conocimientos, no hubiera tenido del todo claro.

9.3.2. Vida útil

Es especialmente en esta fase temporal, donde el proyecto y en concreto la apli-cación, dan lo mejor de sí: el uso de la app mejorará la calidad de vida de laspersonas y los perros (ya sean domésticos o de protectoras/perreras) e influenciaráa mucha gente a promover la ideología animalista que queremos difundir sobre lapoblación. Es agradable mencionar que, el público al que nos queremos dirigir, esun conjunto de gente que tiene mucha iniciativa y ganas de probar ideas de estetipo (que busquen el apoyo al mundo animal, mejorando el bienestar de éstos). Lanecesidad de este proyecto es tangible, sobretodo para los dueños de las mascotas.Es posible que a su vez, la puesta en marcha de esta aplicación anime a otraspersonas a crear proyectos atrevidos de índole parecida.

9.3.3. Riesgos

Para este proyecto, es difícil imaginar riesgos que puedan afectar negativamentea alguien: en principio, todo el mundo obtiene un beneficio gracias a la imple-mentación del sistema que describimos en la aplicación. Si nos viéramos forzadosa mencionar a algún colectivo en concreto, probablemente mencionaríamos a lospaseadores de perros por encargo: nos referimos a las personas que buscan un áni-mo de lucro monetizando las actividades de paseos de canes. Es posible que unabuena adaptación de nuestra ideología redujera la cantidad de clientes potencialesque hay ahora mismo en el país, que no son precisamente escasos. Por esto, lospaseadores de perros que cobran dinero tendrían que buscar otro trabajo.

35

9.4. Dimensión ambiental

9.4.1. Proyecto puesto en producción

Partimos de la cantidad de 197.6 kWh, que hemos utilizado para el ordenadorde sobremesa (y sus periféricos), la pantalla y el smartphone. Adicionalmente,tenemos que considerar la presencia del servidor web (que no tenemos nosotros peropagamos por el servicio), como su hardware es tan discreto (además, es virtual)y la empresa no nos proporciona datos exactos, supondremos que consume 2.4 W(el doble que una Raspberry PI 2, ya que tienen hardware similar). Si tenemosen cuenta que estará encendido 5 meses llegamos a la cantidad de 8.64 kWh, quesumaremos adicionalmente a la que ya teníamos, para un total de 206.24 kWh. Parasaber la masa de CO2 equivalente a ese gasto energético, utilizaremos una páginaweb (17) que hace esa conversión teniendo en cuenta la ubicación geográfica de lared eléctrica. Finalmente, hemos determinado que la huella ecológica del desarrollodel proyecto es de 57 Kg de CO2. En caso de no tener que redactar el TFG, nosahorraríamos el gasto eléctrico del ordenador que usamos para redactar.

9.4.2. Vida útil

Una vez que el proyecto ya esté en marcha, el único impacto ecológico que perma-necería sería el coste eléctrico del servidor. Aquí tenemos que hacer una distinciónentre si seguimos con el mismo servidor del desarrollo (de prestaciones bajas) o sihubiéramos escalado el servidor (caso realista). Suponiendo que nuestra app estu-viera en el mercado durante 6 años, con el servidor original consumiríamos 105.2kWh, que equivalen a 29 Kg de CO2 (17), y con el servidor mejorado (caso máspropenso), suponiendo un consumo de 300 W, consumiríamos 15779 kWh, queequivalen a 4.36 t de CO2 (17). Aunque hayamos generado una huella ecológicaconsiderable, consideramos que los beneficios sociales del proyecto lo compensan.

9.4.3. Riesgos

El riesgo principal, que ya hemos mencionado y cuantificado en el apartado ante-rior, es el hecho de tener que escalar el servidor web a uno más potente para podersatisfacer la demanda de recursos de los usuarios. Es un riesgo muy real, pero lasestimaciones que hacemos en el área de presupuestos son para la realización delproyecto, no para su vida útil, es decir, nuestras predicciones sobre el desarrollodel proyecto no se verían afectadas por éste, bastante posible, riesgo a considerar.

36

10. Especificación de requisitos

10.1. Proceso de obtención

La principal fuente de obtención de los requisitos en este proyecto ha sido mediantela comprensión de la problemática que el proyecto quiere resolver, es decir, hemosobtenido un seguido de problemas que queremos resolver y hemos planteado unseguido de requisitos para poder satisfacerlos.

Mediante este proceso (18) (19) hemos determinado una serie de requisitos quehemos clasificado en dos categorías: funcionales y no funcionales.

Los requisitos funcionales, que en nuestro proyecto los hemos indicado como his-torias de usuario, los dividimos a su vez por temáticas para poder organizarlos deforma más eficaz: acceso, perros, usuarios, chat y informativa.

Los requisitos no funcionales se han especificado mediante la plantilla de especifi-cación de requisitos de Volere (20), de forma que sean lo más técnicos posibles.

37

10.2. Listado y clasificación

10.2.1. Requisitos funcionales

10.2.1.1 De temática: acceso

Historia de usuario: Registro de usuarioDescripción: Como potencial nuevo usuario, quiero poder registrarme conmi correo electrónico de forma que pueda entrar en la aplicación.

Historia de usuario: Inicio de sesión con GoogleDescripción: Como potencial nuevo o ya existente usuario, quiero poderacceder a través de Google de forma que pueda entrar en la aplicación.

Historia de usuario: Inicio de sesión con TwitterDescripción: Como potencial nuevo o ya existente usuario, quiero poderacceder a través de Twitter de forma que pueda entrar en la aplicación.

Historia de usuario: LogoutDescripción: Como usuario logueado, quiero poder cerrar sesión en la apli-cación de forma que pueda iniciar sesión con otra cuenta o que otras personasno puedan ver mi cuenta desde mi dispositivo.

Historia de usuario: Resetear contraseñaDescripción: Como usuario existente, quiero poder resetear mi contraseñaen caso de olvido o extravío de forma que pueda recuperar el acceso a micuenta.

Historia de usuario: Cambiar contraseñaDescripción: Como usuario existente, quiero poder cambiar mi contraseñade forma que pueda renovarla periódicamente.

38

10.2.1.2 De temática: perros

Historia de usuario: Listar perros cercanosDescripción: Como usuario logueado, quiero poder ver los perros que haycerca de mí, de forma que pueda acceder a sus perfiles.

Historia de usuario: Ver perfil de perroDescripción: Como usuario logueado, quiero poder ver el perfil de un perrode forma que esté informado sobre sus características si lo quiero pasear.

Historia de usuario: Añadir perroDescripción: Como usuario logueado, quiero poder añadir un perro de for-ma que los paseadores puedan acceder a su perfil.

Historia de usuario: Modificar perroDescripción: Como usuario logueado, quiero poder modificar los datos demi perro de forma que pueda comunicar a los usuarios que visiten su perfilalgún cambio, por ejemplo, que se haya esterilizado.

Historia de usuario: Eliminar perroDescripción: Como usuario logueado, quiero poder eliminar el perfil de miperro en caso de fallecimiento o de que ya no necesite paseos de forma queotros usuarios no me contacten más acerca de éste.

Historia de usuario: Ver perros de usuarioDescripción: Como usuario logueado, quiero poder ver los perros de unusuario de forma que pueda acceder a sus perfiles, y si son mis perros, parapoder modificarlos o eliminarlos.

39

10.2.1.3 De temática: usuarios

Historia de usuario: Ver perfil de usuarioDescripción: Como usuario logueado, quiero poder ver el perfil de un usua-rio de forma que pueda contactar con él, ver sus perros, ver su disponibilidad,ver sus valoraciones y su ubicación aproximada.

Historia de usuario: Modificar perfil de usuarioDescripción: Como usuario logueado, quiero poder modificar mi perfil deforma que pueda comunicar a otros usuarios algún cambio, por ejemplo, enmi descripción.

Historia de usuario: Ver calendario de disponibilidadDescripción: Como usuario logueado, quiero poder ver el calendario de dis-ponibilidad de un usuario de forma que pueda saber en que horas podríamoscoincidir para los paseos.

Historia de usuario: Establecer calendario de disponibilidadDescripción: Como usuario logueado, quiero poder establecer mi calendariode disponibilidad de forma que pueda comunicar a otros usuarios a que horaspodríamos coincidir para los paseos.

Historia de usuario: Valorar usuarioDescripción: Como usuario logueado, quiero poder valorar otro usuario (yasea propietario o paseador) de forma que pueda dar feedback representativopara él y los demás usuarios.

Historia de usuario: Ver valoraciones de usuarioDescripción: Como usuario logueado, quiero poder ver las valoraciones deun usuario de forma que pueda hacerme una idea de lo responsable que es ycuanto compromiso tiene.

40

10.2.1.4 De temática: chat

Historia de usuario: Chatear con otro usuarioDescripción: Como usuario logueado, quiero poder contactar con otro usua-rio de forma que podamos hablar y establecer los detalles para un paseo.

Historia de usuario: Ver chats recientesDescripción: Como usuario logueado, quiero poder ver los chats con laspersonas que hablo de forma que pueda seguir el contacto con ellos.

10.2.1.5 De temática: informativa

Historia de usuario: Visualizar consejos útiles de paseoDescripción: Como usuario logueado, quiero poder ver consejos útiles depaseo de forma que pueda ver información sobre como puedo mejorar lospaseos de un perro.

Historia de usuario: Visualizar leyes y regulacionesDescripción: Como usuario logueado, quiero poder informarme sobre lasleyes y regulaciones que afectan a los perros de forma que tenga unos cono-cimientos mínimos en caso de que me fueran necesarios.

Historia de usuario: Ver ubicación en mapaDescripción: Como usuario logueado, quiero poder ver una localización enun mapa para poder ver donde está situada.

Historia de usuario: Listar parques y fuentes de agua cercanasDescripción: Como usuario logueado, quiero poder ver los parques máscercanos, de forma que pueda visitarlos en los paseos y las fuentes de agua,de forma que pueda hidratar al perro y a mí en caso de no llevar agua.

Historia de usuario: Ver logrosDescripción: Como usuario logueado, quiero poder ver los logros que heconseguido de forma que me incentive a seguir usando la aplicación.

41

10.2.2. Requisitos no funcionales

Requisito: La aplicación podrá ser usada por usuarios sin entrenamiento.Categoría: 11a) Facilidad de uso - Usabilidad y Humanidad

Requisito: Cualquier interacción entre el usuario y la interfaz de la aplica-ción tendrá un tiempo máximo de respuesta de 3 s.Categoría: 12a) Velocidad y Latencia - Rendimiento

Requisito: Se actualizará la aplicación una vez cada 8 meses.Categoría: 13e) Release - Operacional y de entorno

Requisito: La aplicación solo funcionará en dispositivos Android.Categoría: 14c) Adaptabilidad - Mantenimiento y soporte

Requisito: La aplicación evitará que el usuario introduzca datos incorrectos.Categoría: 15b) Integridad - Seguridad

Requisito: El servidor de la aplicación se ha protegido frente a ataques.Categoría: 15e) Immunidad - Seguridad

Requisito: La información personal se almacenará según la LOPD.Categoría: 17a) Cumplimiento de aspectos legales - Cumplimiento

42

11. Arquitectura del sistema

11.1. Visión general

Figura 1: Visión general del sistema

Como podemos ver en la figura 1, nuestro sistema aprovecha diferentes serviciospara satisfacer sus necesidades. Sabiendo que el servidor que tenemos contratadoes, de momento, de bajas prestaciones, hemos decidido liberar toda la carga posiblemediante el uso de estos servicios, que explicaremos detalladamente a continuación.

En primer lugar, todos los correos que nuestro sistema son enviados medianteSendGrid (21), un servicio de correo electrónico que permite enviar correos a nom-bre de un dominio (walkee.ovh) habiéndolo verificado con anterioridad. Esto nospermite, además de liberar carga del servidor, disponer de cierta escalabilidad.

En segundo lugar, tenemos que proveer acceso a Google (22) y Twitter (23) desdeel cliente, para identificar los usuarios en los inicios de sesión con estas plataformas,y desde el servidor, para validar las identificaciones que nos llegan desde el cliente.

En tercer lugar, usaremos Cloudinary (24) para subir las imágenes de los perfiles deusuarios y de perros, de esta manera ahorramos recursos como por ejemplo anchode banda y espacio de almacenamiento. Además, la misma plataforma actúa comoun CDN para optimizar la entrega de imágenes según la ubicación geográfica.

En cuarto y último lugar, usaremos la API Overpass (25) que nos provee OpenS-treetMap (26) para ubicar puntos geográficos y mostrar parques y fuentes cercanas.

43

11.2. Patrones implicados

11.2.1. Active Record

El patrón Active Record (27), cuyo nombre fue establecido por Martin Fowler,conecta clases con tablas de bases de datos relacionales, de esta manera se consigueestablecer una capa de persistencia, con relativamente poca configuración, paraaplicaciones. A las clases que han sido ligadas con tablas de un SGBD se lasdenomina modelos, y éstos pueden estar ligados entre sí formando asociaciones, porejemplo, el modelo “comercio” puede estar asociado con varios modelos “factura”.

El mismo patrón en sí es una implementación de la técnica ORM (Object-RelationalMapping), pero la ventaja que Active Record ofrece sobre sus cimientos es que uti-liza convenciones de nombres para liberar la carga de configuración que la anteriortécnica impone, es decir, un modelo o clase que se llame “Usuario” se mapearáimplícitamente a la tabla llamada “usuarios” de la base de datos, el inconvenien-te que esto supone es que, al ser un patrón muy dependiente en convenciones denombres, resulta complicado modificar ciertos comportamientos de éste.

En nuestro proyecto utilizamos este patrón concretamente en la parte de backend,ya que es utilizado por defecto por el framework Ruby on Rails (28), que explica-remos en la sección correspondiente del documento.

11.2.2. Adaptador

El patrón Adaptador (29) es un patrón estructural que permite usar objetos apa-rentemente incompatibles, es decir, con interfaces distintas, mediante el uso de unaclase adaptador que se encarga de gestionar la compatibilidad entre éstas.

Por ejemplo, supongamos que disponemos de una aplicación propia que trabajecon datos bursátiles de distintos servicios web, pero todos los servicios devuelvanlos resultados en formato XML. Lógicamente, lo más coherente es pensar que laaplicación fue diseñada para trabajar con este formato de datos, y en base a eso,interactuaba con un servicio externo de estadísticas que funcionaba también conXML, pero que desgraciadamente ha salido del mercado, ahora, la única alterna-tiva viable es un servicio que solo interpreta datos en JSON. Gracias al patrónadaptador, podemos crear una clase que se encargue de encapsular los objetos in-compatibles para que produzcan resultados en JSON aceptables por este servicio.

En nuestro proyecto utilizamos este patrón concretamente en la parte de frontend,cuando se enlaza una instancia de una clase a elementos de una vista llamadaRecyclerView (30), que se usa para mostrar listas de elementos.

44

11.2.3. Modelo-Vista-Controlador (MVC)

El patrón Modelo-Vista-Controlador (31) es un patrón arquitectónico que, en elcontexto de una aplicación, separa la lógica de datos de la de las vistas. La lógicade los datos se representa mediante los modelos y la lógica de las vistas a travéslas interfaces gráficas, para poder relacionarlas se recurre a los controladores, queson los encargados de ser intermediarios entre los modelos y las vistas.

En nuestro proyecto utilizamos este patrón en las dos partes de nuestra aplicación,en el backend y en el frontend, de hecho, es un patrón bastante común.

En el backend lo usamos ya que Ruby on Rails se centra en aplicarlo, de hechoel patrón Active Record corresponde justamente a la parte del modelo de MVC,las vistas del backend son serializadores que convierten un objeto o un grupo deobjetos a un formato visual, en nuestro caso JSON, excluyendo o añadiendo ciertosatributos, y los controladores corresponden a los métodos que se ejecutan en cadallamada de nuestra API, y que por tanto manejan modelos y vistas.

En el frontend lo usamos por defecto a la hora de construir el proyecto, los modeloscorresponden a los objetos de clases con las que trabajamos (por ejemplo, perro),las vistas corresponden a los layouts o ficheros XML donde se describe como seorganizan los elementos en la pantalla y los controladores son las actividades (32)(o activities, en inglés) que se encargan de gestionar y enlazar los eventos de lainterfaz gráfica con la lógica de los datos de nuestra aplicación Android.

11.2.4. Singleton

El patrón Singleton (33) es un patrón de diseño que se usa para garantizar queuna clase solo pueda tener una instancia, y que ésta sea globalmente accesible enel programa. Se puede pensar que una variable global es a efectos prácticos igual,pero es un razonamiento erróneo, ya que, en primer lugar, el patrón Singleton noexpone su constructor al resto de la aplicación y además utiliza el patrón de diseñolazy loading (34), que evita la inicialización prematura de la instancia de la clasehasta el momento de su uso.

En nuestro proyecto lo utilizamos, por ejemplo, a la hora de acceder a los datosdel usuario activo. Disponemos de una clase llamada Credentials que utiliza estepatrón y permite acceder globalmente en la aplicación a los tokens de sesión asícomo al identificador del usuario.

45

11.3. Esquema conceptual de la base de datos

Figura 2: Diseño de la base de datos

El diseño UML de la base de datos, presentado en la figura 2 se ha hecho me-diante migraciones (35) de Ruby on Rails, que son pequeños cambios a tablas ycolumnas que se van acumulando hasta formar el esquema actual de la base dedatos. Esta característica del patrón Active Record permite trabajar de forma ágilen el proyecto sin detenerse a diseñar la base de datos con anterioridad, ademásde mantener la información de la base de datos durante el desarrollo.

El patrón Active Record tiene un gran inconveniente, y es que desviarse del uso pordefecto de ids como clave primaria resulta difícil (36) y contrario a la convención.

46

11.4. Diseño de la interfaz gráfica

11.4.1. Consideraciones generales

11.4.1.1 Contraste

Durante el diseño de la interfaz de la aplicación hemos utilizado mayoritariamentetres colores: el negro (en hex. #000000) , un color parecido al ocean green (enhex. #45A187) y un color parecido al shadow green (en hex. #9FC2BA) .

El color negro es el que nos define el color del texto de la interfaz, mientras queel que se parece al ocean green es el que usamos de fondo, y finalmente, el que separece al shadow green es el que usamos para dividir elementos del fondo. Midiendoel ratio de contraste entre los dos colores temáticos de la aplicación y el color negrodel texto, hemos obtenido los siguientes resultados (37) (38).

≈ Ocean green ≈ Shadow greenGeneral Ratio de contraste 6.70 : 1 10.90 : 1

WCAG AA OK OKTexto normal WCAG AAA NO OK OKWCAG AA OK OKTexto grande WCAG AAA OK OK

Gráficos y UX WCAG AA OK OK

Tabla 11: Resultados del análisis de contraste

Como podemos ver, cumplimos todos los criterios de contraste de las WCAG (39)(Web Content Accessibility Guidelines) a excepción del WCAG AAA para textonormal. Lo que ésto nos sugiere es que deberíamos evitar juntar el texto de medidanormal con el fondo de ocean green, y en su lugar juntarlo con el shadow green.

Es necesario matizar que, en el registro, mezclamos el fondo de ocean green conun rojo que resalta mucho. Lo hemos planteado así ya que lo utilizamos para quelos usuarios vean la validación del formulario, aunque sería mejor buscar un coloralternativo para los usuarios con daltonismo rojo-verde.

11.4.1.2 Navegación

Para la navegación de la aplicación hemos decidido usar un menú con el que losusuarios se sientan familiarizados, ya que no queremos confundirlos. El menú quehemos utilizado se llama Navigation drawer (40) y forma parte de Material Design,una normativa de diseño creada por Google y orientada a dispositivos Android.

47

48

11.4.2. Capturas de la aplicación

(a) Pantalla de carga (b) Inicio de sesión (c) Registro (I)

49

(d) Registro (II) (e) Reseteo de contraseña (f) Menú desplegable

50

(g) Perros cercanos (h) Perfil de perro (i) Perfil de usuari@

51

(j) Ubicación en mapa (k) Valoraciones de usuari@ (l) Valorar usuari@

52

(m) Chat con usuari@ (n) Parques cercanos (ñ) Fuentes cercanas

53

(o) Consejos útiles (p) Leyes y regulaciones (I) (q) Leyes y regulaciones (II)

54

(r) Chats recientes (s) Mi perfil (t) Mi disponibilidad

55

(u) Modificar perfil (v) Cambiar contraseña (w) Cerrar sesión

12. Desarrollo

12.1. Recursos utilizados

12.1.1. Lenguajes de programación

12.1.1.1 Ruby

Figura 11: Logo de Ruby

Ruby (41), publicado en 1995 por Yu-kihiro “Matz” Matsumoto, es un len-guaje de programación dinámico y decódigo abierto enfocado en la simplici-dad y en la productividad. La filoso-fía de Matz fue desarrollar un lenguajeque fuera más poderoso que Perl y másorientado a objetos que Python, duran-te el desarrollo de éste, Matz mezclópartes de sus lenguajes favoritos: Perl,Smalltalk, Eiffel, Ada y Lisp.

12.1.1.2 Java

Figura 12: Logo de Java

Java (42), publicado en 1996 por SunMicrosystems y mantenido actualmen-te por Oracle, es un lenguaje de pro-gramación de propósito general, concu-rrente, basado en clases y orientado aobjetos; es suficientemente simple comopara que los programadores puedan al-canzar cierta fluidez en éste rápidamen-te. Tiene ciertos aspectos parecidos a Cy a C++ pero está organizado más biende forma distinta. Una de sus grandesventajas es que se compila a código má-quina para la máquina virtual de Java,de forma que si se ha programado lamáquina virtual de Java para un hard-ware en concreto, éste podrá ejecutarcualquier programa en Java.

56

12.1.2. Tecnologías usadas

12.1.2.1 Android

Figura 13: Logo de Android

Android (43), publicado en 2008 porGoogle, es un sistema operativo ba-sado en el núcleo Linux y de carác-ter open-source. Fue diseñado princi-palmente para teléfonos móviles peroen la actualidad se ha extendido a dis-positivos como netbooks, tablets, relo-jes, etc. Google trabaja activamente ensu desarrollo, habiendo lanzado la últi-ma versión 9.0 Pie en agosto de 2018.Android proporciona paquetes para quelos desarrolladores puedan crear appscon lenguajes como Java o Kotlin.

12.1.2.2 Ruby on Rails

Figura 14: Logo de Ruby on Rails

Ruby on Rails (28), publicado en 2005por David Heinemeier Hansson, es unframework de aplicaciones web de ca-rácter open-source desarrollado en len-guaje Ruby. Funciona muy bien conmetodologías ágiles ya que desarrollarcon él es muy rápido, y además propor-ciona una buena seguridad por defecto.

12.1.2.3 PostgreSQL

Figura 15: Logo de PostgreSQL

PostgreSQL (44), publicado en 1995por Michael Stonebraker, es un SGBDrelacional orientado a objetos de carác-ter open-source desarrollado en C. Ac-tualmente tiene una comunidad muyactiva de usuarios que lo usan y unade sus principales ventajas es que ofre-ce una inmensidad de funcionalidadesque otros sistemas de gestión de basede datos no llegan a ofrecer aún.

57

12.1.3. Herramientas

12.1.3.1 Android Studio

Figura 16: Logo de Android Studio

Android Studio (45), publicado en2014, es un IDE (Integrated Develop-ment Environment) de desarrollo oficialde Android. Es un software multipla-taforma y está basado en el softwareIntelliJ IDEA de Netbeans, aunque fueliberado bajo la licencia Apache 2.0. Suuso facilita mucho el desarrollo de apli-caciones para dispositivos Android yaque permite conectarse fácil y rápida-mente con hardware real y emuladores.

12.1.3.2 Visual Studio Code

Figura 17: Logo de Visual Studio Code

Visual Studio Code (46), publicado en2015, es un IDE de código abierto desa-rrollado por Microsoft. Es un softwaremultiplataforma y está basado en Elec-tron, un framework que se utiliza pa-ra ejecutar aplicaciones en Node.js paraescritorio. Es compatible con la sintaxisde muchos lenguajes de programación yproporciona una interfaz muy usable.

12.1.3.3 Overleaf

Figura 18: Logo de Overleaf

Overleaf (47) (antes ShareLaTeX), esun servicio web de escritura y publica-ción colaborativa que facilita mucho laescritura de textos de carácter acadé-mico. Contiene un intérprete de LaTeX(48), que es un sistema de preparaciónde documentos muy personalizable quepermite la inclusión de paquetes pa-ra propósitos específicos, normalmenteorientados al ámbito técnico-científico.

58

12.2. Implementación de las historias de usuario

En este apartado explicaremos las historias de usuario más complejas del proyecto.

12.2.1. Instalación y configuración de herramientas

Una vez hemos adquirido el servidor con Ubuntu debemos configurarlo apropiada-mente para que podamos ejecutar el servidor web, y además establecer un mínimode seguridad para protegerlo de ataques remotos que puedan ponerlo en peligro.

En primer lugar, nos conectaremos mediante ssh con las credenciales que nos hadado la empresa proveedora (que son las del usuario root), una vez tengamos accesoa la terminal debemos cambiar la contraseña a una segura inmediatamente paraevitar ataques por fuerza bruta (49), más adelante lo aseguraremos más pero porahora (para tener un mínimo de seguridad mientras configuramos todo) sirve.

Seguidamente, actualizaremos los paquetes del sistema para corregir cualquier posi-ble vulnerabilidad, y además instalaremos unattended-upgrades (que es un paqueteque nos mantiene el sistema actualizado sin tener que hacerlo manualmente), cadacierto tiempo es posible que precise de reiniciar el sistema (afectando a la dispo-nibilidad del servicio), pero es un precio que merece la pena pagar de cara a tenerseguridad para nuestro servidor y comodidad para el mantenimiento.

A continuación, añadiremos una cuenta de usuario nueva y la añadiremos al gru-po de sudoers, después de hacerlo entraremos con esta cuenta. Instalaremos rvm(un paquete que se encarga de gestionar versiones de Ruby) y le pediremos quenos instale la versión estable más reciente, cuando termine de instalarse tambiéninstalaremos Rails y crearemos la carpeta del proyecto.

De forma adicional, desactivaremos el acceso del usuario root mediante ssh y can-celaremos el inicio de sesión por contraseña, lo cambiaremos a acceso a través declaves ssh, que son mucho más seguras que las contraseñas (50). Además, cambia-remos el puerto que utilizamos para ssh a otro diferente, para hacer más difíciles lasintrusiones de los posibles atacantes, y añadiremos el paquete fail2ban (nos servirápara banear las IPs que intenten acceder de forma sospechosa automáticamente).

Asimismo, instalaremos sshfs (que nos servirá para acceder de forma remota a lacarpeta del proyecto, sin tener que usar ftp) y git (para controlar las versiones denuestro proyecto), junto con git-flow (una serie de extensiones para git de cara aldesarrollo software), también utilizaremos claves ssh con git por comodidad.

Finalmente, nos adueñaremos de un dominio el cual haremos que apunte a la má-quina y obtendremos un certificado SSL gratuito de la autoridad verificada llamadaLet’s Encrypt (51), que nos permitirá cifrar los datos de las comunicaciones.

59

12.2.2. Inicio de sesión

12.2.2.1 Planteamiento

El inicio de sesión es una de las partes más fundamentales de la aplicación, sinella los usuarios no podrían acceder y gestionar los recursos que hay en ésta.No obstante, muchos desarrolladores descuidan el apartado de seguridad, por esarazón, nosotros vamos a esforzarnos para que nuestra app cumpla unos requisitosmínimos de seguridad, con el objetivo de proteger la información de los usuarios.

Debido a que nuestro proyecto incorpora cierta variedad de servicios de tercerospara autorizarse en el sistema, es necesario crear un método para acabar abstrayén-dolos todos para no tener que redefinir el proceso (además de añadirle complejidad)cada vez que queramos añadir un nuevo servicio. En otras palabras, diseñaremosun flujo de trabajo que sea independiente del servicio de cara a la app.

Antes que nada, tenemos que explicar tres conceptos muy importantes:

1. Un JWT (JSON Web Token) (52) es un estándar de la IETF que consisteen un medio compacto y URL-safe para representar identidades o privilegiosentre dos sistemas, estos tokens tienen tres partes bien diferenciadas: la ca-becera (header), el contenido (payload) y la firma (signature). De forma muyresumida, estos tokens se suelen firmar utilizando una key que es productode la unión de su contenido y de un secreto adicional (como una especie decontraseña) que solo conoce el sistema emisor del token, y con el cual puedevalidar su integridad. En definitiva, la característica clave de este medio esque cualquier manipulación ajena del token cambiaría su firma y dejaría deser válida, con lo cual tenemos un token inmutable.

2. Un access token (53) es un token, generalmente del tipo JWT, que se usacomo credencial para acceder a recursos protegidos de un sistema. Tienen laparticularidad de que caducan en un tiempo corto, normalmente medido enhoras, cuando expiran ya no se pueden volver a usar y se debe obtener otro,ya sea iniciando sesión o pidiendo uno nuevo mediante un refresh token.

3. Un refresh token (53) es un token que no alberga información y se suelegenerar con la unión de caracteres aleatorios URL-safe. Estos tokens se al-macenan también en el servidor (con lo cual se pueden denegar, por ejemplo,de un intruso) y tienen una duración mucho más larga que los access tokens,de días. El propósito de este token es que se envíe al servidor para obtenerun nuevo access token con el que volver a autorizarse al sistema, el hecho deque el refresh token caduque obliga al usuario a volver a iniciar sesión.

60

Cada vez que el usuario inicie sesión manualmente la app recibirá un access tokeny un refresh token, que ésta guardará en las SharedPreferences (una especie de basede datos) de la aplicación, para usos posteriores. Como estos datos están en textoplano (no deberían poder ser accedidos por otras apps, pero sí con un usuarioroot de alto privilegio), hemos decidido añadir una capa de seguridad adicionalmediante la encriptación de estos valores con una librería llamada Armadillo (54).

Entonces, en cada petición al servidor que requiera de autenticación, el accesstoken se incluirá (concretamente en la cabecera Authorization de la petición), yde esta forma identificaremos al usuario únicamente. Tal como hemos mencionadoantes, cuando este access token caduque se usará el refresh token para obtener unonuevo, repitiendo este proceso hasta que el refresh token caduque y sea necesariovolver a iniciar sesión manualmente.

Es necesario mencionar que, dado que nos hemos asegurado que todas las comuni-caciones de la aplicación se realizan únicamente por HTTPS, los tokens no podránser usurpados por terceros (mientras el protocolo SSL no se vea comprometido).

Así pues, para ilustrarlo, adjuntamos a continuación la figura 19, que nos muestrael ciclo de vida de los access tokens, desde que se crean hasta que se renuevan.

Figura 19: Diagrama de secuencia de OAuth2

Fuente: https://tools.ietf.org/html/rfc6749#section-1.5

En nuestro caso particular, el servidor de recursos y el de autenticación son elmismo, por lo tanto todas las comunicaciones se producen entre estos dos agentes.En definitiva, este es el proceso general que seguirá nuestra aplicación.

61

12.2.2.2 Inicio de sesión con Google

Cuando el usuario pulse el botón de inicio de sesión con Google, la aplicación en-viará una petición de autorización (o authorization request) al servidor de Google,hecho que tendrá como resultado un diálogo de selección de cuentas al usuario.

Una vez el usuario haya escogido una cuenta, la aplicación recibirá tres parámetros(55): un access token, un id_token y un one-time code. El primer parámetro esun access_token que Google nos da para hacer peticiones a su API en nombrede nuestro usuario; como en nuestra aplicación no serán necesario este tipo deaccesos, no necesitamos este valor. El segundo parámetro, id_token, contiene todala información necesaria para identificar al usuario (por ejemplo, el nombre deusuario, un link a la imagen de su avatar, el email (a veces), etc.): al ser un tokenJWT, está firmado por Google, y es claramente el valor que necesitamos. El tercerparámetro, el one-time code, es un valor que se intercambia por un access_token,pero solo funciona una vez y tampoco lo usaremos en nuestra app.

Una vez recibimos el id_token, tenemos que enviarlo a nuestro servidor para de-mostrar que nos hemos autorizado correctamente con Google. Pero esto no serásuficiente de por sí, ya que un usuario malintencionado podría haber replicado untoken igual y habría conseguido acceso. Para que esto no suceda, debemos verifi-car que la firma de Google sea correcta, para ello tendremos que disponer de suscertificados, que por medidas de seguridad no son estáticos sino que van rotandocada cierto tiempo. Esto nos predispone a tener que ir a buscarlo a su servidor o averificarlo enviándoselo al mismo Google, en nuestro caso lo recogeremos de formatransparente utilizando una gem de Ruby llamada google-id-token (56).

Figura 20: Diagrama de secuencia del inicio de sesión con Google

Fuente: https://developers.google.com/identity/sign-in/web/backend-auth

62

12.2.2.3 Inicio de sesión con Twitter

Una vez el usuario haya pulsado el botón de inicio de sesión con Twitter (57),nuestra aplicación enviará una petición al servidor de Twitter para obtener unrequest token, a continuación lo enviaremos a Twitter para que nos genere undiálogo de inicio de sesión, y tras un inicio de sesión correcto se enviarán losparámetros que hemos recibido para intercambiarlo por un access token, el cualenviaremos a nuestro servidor.

Como este proceso es bastante complejo (lo hemos explicado de forma muy resu-mida y simplificada), hemos optado por usar en nuestra app una librería llamadatwitter-kit-android (58), que nos abstraerá de estas llamadas y nos proveerá, conun solo callback de retorno, los datos necesarios que enviaremos a nuestro servidor.

Una vez recibamos los datos en nuestro servidor, haremos una petición a un end-point de Twitter llamado verify_credentials (59), que en caso de ser satisfactorianos demostrará que esos datos de acceso son correctos y además nos dará toda lainformación que necesitamos del usuario. Para hacer esta llamada en el backend,haremos uso de una gem de Ruby llamada twitter (60), que es una interfaz paracomunicarse con Twitter.

Así pues, podemos ilustrar el procedimiento con la figura 21:

Figura 21: Diagrama de secuencia del inicio de sesión con Twitter

Fuente: https://developer.twitter.com/en/docs/twitter-for-websites/log-in-with-twitter/guides/implementing-sign-in-with-twitter.html

63

12.2.2.4 Inicio de sesión con email

A diferencia de los otros inicios de sesión, necesitaremos dos endpoints distintos(para el inicio de sesión y el registro), ya que no creamos la cuenta en el momentosi no existía previamente, y con los servicios de terceros sí. Además, este tipo deautenticación requiere de lógica adicional en el servidor, ya que cuando efectuamosel inicio de sesión tenemos que identificarnos con una dirección de correo y unacontraseña. Para poder comprobar que esta contraseña es correcta, tiene que estarde alguna manera, almacenada en el servidor, pero nunca en texto plano, sinohasheada. En referencia al envío de ésta, consideramos que mediante HTTPS essuficiente. Evidentemente, se puede mejorar, pero no es necesario en nuestra app.

12.2.3. Registro de usuario

El registro de usuario nos obliga a añadir complejidad al servidor. Como hemoscomentado antes, tenemos que guardar la información crítica de forma segura en elservidor (en nuestro caso, la contraseña). Hemos usado una librería llamada bcrypt-ruby (61) para proteger las contraseñas, de esta manera, si un intruso lograra accesoal sistema no se comprometería la contraseña del usuario directamente (en caso deque estuviese en texto plano, el atacante podría usarla para otros servicios).

Adicionalmente, el hecho de que los usuarios se identifiquen por su correo nosobliga a tener que comprobar la propiedad del mismo. Para ello, después de que elusuario se registre, hemos hecho uso de un proceso en el que mandamos un correoa su email con un código de verificación mediante un servicio externo llamadoSendGrid (21), que permite enviar correos electrónicos. Para poder ser un usuariolegítimo es necesario que confirme ese código, de no ser así no podrá acceder alsistema y no se le considerará como un usuario de la aplicación como tal.

Hemos usado los siguientes criterios a la hora de limitar los campos del registro:

Usuario: Un mínimo de 4 caracteres y un máximo de 16. Estos solo podránser alfanuméricos (y las letras solo en minúscula), a excepción del separador“.” que solo se podrá usar entre letras, por ejemplo: alexandre.calle

Contraseña: Un mínimo de 8 caracteres y un máximo de 20. Estos podránser cualquier carácter, por ejemplo, #7aP=T&aX3_p

Finalmente, tenemos que mencionar que el código de verificación es alfanuméricoy mide 6 caracteres. El motivo de que no contenga símbolos es para facilitarle laescritura al usuario, y que no necesite cambiar el modo de entrada del teclado.

64

12.2.4. Reseteo de contraseña

El reseteo de contraseña es una funcionalidad que ayuda a los usuarios a recuperarel acceso a la aplicación en caso de pérdida de la clave, es de esperar pues, quela examinemos detenidamente al ser una funcionalidad que puede llegar a serproblemática en muchos sentidos, incluyendo brechas de seguridad.

Lógicamente, esta funcionalidad solo se aplicaría a cuentas que hayan sido creadasmediante registro por correo electrónico, ya que las de redes sociales (Twitter,Google) no están asociadas con una contraseña en nuestro sistema.

Una implementación sencilla pero necia, sería enviar una nueva contraseña aleato-ria directamente por al email de usuario, es decir, el usuario indicaría su email ya continuación se enviaría el correo, ahora veamos el porqué esta idea no es bue-na. Si un usuario malintencionado (A) intenta molestar a un usuario legítimo (B)con esta implementación, solo necesita resetear la contraseña de forma constantemediante su email para dejar al usuario legítimo (B) sin acceso al servicio.

La solución que nosotros hemos propuesto, y que soluciona el problema anteriorconsiste en que, al resetear la contraseña, se envíe un correo con un enlace directoprovisto con un access token al dominio de nuestro servidor, en nuestro caso, elenlace este aspecto (nótese que la comunicación es por HTTPS):

https://walkee.ovh/account/confirm?accessToken=aaa.bbb.ccc

Este access token, que tiene un formato igual al que usa la aplicación, tiene unavalidez exacta de 1 hora desde que se emite, y dado que no se dispone de un refreshtoken, no se puede renovar. Cuando el usuario legítimo acceda al link anterior queha recibido por correo, el backend validará el token como en cualquier otro caso,y enviará un correo nuevamente con una contraseña aleatoria generada con la queel usuario podrá volver a entrar en la app.

Es necesario que mencionemos que todos los access token de la aplicación llevanuna variable que se llama rnd_code, que es un valor aleatorio que solo cambiacuando se cambia la contraseña del usuario. Cuando nuestro backend valida eltoken, comprueba además si esta variable coincide con la que hay almacenada, ysi no coinciden, da el token por inválido, lo que ésto nos permite es revocar todaslas sesiones abiertas, principio que la OWASP recomienda (62).

Para completar la revocación de las sesiones abiertas, solo nos queda eliminarcualquier refresh token al cual el usuario tuviera acceso, así no podrá intercambiareste tipo de token por un acccess token. Finalmente, es conveniente decir que en unsistema más seguro se le pediría preguntas de seguridad al usuario y se le hubieraobligado a introducir una nueva contraseña por motivos de seguridad.

65

12.2.5. Subida de imágenes

En las funcionalidades de perfiles, de las cuáles en el desarrollo aún no hemoshablado, se ha añadido la opción de incluir una imagen a modo de avatar, estoimplica una decisión acerca de si se deberían guardar las imágenes en el servidoro en un servicio externo de almacenamiento.

Después de valorar las ventajas y los inconvenientes, hemos decidido optar por lasegunda opción por los siguientes motivos:

1. Liberarnos de la lógica de las imágenes: Para guardar imágenes hayque tener un control exhaustivo sobre lo que es una imagen y lo que no. Hayque tener en cuenta factores como el tipo de fichero, tamaño, etc.

2. Liberarnos de la gestión de los archivos: Establecer la persistencia enel servidor implica tener que gestionarla, esto derivaría en necesidades comopor ejemplo tener que ampliar el espacio de disco. Además, nos obliga a tenerque añadir, reemplazar y eliminar ficheros constantemente en el servidor.

3. Ser precavidos en seguridad: Una gestión de archivos no apropiada puedeacarrear vulnerabilidades como pueden ser directory traversal, shell upload oincluso ataques del tipo denial of service (subiendo archivos enormes).

4. Ahorrarnos recursos del servidor: Consideramos que la prioridad delservidor es responder a las llamadas de la API, y por tanto creemos queel servidor no debería estar ocupado constantemente entregando imágenes,especialmente en un servidor tan básico como el que disponemos.

Las referencias a las imágenes se guardarán como URLs en nuestro servidor, y lassubidas de imágenes serán hechas desde la misma aplicación hacia los servidoresde Cloudinary. Además, para poder subir una imagen, antes tendrá que generarsela autorización correspondiente en nuestro servidor, siguiendo este esquema:

Figura 22: Diagrama de secuencia de la subida de imágenes a Cloudinary

66

12.2.6. Listar perros cercanos

Para poder mostrar los perros de la aplicación hemos tenido que considerar variosaspectos técnicos. En primer lugar, hemos decido que, obviamente, para solicitarla lista haríamos una petición GET a un endpoint de la API, concretamente /dogs.Este hecho, que aparentemente es sencillo, hace emerger una cuestión, ¿cómo equi-libramos la transferencia de datos entre el servidor y el usuario para poder reducirla carga del servidor, la latencia de la respuesta y ahorrar datos móviles del usua-rio?. Este hecho representa un problema de escalabilidad, ya que con 100 perrosen la aplicación no supondrá un problema, pero si llegamos al orden de miles deperros sería un overhead muy significativo para nuestra aplicación.

La solución que hemos aplicado se denomina paginación (63), que es una técnicaque consiste en dividir los resultados de una petición en páginas para reducir laescala de los datos y poder trabajar mejor con ellos, además de solventar todoslos problemas que hemos mencionado anteriormente. En nuestro caso concreto,la hemos aplicado mediante Kaminari (64), una gem de Ruby que nos ayuda ausarla. Hemos usado la configuración por defecto, que devuelve 25 elementos porpágina. Para iterar sobre las páginas, pasamos un parámetro llamado num_pageal endpoint con el número de página que queramos solicitar al servidor.

Es importante mencionar que nuestra implementación de la paginación, aún siendosimple y fácil, no es la más completa. El motivo es que si hubiera muchas mani-pulaciones de datos durante las consultas (que en nuestro tipo de aplicación no esasí) se podrían perder resultados al ir iterando sobre las páginas. La técnica másrecomendada es el uso de cursores de resultados (65), pero son complejos.

Por otro lado, la naturaleza de nuestra petición es compleja, ya que el orden de losresultados (por distancia geográfica de menor a mayor) tiene que ser calculado porel SGBD a partir de una latitud y una longitud. Para poder ejecutar la consultade esta manera, hemos hecho uso de una gem de Ruby llamada Geocoder (66), lacual nos obliga a guardar la ubicación geográfica de los usuarios y los perros (quese ha considerado la misma) en sus respectivos modelos de la base de datos.

Así pues, para implementar esta funcionalidad, hemos tenido que combinar la téc-nica de paginación junto con la de ordenar los resultados por distancia. Finalmente,aún existiendo complejidad en la implementación de estas técnicas, se ha abstraídosatisfactoriamente gracias a las librerías que hemos mencionado anteriormente.

67

12.2.7. Chatear con otro usuario

Esta funcionalidad permite aun usuarios conversar con otro a través de su perfil,de manera que puedan preguntar datos sobre el perro o detalles de contacto, paraimplementarlo hemos introducido los modelos de chat y mensaje.

Cuando el usuario que inicia el chat escribe el primer mensaje y lo envía, se crea unainstancia de chat en el backend, donde queda constancia de quien es el autor delchat y quien es el destinatario, y se le adjunta una instancia del mensaje. Además,el usuario ya puede acceder directamente a este chat mediante el apartado “Chatsrecientes” de la aplicación, para su propia comodidad y facilidad de acceso.

Ya que el chat está pensado para la toma de contacto inicial entre usuarios, yconsideramos que es muy probable que los mismos, tras intercambiar datos decontacto usen otro servicio de mensajería, hemos decidido hacer una implemen-tación sencilla de un servicio de chat (no es el objetivo del proyecto) la cual esprobable que tengamos que cambiar si queremos escalar la aplicación.

El chat funciona de la siguiente manera: una vez se ha creado, la aplicación con-sulta periódicamente cada 0.5 s los nuevos mensajes, (asemejándose al conceptode polling) que hayan aparecido en el chat, de forma que los usuarios puedanmantener una comunicación. Este tipo de implementación no es la más óptimani eficiente, pero es sencilla y básica de implementar. En caso de que usáramossockets, se hubiera complicado mucho, pero sería mensajería más competitiva.

Para no estar constantemente descargando los mismos mensajes del servidor, he-mos implementado un endpoint sobre los mensajes de un chat que inicialmenterecibía un unix timestamp (inicialmente 0) y mostraba los mensajes creados apartir de esa marca temporal. Para no enviar demasiada información, se enviabanlos 100 mensajes inmediatamente posteriores a ese instante, y luego la aplicaciónvolvía a enviar una petición, pero esta vez con un unix timestamp igual al delmensaje con el valor mayor de éste que hubiese recibido, de forma que no se vol-vieran a pedir los mismos mensajes otra vez. Finalmente, decidimos cambiar elunix timestamp por la misma id del mensaje, ya que el identificador del mensajees secuencial y no depende de los relojes de los sistemas.

Nuestra aplicación no incorpora una base de datos en el cliente, así que no guar-damos los mensajes y se tienen que recuperar cada vez que se inicia el chat. Sinembargo, la implementación del chat está preparada para poder acoplarse con una,ya que mostrando los mensajes anteriores guardados y preguntando por los men-sajes desde el último identificador del mensaje conseguiríamos el mismo resultado.

68

12.2.8. Añadir perro

Esta funcionalidad es bastante simple, en el lado del cliente rellenaremos unoscuantos campos: nombre, género, peso, edad, raza, vacunación, esterilización, si esde protectora y descripción. Además, podremos añadir una imagen como avatar.

La única decisión técnica a tomar es como se gestiona la información de la razadel perro, en nuestro sistema tenemos definidas 313 razas de perros y a la hora deañadir un perro se tiene que escoger una de la lista, donde también hay una opciónpara perros mestizos que no se puedan clasificar en ninguna raza en concreto.

Tendría sentido entonces, definir la raza como un recurso y por tanto asociarlo aun endpoint como por ejemplo /breeds. Sin embargo, al ser una lista que no deberíamodificarse demasiado, consideramos que hacer una petición a la API solo pararellenar la lista de razas es una decisión no muy acertada a la hora de ahorrar-nos tráfico de red, y con ello datos móviles del usuario. Por este motivo, hemosdecidido incluir la lista de razas en la misma aplicación móvil para ahorrarnosestas transferencias. A la hora de enviar los datos, el servidor comprobaría que,efectivamente, se trata de una raza válida que está presente en el servidor.

12.2.9. Ver ubicación en mapa

Durante el desarrollo hemos intentado que la experiencia de usuario sea lo másinmersiva posible, es decir, queremos evitar que el usuario tenga que lanzar apli-caciones adicionales para usar las funcionalidades de la aplicación.

En el caso de esta funcionalidad, lo hemos logrado a través de una pantalla querecibe unas coordenadas geográficas como parámetro. Este parámetro nos servirápara actualizar una vista de mapa que se genera mediante una librería de Javallamada osmdroid (67), que es un reemplazo de la vista de mapa (o MapView)nativa de Android que funciona con los servidores de OpenStreetMap (26).

Hemos decidido prescindir de MapView ya que para poder usarlo se necesita unaAPI key de Google, ésta requiere que se rellene información de facturación queproporciona una cantidad determinada de solicitudes gratuitas, pero después dealcanzar ese número se empieza a cobrar por el uso, efecto que hemos queridoevitar mediante el uso de una alternativa de contenido abierto.

Adicionalmente, osmdroid permite dibujar un círculo con un radio dinámico paramarcar áreas de mapa, muy útil si queremos indicar ubicaciones como ubicacionesde usuarios preservando su privacidad. Además, hemos considerado la inclusión deun botón que permita acceder a la aplicación de Google Maps para su comodidad.

69

12.2.10. Ver leyes y regulaciones

Esta funcionalidad ha sido compleja de evaluar, ya que inicialmente la habíamosplanteado como un espacio dentro de la aplicación donde los usuarios pudiesenver todas las normativas y leyes referentes a paseos de perros. Sin embargo, notardamos demasiado en darnos cuenta que no hay artículos legislativos específicosde paseos de perros, sino que esta información se encuentra fragmentada entre laslegislaciones de animales domésticos, y que agregarla toda era demasiado com-plejo y complicado, por lo tanto, lo que hemos hecho para solventarlo es incluirtodas las leyes y regulaciones de animales domésticos (que además, varían segúnla comunidad autónoma), en lugar de las de paseo, que no existen de por sí.

Una vez encontramos la agrupación de estas normativas (68), las fuimos ordenandoy clasificando dentro de una vista de la aplicación, pero no queríamos que fuesensolo enlaces web. La solución para que el usuario tuviese una experiencia inmersivafue enlazar cada botón asociado a una ley o normativa con su respectivo artículojurídico en formato pdf, que de hecho suele ser más rico en imágenes que la propiaweb, donde se expone mayoritariamente en texto plano.

Esta solución resultaba a priori sencilla, pero nos encontramos con complicacionesdurante su implementación. La primera idea fue incluir una vista llamada Web-View, que se encarga de mostrar una página web en una vista, para que mostraseel pdf, pero nos dimos cuenta que Android no incorpora un lector de pdf nativo.

Sorprendentemente, la solución directa que nos ofrece la comunidad de desarro-lladores para este problema es utilizar un servicio de Google Drive como proxypara transformarlo en html. Dicha solución nos parecía nefasta ya que además elservicio limita el uso por dirección IP, así que recurrimos a una librería llamadaFile-Loader (69) para descargar el archivo en la caché de la aplicación (de hecho,probamos más librerías anteriormente pero tenían problemas, ya que descarga-ban los archivos pdf de forma incompleta), para posteriormente usar otra libreríallamada AndroidPdfViewer (70) para mostrarlo en una vista para los usuarios.

Figura 23: Diagrama de secuencia de la visualización de un archivo pdf externo

70

12.2.11. Ver/establecer calendario de disponibilidad

Hemos considerado que la mejor manera para poder ver/establecer el calendario dedisponibilidad de un usuario, era mediante una tabla de checkboxes compuesta de24 filas para cada hora que tiene un día y 7 columnas para cada día de la semana,así conseguimos que los usuarios puedan establecerla con suficiente detalle.

Para no complicar la estructura del layout de la funcionalidad, hemos decididoque generaríamos esas 168 checkboxes (7 días * 24 horas) en tiempo de ejecución,además, de ésta manera es más fácil guardar las referencias a las instancias de lascheckbox, hecho que facilita mucho el trabajo a la hora de leer o rellenar la tablaya que, por ejemplo, al enviar los datos, hay que mirar cuáles están seleccionadas.

Una vez el usuario rellena la tabla a su criterio, hace click en un botón de guardadoque envía los datos al servidor. Pero, ¿cómo enviamos la información de tantoselementos que pueden ser interpretados como sí o no? Inicialmente, decidimosafrontar este caso con el uso de bitmaps, pero el backend no disponía por defectode este tipo de datos, así que hemos decidido usar un string en donde cada caráctersea un 1 o un 0, según si la casilla está o debería de estar marcada (según sienviamos o consultamos), de ésta forma obtenemos un string de 168 caracteres.

12.2.12. Listar parques y fuentes de agua cercanas

Para poder mostrar los parques y fuentes de agua cercanas al usuario hemos hechouso de la Overpass API (25), pero nos hemos encontrado con el problema de queninguna de las librerías de OpenStreetMap (26) existentes para Java estaba actua-lizada y no nos podían ofrecer la consulta que queremos ejecutar, así que hemostenido que montarnos nosotros las llamadas y crear un adaptador compatible.

La consultas que se hacen a la API tienen una sintaxis propia que se llama OverpassQL (71), hecho que nos ha complicado la llamada ya que la librería que usamospara las llamadas de la app, retrofit (72), no soporta el binding o reemplazamientode variables dentro de un parámetro. Las queries que hemos utilizado para parquesy fuentes, son respectivamente, y sustituyendo LAT por latitud, LON por longitudy R por el radio en metros (fuentes 3 km, parques 10 km).

[out:json];rel[leisure=park](around:LAT,LON,R);out geom;[out:json];node[amenity=drinking_water](around:LAT,LON,R);out geom;

Para los parques, hay que calcular las coordenadas mediante la bounding box, yademás, hemos descartado las ubicaciones sin nombre por estética de la app.

71

12.3. Seeding de la base de datos

Para poder ir probando las historias de usuario desde la aplicación, y para enseñarla aplicación durante la defensa del proyecto como si ya tuviera mucho contenido,necesitábamos generar y/u obtener datos que nos ayudasen a “rellenar” el sistemapara que se viese lo más completo posible, ya que una app vacía no es atractiva.

Para ello, hemos recurrido al database seeding, una técnica que consiste en llenarla base de datos con información a la hora de crearla, pero, ¿de dónde la sacamos?,nosotros hemos recurrido a una multitud de APIs y librerías que están disponiblesen Internet para estos propósitos, que comentaremos a continuación:

Empezando por los usuarios, hemos usado una gem de Ruby llamada Faker (73)para generar los atributos de email, nombre de usuario, contraseña y nombre.Para éste, tenemos que determinar previamente si el usuario/a será una mujer oun hombre, y una una vez obtenido (hemos configurado previamente la libreríapara que se obtengan nombres españoles o hispanos), debemos añadirle una fotopara su respectivo perfil.

Desgraciadamente, la librería no nos proporciona fotos, así que las hemos obtenidomediante una API llamada Random User Generator (74), que nos proporcionaidentidades de usuarios con muchos datos, el motivo por el cual no hemos usado elnombre de estas identidades es porque no son nombre españoles o hispanos, sinoque son en mayoría ingleses, y queremos que nuestra aplicación parezca local.

A continuación, tenemos que generar las coordenadas de los usuarios, pero no po-demos escoger cualquiera que haya sido generada aleatoriamente. Recordemos que,la lista de perros cercanos se ordena por distancia geográfica, y que por tanto nosinteresa que estén lo más cerca posible de nosotros. Por este motivo, lo que hemoshecho ha sido generar coordenadas aleatorias alrededor de un punto geográfico, enun radio r, mediante otra gem de Ruby llamada RandomLocation (75) que hemosbuscado específicamente para este propósito (generar un punto de ésta manera noes tan intuitivo como parece, ya que se tiene que tener en cuenta factores como lacurvatura de la Tierra), de ésta manera conseguimos que los usuarios, y sus perros,estén repartidos por el área de Barcelona.

Seguidamente, también hay que hablar de los perros de los usuarios, que debentener también una foto de perfil, una raza, un género y un nombre. Como, lógica-mente, no hay APIs para nombres de perro, y menos si se tiene que diferenciar elhecho de que el perro sea macho o hembra, hemos tenido que buscar por Internety usar bastante imaginación, hasta que finalmente, hemos encontrado una web quegenera nombres de perro macho y hembra, según lo que necesitemos.

72

Esta web se llama Clickperros (76), hemos estado investigando y funciona de lasiguiente manera, en el código javascript de la página hay dos arrays de strings,según macho o hembra, con todos los nombres de perro, los cuales hemos extraído,filtrado y transformado a formato csv para usarlos en la selección del nombre delos perros durante la database seeding.

Ahora, hay que escoger una raza de perro de todas las posibles que tenemos en labase de datos (sobre unas 300), que de hecho, hemos extraído, filtrado y procesadode una web llamada InformePerros (77) a formato csv, y este fichero se carga alinicializar la base de datos.

Ahora solo nos queda determinar la raza del perro y adjuntarle una fotografía, queobviamente, tiene que ser la misma raza. Para obtener fotos de perros junto consu raza, usaremos una API llamada Dog API (78), que nos proporcionará fotosde perros, o bien aleatorias, o bien de una raza en concreto. Nosotros queremosobtenerlas de una en específico, ya que por eso las hemos recopilado todas, peronuestra lista está en castellano y la de la API usa unos alias, así que en el modelode la base de datos de la raza habrá que añadir un campo alias que nos permitaacceder a esta API con la raza, durante el database seeding, ya que con la API nose puede usar la representación en castellano.

Finalmente, previamente habiendo escogido la raza, accedemos a la Dog API yguardamos la foto del perro, del cual no hacemos distinción de si es macho ohembra, por razones obvias.

Si os fijáis, nunca guardamos las fotos físicamente en el servidor, ya sean de usuarioo de perro, sino que guardamos su dirección web, ésto nos libera de muchísimacarga y gasto de almacenamiento en el servidor, hecho que se tuvo en cuenta a lahora de decidir donde se guardarían las imágenes del servidor (recordemos que lasguardábamos en Cloudinary (24)).

73

13. Pruebas

13.1. Pruebas del backend

13.1.1. Modelos

Es muy importante asegurarse que no hay ningún comportamiento no deseadoen la lógica de negocio del sistema, para ello, hemos hecho un testing exhaustivode los modelos probando su comportamiento y el correcto funcionamiento de susasociaciones, podéis consultar la distribución de las pruebas en la siguiente tabla:

Modelo Total User Dog Chat Rating Message RefreshToken Breed AchievementN.o Pruebas 104 37 25 9 9 6 6 6 6

Tabla 12: Distribución de las pruebas de los modelos

A grandes rasgos, hemos probado los siguientes aspectos o características de losmodelos que hemos mencionado en la tabla 12 de resumen:

Presencia de atributos: para cada modelo, hay que validar qué atributos de-ben estar de forma obligatoria y cuáles son opcionales.

Formato de los atributos: para cada modelo, hay que validar el formato deciertos atributos, por ejemplo, el del email, el del nombre de usuario, etc.

Límites de atributos: para cada modelo, hay que validar el rango de ciertosatributos, por ejemplo, el intervalo numérico en el que debe pertenecer unatributo, o la medida máxima de los strings.

Asociaciones de los modelos: para cada modelo, hay que validar que se pue-dan formar asociaciones con los modelos con los que interactúa, por ejemplo,los perros con los usuarios, los mensajes con los chats, etc.

Reglas de negocio: para cada modelo, hay que validar algunas reglas quesurgen de su propia naturaleza. Por ejemplo, no debemos permitir que unusuario se valore o entable conversación con sí mismo.

Reglas de integridad: para cada modelo, hay que validar que los atributosque forman claves primarias hagan su función correctamente, ya que Railsnos fuerza por convención a usar los identificadores (ids) de los modelos.

Podéis encontrar los tests de los modelos en la carpeta app/test/models del proyec-to del backend, donde hay un fichero de tests por modelo. Estos tests nos serviránademás de base para los tests de los endpoints. Para ejecutarlos, usad rails test.

74

13.1.2. Endpoints

Ahora que, gracias a las pruebas de los modelos, ya nos hemos asegurado de quenuestro sistema no quede en un estado inconsistente, ya podemos añadir una capade validación por encima para evitar errores indeseados durante las llamadas a losendpoints de las historias de usuario, que es justo lo que testearemos ahora. Podéisconsultar la distribución de las pruebas en la siguiente tabla resumen:

Controlador Total Account Chats Tokens Users Dogs Auth RatingsN.o Pruebas 56 11 11 10 9 7 4 4

Tabla 13: Distribución de las pruebas de los endpoints

Es importante que mencionemos que la distribución es diferente a la de los modelos,ya que cada algunos controladores se encargan de más modelos que otros, porejemplo, el controlador de chats se encarga de los chats y de los mensajes a la vez.

A grandes rasgos, hemos probado los siguientes aspectos o características de locontroladores que hemos mencionado en la tabla 13 de resumen:

Códigos de estado: para cada endpoint, hay que comprobar que se devuelveel código de estado apropiado según la naturaleza de la consulta, por ejemplo,404 si el recurso no existe, 201 si se ha creado un recurso, etc.

Presencia, formato y límites de atributos: para cada endpoint, hay que vol-ver a hacer las mismas comprobaciones que hacíamos con los modelos, yaque no queremos gastar recursos ejecutando el método del endpoint si losparámetros de entrada son incorrectos ya al empezar (las validaciones de losmodelos son un respaldo para garantizar la consistencia de la base de datos).

Reglas de negocio: para cada endpoint, hay que volver a validar las reglas denegocio antes de que lleguen al modelo, con tal de devolver el código de estadoapropiado, por ejemplo, si intentamos registrar un usuario con un email queya existe para otra persona registrada mediante esa vía o intentamos crearun chat entre dos personas que ya existe, devolveremos el código de estadode conflicto 409.

La funcionalidad que se ha probado más extensamente es la del listado de perros,que corresponde al endpoint /dogs?num_page=x (donde x es el número de página).Con su prueba comprobamos que todos los perros están correctamente repartidosentre las páginas y ordenados de menor a mayor según la distancia geográfica.

Podéis encontrar los test de los endpoints en la carpeta app/spec/controllers delproyecto del backend, donde hay un fichero de test por grupo de endpoints. Paraejecutarlos, basta con lanzar el comando rspec en la carpeta del proyecto.

75

13.2. Pruebas del frontend

13.2.1. Monkey testing

Uno de los métodos que vamos a usar para testear la aplicación se llama Monkeytesting (79), básicamente consiste en que un programa genere miles de eventosaleatorios de la interfaz de usuario de forma muy rápida, por ejemplo, hacer clicken un botón, abrir un menú, escribir en un recuadro, etc. Se podría decir que es untest de estrés de la interfaz que ayuda a descubrir errores, los cuáles suelen pasardesapercibidos durante la ejecución normal de las historias de usuario.

Mediante la repetición de esta prueba, hemos conseguido encontrar algunos fallosque, de otra forma, no hubiésemos podido encontrar. Así pues, este método detesteo nos ayuda a mejorar la estabilidad de nuestra aplicación.

13.2.2. Pruebas con usuarios reales

Adicionalmente, hemos realizado un seguido de pruebas a 4 usuarios mediante unguión, para ver como de usable es nuestra aplicación, el guión es el siguiente:

1. Regístrate mediante email.2. Modifica tu perfil: cambia el nombre por defecto al tuyo y añade una foto.3. Añade un perro.4. Explora la lista de perros cercanos, y entra en el perfil de uno.5. Mira el perfil de su dueño.6. Mira en el mapa su ubicación aproximada.7. Envíale un mensaje.8. Establece tu disponibilidad horaria a: lunes de 13 a 18.9. Consulta tus logros.10. Valora a un usuario.11. Cierra sesión.

Para cada paso, hemos recopilado los comentarios de los usuarios con críticasconstructivas para mejorar la aplicación, y que agregamos a continuación:

Usuario A: Hay algunas pantallas donde el teclado tapa lo que escribes.

Usuario B: En los mensajes del chat tendría que salir el autor y la hora.

Usuario C: No queda claro que es el símbolo azul en la lista de perros.

Usuario D: Los radio-buttons tendrían que tener otro color (no verde).

76

14. Planificación final y desviaciones

La planificación inicial y la final, que podéis consultar respectivamente en el anexoB y en el C, han cambiado en algunos aspectos, que se deben principalmente atres factores implicados:

1. El proyecto se ha empezado más tarde de lo previsto, entre el final de lagestión del proyecto (7 de octubre) y el inicio del desarrollo (22 de octubre)transcurrieron 15 días que se tomaron como descanso.

2. La aparición de nuevas historias de usuario, las cuales se habían pasado poralto en la planificación, en el Gantt final están marcadas de color naranja.

3. Las vacaciones que se tomaron de descanso entre el inicio de navidad (22 dediciembre) y el final de reyes (8 de enero).

Tarea Horas reales Horas planificadas DiferenciaFamiliarizarse con Android 60.00 h 60 h + 0.00 hFamiliarizarse con Rails 60.00 h 60 h + 0.00 hGestión del proyecto 75.25 h 75.25 h + 0.00 h

Preparación de los repositorios 0.25 h 4 h - 3.75 hInstalación y configuración de herramientas 14.56 h 12 h + 2.56 h

Registro de usuario 10.59 h 12 h - 1.41 hLogin con email 10.59 h 12 h - 1.41 hLogin con Google 29.13 h 12 h + 17.13 hLogin con Twitter 8.54 h 12 h - 3.46 h

Reseteo de contraseña 8.87 h 8 h + 0.87 hVer perfil de perro 15.79 h 20 h - 4.21 h

Listar perros cercanos 13.24 h 22 h - 8.76 hVer perfil de usuario 10.21 h 10 h + 0.21 hUpload de imágenes 8.54 h - + 8.54 h

Modificar perfil de perro 10.13 h - + 10.13 hModificar perfil de usuario 6.93 h - + 6.93 h

Añadir perro 11.47 h - + 11.47 hVer perros de usuario 8.62 h - + 8.62 h

Eliminar perro 4.75 h - + 4.75 hProgramar un paseo - 20 h - 20.00 h

Listar parques y fuentes de agua cercanas 16.35 h 30 h - 13.65 hEstablecer calendario de disponibilidad 7.81 h 12 h - 4.19 h

Ver calendario de disponibilidad 7.81 h 12 h - 4.19 hChatear con otro usuario 22.84 h 30 h - 7.16 h

Valorar usuario 7.23 h 16 h - 8.77 hVer valoraciones de usuario 8.04 h 8 h + 0.04 hIntegrar sistema de medallas 7.91 h 16 h - 8.09 hVisualizar consejos útiles 8.32 h 8 h + 0.32 h

Visualizar leyes y regulaciones 12.31 h 12 h + 0.31 hPreparación de la defensa 12.00 h 12 h + 0.00 h

Total 478.08 h 495.25 h - 17.17 h

Tabla 14: Diferencias en la planificación

77

15. Conclusiones

15.1. Satisfacción de los objetivos iniciales

Aún teniendo ciertas dificultades en la planificación del proyecto, ya que a lahora de diseñarla no habíamos considerado las siguientes historias de usuario:modificación del perfil de usuario, modificar perfil de perro y eliminar perro, hemosconseguido satisfacer todos los objetivos iniciales del proyecto.

De forma concreta, tal y como hemos mencionado en los objetivos del proyecto,hemos logrado el diseño e implementación de una aplicación de Android (juntocon su respectivo backend) que permita a su público el uso de historias de usuariorelacionadas con el concepto de perros y personas: perfiles, valoraciones, etc., juntocon los subobjetivos que habíamos planteado, como el hecho de que los paseadorespuedan encontrar parques y fuentes de agua potable, ver consejos útiles de paseos,consultar aspectos legales, etc.

Sin embargo, la funcionalidad de “Programar un paseo” ha sido delegada comoparte del chat, con tal de facilitar la interacción entre usuarios que sobretodofuesen regulares en la aplicación. Consideramos que el término paseo llega a seruna restricción ligada a la disponibilidad, y que los usuarios, en cierta manera,llegan a ser flexibles o acordar algunos tratos usando el chat.

El chat, tiene como objetivo la toma de contacto inicial entre el propietario y elpaseador, ya que como suele ser el caso en la mayoría de aplicaciones, el contactose acaba migrando a servicios de mensajería más comunes, como por ejemploWhatsApp y similares.

Viendo el proyecto en retrospectiva, nos hubiese ayudado el hecho de haber con-siderado mejor las posibles pantallas de la aplicación, con tal de determinar lashistorias de usuario más detenidamente para el ajuste de la planificación de nuestroproyecto.

78

15.2. Satisfacción de las competencias técnicas

15.2.1. CES1.3

Identificar, evaluar y gestionar los riesgos potenciales asociados a la construcción de software.

Nivel de satisfacción: Un poco

Especialmente en el inicio del proyecto, hemos considerado los riesgos a los cualesnuestro sistema se puede someter, es por eso que ya con la contratación del servi-dor para el backend hemos dedicado mucho esfuerzo en fortalecerlo contra posiblesataques externos. A lo largo de una de las primeras tareas, “Instalación y configura-ción de herramientas” (12.2.1), hemos especificado como hemos protegido nuestroservidor con medidas, como por ejemplo la imposición de ssh keys para el manejoremoto, el uso de contraseñas seguras en el sistema, así como la desactivación delacceso mediante el usuario root, el uso de un certificado SSL para garantizar laseguridad de las conexiones, etc.

Además, hemos tenido también en cuenta factores como validar el input del usuario(80) (recomendado por la OWASP) e incluso aunque no lo hayamos mencionadodurante el proyecto, estamos protegidos contra ataques del tipo SQL injection (quese basa en la modificación del funcionamiento de una sentencia SQL) ya que Rubyon Rails recomienda el uso de prepared statements, que es justo lo que usamos a lolargo del desarrollo (y por supuesto, no operamos queries como si fueran strings).

15.2.2. CES1.4

Desarrollar, mantener y evaluar servicios y aplicaciones distribuidas con soporte de red.

Nivel de satisfacción: En profundidad

Cada usuario de la aplicación móvil se conecta, vía internet, al backend de nuestraaplicación web mediante llamadas a la REST API que hemos integrado en nuestrosistema. Dicha comunicación precisa de algunos elementos de control, como porejemplo la gestión de errores o la interpretación de mensajes de estado.

La hemos desarrollado en profundidad, ya que es un elemento vital para que nuestraaplicación pueda funcionar. En un proyecto de este tipo, las dos partes tienen quefuncionar conjuntamente o no será capaz de ofrecer sus funcionalidades.

79

15.2.3. CES1.7

Controlar la calidad y diseñar pruebas en la producción de software.

Nivel de satisfacción: Un poco

Hemos asegurado el correcto funcionamiento de nuestra aplicación, tanto comodesde el punto de vista del uso de los usuarios como de la lógica y las funciona-lidades presentes en el backend, es decir, además de usar Unit Testing, tenemostambién validaciones para asegurarnos de que el sistema no está sujeto a errores.

El grado de satisfacción establecido es ‘Un poco’, ya que hemos mantenido laspruebas simples, sin hacerlas demasiado complejas.

15.2.4. CES1.9

Demostrar comprensión en la gestión y gobierno de los sistemas software.

Nivel de satisfacción: Un poco

Nuestro proyecto tiene una base de datos, que es propensa a contener informaciónde los usuarios. Dichos datos, tienen que ser manejados correctamente de acuerdoa la LOPD (Ley Orgánica de Protección de Datos de Carácter Personal).

Hemos determinado que el grado de satisfacción es ‘Un poco’, ya que guardaremosla información mínima y necesaria de los usuarios, y que por tanto, sabemos yconsideramos que tienen que ceñirse a las regulaciones de esta ley.

15.2.5. CES2.1

Definir y gestionar los requisitos de un sistema software.

Nivel de satisfacción: Bastante

El sistema software de nuestro proyecto define todos sus requisitos. Los enumeray los documenta en su respectivo apartado, hemos determinado que los requisi-tos funcionales de la aplicación corresponden a las historias de usuario y los nofuncionales a aspectos técnicos relacionados con la satisfacción del usuario.

Hemos calificado el grado de satisfacción a ‘Bastante’, ya que se han trabajado condetalle en su respectivo apartado del proyecto.

80

15.3. Trabajo futuro

Si la recepción del público a la aplicación es positiva, plantaremos las siguientesmejoras o estrategias a nuestro proyecto con tal de facilitar su crecimiento:

Integración con los sistemas de las protectoras: mediante la gestiónautomatizada de los perros de éstas, conseguiremos una mejor presencia delos animales y facilitar el trabajo de responsables en la aplicación.

Mejoras del sistema: podemos añadir nuevas funcionalidades a la apli-cación que le otorguen valor añadido, por ejemplo, botones para compartirrecursos con redes sociales, funcionalidades sugeridas por usuarios que hayansido recibidas mediante feedback, etc.

Traducción a otros idiomas: para llegar a un público más extenso, yademás, podemos considerar la posibilidad de plantearla para otros países.

Inclusión de publicidad: para poder asumir los gastos de escalabilidaddurante el crecimiento de la aplicación, podemos exponer anuncios relacio-nados con cosas de perros (comida, juguetes, etc.) que ayuden a pagar elservicio que proveemos, y si hubiera ingresos adicionales, los podríamos do-nar selectivamente a las protectoras de la aplicación.

Patrocinio y difusión de la aplicación: podemos pedir a grandes empre-sas de la industria relacionada con los perros que publiciten nuestra aplica-ción, ya que se asocia a una causa benéfica, de esta manera nosotros ganamosrepresentación y las empresas ganan en perspectiva social.

Creemos que el trabajo a un ritmo constante después de la publicación de laaplicación ayudaría a generar más público en forma de usuarios y a su difusiónentre personas, además de mejorar la valoración de los usuarios sobre la aplicación.

81

A. Entrevistas a protectoras

A.1. SOS Animales de Balanegra

Soy Isabel María Linares, fundadora y voluntaria de la asociación animalista sinánimo de lucro SOS Animales de Balanegra en Almería.

1. ¿Cuántos perros suele haber de media en la protectora?

Pues varía dependiendo de la época en la que nos encontremos, en periodos va-cacionales el número de abandonos aumenta y por ende, el número de rescatesy aforo en la protectora, en el caso de nuestra asociación tenemos animales encasas de acogida temporal y además contamos con un pequeño terreno adaptadopara albergar un máximo de 15 perros. Actualmente contamos con 13 perros en elterreno y 7 en casas de acogida.

2. ¿Resulta complicado encontrar hogar a los perros de la protectora?

Bastante, la gente poco a poco se va concienciando cada vez más, aunque aquí enAlmería cuesta, el porcentaje de abandono es mucho más elevado al porcentaje deadopciones, muchas de las adopciones se caen debido a que para llevarse a cabohacemos un contrato de seguimiento y vacunación (además de castración en casode cachorros), y es un grado de compromiso para el bienestar de nuestros perrosque mucha gente no acepta. En nuestro caso, el 80% de adopciones se llevan acabo fuera de España, las protectoras extranjeras conocen el estado en el quese encuentran nuestros animales y gestionamos a través de ellas las adopciones,concretamente nuestros perros viajan hasta Alemania y Francia.

3. ¿Cuántos voluntarios/as hay actualmente en la protectora?

Actualmente somos 16 voluntarios los que nos encargamos según disponibilidad de,por turnos de 3 o 4 personas del cuidado diario de los animales que se encuentranen nuestras instalaciones, tareas como pasearlos, rellenar comederos y bebederos,y en caso de necesitarlo, medicarlos o llevar a cabo curas.

4. ¿Es habitual la incorporación de nuevos voluntarios/as en la protectora?

Según la disponibilidad tenemos, como mencioné antes a 16 voluntarios habitualesy esporádicamente surgen voluntarios puntuales qué o bien por tiempo o por edad,no tienen tanta disponibilidad diaria, éstos nuevos voluntarios nos ayudan con eltransporte, difusión, cuidado, rescates, en eventos de recogida de pienso, decorandoartículos que ponemos a la venta o vendiendo papeletas para los sorteos de laasociación.

82

5. ¿Cuáles son las tareas en las que se emplea más tiempo dentro de una protectora?

La tarea en la que más tiempo empleamos es en el cuidado diario de los animales,una vez al día visitamos a los perros que hay en el terreno para echarles comiday agua, pasearles, y limpiar sus habitaciones, aproximadamente empleamos unamedia de 3 horas en hacer todo lo anterior.

6. ¿De dónde provienen los diversos ingresos económicos de la protectora?

Nuestra asociación subexiste gracias a las donaciones de la gente, a lo que recauda-mos vendiendo artículos que compramos al por mayor o hacen nuestros voluntariosde forma artesanal y a lo recaudado con las papeletas de los sorteos que hacemosen beneficio de los animales.

7. ¿Se cubren los gastos de la protectora con las subvenciones y donaciones recibidas?

Sí, tenemos la suerte de que la gente participa sobre todo en los sorteos que realiza-mos y comprando los artículos que ponemos a la venta, la verdad que no tenemosdemasiado problema en la recaudación y pago de gastos, aunque todo depende delos rescates y la gravedad de éstos.

8. ¿Los establecimientos o empresas colaboran con vuestras causas? ¿De qué manera?

Contamos con la ayuda de varios establecimientos del pueblo, que nos ayudancomo puntos de recogida de donaciones de pienso, poniendo a la venta nuestrosartículos, colocando nuestras huchas benéficas y difundiendo las imágenes de nues-tros perros. También recibimos ayuda de grandes supermercados que nos facilitansus instalaciones para llevar a cabo recogidas benéficas de pienso y artículos dehigiene para el cuidado y mantenimiento los animales de la asociación.

9. ¿Crees que los paseos tienen beneficios psicológicos en los perros?

Por supuesto, además de por la propia salud física del perro ejercitándose durantelos paseos, también éstos ayudan a su actividad mental de varias formas, puesel perro obtendrá beneficios en su estado de ánimo y al socializar interactuandocon otros perros y humanos ayudará a reforzar lazos con ambos. De esta maneraevitaremos que los perros sufran ansiedad, estrés, depresión o se vuelvan agresivos,comportamientos típicos de perros no socializados.

83

10. ¿Crees que el hecho de que alguien (externo o de la protectora) pasee a un perroesté relacionado con la posibilidad de que lo adopte?

Si, de hecho se han dado casos en nuestra asociación de voluntarios que debido alcontacto que han tenido con algún perro, se ha decidido finalmente a adoptarlo, yaque se establecen lazos entre la persona encargada del paseo o su cuidado y el perroen cuestión, y que mejor que alguien que conoce a la perfección las necesidades ypersonalidad del animal debido a pasar tiempo con el mismo.

11. ¿Cuáles son las mayores fuentes de difusión social de los perros?

Pues nosotros la mayor fuente de difusión que tenemos es una página de Facebooken la cual, se postean los casos, fotos y vídeos de los animales que vamos rescatando,se va actualizando el estado de los perros, tanto de los que siguen buscando hogarcomo de los que ya encontraron una familia, y desde la página de Facebook sepide difusión de los mismos compartiendo las publicaciones para llegar al máximopúblico, y a través de ésta se consiguen la mayoría de las adopciones.

12. ¿Qué opinas del modelo de paseo de perros remunerado que está tan de moda?

Me parece bien para la persona particular que pueda pagarlo y no tenga dispo-nibilidad para cubrir las necesidades de su mascota. Por parte de los paseadorespues entiendo que hay dos tipos: los que recurren a ésto por necesidad, ya queno tienen otro trabajo y lo toman como un trabajo más y por otro lado, los queencuentran una forma de pasar tiempo con animales si no tienen forma de tenerlosde manera propia, como un hobby, llevándose a cambio y de forma secundaria unaretribución.

13. ¿Conoces la idea de pet sharing o cuidado sin ánimo de lucro de mascotas ajenas?

Sí, me parece perfecta ésta idea por dos motivos, el motivo número uno es que esideal para casos como el nuestro, debido a la demanda de atención por parte de losanimales y la escasez de tiempo para cubrirla, ya que encontraríamos voluntariosde una manera más sencilla, por ejemplo, para aumentar el número de paseosde nuestros perros, y el segundo motivo es porque te aseguras de que la personaencargada del cuidado lo hace de una forma desinteresada y lo hace realmenteporque le gusta y el perro va a estar cuidado y atendido el tiempo que este con élo ella.

84

14. ¿Crees que una app de paseo de perros sin ánimo de lucro es llamativa e interesante?

Sin duda, este tipo de aplicaciones resultan novedosas e interesantes, ya que traenbeneficios a todas las partes involucradas en la misma, que las personas que quierenestar con perros y por sus motivos no tengan acceso, puedan hacerlo, a las personasque no dispongan del tiempo necesario para cuidar a sus mascotas y soliciten unapersona que pueda hacerlo, y sobre todo los perros, ya que es el motivo principalque se busca, que ellos estén felices y cuidados.

15. ¿Crees que sería beneficioso para la protectora el añadir los perros a la aplicación?¿De qué manera?

Si, como dije antes por motivos laborales y de tiempo, ya que todos los miembros dela asociación tenemos un trabajo a parte, solo podemos ir una vez al día a paseary sacar a los perros de la protectora, este tipo de app’s son muy interesantesporque ayudan a cubrir de una mejor manera estos cuidados y ésto repercute enla mejora de calidad de vida de los animales que tenemos, además de que se daríauna mayor difusión para que se conozcan nuestros perros y que por ésto puedanllegar a encontrar un hogar al ser una nueva plataforma de difusión.

85

A.2. Refugio de perros abandonados Bú Bup Parc

1. ¿Cuántos perros suele haber de media en la protectora?

Nosotros tenemos como límite 70 perros, normalmente estamos en los 63-64.

2. ¿Resulta complicado encontrar hogar a los perros de la protectora?

Siempre depende del perfil de perro. Hemos visto que las hembras, igual que seabandonan menos, salen mas en adopción que los machos. También hemos vistoque los perros que son negros, salen menos que los de color más claro. Los perrosconsiderados PPP (perro potencialmente peligroso), tienen menos posibilidades desalir en adopción que otras razas, igual que los perros miedosos también (respectoa la media) menos posibilidades de encontrar casa. Como supongo que en todoslos refugios, los que primero salen son los cachorros.

3. ¿Cuántos voluntarios/as hay actualmente en la protectora?

Disponemos de unos 20 voluntarios veteranos que hacen años que vienen y suelenvenir fijos uno o dos días a la semana. Luego están los que van viniendo muyde vez en cuando. Actualmente en los fines de semana, que son los días que másvoluntarios vienen, conseguimos que salgan casi todos los perros de paseo, así quetenemos más o menos unos 70 voluntarios que vienen de paseo.

4. ¿Es habitual la incorporación de nuevos voluntarios/as en la protectora?

Siempre vienen voluntarios nuevos, sobretodo con niños pequeños, parece que cadavez más se intenta inculcar a los niños el tema de abandonos y cuidar perros.

5. ¿Cuáles son las tareas en las que se emplea más tiempo dentro de una protectora?

La tarea a la que le dedicamos mas tiempo es el mantenimiento de la limpieza,ya que 70 perros ensucian mucho. Intentamos organizarnos de forma que se puedatrabajar mucho (reconducir conductas, presentaciones, etc.), aún así no le podemosdedicar todo el tiempo que nos gustaría.

6. ¿De dónde provienen los diversos ingresos económicos de la protectora?

Mayoritariamente los ingresos vienen de socios, también a base de adopciones yservicio de residencia.

7. ¿Se cubren los gastos de la protectora con las subvenciones y donaciones recibidas?

Se cubren las necesidades básicas para que ellos puedan comer, puedan ser medi-cados, puedan ir al veterinario, se les pueda operar, etc. Los trabajadores vemosnecesidades adicionales que normalmente necesitan más recaudación, como refor-zar vallas, llenar la balsa de agua, etc.

86

8. ¿Los establecimientos o empresas colaboran con vuestras causas? ¿De qué manera?

Actualmente no.

9. ¿Crees que los paseos tienen beneficios psicológicos en los perros?

Hay paseos colectivos, los cuales sirven para que los perros corran y se desahoguen.Luego intentamos que haya paseos individuales, donde se les puede enseñar a notirar de la correa, trabajar obediencia, y que el perro disfrute de una atención in-dividualizada. Sea como sea el paseo, a los perros les da un refuerzo psicológico, yaque a muchos les cuesta entender que aquí nunca más serán maltratados. Tambiénes refuerzo que tengan contacto con diferentes personas, con niños, perros de fuera,etc.

10. ¿Crees que el hecho de que alguien (externo o de la protectora) pasee a un perroesté relacionado con la posibilidad de que lo adopte?

Aumentan las posibilidades ya que el perro queda mas trabajado. Quizás un perroque podía ser más miedoso o con conductas agresivas, puede quedar más recondu-cido a base de esos trabajos.

11. ¿Cuáles son las mayores fuentes de difusión social de los perros?

Nosotros los difundimos en Facebook, también intentamos ir a eventos con ellos,donde se pueden ver más.

12. ¿Qué opinas del modelo de paseo de perros remunerado que está tan de moda?

Creemos que bastante importante siempre que la persona sepa a que manos deja asu perro. Hay muchas personas que no pueden dedicarle el tiempo necesario a lospaseos, y eso puede provocar a los perros ansiedad, malas conductas, etc. Creemosque para evitar estos tipos de situaciones, es aceptable este tipo de paseo.

13. ¿Conoces la idea de pet sharing o cuidado sin ánimo de lucro de mascotas ajenas?

Puede ser una opción que puede salir mal igual que bien, creo que eso es más bienpersonal. Yo personalmente no accedería a ése tipos de aplicaciones, buscaría unasolución alternativa.

14. ¿Crees que una app de paseo de perros sin ánimo de lucro es llamativa e interesante?

Supongo que lo es para personas que no pueden asumir el gasto. Personalmentecreo que cuando una persona se compromete a cuidar de su mascota, antes detodo, tiene que saber su condición económica, y tener presente que si en algúnmomento no sea capaz de cubrirle esa necesidad, contar o con una residencia o conun paseador “oficial”.

87

15. ¿Crees que sería beneficioso para la protectora el añadir los perros a la aplicación?¿De qué manera?

Sí, podría ser una buena opción. Nosotros tenemos el formato en papel, dondecada día marcamos a los perros que han salido de paseo, así en días puntuales,podemos valorar que perros han salido menos de paseo, y hacer que salgan más.Claro que en digital se nos haría más fácil. Es una buena idea.

88

A.3. Sociedad Protectora de Animales y Plantas de Madrid

1. ¿Cuántos perros suele haber de media en la protectora?

Actualmente acogemos a unos 400 animales en nuestro albergue, entre perros ygatos.

2. ¿Resulta complicado encontrar hogar a los perros de la protectora?

Requiere algo de dedicación, se realiza entrevista y cuestionario preadopción. Esimportante el uso de todos los medios que disponemos para garantizar el bienestaranimal. En cualquier caso, es siempre más difícil que acoger a animales en abandonoo maltrato.

3. ¿Cuántos voluntarios/as hay actualmente en la protectora?

6 de forma continua y otros tantos de forma ocasional, también en redes 2 másque difunden y ayudan a que estemos más al día.

4. ¿Es habitual la incorporación de nuevos voluntarios/as en la protectora?

Es habitual que al menos nos soliciten información de cómo ayudar. Dependiendodel perfil de cada uno pueden ser muy útiles en diferentes campos.

5. ¿Cuáles son las tareas en las que se emplea más tiempo dentro de una protectora?

Fundamentalmente Protocolo CES de gestión de colonias felinas de la calle, segui-mientos de casos de maltrato, rescates de callejeros en mal estado.

6. ¿De dónde provienen los diversos ingresos económicos de la protectora?

De nuestros socios, de las adopciones, donaciones, mercadillos, etc.

7. ¿Se cubren los gastos de la protectora con las subvenciones y donaciones recibidas?

Habitualmente no.

8. ¿Los establecimientos o empresas colaboran con vuestras causas? ¿De qué manera?

Siempre que se trata de animales se suele encontrar colaboración, aunque quedamucho por recorrer en este campo.

9. ¿Crees que los paseos tienen beneficios psicológicos en los perros?

Sí, se genera un buen vínculo.

10. ¿Crees que el hecho de que alguien (externo o de la protectora) pasee a un perroesté relacionado con la posibilidad de que lo adopte?

No siempre, pero hemos tenido casos.

89

11. ¿Cuáles son las mayores fuentes de difusión social de los perros?

Correos electrónicos y redes sociales.

12. ¿Qué opinas del modelo de paseo de perros remunerado que está tan de moda?

Si el propietario no puede encargarse, es una alternativa, pero siempre se debeasegurar una buena formación.

13. ¿Conoces la idea de pet sharing o cuidado sin ánimo de lucro de mascotas ajenas?

Conocemos alguna aplicación, pero nunca hemos trabajado con sistemas comoéstos.

14. ¿Crees que una app de paseo de perros sin ánimo de lucro es llamativa e interesante?

Sí, pero siempre que el personal esté bien formado.

15. ¿Crees que sería beneficioso para la protectora el añadir los perros a la aplicación?¿De qué manera?

No tanto al albergue, si no para formación e información de casas de acogida ynuevas adopciones.

90

B. Diagrama de Gantt

Figura 24: Diagrama de Gantt91

92

C. Diagrama de Gantt final

Figura 25: Diagrama de Gantt final

Referencias

[1] Katherine Jacobs Bao and George Schreer. Pets and happiness: Examining theassociation between pet ownership and wellbeing. Anthrozoös, 29(2):283–296,2016. doi:10.1080/08927936.2016.1152721. URL https://www.tandfonline.com/doi/abs/10.1080/08927936.2016.1152721.

[2] Anna-Yezica Norling and Linda Keeling. Owning a dog and working: Atelephone survey of dog owners and employers in sweden. Anthrozoös, 23(2):157–171, 2010. doi:10.2752/175303710X12682332910015. URL https://www.tandfonline.com/doi/abs/10.2752/175303710X12682332910015.

[3] Luis Benvenuty. Barcelona quiere que los perros vayan atados por los par-ques. La Vanguardia, 2018. URL https://www.lavanguardia.com/local/barcelona/20180616/45134567267/perros-correa-parques.html.

[4] Valli Parthasarathy and Sharon Crowell-Davis. Relationship between attach-ment to owners and separation anxiety in pet dogs ( canis lupus familia-ris). Journal of Veterinary Behavior: Clinical Applications and Research,1:109–120, 11 2006. doi:10.1016/j.jveb.2006.09.005. URL https://www.journalvetbehavior.com/article/S1558-7878(06)00116-X/fulltext.

[5] Sandra Mccune. The health benefits of dog walking for pets andpeople. Purdue University Press, 01 2011. ISBN 978-1-55753-582-5. URL https://www.researchgate.net/publication/290438903_The_health_benefits_of_dog_walking_for_pets_and_people.

[6] Gudrun Braun. Taking a shelter dog for walks as an impor-tant step in the resocialization process. Journal of VeterinaryBehavior: Clinical Applications and Research, 6:100–100, 02 2011.doi:10.1016/j.jveb.2010.08.004. URL https://www.journalvetbehavior.com/article/S1558-7878(10)00108-5/fulltext.

[7] Luciana Bergamasco, Maria Cristina Osella, Paolo Savarino, Giuseppe Laro-sa, Laura Ozella, Monica Manassero, Paola Badino, Rosangela Odore, Raf-faella Barbero, and Giovanni Re. Heart rate variability and saliva cor-tisol assessment in shelter dog: Human–animal interaction effects. Ap-plied Animal Behaviour Science, 125(1):56 – 68, 2010. ISSN 0168-1591.doi:10.1016/j.applanim.2010.03.002. URL http://www.sciencedirect.com/science/article/pii/S0168159110000985.

[8] Bennett P Howell T, King T. Puppy parties and beyond: the role of early

93

age socialization practices on adult dog behavior. Dove Medical Press, pages143–153, 4 2015. doi:10.2147/VMRR.S62081.

[9] P.S. Yam, C.F. Butowski, J.L. Chitty, G. Naughton, M.L. Wiseman-Orr,T. Parkin, and J. Reid. Impact of canine overweight and obesity on health-related quality of life. Preventive Veterinary Medicine, 127:64 – 69, 2016.ISSN 0167-5877. doi:10.1016/j.prevetmed.2016.03.013. URL http://www.sciencedirect.com/science/article/pii/S0167587716300988.

[10] A.J. German, S.L. Holden, M.L. Wiseman-Orr, J. Reid, A.M. Nolan, V. Bio-urge, P.J. Morris, and E.M. Scott. Quality of life is reduced in obese dogsbut improves after successful weight loss. The Veterinary Journal, 192(3):428 – 434, 2012. ISSN 1090-0233. doi:10.1016/j.tvjl.2011.09.015. URL http://www.sciencedirect.com/science/article/pii/S1090023311003698.

[11] Anna Nyström. Agile solo : Defining and evaluating an agile software de-velopment process for a single software developer. Master’s thesis, Chal-mers University of Technology, SE - 412 96 Göteborg, Sweden, 6 2011. URLhttp://publications.lib.chalmers.se/records/fulltext/147143.pdf.

[12] GitLab. Gitlab, 2019. URL https://gitlab.com. Accedido el 15-01-2019.

[13] Atlassian. Trello, 2019. URL https://trello.com. Accedido el 15-01-2019.

[14] Clockify. Clockify - time tracker, 2019. URL https://clockify.me. Accedidoel 15-01-2019.

[15] PayScale. Salary data & career research center (spain), 2018. URL https://www.payscale.com/research/ES/. Accedido el 05-10-2018.

[16] OECD. Average annual hours actually worked. OECD Journal,2014. doi:10.1787/data-00303-en. URL https://www.oecd-ilibrary.org/content/data/data-00303-en.

[17] National Energy Foundation. Simple carbon calculator, 2017. URL http://www.carbon-calculator.org.uk/. Accedido el 08-10-2018.

[18] Suzanne Robertson and James Robertson. Mastering the Requirements Pro-cess: Getting Requirements Right (3rd Edition). Addison-Wesley Professio-nal, 2012. ISBN 0321815742. URL https://books.google.es/books?id=yE91LgrpaHsC.

[19] A. Wohlin Aurum. Engineering and Managing Software Requirements. Sprin-ger, 2005. ISBN 3540250433. URL https://books.google.es/books?id=pUG1IaikDhMC.

94

[20] J. Robertson and Suzanne Robertson. Volere. Requirements SpecificationTemplate. Edition 6.0. Technical report, Atlantic Systems Guild, 1998.

[21] SendGrid. Sendgrid, 2019. URL https://sendgrid.com. Accedido el 20-11-2018.

[22] Google. Google, 2019. URL https://google.com. Accedido el 09-01-2019.

[23] Twitter. Twitter, 2019. URL https://twitter.com. Accedido el 09-01-2019.

[24] Cloudinary. Cloudinary, 2019. URL https://cloudinary.com. Accedido el09-01-2019.

[25] OpenStreetMap. Overpass api, 2019. URL https://wiki.openstreetmap.org/wiki/Overpass_API. Accedido el 09-01-2019.

[26] OpenStreetMap. Openstreetmap, 2019. URL https://www.openstreetmap.org. Accedido el 09-01-2019.

[27] Rakhitha Nimesh. Active record basics. Rails Guides, 2018. URLhttps://guides.rubyonrails.org/active_record_basics.html#the-active-record-pattern. Accedido el 09-01-2019.

[28] Ruby on Rails | A web application framework. Active record basics, 2019.URL https://rubyonrails.org. Accedido el 09-01-2019.

[29] Alexander Shvets. Design patterns - adapter. Refactoring Guru, 2018. URLhttps://refactoring.guru/design-patterns/adapter. Accedido el 09-01-2019.

[30] Google. Recyclerview. Android Developers, 2018. URL https://developer.android.com/reference/android/support/v7/widget/RecyclerView.Accedido el 09-01-2019.

[31] IBM. Understanding model-view-controller. IBM Knowledge Center, 2018.URL https://www.ibm.com/support/knowledgecenter/en/SSZLC2_8.0.0/com.ibm.commerce.developer.doc/concepts/csdmvcdespat.htm. Acce-dido el 10-01-2019.

[32] Google. Activity. Android Developers, 2018. URL https://developer.android.com/reference/android/app/Activity. Accedido el 09-01-2019.

[33] Alexander Shvets. Design patterns - singleton. Refactoring Guru, 2018. URLhttps://refactoring.guru/design-patterns/singleton. Accedido el 10-01-2019.

[34] Saket Kumar. Lazy loading design pattern. GeeksforGeeks, 2018. URL https:

95

//www.geeksforgeeks.org/lazy-loading-design-pattern/. Accedido el10-01-2019.

[35] Rakhitha Nimesh. Active record migrations. Rails Guides, 2018. URL https://edgeguides.rubyonrails.org/active_record_migrations.html. Acce-dido el 10-01-2019.

[36] Yong Wen Chua. Changing the primary key type inruby on rails models. Oliver Wyman Labs, 2018. URLhttps://tech.labs.oliverwyman.com/blog/2013/09/30/changing-the-primary-key-type-in-ruby-on-rails-models/. Ac-cedido el 15-01-2019.

[37] WebAIM. Color contrast checker - #00000 vs #45a187, 2019. URLhttps://webaim.org/resources/contrastchecker/?fcolor=000000&bcolor=45A187. Accedido el 10-01-2019.

[38] WebAIM. Color contrast checker - #00000 vs #9fc2ba, 2019. URLhttps://webaim.org/resources/contrastchecker/?fcolor=000000&bcolor=9FC2BA. Accedido el 10-01-2019.

[39] Shawn Lawton Henry. Web content accessibility guidelines (wcag) over-view. W3C, 2018. URL https://www.w3.org/WAI/standards-guidelines/wcag/. Accedido el 10-01-2019.

[40] Google. Navigation drawer. Material Design, 2018. URL https://material.io/design/components/navigation-drawer.html#. Accedido el10-01-2019.

[41] Yukihiro Matz Matsumoto. Ruby - a programmer’s best friend, 2019. URLhttps://www.ruby-lang.org/en. Accedido el 11-01-2019.

[42] Oracle. Java language specification - se8. Java SE Specifications,2018. URL https://docs.oracle.com/javase/specs/jls/se8/html/jls-1.html. Accedido el 11-01-2019.

[43] Google. Android, 2019. URL https://developer.android.com/about. Ac-cedido el 11-01-2019.

[44] Michael Stonebraker. Postgresql, 2019. URL https://www.postgresql.org.Accedido el 11-01-2019.

[45] Google. Android studio, 2019. URL https://developer.android.com/studio/?hl=es-419. Accedido el 11-01-2019.

96

[46] Microsoft. Visual studio code, 2019. URL https://code.visualstudio.com.Accedido el 11-01-2019.

[47] John Lees-Miller John Hammersley. Visual studio code, 2019. URL https://code.visualstudio.com. Accedido el 11-01-2019.

[48] LaTeX3 Project. Latex – a document preparation system, 2019. URL https://www.latex-project.org. Accedido el 11-01-2019.

[49] Adrien de Beaupré. Distributed ssh brute force attemptson the rise again, 06 2010. URL https://threatpost.com/ssh-brute-force-attacks-resurface-061810/74128/. Accedido el02-11-2018.

[50] Indiana University. Set up ssh public-key authentication to connect to aremote system, 08 2018. URL https://kb.iu.edu/d/aews. Accedido el 02-11-2018.

[51] Linux Foundation. Let’s encrypt, 2018. URL https://letsencrypt.org/.Accedido el 08-11-2018.

[52] J. Bradley Ping Identity N. Sakimura M. Jones, Microsoft and NRI. Json webtoken (jwt). RFC 7519, Internet Engineering Task Force (IETF), May 2015.URL https://tools.ietf.org/html/rfc7519. Accedido el 13-11-2018.

[53] Ed. D. Hardt and Microsoft. The oauth 2.0 authorization framework. RFC6749, Internet Engineering Task Force (IETF), October 2012. URL https://tools.ietf.org/html/rfc6749#section-1.4. Accedido el 13-11-2018.

[54] Patrick Favre-Bulle. Armadillo. https://github.com/patrickfav/armadillo, 2018.

[55] Google. Authenticate with a backend server. Google Developers,2018. URL https://developers.google.com/identity/sign-in/web/backend-auth. Accedido el 16-11-2018.

[56] Google. google-id-token. https://github.com/google/google-id-token,2012.

[57] Twitter. Implementing sign in with twitter. Twitter Developers, 2018.URL https://developer.twitter.com/en/docs/twitter-for-websites/log-in-with-twitter/guides/implementing-sign-in-with-twitter.html. Accedido el 20-11-2018.

[58] Twitter. twitter-kit-android. https://github.com/twitter/twitter-kit-android, 2018.

97

[59] Twitter. Get account/verify_credentials. Twitter Developers, 2018.URL https://developer.twitter.com/en/docs/accounts-and-users/manage-account-settings/api-reference/get-account-verify_credentials.html. Accedido el 21-11-2018.

[60] sferik. twitter. https://https://github.com/sferik/twitter, 2018.

[61] Coda Hale. bcrypt-ruby. https://github.com/codahale/bcrypt-ruby,2018.

[62] OWASP. Forgot password cheat sheet. OWASP, 2018. URL https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet. Accedido el 17-01-2019.

[63] Tristan Sokol. Tips and tricks for api pagination. Me-dium, 2017. URL https://medium.com/square-corner-blog/tips-and-tricks-for-api-pagination-5cacc6f017da. Accedido el28/12/2018.

[64] amatsuda. kaminari. https://github.com/kaminari/kaminari, 2018.

[65] Rakhitha Nimesh. Paginating real-time data with cursor basedpagination. Sitepoint, 2014. URL https://www.sitepoint.com/paginating-real-time-data-cursor-based-pagination. Accedido el28/12/2018.

[66] alexreisner. geocoder. https://github.com/alexreisner/geocoder, 2018.

[67] OpenStreetMap. osmdroid. https://github.com/osmdroid/osmdroid,2018.

[68] Cibercomunidades. Información, legislación y normativa sobre animales do-mésticos. El web de las comunidades, 2018. URL https://www.comunidades.com/legislacion/comunidades/animales-domesticos. Accedido el 12-01-2019.

[69] kk121. File-loader. https://github.com/kk121/File-Loader, 2018.

[70] barteksc. Androidpdfviewer. https://github.com/barteksc/AndroidPdfViewer, 2018.

[71] OpenStreetMap. Overpass query language. OpenStreetMap Wiki, 2009.URL https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL. Accedido el 16-01-2019.

[72] Square. Retrofit. https://github.com/square/retrofit, 2018.

98

[73] stympy. Faker. https://github.com/stympy/faker, 2018.

[74] Keith Armstrong. Random user generator, 2018. URL https://randomuser.me. Accedido el 20-01-2019.

[75] sauloperez. random-location. https://github.com/sauloperez/random-location, 2013.

[76] Click! Adiestramiento canino. Click! adiestramiento canino, 2018. URLhttps://www.clickperros.com/generador-de-nombres-para-perros.html. Accedido el 20-01-2019.

[77] InformePerros. Lista de todas las razas de pe-rros, 2018. URL http://informeperros.com/lista-de-todas-las-razas-de-perros-por-orden-alfabetico/. Acce-dido el 20-01-2019.

[78] Dog API. Dog api, 2018. URL https://dog.ceo/dog-api. Accedido el20-01-2019.

[79] Google. Ui/application exerciser monkey. Android Developers, 2018. URLhttps://developer.android.com/studio/test/monkey. Accedido el 20-01-2019.

[80] OWASP. Don’t trust user input. OWASP, 2009. URL https://www.owasp.org/index.php/Don%27t_trust_user_input. Accedido el 15-01-2019.

99