Adopcion Mascotas

MÁSTER UNIVERSITARIO EN INGENIERÍA WEB
Plataforma web para la adopción y gestión

de animales procedentes de protectoras
TRABAJO FIN DE MÁSTER
Autor
Tomás Muñoz Testón
Tutor
Santiago Alonso Villaverde
Jennifer Pérez Benedí
Curso 2018 – 2019 Madrid, JULIO 2019

Agradecimientos
A mi tutor Santiago Alonso, por ayudarme tanto con este proyecto, empujarme a hacer
cosas grandes y hacer que crea en mis posibilidades.
A mi gran amigo Rodrigo de Miguel, por ser mi compañero de batallas y hacer que todo
sea posible.
A mis padres, por apoyarme día a día.

Para Beatriz Pérez, por ser la luz que ilumina mi camino.
Índice
Resumen ................................................................................................................... 1
Abstract..................................................................................................................... 1
1. INTRODUCCIÓN......................................................................................................... 2
1.1. Contexto ............................................................................................................. 3
1.2. Motivación ......................................................................................................... 7
1.3. Objetivos ............................................................................................................ 7
2. GESTIÓN DEL PROYECTO Y TECNOLOGÍAS ................................................................. 8
2.1. Plan de empresa ................................................................................................. 9
2.1.1. Público objetivo ....................................................................................................... 9
2.1.2. Competencia ........................................................................................................... 9
2.1.3 Marketing ............................................................................................................... 12
2.1.4. Fuente de ingresos y viabilidad económica ............................................................ 13
2.1.5. Viabilidad técnica .................................................................................................. 13
2.1.6. Estrategia de evolución .......................................................................................... 14
2.1.7. Estrategia de expansión ......................................................................................... 15
2.1.8. Plan de contingencia .............................................................................................. 15
2.2. Tecnologías para la gestión ............................................................................... 16
2.2.1. Trello ..................................................................................................................... 16
2.2.2. Google Drive .......................................................................................................... 17
2.2.3. Heroku .................................................................................................................. 17
2.2.4. Git - Github ............................................................................................................ 18
2.2.5. Amazon web services - Storage Service (Amazon - S3) ........................................... 19
2.3. Arquitectura y tecnologías utilizadas ................................................................ 20
2.3.1. Tecnologías - cliente (Frontend) ............................................................................. 20
i
2.3.2. Estructura y jerarquía de componentes React - Redux ........................................... 29
a) Estructura ............................................................................................................ 29
b) Jerarquía.............................................................................................................. 32
2.4. Configuración de la forja ................................................................................... 33
2.4.1. API REST ................................................................................................................ 34
2.4.2. Node package manager (NPM) .............................................................................. 34
2.4.3. Node.js y Express ................................................................................................... 34
2.4.4. MongoDB - Mongoose - Mongolab ........................................................................ 36
2.4.5. Heroku .................................................................................................................. 36
2.4.6. CORS ..................................................................................................................... 37
3. PLANIFICACIÓN DEL PROYECTO ............................................................................... 39
3.1. Requisitos no funcionales ................................................................................. 40
3.2. Requisitos funcionales ...................................................................................... 41
3.3. Metodología ágil - Scrum .................................................................................. 42
3.3.1. Manifiesto ágil ....................................................................................................... 42
3.3.2. SCRUM .................................................................................................................. 43
3.3.3. Planificación del proyecto. ..................................................................................... 45
a) Inception Deck ..................................................................................................... 45

b) Estimación y priorización de características ......................................................... 46
c) Product Backlog ................................................................................................... 47
d) Desarrollo de sprints ............................................................................................ 64
d.1) Primer y segundo sprint - Investigar tecnologías ............................................... 64
Guía de estilos:............................................................................................. 65
Para facilitar el diseño de los componentes, se crea una guía de estilos que facilite
la creación de los componentes React. Ver Anexo A............................................. 65
d.2.) Tercer sprint - Creación de arquitectura ........................................................... 65
Arquitectura React - Redux........................................................................... 67
Sprint Review ............................................................................................... 70
d.3.) Cuarto sprint - Módulo protectora ................................................................... 70
Diagramas de casos de uso ........................................................................... 73
ii
Modelo de datos: ......................................................................................... 73
API REST - Conexión cliente - servidor .......................................................... 75
Componentes............................................................................................... 83
Sprint Review ............................................................................................... 86
d.4.) Quinto sprint - Módulo animales ..................................................................... 86
Diagramas de casos de uso ........................................................................... 89
Modelo de datos: ......................................................................................... 89
API REST - Conexión cliente - servidor .......................................................... 90
Componentes............................................................................................... 98
Sprint Review ............................................................................................. 102
d.5.) Sexto sprint - Login y gestión de imágenes principales. .................................. 103
Diagramas de casos de uso ......................................................................... 105
API REST - Conexión cliente - servidor ........................................................ 105
Componentes............................................................................................. 108
Sprint Review ............................................................................................. 109
d.6.) Séptimo sprint - Obtener imágenes y contacto vía email. ............................... 110
Componentes............................................................................................. 115
Sprint Review ............................................................................................. 116
d.7.) Octavo sprint - Contacto vía whatsapp y verificar cuenta protectora .............. 117
Componentes............................................................................................. 121
Sprint Review ............................................................................................. 121
4. CONCLUSIONES Y POSIBLES AMPLIACIONES .......................................................... 122
4.1. Conclusiones ................................................................................................... 123
4.2. Trabajo futuro ................................................................................................ 123
5. BIBLIOGRAFÍA........................................................................................................ 125
ANEXO A. GUÍA DE ESTILO......................................................................................... 128
iii
Índice figuras
Figura 1. Evolución del número de animales que llegan cada año a refugios o protectoras.
Fuente: Fundación Affinity. ........................................................................................... 3
Figura 2. Motivos para el abandono de animales de compañía. Fuente Fundación

Affinity. ......................................................................................................................... 4
Figura 3. Motivos para no adoptar un animal de compañía en personas inicialmente

interesadas en una adopción. Fuente Fundación Affinity. ............................................. 5
Figura 4 - Motivos de fracaso de la adopción. Fuente Fundación Affinity. ..................... 6
Figura 5 - Actores de la plataforma ............................................................................... 9
Figura 6 - Esquema viabilidad tecnológica. .................................................................. 13
Figura 7. Mapa organización de la Comunidad de Madrid. .......................................... 15
Figura 8. Tecnologías más populares en 2018. Fuente: Stackoverflow. ........................ 20
Figura 9. Tabla comparativa entre React y Angular...................................................... 22
Figura 10. Frameworks, bibliotecas y herramientas más utilizadas en 2018. Fuente:

Stackoverflow. ............................................................................................................ 23
Figura 11. Diagrama de flujo que sigue Redux desde una interacción, hasta que la
aplicación actualiza la UI. ............................................................................................ 25
Figura 12. Ejemplo de transpilado de ficheros. Fuente: webpack.js.org. ...................... 26
Figura 13. Estructura componente React - Redux. ....................................................... 31
Figura 14. Ejemplo jerarquía de componentes. ........................................................... 33
Figura 15. Procesos de una metodología Scrum. Fuente: Scrum.org. ........................... 45
Figura 20 - AlertCheckComponent............................................................................... 85
Figura 21. AlerConfirmComponent. ............................................................................. 85
Figura 22. CardProtectoraComponent. ........................................................................ 85
Figura 23. AdminComponent. ..................................................................................... 86
iii
Figura 24. Diagrama de Casos de Uso - Módulo animales. ........................................... 89
Figura 25. selectRadioGroupComponent ..................................................................... 99
Figura 26. switchButtonComponent. ........................................................................... 99
Figura 27. selectRadioGroupComponent2 ................................................................... 99
Figura 28. inputMutiselectComponent. ..................................................................... 100
Figura 29. homeComponent. ..................................................................................... 101
Figura 30. AnimalFormComponent. .......................................................................... 102
Figura 31. Módulo login y gestión de imágenes principales. ...................................... 105
Figura 32. loginFormComponent. ............................................................................. 108
Figura 33. dragAndDropAndCropComponent. ........................................................... 109
Figura 34. Módulo obtener imagen principal y envío email protectora...................... 112
Figura 35. imagenPrincipalComponent. ..................................................................... 115
Figura 36. enviarEmailProtectora. ............................................................................. 116
Figura 37. Módulo gestión whatsapp y verificación email protectora. ....................... 118
Figura 38. contactWhatsappComponent. .................................................................. 121
Figura 39. Colores guía de estilos. ............................................................................. 129
Figura 40. Tablas guía de estilos. ............................................................................... 129
Figura 17. Botones guía de estilos. ........................................................................... 130
Figura 41 - Botones solo contorno - guía de estilos. .................................................. 130
Figura 42. Grupo de botones - guía de estilos. ........................................................... 130
Figura 43. Botones con funcionalidad - guía de estilos. ............................................. 131
Figura 44. Elementos de formulario - guía de estilos. ................................................ 131
Figura 45. Elementos de formulario extra - guía de estilos. ...................................... 131
Figura 46. Alertas - guía de estilos. ............................................................................ 131
Figura 47. Barras de progreso - guía de estilos. ........................................................ 132
iv
Figura 48. Información sobre botones - guía de estilos. ............................................. 132
Figura 49. Badges - guía de estilos. ............................................................................ 133
Figura 50. Navegación - guía de estilos. ..................................................................... 133
Figura 51. Barras de progreso - guía de estilos. ......................................................... 133
Figura 52. Paginación y migas de pan - guía de estilos. ............................................. 133
Figura 53. Colapsables y carousel - guía de estilos. .................................................... 133
Figura 54. Tipografías - guía de estilo. ....................................................................... 134
Figura 55. Texto en bloque - guía de estilo. ............................................................... 134
Figura 56. Listados - guía de estilo. ............................................................................ 134
Figura 57. panel tipo cartas - guía de estilo. .............................................................. 135
Figura 58. Navegación de cartas - guía de estilo. ....................................................... 135
Figura 59. Variación de cartas - guía de estilo. ........................................................... 135
Figura 60. Seleccionables - guía de estilo. .................................................................. 136
Figura 61. Etiquetas - guía de estilo. .......................................................................... 136
Figura 62. Jumbotron - guía de estilo. ....................................................................... 136
v
Resumen
El abandono de animales es un importante problema en España. El número de animales

que llegan a las protectoras está volviendo a crecer desde 2015.
Adoptaunanimal es una plataforma web que permite unificar a las protectoras en un

único lugar para mejorar su presencia en internet y aumentar la visibilidad de sus
animales. Esta plataforma permite a los usuarios buscar un animal en concreto, ver la
información del animal con detalle y contactar con la protectora si así lo desean.
El presente proyecto pretende ilustrar el proceso de desarrollo de la plataforma,

utilizando metodologías ágiles para tolerar requisitos cambiantes y aportar valor de
producto en etapas tempranas del proyecto. Las tecnologías utilizadas son actuales
como React y Redux en la parte cliente, NodeJS y Express en la parte servidor y
Mongoose con MongoDB para la integración con base de datos.
Abstract
Pet abandonment is an important problem in Spain. The number of animals that end up in the
shelters is growing again since 2015.
Adoptaunanimal is a web platform that allows unifying the animal shelters in a single place to
improve their presence on the Internet and increase the visibility of their animals. This platform
allows users to search for a specific animal, view the animal’s information in detail and contact
the shelter if they wish.
This project aims to illustrate the development process of the platform, using agile
methodologies to tolerate changing requirements and provide product value in early stages of
the project. The technologies used are current as React and Redux on the client side, NodeJS
and Express on the server side and Mongoose with MongoDB for database integration
1
1. INTRODUCCIÓN
Introducción
1.1. Contexto
En 2018, 138.307 perros y gatos fueron abandonados en España (Figura 1). 17 de cada
1000 perros y 10 de cada 1000 gatos terminaron en un refugio o protectora durante el
año 2018[1]. Estos datos permiten estimar la tasa de abandono y/o pérdida de animales
en 23 perros y 7 gatos por cada 10.000 habitantes (Población española estimada en
46.733.038 personas 1). El abandono de animales es todavía un importante problema en
España. Según Fundación Affinity, las cifras de animales que llegaron a un refugio o
protectora en 2018 son comparables a las de 2017, confirmándose el estancamiento de
la tímida tendencia a la baja observada a lo largo de los últimos años[1].
Figura 1. Evolución del número de animales que llegan cada año a refugios o protectoras. Fuente:
Fundación Affinity.
Con una media de casi 380 animales desatendidos en las calles cada día, España se sitúa
a la cabeza de Europa en cuanto a abandono se refiere.
Entre las causas atribuibles a este problema destacan las siguientes: camadas no
deseadas (15,5%), el fin de la temporada de caza (12,2%), los factores económicos
(11,7%), el comportamiento del animal (11,4%), y la pérdida del interés por el animal
(10,7%) (Figura 2)[2].
1
Fuente: Instituto Nacional de Estadística (diciembre- 2018).
3
Introducción
Figura 2. Motivos para el abandono de animales de compañía. Fuente Fundación Affinity.
Algunas personas interesadas en adoptar un animal acaban por no hacerlo. Un 29,2%

de las personas con un interés inicial en adoptar un perro o un gato finalmente
decidieron no hacerlo[2].
Los 3 motivos fundamental para no adoptar fueron no haber encontrado el tamaño

(27,6%), la edad (20,7%) o la raza (19,8%) adecuadas (Figura 2)[2]. Además, un 11% de
las personas que mostraron interés inicial en la adopción finalmente decidieron no
hacerlo argumentando que se esperaban un coste menor de la misma(Figura 3)[2].
4
Introducción
Figura 3. Motivos para no adoptar un animal de compañía en personas inicialmente interesadas en una
adopción. Fuente Fundación Affinity.
Observando estos datos se puede ver que los aspectos físicos en general y la raza siguen
siendo algunos de los criterios por los que una persona se decide a adoptar o no a un
animal.
En otras ocasiones, los animales acaban volviendo al refugio tras haber sido adoptados.
Esto ocurre porque en la mayoría de los casos no se disponía de la información necesaria
para favorecer una buena adopción. Por eso, es de vital importancia que las personas
reflexionen y se informen de las consecuencias y la responsabilidad que supone tener
un animal de compañía2[3]. La concienciación es la única vía posible para cambiar esta
realidad presente.
2
Guía tenencia responsable (Gobierno de España)
5
Introducción
Los principales motivos por los que se devuelve un animal a la protectora son:
Figura 4 - Motivos de fracaso de la adopción. Fuente Fundación Affinity.
Las protectoras viven una realidad preocupante ya que la mayoría están desbordadas.
Sin embargo, este problema se podría solucionar con el control de la cría y la
esterilización, tal y como hacen países vecinos de España como Holanda, y con la
identificación mediante microchip para facilitar la recuperación de un animal perdido y
mejorar la conducta de los propietarios.
6
Introducción
1.2. Motivación
Los buscadores de animales que existen a día de hoy en internet utilizan tecnología
anticuada o están abandonados.
No todas las protectoras tienen una página web o lugar donde gestionar y dar visibilidad
a sus animales en internet ya sea por falta de dinero o porque la actualización de las
herramientas que disponen supone mucho tiempo.
1.3. Objetivos
El presente trabajo fin de máster (de ahora en adelante TFM), tiene como objetivo crear
una plataforma web que permita unificar todas las protectoras del ámbito nacional
(empezando por la Comunidad de Madrid). Permitirá que las protectoras puedan
gestionar y mejorar la visibilidad de sus animales y que cualquier usuario pueda
encontrar de una forma sencilla un animal (en un principio perros y gatos) concreto o
saber qué protectoras tiene cerca, así como su información o contacto.
7
2. GESTIÓN DEL PROYECTO Y TECNOLOGÍAS
Gestión del proyecto y tecnologías
2.1. Plan de empresa
Antes de comenzar con el proyecto se realizó un plan de empresa donde se trataron las
siguientes cuestiones:
2.1.1. Público objetivo
La plataforma web se centra en un público de habla hispana (peninsular) concienciado

con la adopción de animales y que dispone de acceso a internet; y son tantos los usuarios
de la plataforma (particulares) como las protectoras de animales de ámbito nacional
(clientes) (Figura 5).
Figura 5 - Actores de la plataforma
2.1.2. Competencia
Para analizar la competencia se buscó en internet plataformas web que hiciesen algo
parecido. Se analizaron sus redes sociales y se utilizó SimilarWeb para generar informes
sobre cada una de sus webs.
a) Bambu-difunde
Esta página web se consideró como competencia directa. En ella se observa que tiene
dado de alta a 103 protectoras, de las cuales la mitad se distribuyen entre las provincias
de:
● Barcelona (27%).
● Alicante (14,5%).
● Madrid (10,6%).
9
Si se tienen en cuenta solo las de Madrid, de las 51 protectoras madrileñas, solamente

11 están registradas en esta web, suponiendo un 21,5% del total. Extrapolado a nivel
nacional (556 protectoras a día 17 de enero de 2019), tan solo suponen un 5% en
Barcelona, un 2,7% en Alicante y en Madrid un 2%.
Además, tenían registrados 7950 animales (5483 perros y 2435 gatos) (a 17 de enero de
2019).
Según SimilarWeb (a día 18 de enero de 2019), el 80% de las visitas que recibe la web
proviene de buscadores, el 12% de forma directa y tan solo un 1.6% de redes sociales
(principalmente Facebook). Las personas que acceden la mayoría son de España
(86,59%) y el resto de los países Latinoamericanos. No han pagado nada para aumentar
su tráfico en la web.
b) Miwuki
Esta empresa tiene plataforma web y aplicación Android. Se centran en el territorio

nacional y el origen de los datos de los animales no está probado.
En la aplicación Android se puede observar que la mayoría de las protectoras no han

registrado ningún animal en la plataforma ni han actualizado su logo (en aquellas que
no tienen logo incluso hacen que la aplicación deje de funcionar).
El listado de perros donde se muestra el total en España no se puede cargar al completo,

pero en Madrid muestran 893 perros de las 64 protectoras de Madrid registradas (a 18
de enero de 2019).
En cuanto a sus redes sociales:

● Facebook: tienen 210.000 seguidores, pero en las publicaciones que realizan tan
solo reciben entre 70 y 200 “Me gusta”, lo que supone menos de un 1% de sus
usuarios, por lo que se puede deducir que son poco activos.
● Twitter: tienen 500 seguidores y no hay apenas actividad (1 - 2 “Me gusta”).
10
Con todos estos datos se deduce que han podido comprar seguidores. Además, parece
que los datos de los perros están desactualizados, ya que figuran perros que en
notificaciones de la protectora por redes sociales nombran como adoptado.
Según SimilarWeb, las visitas que recibió la página en diciembre de 2018 se dividen en
un 12% en la página publicitaria, un 5% en la plataforma web y entre un 4,7% y un 23%
de descargas en la App Android).
Analizando los datos de la APP Android:

● Están en el rango de 10000 a 50000 descargas.
● Tienen 1553 votos (con una media de 4,9/5).
La web publicitaria tiene:

● 25440 visitas.
● Tiempo medio de uso de 1:20 minutos.
● 2,43 páginas por visita.
● Y un ratio de rebote del 47.80%.
La plataforma web:
● 11280 visitas.
● Tiempo medio de uso de 1:49 minutos.
● 3,91 páginas por visita.
● Y un ratio de rebote del 34,94%
Su principal fuente de ingreso es a través de las búsquedas (un 60,9%) mediante

Adwords (prácticamente todas son por pago) y de escritura directa (31,6%), en cambio,
de RRSS solo un 4,51% proveniente de WhatsApp (lo cual destaca mucho para el número
elevado de seguidores en Facebook).
11
c) mascotasadopción.com
Esta página web es competencia directa. Se centra en el ámbito nacional, utiliza

wordpress como tecnología principal y los filtros de búsqueda de animales son bastante
escasos.
Debido a que esta página web ha aparecido recientemente, aún no se ha realizado el

análisis de competencia completo.
d) Adopta un perro - Rastreator
Debido a que esta página web ha aparecido recientemente, aún no se ha realizado el

análisis de competencia completo.
2.1.3 Marketing
Para el marketing del proyecto se utiliza las siguientes herramientas y estrategias:

● Google Adwords como posicionamiento SEM: es un servicio que se utiliza para
hacer publicidad patrocinada dentro del buscador de Google.
● Google Analytics: esta herramienta permite analizar distintos parámetros de la

web. Se puede saber el tráfico que llega y el comportamiento dentro de la misma,
por lo que podemos ajustar la estrategia de marketing con respecto a estos
parámetros.
● Posicionamiento SEO: para mejorar el posicionamiento orgánico (SEO), se

optimiza la web para que Google sea capaz de rastrear e indexar correctamente
la estructura de la plataforma web para que se muestre en las primeras
posiciones en las búsquedas de Google sobre temas con estrecha relación con la
actividad de la plataforma web. Para conseguir esto se tiene muy en cuenta el
tiempo de carga, detallar el contenido con palabras clave, buena experiencia de
navegación y haciendo que otros sitios web tengan enlaces o nombren a la
plataforma.
12
2.1.4. Fuente de ingresos y viabilidad económica
Las principales fuentes de ingresos serán:

● Permitir a las protectoras probar la plataforma durante un tiempo (por ejemplo,
6 meses) para después pagar una subscripción (alrededor 10 euros mensuales).
● Mediante publicidad dentro de la plataforma web.
2.1.5. Viabilidad técnica
La aplicación está planificada como un sistema MVC (Modelo – Vista – Controlador). Se

desarrollará con React.js y Redux en la parte Frontend, y NodeJS y ExpressJS para
generar la API REST con MongoDB como gestor de base de datos junto a S3 de Amazon
web services para almacenar las imágenes (Figura 6).
Se utiliza un control de versiones gratuito (GitHub) manteniendo el proyecto de forma

privada. En cuanto al despliegue, se utilizará la plataforma Heroku para la aplicación con
un “addon” de mongolab para la base de datos.
Figura 6 - Esquema viabilidad tecnológica.
13
2.1.6. Estrategia de evolución
El proyecto se desarrollará en 3 fases:

● Fase 1 – Documentación y funcionalidad básica.
● Fase 2 – Captación de protectoras pequeñas y cercanas (Marketing).
● Fase 3 – Incremento de funcionalidad y expansión nacional.
En la Fase 1:
● Generar un Plan de Empresa y una especificación de requisitos básica. Detallar
la Idea de negocio, funcionalidades básicas y futuras, realizar un estudio de
mercado y analizar las tecnologías que se van a utilizar.
● Realizar una investigación de las tecnologías para aprender a usarlas antes de

empezar con el desarrollo (técnicas, buenas prácticas, etc).
● Planificar el desarrollo del proyecto utilizando metodologías ágiles (en este caso
se utiliza SCRUM).
● Desarrollar la plataforma para obtener una funcionalidad básica.
En la Fase 2:
● Realizar demostraciones de la aplicación en las protectoras con el objetivo de
que la utilicen y puedan dar las primeras impresiones.
● Optimizar el posicionamiento SEO/SEM, las analíticas web y las estrategias de

marketing (ver apartado Marketing).
En la Fase 3:
● Mejorar la funcionalidad básica y añadir nueva (priorizando aquellas que las
protectoras han considerado más importantes en las primeras impresiones).
● Aumentar el alcance a territorio nacional.
14
2.1.7. Estrategia de expansión
En un principio la actividad se centrará en la Comunidad de Madrid, empezando por la

región Oeste (Figura 7) por ser la más conocida por el equipo de desarrollo y la más
cercana.
El principal objetivo es conseguir que las pequeñas y medianas protectoras se interesen

por la plataforma, por ser las que menos impacto tienen en el mercado.
Figura 7. Mapa organización de la Comunidad de Madrid.
2.1.8. Plan de contingencia
Dentro del plan de contingencia se han valorado las siguientes:
a) No tener éxito
En caso de que la plataforma web esté generando pérdidas pasado un año desde su
lanzamiento, se valorará entre eliminar la aplicación o dejarla con los servidores y BBDD
en sus planes gratuitos para que se mantenga el uso de forma gratuita.
15
b) No se crece al ritmo esperado
En este caso se valorará la reducción de los recursos en los servidores y BBDD para evitar
la pérdida de dinero y/o cambio de estrategia de marketing.
c) Mayor crecimiento del esperado

En caso de crecimiento más allá de lo esperado se tendrá que aumentar los recursos
tecnológicos y reducir de forma momentánea la inversión en marketing.
2.2. Tecnologías para la gestión
Para facilitar la comunicación y tener un seguimiento del proyecto se han usado las
siguientes tecnologías:
2.2.1. Trello
Es un programa de administración de proyectos con interfaz web y cliente para Android.

En este caso, se utiliza para especificar el proceso administrativo y de desarrollo donde
se contemplan en qué estado se encuentra las tareas en cada momento facilitando el
seguimiento del proyecto. Estas tareas pasan por los siguientes estados:
○ To do: este estado almacena todas las tareas pendientes de hacer.
○ Doing: aquí aparecen las tareas que están en progreso.
○ Test: tareas que se encuentran en un proceso de pruebas.
○ Review: si hay alguna tarea que está pendiente de revisión por parte de
cualquier integrante del proyecto.
○ Done: en este apartado aparecen almacenadas aquellas tareas que están

ya finalizadas.
16
2.2.2. Google Drive
Es una aplicación online de alojamiento de archivos. En este caso es de gran utilidad para
compartir documentación y código desarrollado. Se sigue la siguiente estructura de
carpetas:
● Plantillas: en esta carpeta se almacena todo lo referente al diseño de la
plataforma web.
● Marketing: aquí se guarda todo lo relacionado con las estrategias de marketing,

información valiosa de la competencia e infografía.
● Documentación: en este directorio se guardan las actas de las reuniones del

equipo, el plan de empresa, la especificación de requisitos y cualquier fichero
que pueda aportar información valiosa, como por ejemplo, el censo de animales
de la Comunidad de Madrid.
● Aplicación: copia de seguridad de la aplicación.
2.2.3. Heroku
Es un ecosistema de servicios que permite alojar aplicaciones en la nube. Se centra en

mejorar la experiencia del desarrollador en torno a las aplicaciones ya que automatiza
los procesos de implementación, configuración, escalado, ajuste y administración de la
aplicación permitiendo que el desarrollador se centre solamente en crear la
aplicación[4].
Los complementos (Add-ons) de Heroku son servicios totalmente gestionados,

integrados para su uso con Heroku. Se pueden aprovisionar y escalar en un solo
comando, y permiten a los desarrolladores ampliar las capacidades de una aplicación[4].
Se decide usar Heroku para el despliegue de la aplicación por su facilidad de uso y por el
precio.
17
2.2.4. Git - Github
Para el control de administración y revisión del código se decide usar Github. Esta
plataforma permite centralizar el código en un solo lugar. Además, la flexibilidad de Git
permite una fácil revisión del código y gestionar distintas versiones. Esto se puede lograr
mediante el uso de metodologías como “Atlassian GitFlow WorkFlow”[5]. Esta
metodología proporciona un conjunto de buenas prácticas para la gestión del código
fuente ya que define una estructura de ramificación que está estrictamente relacionada
con las actividades del proceso de desarrollo haciendo que cada actividad individual de
codificación tenga su propia rama. Para ello, la convención establece seis tipos de ramas:
● Master: contiene la versión estable de la aplicación (producción). Sólo puede
existir una rama de este tipo en el proyecto.
● Develop: es una rama paralela a “Master” que se utiliza para probar la

estabilidad de la aplicación antes de pasar a producción. Esta rama es también
única en el proyecto.
● Release: antes de mezclar la rama “Develop” con “Master”, se crea esta rama
que sirve para ajustar y probar la versión. Al finalizar, estas ramas también
deberían de mezclarse de nuevo en la rama ‘Develop’ para incorporar los
cambios de ajuste hechos en el desarrollo actual.
● Feature: estas ramas se crean asociadas a cada tarea de desarrollo. Se crean a

partir de la rama “Develop”, se incorporan todos los cambios de esa tarea y
cuando se finaliza se vuelve a mezclar con la rama “Develop”.
● Bug: son similares a las ramas “Feature” pero en este caso el objetivo es arreglar
un problema o fallo.
● Hotfix: al igual que las ramas “Bug”, sirven para arreglar un problema, pero en
este caso son errores que son urgentes. Al completar una rama “Hotfix” debe
fundirse de nuevo en la rama “master” y también en la rama “Develop”.
18
Las ramas “Master” y Develop” son ramas que sus nombres no varían. En cambio, el
resto adoptan la siguiente nomenclatura:
{branchType}/{task#}-sample-task-name
Ejemplos:
● feature/#1-login-module
● bug/#2-login-module-error
Esta forma de clasificar las ramas permite una organización rigurosa por parte del
desarrollador. Además, facilita la integración en un entorno de trabajo en el que se
utilizan metodologías ágiles como Scrum por la flexibilidad del código producido.
Para gestionar las tareas asociadas al proyecto se utiliza Github. Esta plataforma permite
gestionar las tareas en un tablero Kanban, utilizar estados en las tareas, asignarlas a
miembros del equipo de desarrollo, utilizar un chat para las discusiones y tener un
histórico de estados. Como el código se aloja en esta herramienta, se pueden vincular
los los commits de Git directamente a la tarea utilizando el número de identificación de
la tarea. Esta característica es muy útil en la revisión de las tareas jerárquicas y facilita
considerablemente la revisión del Git log.
2.2.5. Amazon web services - Storage Service (Amazon - S3)
Para almacenar las imágenes de los animales, logos de las protectoras, etc. se utiliza un
servicio de almacenamiento que ofrece escalabilidad, disponibilidad de datos, seguridad
y rendimiento. Ofrece facilidades de integración con aplicaciones, controles de acceso y
organizar los datos[6].
19
2.3. Arquitectura y tecnologías utilizadas
2.3.1. Tecnologías - cliente (Frontend)
a) Javascript
El lenguaje de programación Javascript sigue siendo uno de los más usados en los
últimos años (Figura 8)[7], [8]. Está ganando impulso continuamente tanto en
aplicaciones del lado del servidor como del cliente. El motor Chrome V8 está mejorando
su rendimiento en el lado del cliente con el uso de entornos de trabajo (comúnmente
conocidos como Frameworks3) como Angular o librerías como ReactJS o Vue [9].
Figura 8. Tecnologías más populares en 2018. Fuente: Stackoverflow.
Estos entornos de trabajo y librerías están orientados a acelerar el proceso de desarrollo

aprovechando el poder de herramientas creadas por desarrolladores experimentados y
dan solución a muchos problemas comunes[9]. Por lo tanto, antes de decidir qué
tecnologías utilizar, se analizaron las distintas opciones para seleccionar aquellas que se
ajusten a los requisitos de software funcionales y no funcionales de la aplicación.
3
https://es.wikipedia.org/wiki/Framework
20
b) Angular vs React
Angular fue creado por Google y comenzó como un marco MV*, es decir, podía usarse
como MVC (Modelo - vista - controlador) o una arquitectura MVVM (modelo - vista -
vista - modelo). Es flexible y por ello complicado de dominar ya que no existe una forma
específica de trabajar.
La primera versión que se creó de Angular fue la 1.X que no es compatible con versiones
posteriores, ya que Angular 2.X fue una reescritura completa de todo el entorno de
trabajo. Los controladores desaparecieron y fueron sustituidos por componentes y
directivas. Además, incorporaron la posibilidad de usar Typescript proporcionando la
posibilidad de tener tipos estáticos y algunas características atractivas que no están
presentes en Javascript[9].
Por otro lado, React, a diferencia de Angular, es una biblioteca de creación de interfaces
flexible, creada y mantenida por Facebook. React utiliza una arquitectura basada en
componentes.
Esta arquitectura es fácil de mantener y muy reutilizable por lo que permite acelerar el
proceso de desarrollo haciendo que el desarrollador se centre en lo demás. Sin embargo,
no es la arquitectura basada en componentes lo que hace a React una buena alternativa,
si no el Virtual Data Object Model (DOM). Esta característica permite que el DOM virtual
de React pueda crear más de 200,000 nodos por segundo. No solo eso, sino que recrea
el DOM para cada cambio. Además, con el algoritmo “Diffing” es capaz de reducir el
cálculo de la diferencia desde una complejidad de O(n^3) a O(n) 4.
Una de las virtudes de React es la incorporación de JSX, una extensión de Javascript que
permite escribir código HTML como si fuera código Javascript[9].
4
https://reactjs.org/docs/reconciliation.html#the-diffing-algorithm
21
Tabla comparativa entre Angular 2 y React:
Tecnología Angular React
Tipo de tecnología Framework basado en Biblioteca para la generación

componentes utilizando de interfaces con una
Typescript arquitectura basada en
componentes utilizando
Javascript
Enlace de datos Bidireccional Unidireccional
Tamaño Grande, por lo que aumenta Pequeño

el tiempo de carga inicial
Curva de aprendizaje Pronunciada, dado el Fácil de aprender

número de funciones y
opciones básicas a aprender
Optimización Rápido Algo más rápido que Angular
Sencillez Bastante complejo Simple, pero lleva tiempo

configurar un proyecto
completo
Escalabilidad Fácil de escalar gracias al Simple de escalar

potente cliente que lleva
incorporado para facilitar la
generación de componentes
Figura 9. Tabla comparativa entre React y Angular.
Tanto Angular 2 cómo React son muy utilizadas (Figura 9) y cualquiera de ellas se podría
haber utilizado para implementar este proyecto. Sin embargo se opta por utilizar React
por la curva de aprendizaje y su simplicidad.
Ambas tecnologías están muy bien documentadas, son bastante maduras y hay una gran
comunidad detrás.
22
Figura 10. Frameworks, bibliotecas y herramientas más utilizadas en 2018. Fuente: Stackoverflow.
c) Redux
Como los requisitos en aplicaciones Javascript de una sola página se están volviendo
cada vez más complicados, surge la idea de manejar el estado del código.
En programación, se define “estado” como el conjunto de valores almacenados por la

aplicación mediante propiedades o variables en cualquier momento de la ejecución[10].
El estado aplicado al lado del cliente (Frontend) se puede utilizar para almacenar el
estado de la interfaz, las rutas activas, tabs seleccionados, control de paginación, etc. En
las aplicaciones sencillas no es necesario darle importancia a estas herramientas de
gestión de estados, pero si la aplicación crece esta gestión se convierte en un problema,
especialmente cuando los valores de un componente pueden afectar a valores de otros
componentes y se pierde el control del cuándo, cómo y por qué del estado[11].
23
Redux es una librería creada en 2015 por Dan Abramov que facilita la gestión de las
continuas variaciones (mutabilidad), con la incertidumbre de cuándo se producen
(asincronismo), ya que el principal objetivo de Redux es hacer predecible los cambios de
estado, poniendo restricciones de cómo y cuándo se producen estas actualizaciones,
haciendo que el estado sea transparente y determinista. Está librería está en gran parte
influenciada por Flux 5, creada por Facebook para las aplicaciones de React utilizando
lenguaje Elm6 [10].
Redux permite:
● Tener una fuente única de verdad: mantener un único objeto que almacena el
estado de toda la aplicación, permitiendo el acceso a este estado a todos los
componentes.
● Inmutabilidad, el estado es “solo lectura”: las iteraciones no pueden cambiarlo

directamente. Para poder hacer un cambio en el estado hay que emitir una
acción.
● Funciones puras: usar funciones puras para definir cómo cambia el estado en
base a una acción (mantiene lo mismos tipos de variables de entrada y salida).
En Redux, este tipo de funciones se conocen como “Reducers”.
El flujo de actualización del estado con Redux es el siguiente (Figura 10):
1. El componente recibe un evento (clic, por ejemplo) y emite una acción.
2. Esta acción, se pasa al store, que es donde se guarda el estado único.
3. La store comunica la acción junto con el estado actual a los reducers.
4. Los reducers, devuelven un nuevo estado, probablemente modificado en base a

la acción.
5. Los componentes reciben el nuevo estado de la store.
5
https://facebook.github.io/flux/
6
https://elm-lang.org/
24
Figura 11. Diagrama de flujo que sigue Redux desde una interacción, hasta que la aplicación actualiza la
UI.
En este proyecto se utilizará Redux junto con React porque permite describir la interfaz
de usuario como una función de estado en respuesta a acciones y centralizar el control
del estado.
d) Webpack
Webpack es un empaquetador de módulos que permite automatizar procesos como

transpilación de código, preprocesamiento (por ejemplo, de .scss a .css) (Figura 11). Se
puede considerar que Webpack es una evolución de Grunt y Gulp, ya que permite
automatizar los procesos principales que son transpilar y preprocesar código web[12].
25
Figura 12. Ejemplo de transpilado de ficheros. Fuente: webpack.js.org.
Para poder utilizarlo es necesario tener instalado Node.js y crear un fichero en el

proyecto “webpack.config.js” donde escribir toda la configuración necesaria.
Webpack permite trabajar con cualquier tipo de archivo (CSS, preprocesadores CSS,
preprocesadores Javascript, imágenes, etc) simplemente indicando el “loader” a utilizar.
Gracias a esto, podemos preprocesar el código JSX de los componentes de React. El
archivo de configuración utilizado en el proyecto tiene la siguiente configuración:
entry: [
'./src/index.js'
]
Aquí le indicamos que el punto de entrada desde el que debe empezar a leer y realizar
el proceso es el fichero index.js
output: {
path: path.join(__dirname, 'public/'),
publicPath: path.join(__dirname, 'public/'),
filename: 'bundle.js'
}
26
Con esta configuración le estamos indicando donde ha de situar el fichero de salida, será
en la carpeta build con el nombre bundle.js. Si lo servimos desde un servidor de
desarrollo, la ruta pública será “public/”.
module: {
rules: [
{
test: /\.css$/,
use: ['style-loader', 'css-loader'],
},
],
loaders: [
{exclude: '/node_modules/', loader: 'babel', query: {presets: ['react', 'es2015',
'stage-1']}},
{
test: /\.scss/,
loader: ExtractTextPlugin.extract(
"style-loader",
"css-loader!sass-loader"
)
},
{
test: /\.css/,
loader: ExtractTextPlugin.extract("style-loader", "css-loader")
}
],
}
En el objeto loaders se incluyen aquellos archivos que se quieran transpilar. En la parte

test se indica la expresión regular que debe coincidir para aplicar el “loader”
correspondiente. Por ejemplo, los ficheros con extensión “.scss” se transpilan con el
loader “ExtractTextPlugin”. También se indica que a todos los ficheros con extensión “.js
27
| .jsx” les pase el “loader” de Babel. Además, se añade unas opciones de configuración
a Babel con el objeto “query” indicando que utilice el “preset” de “es2015” para
transpilar la sintaxis de Javascript para aquellos navegadores que aún no lo soporten a
la versión que si lo soportan y el “preset” de React que permite el procesamiento de JSX
a Javascript.
resolve: {
extensions: ['', '.js', '.jsx', '.json', '.css', '.scss', '.png', '.jpg', '.jpeg', '.gif'],
modulesDirectories: [
'node_modules'
]
}
Con “resolve” se indica a webpack cuales son las extensiones de los ficheros en los que
se tiene que fijar desde el directorio en el que se encuentre el fichero
“webpack.config.js” hacia dentro.
devServer: {
historyApiFallback: true,
contentBase: './public',
port: process.env.PORT || 5555
}
En este apartado de la configuración se introduce la configuración necesaria que utiliza

el servidor web de desarrollo.
devServer: {
historyApiFallback: true,
contentBase: './public',
port: process.env.PORT || 5555
}
28
e) Jest
Jest es un framework de testing desarrollado por Facebook y destaca por ser rápido y
flexible. Aunque nace en el contexto de React, es un framework de tesing
generalista[13].
Para poder utilizarlo hay que añadir una dependencia en el fichero package.json
utilizando NPM:
npm install --save-dev jest
Para estructurar los test en el proyecto, se agrupan en suites, es decir, en agrupaciones

de test que están relacionados[14]. Para definir este tipo de contextos, Jest nos
proporciona los siguientes niveles de agrupación:
● Nivel de fichero: Cada agrupación puede ir en un fichero distinto siempre y
cuando sea detectado por Jest. Esto sucede bajo ciertas condiciones como llamar
a los ficheros de test *.test.js o que esté dentro de un directorio __test__.
● Definición de contextos: Podemos agrupar los test mediante el constructor

“describe” bajo un concepto compartido: ejemplo:
describe('User registration', () => {

test('....', () => {});
});
En este proyecto se utiliza la agrupación a nivel de fichero, añadiendo un test por cada
componente.
2.3.2. Estructura y jerarquía de componentes React - Redux
a) Estructura
Los componentes son una parte esencial de una aplicación React. Dividir la interfaz de
usuario en componentes permite tener piezas independientes y reutilizables.
29
Conceptualmente, los componentes son como las funciones de Javascript. Estas

funciones aceptan un único argumento de entrada (conocidas como propiedades
“props”) y devuelven elementos React que describen lo que debería aparecer en
pantalla. También se puede utilizar una clase ES6 7 para definir un componente[10].
Estos componentes disponen de un estado que permite administrar datos dentro del
componente. El estado es una de las grandes ventajas de React (aunque el concepto no
es específico de esta tecnología).
El renderizado de los componentes se describe con JSX8. Cabe destacar que React solo
puede devolver un elemento directo, por lo que las devoluciones del renderizado deben
estar envueltas en un solo elemento externo con una etiqueta HTML <div>.
Para poder utilizar un componente se tiene que importar el archivo donde se quiera
utilizar y dentro del renderizado del JSX se coloca el nombre del componente entre los
símbolos de menos que y mayor que:
<Ejemplo
Props={propiedades}
/>
Si la jerarquía de componentes se vuelve muy compleja (es decir, tiene componentes de

presentación fuertemente anidados con innumerables devoluciones de llamadas y paso
de variables hacia sus hijos) es donde entra en juego la centralización del estado con
Redux. Para hacer esto se necesita el HOC9 connect() que proporciona Redux y definir
una función especial llamada “mapStateToProps” que indica cómo transformar el
estado actual del estado centralizado en Redux en propiedades del componente que lo
está utilizando (Figura 12).
7
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes
8
https://medium.com/@Thoughtworks_es/qu%C3%A9-demonios-es-jsx-txt-f5841e51f664
9
https://reactjs.org/docs/higher-order-components.html
30
Figura 13. Estructura componente React - Redux.
Cuando se dispone de muchos componentes, es importante tener el control de los

recursos y de los estados. Para poder hacer esto, se utiliza los métodos de ciclos de vida
de una clase:
● ComponenteWillMount: se ejecuta antes de que el componente sea
desmontado en el DOM.
● ComponenteDidMount: este método solo se ejecuta justo después de que el

componente haya sido montado en el DOM.
● ComponenteWillReceiveProps: este método no se ejecutará una vez se monte

el componente, si no que se espera a recibir nuevas props de un componente
padre para ejecutarse.
31
● ComponenteWillUpdate: es muy similar a componenteWillReceiveProp, solo

que se ejecuta justo antes del render, cuando las props o estados han sido
recibidos.
● ShouldComponentUpdate: se ejecuta de la misma forma que el anterior, solo

que por defecto siempre retorna “true”. Se puede hacer que retorne false para
cancelar el render.
● ComponenteDidUpdate: este método es invocado inmediatamente después de

que el componente se haya actualizado. Este método se utiliza para manejar los
datos del componente ya renderizado y actualizado en el DOM.
● ComponenteWillUnmount: se ejecuta justo antes de que el componente se

destruya o elimine del DOM.
b) Jerarquía
Una de las adaptaciones que se tiene que hacer para desarrollar en React es como crear
la jerarquía de componentes. Lo primero que se debería hacer es dibujar los
componentes (y subcomponentes) y darles nombres. Para saber si se debe crear un
componente se pueden utilizar técnicas como “el principio de responsabilidad única 10,
es decir, un componente idealmente debería hacer solo una cosa. Si termina creciendo,
se debe descomponer en subcomponentes más pequeños (Figura 13).
Cuando ya se tiene clara la jerarquía de componentes se debe crear una versión del
componente que tome el modelo de datos y lo represente, pero sin interactividad. Es
una buena práctica desacoplar estos procesos porque crear una versión estática
requiere mucha escritura sin pensar, y agregar interactividad requiere mucha reflexión
y poca escritura[10].
Una vez se tenga ya la jerarquía y los componentes, se piensa en el conjunto mínimo de

estados mutables que la aplicación necesita. La clave es basarse en concepto
comúnmente conocido como “no te repitas (DRY) 11”.
10
https://en.wikipedia.org/wiki/Single_responsibility_principle
11
https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
32
Figura 14. Ejemplo jerarquía de componentes.
2.4. Configuración de la forja
Aunque este TFM se centra en el desarrollo de la parte cliente, se explica el resto de las
tecnologías que se han utilizado, tanto la parte de servidor como el resto de las
tecnologías necesarias para el despliegue de la aplicación. Se puede construir de arriba
hacia abajo o al revés. Es decir, se puede comenzar con la construcción de los
componentes de más arriba en la jerarquía o con los de más abajo.
En proyectos simples, generalmente es más fácil ir de arriba a abajo, y en proyectos más
grandes, es más fácil ir de abajo hacia arriba y escribir pruebas a medida que se
construye.
33
2.4.1. API REST
La parte de servidor se constituye como un servicio API 12 de transferencia de estado

representacional (en inglés representational state transfer) o REST 13 que sigue una serie
de reglas que se deben cumplir para crear un estilo de arquitectura software, la cual se
apoya en el protocolo HTTP. Las operaciones más importantes que maneja son “GET”
para consultar y leer, “POST” para crear, “PUT” para editar y “DELETE” para eliminar.
Para construir este servicio, en este TFM se utiliza Node.js junto con Express[15].
Para facilitar las validaciones y la lógica empresarial con la integración, se utiliza

Mongoose como ayuda para el mapeo objeto-relacional (ORM14), que proporciona una
solución directa y basada en esquemas para modelar los datos de la aplicación. Incluye
la posibilidad de conversión de tipos y creación de consultas.
2.4.2. Node package manager (NPM)
Este sistema facilita a los desarrolladores compartir y reutilizar código generado como
paquetes o a veces también denominados módulos. Al crear un proyecto Node con
NPM, crea por defecto un archivo llamado “package.json” donde viene toda la
configuración previa necesaria para que un proyecto Node pueda ejecutarse[16].
2.4.3. Node.js y Express
Node.js (de ahora en adelante Node), es un entorno de código abierto 15, multi-
plataforma, para la capa del servidor (pero no limitado a ello), basado en el lenguaje de
programación Javascript, asíncrono 16, con entrada-salida de datos en una arquitectura
12
https://www.redhat.com/es/topics/api/what-are-application-programming-interfaces
13
https://developer.mozilla.org/es/docs/Glossary/REST
14
https://es.wikipedia.org/wiki/Mapeo_objeto-relacional
15
Software distribuido y desarrollado libremente. Se focaliza más en los beneficios prácticos
(acceso al código fuente) que en cuestiones éticas o de libertad que tanto se destacan en el
software libre.
16
La programación asíncrona establece la posibilidad de hacer que algunas operaciones
devuelvan el control al programa llamante antes de que hayan terminado mientras siguen
operando en segundo plano.
34
orientada a eventos, basado en el motor V8 de Google y que promueve la utilización de

módulos. Estos módulos tienen archivos donde se declaran clases, propiedades y
métodos entre otros. Normalmente estos módulos son privados a otros módulos, es
decir, no se puede acceder a ellos desde otros archivos directamente[16].
Express es una infraestructura para aplicaciones web Node.js. Tiene un tamaño muy
reducido y es muy flexible. Proporciona un conjunto sólido de características para las
aplicaciones web. Con miles de métodos de utilidad para el uso de HTTP y “middleware”
que permiten crear una API rápida, sólida y sencilla[17].
Ejemplo de uso en la aplicación:
const express = require("express"),

app = express(),
const router_animals = app.use(require('./negocio/routers/RouterAnimales.js'));
router_animales.route('/animal')
.get(SA_animales.buscarTodosAnimales)
app.listen(config.port, () => {
};
En las primeras dos líneas se incluye el módulo Express y se crea una aplicación de
Express. Este elemento se denomina comúnmente “app”, y posee métodos para el
enrutamiento de las peticiones HTTP.
A continuación, se configura un enrutador de Express que será el encargado de escuchar

las peticiones HTTP, en este caso está escuchando una petición de tipo “GET” con una
dirección “/” relativa al directorio raíz. La función “callback 17” coge una petición y una
17
https://developer.mozilla.org/es/docs/Glossary/Callback_function
35
respuesta que controla el servicio de aplicación de animales lanzando el método

“buscarTodosAnimales”.
El bloque final de código define y crea el servidor, que estará escuchando en el puerto
configurado en el archivo de configuración en la variable de entorno “port”.
2.4.4. MongoDB - Mongoose - Mongolab
MongoDB es una base de datos multiplataforma, de código abierto, que permite un

esquema dinámico y que almacena la información como documentos, por lo que puede
almacenar la información sin una estructura previa, al contrario que las bases de datos
relacionales. Una de las ventajas de MongoDB es su velocidad, alcanzando un balance
entre rendimiento y funcionalidad[18].
Mongoose es un “Object Document Mapper” (ODM). Esta herramienta permite definir

objetos con un esquema fuertemente tipado18 que se asigna a un documento MongoDB
y proporciona una increíble cantidad de funcionalidades para crear y trabajar con
esquemas. Junto a Node, esta herramienta facilita la comunicación y la comunicación
con la base de datos, relacionando el esquema de datos con un documento en
MongoDB.
MongoLab es un servicio de base de datos en la nube autoadministrado que permite

hospedar bases de datos MongoDB. En este proyecto se utiliza y se administra con un
“addon19” de Heroku.
2.4.5. Heroku
Heroku es uno de los proveedores de servicios (PaaS20) más utilizados en la actualidad

por su objetivo de facilitar el despliegue de una aplicación. Además, permite manejar
18
https://es.wikipedia.org/wiki/Tipado_fuerte
19
https://elements.heroku.com/addons
20
Plataforma como servicio - “Platform as a services”
36
los servicios, configuraciones y escalar la aplicación para enfocar todo el esfuerzo en

desarrollar y despreocuparse por la infraestructura.
Esta plataforma utiliza el modelo de contenedor para ejecutar y escalar todas las
aplicaciones de Heroku. A estos contenedores los denomina “Dynos”. Estos
contenedores son Linux aislados y virtualizados que están diseñados para ejecutar
código en función de un comando especificado por el usuario. Su aplicación puede
escalar a cualquier número específico de Dynos en función de la demanda de
recursos[4].
En este proyecto se enlazan distintos servicios con una rama de Github para generar un
despliegue continuo, es decir, cada vez que existe un cambio en dicha rama se despliega
automáticamente en el servicio asociado:
● Servicio para pre-producción: este servicio se utiliza para probar la aplicación
antes de que pase al servicio de producción.
● Servicio producción: este servicio es el que está disponible para nuestros

clientes.
● Servicio demo: se crea este servicio para poder realizar demostraciones a los
posibles clientes.
2.4.6. CORS
Con la aparición de tecnologías como AJAX permitieron la explotación de una

vulnerabilidad en los navegadores conocida como intercambio de Recursos de Origen
Cruzado (CORS21). Es un mecanismo que permite que se puedan solicitar recursos
restringidos en una página web a un dominio que está fuera del dominio que pidió el
recurso[19]. Una página web podría libremente incrustar imágenes, hojas de estilo,
scripts, iframes o videos de origen cruzado [20] que ejecutan código malicioso sin
autorización del usuario. Estos scripts pueden, entre otras cosas, realizar peticiones no
deseadas a otras aplicaciones servidor. Estas peticiones suelen tener el objetivo de robo
21
Inglés: Cross-Site Scription
37
de información, sustracción de dinero, etc. Ciertas peticiones de origen cruzado (como

las peticiones Ajax), están prohibidas por defecto en los navegadores.
CORS define una forma en la cual un navegador y un servidor pueden interactuar para
determinar si es seguro permitir una petición de origen cruzado[20]. Esto permite tener
más libertad y funcionalidad que las peticiones de mismo origen.
Dentro de este proyecto se realiza una especial para CORS en las peticiones que se hacen
a Amazon Web Services (S3) para pedir imágenes22.
22
Configuración CORS Amazon Web Services:
https://docs.aws.amazon.com/es_es/AmazonS3/latest/dev/cors.html
38
3. PLANIFICACIÓN DEL PROYECTO
Planificación del proyecto
3.1. Requisitos no funcionales
Para la correcta implementación del proyecto se han establecido los siguientes

requisitos no funcionales:
• La aplicación consta de dos partes:
o El servicio que tiene toda la lógica de negocio y la expone para que pueda
ser consumida por la plataforma web.
o La parte cliente que consume el servicio anterior. Este genera un archivo

que servirá un servidor Node.js.
• La plataforma web será multiplataforma, adaptando su interfaz a cualquier

dispositivo (móvil, tablet, ordenador, etc).
• Los datos de los clientes, usuarios y animales se almacenan en una base de datos
alojada en la nube y accesible solo por la plataforma web.
• El código del proyecto se almacena en un control de versiones gratuito

manteniendo el código de forma privada (solo los desarrolladores de este
proyecto pueden verlo).
• Para el despliegue de la aplicación, se utiliza un servicio que automatiza el

proceso (Despliegue continuo).
• Para que una protectora pueda acceder al panel de administración es necesario

su registro.
• Todos los posibles datos y cómo acceder a ello se describirán en una Wiki.
• Se abandonan unos 130.000 animales al año, por lo que la aplicación tiene que
estar preparado para poder soportar con fluidez búsquedas en bases de datos
con miles de animales.
40
3.2. Requisitos funcionales
A continuación, se describen las distintas funcionalidades que debe ofrecer la aplicación:

● API REST:
○ Protectora:
■ CRUDA23.
■ Verificar cuenta protectora.
■ Login protectora.
■ Subir imagen principal de protectora a AWS S3.
■ Subir galería de imágenes de protectora a AWS S3.
■ Subir galería de videos de protectora a AWS S3.
■ Obtener imagen principal de protectora en AWS S3.
■ Buscar whatsapp activos de una protectora.
○ Animales:
■ CRUDA.
■ Buscar todos los animales de una protectora.
■ Modificar estado de un animal.
■ Obtener una propiedad concreta de un animal.
■ Subir imagen principal de un animal en AWS S3.
■ Subir galería de imágenes de animal en AWS S3.
■ Subir galería de videos de animales a AWS S3.
■ Obtener imagen principal de animal en AWS S3.
○ Configuración y utilidades:
■ Envío de parámetros de configuración.
■ Obtener datos de geolocalización por código postal.
■ Obtener datos de geolocalización de dirección.
■ Obtener distancia entre dos puntos geográficos.
■ Envío de email a protectora.
23
CRUDA = crear, leer, actualizar y leer todo (Create, Read, Update and All (Read)).
41
● Una protectora no podrá acceder al panel de administración si no se ha

registrado previamente en el sistema.
● Una protectora no podrá acceder a la plataforma hasta que no verifique que el

email que ha introducido en el registro es suyo.
3.3. Metodología ágil - Scrum
3.3.1. Manifiesto ágil
El manifiesto ágil es un documento que se redactó en 2001 por 17 expertos en

programación convocados por Kent Beck. Se reunieron en Salt Lake City para discutir
sobre del desarrollo de software[21]. Los integrantes de la reunión resumieron en cuatro
postulados lo que ha quedado denominado como “Manifiesto Ágil”, que son los valores
sobre los que se asientan estos métodos[22]:
● Individuos e interacciones sobre procesos y herramientas.
● Software funcionando sobre documentación extensiva.
● Colaboración con el cliente sobre negociación contractual.
● Respuesta ante el cambio sobre seguir un plan.
Bajo estos valores se redactaron los principios que de ellos derivan:
● Satisfacer al cliente mediante la entrega temprana y continua de software con

valor.
● Requisitos cambiantes, incluso en etapas tardías del desarrollo. Los procesos

ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
● Entrega de software funcional de forma frecuente, entre dos semanas y dos

meses, siendo preferible periodos cortos de tiempo.
● Los responsables del negocio y los desarrolladores trabajan juntos de forma

cotidiana durante todo el proyecto.
42
● Los proyectos se desarrollan en torno a individuos motivados. Se proporciona un

entorno con buenas condiciones y el apoyo que necesitan.
● El método más eficiente y efectivo de comunicar información al equipo de

desarrollo y entre sus miembros es la conversación cara a cara.
● El software funcionando es la medida principal de progreso.
● Los procesos ágiles promueven el desarrollo sostenido. Los promotores,

desarrolladores y usuarios debemos mantener un ritmo constante de forma
indefinida.
● La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
● La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es

esencial.
● Las mejores arquitecturas, requisitos y diseños emergen de equipos

autoorganizados.
● A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para, a
continuación, ajustar y perfeccionar su comportamiento en consecuencia.
3.3.2. SCRUM
Es una metodología ágil de desarrollo iterativa e incremental, que reduce la complejidad

en el desarrollo de productos para satisfacer las necesidades de los clientes. Tanto el
cliente como el equipo trabajan de forma conjunta alrededor de una serie de requisitos
y tecnologías con el objetivo de entregar de forma temprana productos funcionando
que aporten valor de negocio al cliente[23].
Con esta metodología se trabaja bajo un marco incremental que promueve la

colaboración en los equipos para lograr desarrollar productos complejos. Está basado
en la autoorganización de los equipos para lidiar con los requisitos cambiantes[23].
En este proyecto se utiliza SCRUM como metodología de trabajo.
43
Algunos aspectos a tener en cuenta:

● En este caso no existe en sí la figura de “Product Owner” y “Scrum Master” al ser
un producto propio.
● Se decidió que las iteraciones tuvieran una duración de dos semanas. Del tiempo
disponible (académico), se optó por:
○ Se comienza el proyecto a febrero de 2019, dejando el mes de junio de
2019 para redactar la documentación.
○ Invertir 6 semanas en una fase de investigación y generar la arquitectura

base del proyecto. Una vez analizadas las tecnologías necesarias, se
construye el modelo de dominio, los diagramas generales de casos de uso
de la aplicación y definimos la interfaz gráfica del usuario (GUI), la
estructura de los componentes (HTMl y CSS3) dejando para el resto de
los Sprints el desarrollo de la aplicación. (2 sprints).
○ Los demás sprints se acogen a un modelo tradicional Scrum siguiendo la

siguiente estructura. (Figura 15).
● Las tareas asociadas a las historias de usuario se han planificado utilizando

Planning Poker Cards 24 para estimar el esfuerzo y se asigna el total del esfuerzo
estimado como Story Points25 en cada historia de usuario.
● Para cada iteración tendrá alrededor de 25 Story Points asignados y se

comienzan por aquellas historias de usuario con más Story Points.
● El número de días trabajados por semana serán tres (viernes, sábado y domingo).
Por lo que cada iteración aplica a solo estos tres días.
● Las reuniones de equipo, al ser pocos integrantes en el proyecto, no se hacen

diariamente “Daily Scrum” como se especifica en la documentación oficial, si no
una por semana (generalmente los lunes).
● Al final de cada iteración se mantiene una reunión para mostrar los resultados
obtenidos durante el mismo. En esta reunión se realizan observaciones de las
24
https://www.netmind.es/knowledge-center/estimando-con-planning-poker-y-story-points/
25
https://www.scrum.org/resources/blog/why-do-we-use-story-points-estimating
44
metodologías utilizadas y prácticas que se han realizado para ver si se han

realizado correctamente, ver qué cosas se pueden mejorar y eliminar aquellas
que no dan resultado con el objetivo de mejorar en las siguientes iteraciones.
Figura 15. Procesos de una metodología Scrum. Fuente: Scrum.org.
3.3.3. Planificación del proyecto.
a) Inception Deck
Una buena práctica para comenzar un proyecto de software es utilizar Inception Deck.
Son una serie de técnicas conocidas para la toma de requisitos y de customer
engagement 26 que Jonathan Rasmusson recoge en su libro “Agile Samurai 27” [24] .
Estas técnicas hablan de cómo deben participar todos los implicados en el proyecto, con
la intención de que todo el mundo comparta la misma visión del producto, conocer los
riesgos existentes y las necesidades para abordar el proyecto de forma correcta (30).
Todas estas tareas exponen la ruta a seguir que acabará derivando en las historias de
usuario y tareas a desarrollar por el equipo. De esta hoja de ruta también se pueden
26
https://en.wikipedia.org/wiki/Customer_engagement
27
https://pragprog.com/titles/jtrap/the-agile-samurai
45
estimar unos costes, pero como las metodologías ágiles exigen flexibilidad, es una vista
panorámica inicial que puede variar con el paso de las semanas[25].
Como el inception deck se centra en el entendimiento del cliente con los desarrolladores
y el autor de este TFM es a su vez el propio cliente y se ha partido de una idea previa,
que sería la creación de un servicio donde los clientes puedan registrar su animales y
que potenciales usuarios puedan encontrarlos, no se expone una fase de inception deck,
aunque si se contesta a una de las preguntas que si aporta al proyecto, la estimación y
priorización de características.
b) Estimación y priorización de características
Para saber la cantidad de valor que se está aportando al proyecto, si se están

cumpliendo los objetivos y el esfuerzo que conlleva, es necesario valorar y estimar el
esfuerzo que conlleva desarrollar el proyecto.
Cuando ya se conocen los tiempos y el esfuerzo del proyecto, se puede saber el tiempo
que te llevará realizar cada tarea y si se tienen los recursos suficientes.
Para recoger todas las características del producto se utiliza un Product Backlog donde
quedan reflejadas todas las características de la aplicación. Para cada característica se
asigna el esfuerzo que costaría realizarla. Para ello, se han establecido un total de 100
Story Points (SP) a repartir entre las distintas características. Además, también se asocia
a cada una de ellas una referencia al esfuerzo que conlleva (puntos de esfuerzo: PE) que
oscilan entre 1 y 5 (1 - poco esfuerzo, 5 - mucho esfuerzo). Esta unidad de referencia se
establece como medida comparativa al esfuerzo que costaría crear una fase completa
(crear, leer, modificar, eliminar y listar). Esto permite mantener y priorizar las historias
de usuario asignando unidades de valor a cada historia y se puede ver cómo se quedan
priorizadas en base a las necesidades de la aplicación. En las primeras iteraciones hay
que enfocarse sobre características que aporten mayor valor de negocio y realizar
primero aquellas que sean más críticas.
46
c) Product Backlog
Las historias de usuario son descripciones breves y simples de una característica contada
desde la perspectiva de la persona que desea la nueva capacidad, generalmente un
usuario o un cliente del sistema. La plantilla que se ha utilizado para la descripción es:
Como <tipo de usuario>, quiero/necesito <un objetivo> para/con la finalidad <un
motivo/finalidad>.
Para detallar las historias de usuario se ha utilizado la plantilla que ofrece Mike Cohn(31)
añadiendo los criterios de aceptación con esta plantilla:
Dada <una situación>, cuando <ocurre algo>, entonces <consecuencia>
ID HUXX
Alias Título
Enunciado Como <tipo de usuario>, quiero <un objetivo>, de forma que <motivo>
Criterios de
Dada <una situación>, cuando <ocurre algo>, entonces <consecuencia>
aceptación
Conversación Detalles
Esfuerzo: 1-5 (1 poco esfuerzo - 5 mucho esfuerzo)

Valor: XX Story Points
Prioridad: Baja - Alta
47
Siguiendo dicha plantilla, se han creado las siguientes historias de usuario.
ID HU01 - Historia técnica
Alias Investigar tecnologías
Como sistema,
Enunciado quiero poder entender las tecnologías que queremos utilizar
con la finalidad de poder desarrollar una aplicación web multiplataforma.
Criterios de
-
aceptación
Tecnologías que se han aprendido: React + Redux, Webpack, NodeJS +
Conversación
Express, Amazon Web Services S3 y Heroku.
Esfuerzo: 5
Valor: 50 SP
Prioridad: Alta
ID HU02 - Historia técnica
Alias Creación de arquitectura web
Como sistema,
Enunciado quiero poder tener una arquitectura web desplegada
con la finalidad de poder tener disponible una base de la aplicación.
Criterios de
-
aceptación
Conversación -
Esfuerzo: 5
Valor: 50 SP
Prioridad: Alta
48
ID HU03
Alias Crear protectora
Como protectora, quiero poder registrarme en la plataforma, con la

Enunciado
finalidad de poder acceder a las funcionalidades que ofrezca la plataforma.
Criterios de En el formulario de registro, rellene todos los datos y seleccione el botón de
aceptación crear, entonces se crea el registro en la plataforma.
Cuando se crea el perfil si es correcto aparecerá un mensaje de confirmación
y si hay un error aparecerá un mensaje diciendo que ha habido un error.
Conversación En el formulario habrá un campo donde se introduce el código postal y te

rellena automáticamente la dirección. También, habrá un botón al lado de
los campos de móviles donde se podrá activar el contacto vía whatsapp.
Esfuerzo: 5
Valor: 10 SP
Prioridad: Alta
ID HU04
Alias Leer protectora
Como protectora/usuario,
Enunciado quiero poder ver la información de una protectora,
con la finalidad de poder ver la información.
En el panel de administración o listado de animales, cuando pulse sobre el
Criterios de
perfil de la protectora, se podrán ver los datos de la protectora
aceptación
seleccionada.
Estos datos lo podrán ver las protectoras para consultar sus propios datos o
Conversación los usuarios en el listado de animales. Dentro de este listado de animales se
podrá ver la protectora asociada a cada animal.
Esfuerzo: 2
Valor: 5 SP
Prioridad: Alta
49
ID HU05
Alias Modificar protectora
Como protectora,
Enunciado quiero poder modificar la información registrada,
con la finalidad de poder modificar la información.
En el panel de administración de las protectoras, seleccionando la opción
Criterios de
‘modificar perfil’, podré visualizar los datos actualmente registrado y se
aceptación
podrán cambiar los datos registrados y guardarlos.
Conversación
Esfuerzo: 4
Valor: 10 SP
Prioridad: Media
ID HU06
Alias Eliminar protectora
Como protectora,
Enunciado quiero poder eliminar el perfil,
con la finalidad de eliminar el registro de la plataforma
Criterios de En el panel de administración, seleccionando la opción de ‘eliminar cuenta’,
aceptación se eliminan todos los datos de la protectora.
Conversación
Esfuerzo: 1
Valor: 3 SP
Prioridad: Baja
50
ID HU07
Alias Listar protectoras
Como usuario,
quiero ver el listado con la información básica de todas las protectoras
Enunciado
registradas en el sistema,
con el objetivo de encontrar la protectora que busco.
Criterios de Accediendo a la opción de ‘ver todas las protectoras’, se podrá ver un listado
aceptación de protectoras con su información básica.
Conversación
Esfuerzo: 1
Valor: 5 SP
Prioridad: Baja
ID HU08
Alias Verificar cuenta protectora
Como protectora,
quiero poder verificar que el email con el que me he registrado me
Enunciado
pertenece,
para poder utilizar la plataforma.
Criterios de Mediante un email que envíe la plataforma a la cuenta de email con el que
aceptación se haya registrado, podrá hacer clic sobre un enlace para verificar la cuenta.
Conversación
Esfuerzo: 2
Valor: 6 SP
Prioridad: Alta
51
ID HU09
Alias Reactivar cuenta
Como protectora,
Enunciado deseo poder reactivar mi cuenta,
para poder acceder de nuevo a la plataforma.
Mediante una opción en la parte de Login, podré introducir un email válido
Criterios de
(que ya haya existido) y podré verificar que la cuenta es mía haciendo clic
aceptación
sobre un enlace que recibiré en la cuenta introducida.
Conversación
Esfuerzo: 1
Valor: 2 SP
Prioridad: Baja
ID HU10
Alias Login de protectora
Como protectora,
Enunciado deseo poder acceder a la plataforma,
para poder modificar mis datos o los animales que tenga registrados.
Introduciendo el email y la contraseña con la que se hizo el registro y
Criterios de
pulsando en el botón “Login”, podré acceder al panel de administración que
aceptación
ofrece la plataforma.
Conversación
Esfuerzo: 2
Valor: 10 SP
Prioridad: Alta
52
ID HU11
Alias Subir imagen principal de protectora a AWS S3
Como protectora,
Enunciado quiero poder registrar una imagen principal,
para que sea la imagen que aparezca en la información básica.
Criterios de En el registro de la información, habrá un apartado donde pueda seleccionar
aceptación o arrastrar una imagen, recortarla y seleccionarla como imagen principal.
Conversación
Esfuerzo: 4
Valor: 9 SP
Prioridad: Alta
ID HU12
Alias Obtener imagen principal de una protectora
Enunciado quiero poder obtener la imagen principal de una protectora,
para poder asociar la imagen con la protectora
Criterios de En la información de la protectora, existirá una parte donde se pueda
aceptación visualizar la imagen principal de una protectora (Logo).
Conversación
Esfuerzo: 2
Valor: 8 SP
Prioridad: Alta
53
ID HU13
Alias Subir imagenes de protectora AWS S3
Como protectora,
Enunciado quiero poder subir imágenes de la protectora,
para que los usuarios puedan visualizarlas.
En el registro de la información, habrá un apartado donde se puedan
Criterios de
seleccionar o arrastrar varias imágenes y recortarlas. Cuando se pulse al
aceptación
botón guardar se subirán al servicio de Amazon Web Services S3.
Conversación
Esfuerzo: 5
Valor: 10 SP
Prioridad: Baja
ID HU14
Alias Subir galería de videos de protectora a AWS s3
Como protectora,
Enunciado quiero poder subir videos de la protectora,
para que los usuarios puedan visualizarlos.
En el registro de la información, habrá un apartado donde se puedan
Criterios de
seleccionar o arrastrar videos. Cuando se pulse el botón guardar se subirán
aceptación
al servicio de Amazon Web Services S3.
Conversación
Esfuerzo: 5
Valor: 10 SP
Prioridad: Baja
54
ID HU15
Alias Obtener imágenes de una protectora
Enunciado quiero poder obtener las imágenes de una protectora,
para poder ver cómo es la protectora.
Criterios de En el detalle de una protectora, además de ver sus datos se podrán visualizar
aceptación imágenes de la protectora.
Conversación Estas imágenes irán en un componente de tipo Carrusel.
Esfuerzo: 3
Valor: 7 SP
Prioridad: Alta
ID HU16
Alias Obtener videos de una protectora
Enunciado quiero poder obtener los videos de una protectora,
para poder ver cómo es la protectora.
Criterios de Cuando se cargue la información de la protectora, existirá la posibilidad de
aceptación visualizar videos de la protectora.
Conversación Estos videos irán en un componente de tipo Carrusel.
Esfuerzo: 3
Valor: 7 SP
Prioridad: Baja
55
ID HU17
Alias Gestión de Whatsapps de una protectora
Como protectora,
quiero poder seleccionar de mis teléfonos registrados por cuales se pueden
Enunciado
contactar por whatsapp,
para que el sistema ofrezca solo esos nùmeros como contacto vía whatsapp.
En el registro de la protectora, habrá un campo donde se podrán meter
números móviles y existirá la posibilidad de colocar estos móviles como
Criterios de
“contacto vía whatsapp”. Los usuarios de la plataforma podrán seleccionar
aceptación
el número con el que quieren contactar y abrirá de forma automática la
aplicación Whatsapp.
Conversación
Esfuerzo: 3
Valor: 8 SP
Prioridad: Alta
ID HU18
Alias Crear un animal
Como protectora,
Enunciado deseo poder registrar un animal,
para que los usuarios puedan verlos.
En el panel de administración existirá la posibilidad de registrar un animal
Criterios de pulsando un botón. Rellenando los datos y las imágenes deberán registrarse
aceptación en el sistema. Estos datos deberán poder visualizarlos los usuarios en el
listado de animales sí coinciden con los filtros.
Conversación
Esfuerzo: 5
Valor: 10 SP
Prioridad: Alta
56
ID HU19
Alias Leer un animal
Como protectora,
Enunciado deseo poder visualizar la información de un animal,
para conocer la información de un animal.
En el panel de administración habrá un botón para listar los animales que
Criterios de
tiene registrados una protectora. En este listado se podrá seleccionar un
aceptación
animal para conocer más información.
Conversación
Esfuerzo: 3
Valor: 5 SP
Prioridad: Alta
ID HU20
Alias Modificar un animal
Como protectora,
Enunciado deseo poder modificar los datos de un animal,
para que pueda corregir la información de un animal.
En cada detalle del animal, habrá un botón para poder modificar los datos.
Criterios de Una vez modificados, si se pulsa el botón guardar se sobrescriben los datos
aceptación en el sistema. Estos datos deberán poder visualizarse de forma correcta en
el listado de animales que visualizan los usuarios en el sistema.
Conversación
Esfuerzo: 5
Valor: 10 SP
Prioridad: Media
57
ID HU21
Alias Eliminar un animal
Como protectora,
Enunciado quiero poder eliminar un animal,
para que no aparezca en el listado de animales.
Criterios de En cada detalle del animal habrá un botón para eliminar. Si se elimina dejará
aceptación de aparecer en el listado de animales.
Conversación
Esfuerzo: 2
Valor: 2 SP
Prioridad: Baja
ID HU22
Alias Listar animales
Enunciado quiero poder listar animales según un filtro,
para poder seleccionar el que busco o realizar tareas de administración.
Criterios de Tanto en el panel de administración como en la búsqueda de usuarios se
aceptación podrán visualizar todos los animales según un filtro específico.
En el listado de animales existirá un filtro con el que buscar los animales que
Conversación
aparecen en dicho listado.
Esfuerzo: 5
Valor: 5 SP
Prioridad: Alta
58
ID HU23
Alias Subir imagen principal de un animal a AWS S3
Como protectora,
Enunciado quiero poder registrar una imagen principal,
para que en los listados aparezca por defecto esta imagen.
En el registro de la información de un animal, habrá un apartado donde
Criterios de
pueda seleccionar o arrastrar una imagen, recortarla y seleccionarla como
aceptación
imagen principal.
Conversación
Esfuerzo: 4
Valor: 9 SP
Prioridad: Media
ID HU24
Alias Obtener imagen principal de un animal
Enunciado quiero poder obtener la imagen principal de un animal,
para poder asociar los datos de un animal a una imagen.
Criterios de En la información del animal, existirá una parte donde se pueda visualizar la
aceptación imagen principal de un animal.
Conversación
Esfuerzo: 2
Valor: 8 SP
Prioridad: Alta
59
ID HU25
Alias Subir galería de imágenes de animales a AWS S3
Como protectora,
Enunciado quiero poder subir imágenes de un animal,
para que los usuarios puedan visualizarlas en el listado.
En el registro de la información de un animal seleccionado, habrá un
Criterios de apartado donde se puedan seleccionar o arrastrar varias imágenes y
aceptación recortarlas. Cuando se pulse el botón guardar se subirán al servicio de
Amazon Web Services S3 y quedará vinculadas a ese animal.
Conversación
Esfuerzo: 4
Valor: 5 SP
Prioridad: Alta
ID HU26
Alias Subir galería de videos de animales a AWS S3
Como protectora,
Enunciado quiero poder subir videos de los animales,
para que los usuarios puedan visualizarlos.
En el registro de la información de un animal seleccionado, habrá un
Criterios de apartado donde se puedan seleccionar o arrastrar videos. Cuando se pulse
aceptación el botón guardar se subirán al servicio de Amazon Web Services S3 y
quedarán vinculados a ese animal.
Conversación
Esfuerzo: 4
Valor: 5 SP
Prioridad: Baja
60
ID HU 27
Alias Obtener imágenes de un animal
Enunciado quiero poder obtener las imágenes de un animal,
para poder ver como es el animal.
Criterios de En el detalle de un animal, además de ver sus datos se podrán visualizar
aceptación imágenes del animal.
Conversación Estas imágenes irán en un componente de tipo Carrusel.
Esfuerzo: 2
Valor: 7 SP
Prioridad: Alta
ID HU28
Alias Envío de email a protectora
Como usuario,
Enunciado quiero poder contactar con una protectora,
para obtener más información de un animal o adoptarlo.
Cuando se seleccione un animal dentro del listado de animales, nos dará la
opción de poder contactar con la protectora que ha subido el animal vía
Criterios de
email. Dentro de este panel, podemos poner el email, el asunto (que ya
aceptación
estarán preestablecidos) y el cuerpo del mensaje. Al pulsar enviar le llegará
al email que haya registrado dicha protectora.
Conversación
Esfuerzo: 2
Valor: 9 SP
Prioridad: Alta
61
ID HU29
Alias Añadir animal a favoritos
Como usuario,
Enunciado quiero poder añadir un animal a mi lista de favoritos,
para poder tener localizados en un sitio los que me gustan
En el listado de animales, existirá un icono (por ejemplo, un corazón), que si se
Criterios de pulsa se guardará en un listado de favoritos la información de un animal. Si
aceptación pulsamos sobre un icono de favorito en un animal que ya lo es se eliminará del
listado.
Conversación
Esfuerzo: 1
Valor: 2 SP
Prioridad: Baja
ID HU30
Alias Eliminar un animal de favoritos
Como usuario,
Enunciado quiero poder eliminar un animal de la lista de favoritos,
para poder eliminar los que ya no me interesan
En la lista de animales favoritos, existirá una opción para eliminar el animal
Criterios de
de la lista de favoritos. Si pulsamos sobre esta opción dejará de visualizarse
aceptación
este animal en el listado de favoritos.
Conversación
Esfuerzo: 1
Valor: 2 SP
Prioridad: Baja
62
Después de haber detallado las historias de usuario, se distribuyen por iteraciones de

modo que se cumpla la regla de 25 story points por cada una de ellas. Esta selección se
hará teniendo en cuenta la priorización de estas historias de usuario que van en relación
a la sus Story points y a la relación que existe entre ellas.
ID - alias Story points Iteración
HU01 - Investigar tecnologías 50 1-2
HU02 - Creación de arquitectura web 50 3
HU03 - Crea protectora 10 4
HU05 - Modificar protectora 10 4
HU04 - Leer protectora 5 4
HU18 - Crear animal 10 5
HU20 - Modificar animal 10 5
HU19 - Leer animal 5 5
HU10 - Login protectora 10 6
HU11 - Subir imagen principal de protectora a AWS S3 9 6
HU23 - Subir imagen principal de animal a AWS S3 9 6
HU12 - Obtener imagen principal protectora 8 7
HU24 - Obtener imagen principal animal 8 7
HU28 - Envío de email a protectora 9 7
HU17 - Gestión whatsapp de una protectora 8 8
HU08 - Verificar cuenta protectora 6 8
63
d) Desarrollo de sprints
d.1) Primer y segundo sprint - Investigar tecnologías
En el primer y segundo sprint, se realiza una historia técnica que especifica la

investigación de las tecnologías necesarias para desarrollar la aplicación. Al mismo
tiempo se crea una guía de estilos que se utilizará para la creación del diseño de los
componentes.
Por tanto, para este sprint se han identificado las siguientes tareas estimando el
esfuerzo con Planning poker:
HU01 Investigar tecnologías / T01_01 - Estudiar React
Esfuerzo 21
Tiempo estimado 40
Tiempo dedicado 46
Comentarios
HU01 Investigar tecnologías / T01_02 Estudiar Redux
Esfuerzo 13
Tiempo estimado (horas) 30
Tiempo dedicado (horas) 32
Comentarios
HU01 Investigar tecnologías / T01_03 Estudiar Webpack
Esfuerzo 8
Tiempo estimado 20
Tiempo dedicado 18
Comentarios
64
HU01 Investigar tecnologías / T01_05 Guía de estilos
Esfuerzo 8
Tiempo estimado 6
Tiempo dedicado 10
Comentarios
 Guía de estilos:
Para facilitar el diseño de los componentes, se crea una guía de estilos que facilite la
creación de los componentes React. Ver Anexo A.
 Sprint Review:
En este primer sprint el sprint review no es de gran utilidad ya que fue una fase de
investigación.
d.2.) Tercer sprint - Creación de arquitectura
En este sprint se crea la arquitectura de todo el proyecto, tanto de la parte de cliente

como la del servidor. En la parte de cliente se necesita React con Redux para centralizar
el estado de la aplicación, webpack para la transpilación de código a Javascript, Heroku
con Github para el despliegue de la aplicación y NodeJS para la parte servidor con
MongoDB para la integración.
Por tanto, las tareas para este sprint son:
HU02 Creación de arquitectura / T02_01 Crear proyecto React - Redux
Esfuerzo 21
Tiempo estimado 18
Tiempo dedicado 21
Comentarios
65
HU02 Creación de arquitectura / T02_02 Incorporar Webpack para transpilar
Esfuerzo 13
Tiempo estimado 10
Tiempo dedicado 10
Comentarios
HU02 Creación de arquitectura / T02_03 Crear servidor NodeJS
Esfuerzo 5
Tiempo estimado 15
Tiempo dedicado 18
Comentarios
HU02 Creación de arquitectura / T02_04 Integrar MongoDB con el servidor
Esfuerzo 3
Tiempo estimado 2
Tiempo dedicado 3
Comentarios
HU02 Creación de arquitectura / T02_05 Crear proyecto en Github
Esfuerzo 5
Tiempo estimado 1
Tiempo dedicado 1
Comentarios
66
HU02 Creación de arquitectura / T02_06 Configurar Heroku y Despliegue automático
Esfuerzo 5
Tiempo estimado 2
Tiempo dedicado 2
Comentarios
 Arquitectura React - Redux
Antes de comenzar a desarrollar la aplicación, se toman una serie de decisiones

necesarias para la creación de la arquitectura. Estas decisiones se materializan en una
serie de elementos reutilizables en la aplicación. Además, se definen las rutas que va a
utilizar la aplicación, como se va a conectar el cliente con el servidor y la autenticación
de los clientes en la plataforma.
En esta tarea se genera el marco estructural de archivos y carpetas necesarias para que
el proyecto sea legible. Para hacer esto, la documentación de React y Redux
proporcionan una guía de buenas prácticas en la que se basa este proyecto (incluso
proporciona un cliente para generar un proyecto React básico) 28.
28
https://es.reactjs.org/docs/create-a-new-react-app.html
67
La arquitectura se divide de la siguiente forma (Figura 16):
Figura 16. Arquitectura.
68
● Negocio: En este directorio se encuentra todo el desarrollo del servidor, como la

configuración de base de datos, los servicios de aplicación, los modelos de datos
y los enrutadores.
● Public: Este directorio es la raíz de la aplicación y el sitio adecuado donde ubicar

los archivos estáticos (como por ejemplo las hojas de estilos CSS, los ficheros con
código fuente escrito en lenguaje javascript donde se programa la lógica de la
aplicación, los HTML donde está maquetada la estructura de la aplicación, etc).
Además, es aquí donde se coloca el código transpilado por Webpack ya que es el
lugar donde se encuentra el index.html de la aplicación.
● src: Esta carpeta contiene toda la parte del cliente:
○ Actions: Este directorio contiene todos los ficheros javascript encargados

de modificar los estados de la aplicación. Es una parte fundamental para
la arquitectura con Redux.
○ Components: Todos los componentes React de la aplicación se

encuentran en esta carpeta.
○ Enums: Aquí se almacenan los enumeradores necesarios para la

aplicación. Algunos de los que se han usado para la aplicación son filtros
como la edad o el tamaño de los animales.
○ Reducers: En este directorio se encuentra toda la lógica necesaria para

almacenar la información del estado de la aplicación. Estos estados son
manipulados por las acciones de Redux.
● app.js: Este fichero contiene toda la información para crear un servidor capaz de
servir la aplicación.
● config.js: Toda la información común entre la parte cliente y servidor se

encuentra almacenada en este fichero. Como, por ejemplo, la conexión con la
base de datos.
● jest.config.js: Este fichero contiene la configuración para realizar test unitarios.
● package.json: Este archivo almacena los principales parámetros de

configuración del proyecto Node, tales como:
69
○ Nombre del proyecto.
○ Autor.
○ Versión.
○ Dependencias de la aplicación. Algunas de estas dependencias

necesarias son:
■ React versión 15
■ React-redux: Dependencia necesaria para conectar Redux con
React.
■ webpack.
■ axios.
■ babel.
■ etc.
○ Scripts de lanzamiento.
○ Configuración del repositorio Git.
● node_modules: Este directorio almacena el contenido de las dependencias

necesarias para que la aplicación funcione. Todas estas dependencias son las
especificadas en el archivo package.json.
 Sprint Review
En este sprint se aprovechó esta reunión para comprobar que la arquitectura de cliente
y la de servidor se integran correctamente, ya que el autor de este TFM solo investigó la
arquitectura de cliente.
d.3.) Cuarto sprint - Módulo protectora
En este sprint se lleva a cabo el módulo de protectora. El total de horas asociadas a este
sprint son 48 horas. Las historias de usuario asociadas a este sprint se dividen en las
siguientes tareas:
70
HU03 Crear protectora / T03_01 Generar componentes de formulario
Esfuerzo 13
Tiempo estimado 11
Tiempo dedicado 6
Comentarios
HU03 Crear protectora / T03_02 Crear panel administración base
Esfuerzo 3
Tiempo estimado 2
Tiempo dedicado 1
Comentarios
HU03 Crear protectora / T03_03 Crear componente formulario creación protectora
Esfuerzo 21
Tiempo estimado 12
Tiempo dedicado 21
Comentarios
HU03 Crear protectora / T03_04 Conectar cliente con servidor para registrar protectora
Esfuerzo 5
Tiempo estimado 3
Tiempo dedicado 3
Comentarios
71
HU04 Leer protectora / T04_01 Crear componente lectura de una protectora
Esfuerzo 5
Tiempo estimado 6
Tiempo dedicado 3
Existen varias formas de pedir la información de una protectora:

● Básica
● parcial
Comentarios
● pesada
● completa
El modelo de datos para cada una se especifica en el API REST.
HU04 Leer protectora / T04_02 Conectar cliente con el servidor para leer una protectora
Esfuerzo 5
Tiempo estimado 3
Tiempo dedicado 3
Comentarios
HU05 Modificar protectora/ T05_01 Crear componente formulario modificación protectora
Esfuerzo 21
Tiempo estimado 8
Tiempo dedicado 21
Comentarios
HU05 Modificar protectora / T05_02 Conectar cliente con servidor para modificar protectora
Esfuerzo 5
Tiempo estimado 3
Tiempo dedicado 3
Comentarios
72
 Diagramas de casos de uso
A continuación, se muestra el diagrama de casos de uso de este módulo:
Figura 17. Diagrama de Casos de Uso - Módulo protectora.
 Modelo de datos:
El modelo de datos asociado a estas tareas es (formato JSON29):
{
nombre: {type: String, required: false, unique: true},
password: {type: String, required: true},
NIF: {type: String, required: false},
URL: {type: String},
facebook: {type: String},
instagram: {type: String},
twitter: {type: String},
descripcion: {type: String},
direccion: {
calle: {type: String, required: true},
numero: {type: Number},
29
https://developer.mozilla.org/es/docs/Learn/JavaScript/Objects/JSON
73
cod_Postal: {type: String, required: false},

municipio: {type: String, required: false},
provincia: {type: String, required: false},
pais: {type: String, required: false},
coordenadas_GPS: {
type: {type: String, default: 'Point'},
coordinates: {type: [Number], default: [40.4167, -3.70325]}
},
},
telefonos: [
{
telefono: String,
WhatsApp: Boolean
}
],
email: {type: String, required: false, unique: true},
realiza_envios: {type: Boolean, default: false},
logo: {type: String},
galeria_imagenes: {type: [String]},
galeria_videos: {type: [String]},
fecha_registro: {type: Date, default: Date.now},
visitas_recibidas: {type: Number, default: 0},
verificada_Admin: {type: Boolean, default: false},
verificada: {type: Boolean, default: false},
token_verificacion: {type: String, required: false},
estado: {type: String, enum: parametros.estados_protectora, default:
parametros.estados_protectora[0]}
}
74
 API REST - Conexión cliente - servidor
Para conectar los componentes de la aplicación con los datos del servidor se utiliza
peticiones al servidor bajo el protocolo HTTP 30. Los endpoints que proporciona el
servidor para estas tareas son:
Crear protectora - Registra una protectora en la BBDD
URL /protectora
Método POST
Parámetros URL -
Parámetros Query -
{
nombre: {type: String, required: true, unique:true},
password: {type:String, required:true},
cod_Postal: {type: String, required: true},
calle: {type: String, required: true, formato: "<NOMBRE_CALLE>"},
numero: {type: Number, required: true, formato: "<NUMERO>"},
NIF: {type: String, required: true},
Parámetros en el Body twitter: {type: String},
telefonos: [
{
telefono:String,
WhatsApp:Boolean
}
],
email: {type: String, required: true, unique:true},
}
30
https://developer.mozilla.org/es/docs/Web/HTTP/Methods
75
Code: 201 - Created

Respuesta satisfactoria
Content: ID Protectora
Code: 403 - FORBIDDEN
Content: errror.EMAIL_DUPLICADO
Code: 400 - BAD REQUEST

Content: error.ENTIDAD_DUPLICADA
Respuesta de error code: 500 - INTERNAL_SERVER_ERROR

content: error.
● ERROR_AL_REGISTRAR
● ERROR_ENVIO_EMAIL_PROTECTORA
● ERROR_ENVIO_EMAIL_ADMIN
Modificar protectora - Modificar una protectora en la BBDD
URL /protectora
Método PUT
Header Params Authorization -> Basic [USUARIO:PASSWORD]
Parámetros URL -
Parámetros Query -
{
Parámetros en el Body calle: {type: String, required: true, formato: "<NOMBRE_CALLE>"},
numero: {type: Number, required: true, formato: "<NUMERO>"}
76

telefonos: [
{
telefono:String,
WhatsApp:Boolean
}
],
}
Code: 201 - Created
Content: error/es en los datos de envío
Code: 500 - INTERNAL_SERVER_ERROR

Content: error.ERROR_AL_ACTUALIZAR_PROTECTORA
Respuesta de error
code: 502
content: error.DIRECCION_MAL_ESPECIFICADA
Leer protectora - Buscar protectora por ID
URL /protectora/:id
Método GET
Parámetros URL id=[MongoID]
:tipo = [‘básica’, ‘parcial’, ‘pesada’, ‘completa’]

Parámetros Query
77
● básica
{
logo,
nombre,
direccion,
estado,
telefonos,
emails
}
● parcial (+ basica)
{
logo,
nombre,
direccion,
NIF,
URL,
facebook,
instagram,
twitter,
descripcion,
email,
estado,
fecha_registro,
realiza_envios,
telefonos,
visitas_recibidas,
}
● pesada (+ parcial)
{
logo,
nombre,
galeria_imagenes,
galeria_videos,
}
78
● completa (+ pesada)
{
logo,
nombre,
direccion,
NIF,
URL,
facebook,
instagram,
twitter,
descripcion,
realiza_envios,
email,
estado,
telefonos,
visitas_recibidas,
galeria_imagenes,
galeria_videos,
password
}
Parámetros en el Body -
Code: 200
Content: JSON Proyección parámetro :tipo
Code: 404 - NOT_FOUND

Content: Array de parámetros erroneos -> [{code 123, str:
Respuesta de error
“texto”, ...]
code: 500 - INTERNAL SERVER ERROR
79
Crear protectora - Registra una protectora en la BBDD
URL /protectora
Método POST
Parámetros URL -
Parámetros Query -
{
password: {type:String, required:true},
calle: {type: String, required: true, formato: "<NOMBRE_CALLE>"},
numero: {type: Number, required: true, formato: "<NUMERO>"},
NIF: {type: String, required: true},
Parámetros en el Body
telefonos: [
{
telefono:String,
WhatsApp:Boolean
}
],
email: {type: String, required: true, unique:true},
}
Code: 201 - Created

Respuesta de error Content: errror.EMAIL_DUPLICADO
80

Content: error.ENTIDAD_DUPLICADA
code: 500 - INTERNAL_SERVER_ERROR

content: error.
● ERROR_AL_REGISTRAR
● ERROR_ENVIO_EMAIL_PROTECTORA
● ERROR_ENVIO_EMAIL_ADMIN
Crear protectora y Modificar protectora - Obtener datos dirección por código postal
URL /utils/GeocodeByCodPostal
Método GET
Parámetros URL -
Requeridos:
Parámetros Query ● :cod_postal
● :pais (por defecto España)
Code: 200
Content:
Content:
{
"cod_Postal": "28200",
Respuesta satisfactoria "municipio": "San Lorenzo de El Escorial",
"provincia": "Madrid",
"comunidad": "Comunidad de Madrid",
"pais": "España"
}
81
Code 400: - BAD REQUEST

Content: CODIGO_POSTAL_NO_ENCONTRADO
Respuesta de error
Code: 502 - BAD GATEWAY
Content: PARAMETRO_MAL_ESPECIFICADO
Crear protectora y Modificar protectora - Obtener whatsapp activos de una protectora
URL /protectora/:id/whatsapp
Método GET
Required:
Parámetros URL
● id=[MongoID]
Parámetros Query -
Code: 200
Content:
Content:
{
"totalRecord": <NUMERO DE WHATSAPP ACTIVOS>,
"result": {
"_id": <ID PROTECTORA>,
"telefonos": [
Respuesta satisfactoria {
"telefono": "676736397",
"WhatsApp": true,
"_id": "5b22f2f93284b110015a29b5"
}
]
}
}
82
Code 400: BAD REQUEST

Content: ERROR EN LOS DATOS ENVIADOS
Code 404 - NOT FOUND

Respuesta de error
Content: ERROR_PROTECTORA_NO_ENCONTRADA
Code: 500 - INTERNAL SERVER ERROR

Content: ERROR_BUSCAR_PROTECTORA
 Componentes
Los componentes que se han diseñado e implementado para estas historias de usuario
son:
● Componentes de formulario
Figura 18. Input component.
83
● Componente formulario para creación y modificación de protectora
Figura 19. PerfilComponent.
84
● Componentes Alerts:
Figura 20. AlertCheckComponent.
Figura 21. AlerConfirmComponent.
● Componente Lectura protectora:
Figura 22. CardProtectoraComponent.
85
● Componente Panel administración:
Figura 23. AdminComponent.
 Sprint Review
Después del desarrollo de esta iteración y comprobado que se cumplen los criterios de
aceptación, se realizaron las siguientes observaciones:
● Revisar los posibles problemas por CORS 31.
● Crear un control de errores genérico. Para ello el servidor tendría que devolver
un mensaje de error para que el cliente simplemente lo muestre.
● Redactar toda la documentación de los endpoints en la Wiki de Github.
● Utilizar un Addon de Heroku para enviar un email cuando una protectora se

registre. Este email servirá para verificar que el email que ha introducido la
protectora le pertenece.
● Añadir un sistema de logs para mejorar la depuración de errores.
● De momento no se incluye el NIF de la protectora en el formulario.
d.4.) Quinto sprint - Módulo animales
En este sprint se lleva a cabo el módulo de animales. El total de horas asociadas a este
sprint son 48 horas.
Las historias de usuario asociadas a este sprint se dividen en las siguientes tareas:
31
https://developer.mozilla.org/es/docs/Web/HTTP/Access_control_CORS
86
HU18 Crear animal/ T18_01 Crear componente formulario creación animal
Esfuerzo 21
Tiempo estimado 15
Tiempo dedicado 18
Comentarios
HU18 Crear animal/ T18_02 Conectar cliente con servidor para crear animal
Esfuerzo 5
Tiempo estimado 2
Tiempo dedicado 2
Comentarios
HU19 leer animal / T19_01 Crear componente lectura de un animal
Esfuerzo 8
Tiempo estimado 4
Tiempo dedicado 4
Existen varias formas de pedir la información de un animal:

● básica
● parcial
Comentarios
● pesada
● completa
El modelo de datos para cada una se especifica en el API REST.
HU19 Leer protectora / T19_02 Conectar cliente con el servidor para leer un animal
Esfuerzo 5
Tiempo estimado 2
Tiempo dedicado 2
Comentarios
87
HU19 Leer protectora / T19_03 Crear página bienvenida (“Home”)
Esfuerzo 5
Tiempo estimado 3
Tiempo dedicado 8
Comentarios
HU19 Leer protectora / T19_04 Filtros búsqueda animales
Esfuerzo 13
Tiempo estimado 8
Tiempo dedicado 10
Comentarios
HU20 Modificar animal / T20_01 Crear componente formulario modificación animal
Esfuerzo 13
Tiempo estimado 12
Tiempo dedicado 15
Comentarios
HU20 Modificar animal / T20_02 Conectar cliente con servidor para modificar animal
Esfuerzo 5
Tiempo estimado 2
Tiempo dedicado 2
Comentarios
88
Figura 24. Diagrama de Casos de Uso - Módulo animales.
 Modelo de datos:
El modelo de datos asociado a estas tareas son (formato JSON 32):
{
nombre: {type: String},
especie: {type: String, enum: parametros.especie_animal, required: true},
raza: {type: String, enum: [].concat(parametros.razas_Gato, parametros.razas_Perro),
required: true},
mestizo: {type: Boolean, required: true},
sexo: {type: String, enum: parametros.sexos, required: true},
tamano: {type: String, enum: parametros.tamaños_animal, required: true},
edad: {type: String, enum: parametros.edades_animal, required: true},
ppp: {type: Boolean},
color: {type: [String]},
32
https://developer.mozilla.org/es/docs/Learn/JavaScript/Objects/JSON
89
caracter: {type: [String]},

chip: {type: Boolean},
esterilizado: {type: Boolean},
enfermedades: {type: [String]},
vacunas: {type: Boolean},
fecha_entrada_Protectora: {type: Date},
fecha_registro: {type: Date, default: Date.now},
fecha_Adopcion: {type: Date},
estado: {type: String, enum: parametros.estados_animal},
img_principal: {type: String},
galeria_imagenes: {type: [String]},
galeria_videos: {type: [String]},
visitas_recibidas: {type: Number, default: 0},
direccion: {
municipio: {type: String, required: true},
coordenadas_GPS: {
type: {type: String, default: 'Point'},
coordinates: {type: [Number], default: [40.4167, -3.70325]}
},
},
protectora: {type: mongoose.Schema.ObjectId, ref: 'Protectora'}
}
33
90
Crear animales - Registra un animal en la BBDD
URL /animal
Método POST
Parámetros cabecera Authorization -> Basic [USUARIO:PASSWORD]
Parámetros URL -
Parámetros Query -
{
especie: {type: String, enum: parametros.especie_animal,
required: true},
raza: {type: [String], enum: `parametros.raza_Perro o Gato`,
required: true},
tamano: {type: String, enum: parametros.tamanos_animal,
required: true},
edad: {type: String, enum: parametros.edades_animal, required:
true},
Parámetros en el Body ppp: {type: Boolean, required: true},
color: {type: [String], required: true},
caracter: {type: [String], required: true},
chip: {type: Boolean, required: true},
descripcion: {type: String, required: true},
esterilizado: {type: Boolean, required: true},
enfermedades: {type: Boolean, default:false},
vacunas: {type: Boolean, required: true},
fecha_entrada_Protectora: {type: Date, required: true, formato:
"<AAAA-MM-DD>"},
estado: {type: String, enum: parametros.estados_animal,
required: true}
}
91
NOTA: uno o varios elementos separados por comas (sin espacios ni

comillas).
Code: 200
Content: JSON con proyección pedida
Content: Array de parámetros erróneos
Code: 404 - NOT FOUND

Content: JSON empty
Respuesta de error

content: ERROR_AL_REGISTRAR_ANIMAL
Modificar animales - Modificar un animal en la BBDD
URL /animal/:id
Método PUT
Header Params Authorization -> Basic [USUARIO:PASSWORD]
Parámetros URL :id = [MongoID]
Parámetros Query -
{
especie: {type: String, enum: parametros.especie_animal,
required: true},
raza: {type: [String], enum: `parametros.raza_Perro o Gato`,
required: true},
92
tamano: {type: String, enum: parametros.tamanos_animal,

required: true},
edad: {type: String, enum: parametros.edades_animal, required:
true},
ppp: {type: Boolean, required: true},
color: {type: [String], required: true},
caracter: {type: [String], required: true},
chip: {type: Boolean, required: true},
descripcion: {type: String, required: true},
esterilizado: {type: Boolean, required: true},
enfermedades: {type: Boolean, default:false},
vacunas: {type: Boolean, required: true},
fecha_entrada_Protectora: {type: Date, required: true, formato:
"<AAAA-MM-DD>"},
estado: {type: String, enum: parametros.estados_animal,
required: true}
}
Code: 200
Content: JSON con proyección pedida
Content: Array de parámetros erroneos

Content: NO_TIENE_PERMISOS
Respuesta de error Description: En caso de que la protectora loueada no sea dueña
del animal que se quiere modificar.

Content: ERROR_ANIMAL_NO_ENCONTRADO
code: 500 - INTERNAL SERVER ERROR
93
content:
● ERROR_BUSCAR_ANIMAL
● ENTIDAD_DUPLICADA
● ERROR_AL_REGISTRAR_ANIMAL
Leer animales - Buscar animal por ID
URL /animal/:id
Método GET
:tipo = [‘básica’, ‘parcial’, ‘pesada’, ‘completa’]
● básica
{
nombre,
protectora,
lugar,
estado,
especie,
raza,
mestizo,
Parámetros Query sexo,
ppp,
visitas_recibidas,
fecha_registro,
img_principal,
}
● parcial (+ basica)
{
img_principal,
nombre,
protectora,
especie,
94
raza,
mestizo,
sexo,
tamano,
edad,
ppp,
color,
caracter,
chip,
descripcion,
esterilizado,
enfermedades,
vacunas,
lugar,
fecha_entrada_Protectora,
fecha_registro,
fecha_Adopcion,
estado,
visitas_recibidas,
}
● pesada (+ parcial)
{
img_principal,
nombre,
protectora,
galeria_imagenes,
galeria_videos,
}
● completa (+ pesada)
{
img_principal,
nombre,
protectora,
95
especie,
raza,
mestizo,
sexo,
tamano,
edad,
ppp,
color,
caracter,
chip,
descripcion,
esterilizado,
enfermedades,
vacunas,
lugar,
fecha_entrada_Protectora,
fecha_registro,
fecha_Adopcion,
estado,
visitas_recibidas,
galeria_imagenes,
galeria_videos,
}
● Protectora Embebida:
{
nombre,
email,
telefonos,
URL,
}
:conP = [false, true] -> Por defecto: true (Inserta subdocumento
con la protectora).
96
Code: 200
Content: JSON Proyección pedida
Code: 404 - NOT_FOUND

Content: Array de parámetros erroneos -> [{code 123, str:
Respuesta de error
“texto”, ...]
code: 500 - ERROR_BUSCAR_ANIMAL
Leer animales- Buscar todos los animales
URL /animal
Método GET
Parámetros URL -
● Opcional:
○ :tipo = [‘basica’, ‘parcial’, ‘pesada’, ‘completa’] ->
Por defecto ‘basica’
Parámetros Query
○ Config
■ :num -> default 10
■ :pag -> default 0
Code: 200
Content: JSON proyección pedida.
Content: errror.EMAIL_DUPLICADO
Respuesta de error
97

content: error.ERROR_BUSCAR_ANIMALES
Leer animales- Buscar todos los animales de una protectora
URL /protectora/:id_prot/animales
Método GET
Parámetros URL :id_prot = [MongoID]
● Opcional:
○ :tipo = [‘basica’, ‘parcial’, ‘pesada’, ‘completa’] ->
Por defecto ‘basica’
Parámetros Query
○ Config
■ :num -> default 10
■ :pag -> default 0
Code: 200
Content: JSON proyección pedida.
Respuesta de error code: 500 - INTERNAL_SERVER_ERROR

content: error.ERROR_BUSCAR_ANIMALES
 Componentes
son:
98
● Componentes de formulario y filtros de búsqueda:
Figura 25. selectRadioGroupComponent
Figura 26. switchButtonComponent.
Figura 27. selectRadioGroupComponent2
99
Figura 28. inputMutiselectComponent.
100
● Página bienvenida con filtrado de animales previo:
Figura 29. homeComponent.
101
● Componente formulario para creación y modificación de animal:
Figura 30. AnimalFormComponent.
 Sprint Review
Después del desarrollo de esta iteración y comprobado que se cumplen los criterios de
aceptación, se realizaron las siguientes observaciones:
● Los componentes se están realizando correctamente ya que se están generando
lo más desacoplados posible para que sean lo más reutilizables.
● Los filtros podrían ser activados o desactivados en vez de filtrar siempre por
todos.
● La cabecera de la página web podría quedarse fija en la parte superior cuando el

usuario se mueve por el listado de animales.
● Cuando se hace una recarga de datos cambiando los filtros queda la cabecera
demasiado pegada a la parte superior.
102
● Se han estimado las tareas de una forma demasiado optimista, por lo que no se
llegaba a tiempo.
d.5.) Sexto sprint - Login y gestión de imágenes principales.
En este sprint se crea el formulario de login para las protectoras y se crea un

componente que permite seleccionar y ajustar la imagen principal tanto de una
protectora como de los animales. El total de horas asociadas a este sprint son 48 horas.
Las historias de usuario asociadas a este sprint se dividen en las siguientes tareas:
HU10 login protetora / T10_01 Crear componente formulario login
Esfuerzo 13
Tiempo estimado 13
Tiempo dedicado 13
Comentarios
HU10 login protectora / T10_02 Conectar cliente con servidor para login protectora
Esfuerzo 3
Tiempo estimado 2
Tiempo dedicado 2
Comentarios
HU11 Subir imagen principal de protectora a AWS S3 / T11_01 Crear componente Drag &
Drop & Crop
Esfuerzo 21
Tiempo estimado 21
Tiempo dedicado 25
Comentarios
103
HU11 Subir imagen principal de protectora a AWS S3 / T11_02 Introducir el componente Drag
& Drop & Crop en formulario protectora
Esfuerzo 5
Tiempo estimado 4
Tiempo dedicado 3
Comentarios
HU11 Subir imagen principal de protectora a AWS S3 / T11_02 conectar el componente Drag
& Drop & Crop parte protectora al servidor
Esfuerzo 3
Tiempo estimado 2
Tiempo dedicado 2
Comentarios
HU23 Subir imagen principal de protectora a AWS S3 / T23_01 Introducir el componente Drag
& Drop & Crop en formulario animales
Esfuerzo 5
Tiempo estimado 4
Tiempo dedicado 4
Comentarios
HU23 Subir imagen principal de protectora a AWS S3 / T23_02 conectar el componente Drag
& Drop & Crop parte animales al servidor
Esfuerzo 3
Tiempo estimado 2
Tiempo dedicado 2
Comentarios
104
Figura 31. Módulo login y gestión de imágenes principales.
Login protectora
URL /login/protectora
Método GET
Parámetros URL -
Parámetros Query -
34
105
Respuesta satisfactoria Code: 200
Respuesta de error Code: 401 - UNAUTHORIZED
Componente Drag & Drop & Crop - Subir imagen principal de una protectora a AWS S3
URL /protectora/:id/imagen
Método PUT
Parámetros Query -
:imagen
Code: 200
Content: empty
Content1: Array de parámetros erróneos
Content2: IMAGEN_REQUERIDA

Respuesta de error
Code: 500: INTERNAL SERVER ERROR
Content1: ERROR_AL_ACTUALIZAR_PROTECTORA
Content2: ERROR_AL_BUSCAR_PROTECTORA
Code: 502: BAD GATEWAY

Content: ERROR_AL_ACTUALIZAR_PROTECTORA
106
Componente Drag & Drop & Crop - Subir imagen principal de un animal a AWS S3
URL /animal/:id/imagen
Método PUT
Parámetros Query -
:imagen
Code: 200
Content: empty
Code: 201
Content: {_id: animal._id}
Content2: IMAGEN_REQUERIDA

Content: ERROR_ANIMAL_NO_ENCONTRADO
Respuesta de error
Code: 500: INTERNAL SERVER ERROR
Content1: ERROR_AL_ACTUALIZAR_ANIMAL
Content2: ERROR_AL_BUSCAR_ANIMAL
Code: 502: BAD GATEWAY

Content: ERROR_AL_ACTUALIZAR_ANIMAL
107
 Componentes
son:
● Componentes de formulario para login de protectora en el sistema:
Figura 32. loginFormComponent.
108
● Componentes drag & drop & crop:
Figura 33. dragAndDropAndCropComponent.
 Sprint Review
● En este sprint se ha calculado mejor los tiempos estimados aunque el

componente drag&drop&crop haya sido algo más complicado de lo esperado.
● En este sprint se ha tenido que dedicar un tiempo de investigación extra para

configurar CORS en Amazon Web Services.
109
d.6.) Séptimo sprint - Obtener imágenes y contacto vía email.
Este sprint se centra en la obtención de imágenes y la creación de un componente para

facilitar el contacto de los usuarios con las protectoras. Las historias de usuario
asociadas a este sprint se dividen en las siguientes tareas:
HU12 Obtener imagen principal protectora / T12_01 Crear componente para cargar imágenes
Esfuerzo 13
Tiempo estimado 12
Tiempo dedicado 10
Comentarios
HU12 Obtener imagen principal protectora / T12_02 Incorporar componente para cargar
imágenes en el componente de información de una protectora
Esfuerzo 5
Tiempo estimado 5
Tiempo dedicado 4
Comentarios
HU12 Obtener imagen principal protectora / T12_03 Conectar cliente con servidor para cargar
imagen principal de la protectora
Esfuerzo 3
Tiempo estimado 2
Tiempo dedicado 2
Comentarios
110
HU24 Obtener imagen principal animal / T24_01 Incorporar componente para cargar
imágenes en el componente de información de animal
Esfuerzo 5
Tiempo estimado 5
Tiempo dedicado 4
Comentarios
HU24 Obtener imagen principal animal / T24_02 Conectar cliente con servidor para cargar
imagen principal de un animal
Esfuerzo 3
Tiempo estimado 2
Tiempo dedicado 2
Comentarios
HU28 Envío de email a protectora/ T28_01 Crear componente para contactar vía email
Esfuerzo 3
Tiempo estimado 2
Tiempo dedicado 2
Comentarios
HU28 Envío de email a protectora/ T28_02 Conectar cliente con servidor para envio de email
a protectora
Esfuerzo 3
Tiempo estimado 2
Tiempo dedicado 2
Comentarios
111
A continuación se muestra el diagrama de casos de uso de este módulo:
Figura 34. Módulo obtener imagen principal y envío email protectora.
Obtener imagen principal de protectora en AWS S3.
URL /protectora/:id/imagen
Método GET
Parámetros Query -
35
112
Code: 200
Content:
{
"logo": {
Respuesta satisfactoria data: <IMAGEN_CODIFICADA_EN_BASE64>,
contentType: <ContentType>
}
}


Respuesta de error
Code: 500 INTERNAL SERVER ERROR
Code: 502 BAD GATEWAY

Content: ERROR_AL_RECUPERAR_LOGO_PROTECTORA
Obtener imagen principal de animal en AWS S3.
URL /animal/:id/imagen
Método GET
Parámetros Query -
113
Code: 200
Content:
{
"logo": {
Respuesta satisfactoria data: <IMAGEN_CODIFICADA_EN_BASE64>,
contentType: <ContentType>
}
}


Content: ERROR_ANIMAL_NO_ENCONTRADA
Respuesta de error
Content: ERROR_BUSCAR_ANIMAL
Code: 502 BAD GATEWAY

Content: ERROR_AL_RECUPERAR_IMG_PRINCIPAL_ANIMAL
Enviar email a protectora
URL /utils/enviarEmail
Método POST
Parámetros URL -
Parámetros Query -
● Required:
○ fromEmail -> [Email] Email origen
Parámetros en el Body ○ tipoEmail -> [String] Tipo email que se va a enviar
○ protectora -> [MongoID] ID de la protectora a la que
se le manda email
114
○ texto -> [String] Texto que la protectora recibe

● Opcional
○ animal -> [MongoID] ID del naimal que se adjunta al
email
● Info params:
○ tipo email -> [registro_de_^rotectora,
paramAdmin_errores_en_registro_de_protectora,
paraAdmin_registro_de_Protectora,
peticion_información_de_protectora,
interes_por_animal]
Code: 200
Content:
{
“status”: “OK”
}

Respuesta de error
Content: ERROR_ENVIAR_EMAIL
 Componentes
son:
● Componente para cargar imagen principal:
Figura 35. imagenPrincipalComponent.
115
• Componente para enviar email a protectora:
Figura 36. enviarEmailProtectora.
 Sprint Review
● Para facilitar la creación de plantillas de emails y mejorar el diseño se decide

añadir un addon de Heroku que detecta el email que quieres mandar e inyecta
la información antes de enviar el email.
● En este sprint el control de las horas dedicadas se ha gestionado peor ya que no

se han registrado hasta el último momento, se tienen que registrar en cuanto se
termine la tarea.
116
d.7.) Octavo sprint - Contacto vía whatsapp y verificar cuenta protectora
En este sprint se incluye el contacto con una protectora por whatsapp y se crea la lógica
para verificar que la cuenta con la que se registra una protectora es válida y la pertenece.
HU17 Gestión de whastapp de una protectora/ T17_01 Crear componente para habilitar
whatsapp en un móvil de protectora
Esfuerzo 13
Tiempo estimado 10
Tiempo dedicado 10
Comentarios
HU17 Gestión de whastapp de una protectora / T17_02 Conectar cliente con servido para
comunicar que móvil tiene habilitado whatsapp
Esfuerzo 5
Tiempo estimado 3
Tiempo dedicado 3
Comentarios
HU17 Gestión de whatsapp de una protectora / T17_03 Crear componente para que un
usuario pueda contactar con la protectora vía whatsapp
Esfuerzo 21
Tiempo estimado 13
Tiempo dedicado 13
Comentarios
117
HU17 Gestión de whatsapp de una protectora / T17_03 Crear conexión con la api de whatsapp
Esfuerzo 13
Tiempo estimado 12
Tiempo dedicado 12
Comentarios
HU08 Verificar cuenta protectora / T08_01 Crear un email para verificar una cuenta de una
protectora
Esfuerzo 13
Tiempo estimado 8
Tiempo dedicado 8
Comentarios
A continuación se muestra el diagrama de casos de uso de este módulo:
Figura 37. Módulo gestión whatsapp y verificación email protectora.
118
Whatsapp activos de una protectora
URL /protectora/:id/whatsapp
Método GET
Parámetros Query -
-
Code: 200
Content:
{
"totalRecord": <NUMERO DE WHATSAPP ACTIVOS>,
"result": {
"_id": <ID PROTECTORA>,
"telefonos": [
{
"telefono": "676736397",
"WhatsApp": true,
"_id": "5b22f2f93284b110015a29b5"
}
]
}
}
36
119


Respuesta de error

Verificar cuenta protectora
URL /protectora/verificar/:id/:token
Método PUT
id=[MongoID]
Parámetros URL
token=[string 16byte base64]
Parámetros Query -
-
Code: 200
Content: OK
Respuesta de error
120
 Componentes
son:
● Contacto vía whatsapp:
Figura 38. contactWhatsappComponent.
 Sprint Review
● En este último Sprint Review se revisa que todas las historias de usuario estén
implementadas.
121
4. CONCLUSIONES Y POSIBLES AMPLIACIONES
Conclusiones y posibles ampliaciones
En este apartado se analizan las conclusiones a las que se ha llegado desarrollando este
proyecto y los posibles trabajos futuros a realizar.
4.1. Conclusiones
Con el desarrollo de este proyecto se ha conseguido aprender a generar una

arquitectura capaz de crear una plataforma basada en componentes y fácilmente
mantenible.
Se ha conseguido trabajar en equipo usando gestión de versionado de código con

despliegue continuo y a utilizar herramientas de gestión de proyectos.
Además, desde el comienzo del proyecto se ha utilizado un marco de trabajo ágil

facilitando el desarrollo del proyecto y su seguimiento.
4.2. Trabajo futuro
Aunque se ha desarrollado muchos de los objetivos propuesto al comienzo del proyecto

se pueden incluir al sistema las siguientes funcionalidades:
● Incluir un mapa que permita localizar protectoras próximas a la posición de un
usuario.
● Permitir a las protectoras eliminar animales registrados o eliminar su cuenta.
● Incluir integración continua con un sistema de testing unitario mejorado (Jest).
● Implementar un sistema para compartir información de animales mediante las

redes sociales.
● Incluir un sistema de animales favoritos para los usuarios.
● Desarrollar un sistema de verificación de protectoras mediante SMS 37.
● Mejorando el sistema de búsquedas para permitir habilitar y deshabilitar campos

de forma unitaria.
37
https://es.wikipedia.org/wiki/Servicio_de_mensajes_cortos
123
Conclusiones y posibles ampliaciones
● Implementar un sistema de logs que facilite la detención errores en la aplicación.
● Incluir un sistema de búsqueda de protectoras por geolocalización.
● Mejorar el listado de animales para que sea una lista virtualizada y mejorar la
experiencia de usuario.
● Actualizar React a la versión 16 y cambiar las clases por hooks 38.
38
https://es.reactjs.org/docs/hooks-intro.html
124
5. BIBLIOGRAFÍA
Bibliografía
[1] Fundación Affinity, «Whitepaper Estudio sobre Abandono y Adopción de Animales

de Compañía 2018», 19-jun-2018.
[2] J. Fatjó et al., «Epidemiology of Dog and Cat Abandonment in Spain (2008–2013)»,
Animals, vol. 5, n.o 2, pp. 426-441, jun. 2015.
[3] G. de E. Ministerior de agricultura y pesca, alimentación y medio ambiente, «Guía
para tenencia responsable de animales de compañía». [En línea]. Disponible en:
http://eresresponsable.es/wp-content/uploads/2018/04/Gu%C3%ADa-Tenencia-
Responsable.pdf. [Accedido: 15-may-2019].
[4] «What is Heroku | Heroku». [En línea]. Disponible en:
https://www.heroku.com/what. [Accedido: 19-may-2019].
[5] «Git - Branching Workflows». [En línea]. Disponible en: https://git-
scm.com/book/en/v2/Git-Branching-Branching-Workflows. [Accedido: 19-may-
2019].
[6] «AWS | Almacenamiento de datos seguro en la nube (S3)», Amazon Web Services,
Inc. [En línea]. Disponible en: https://aws.amazon.com/es/s3/. [Accedido: 19-may-
2019].
[7] «Angular vs React: [2019] Everything You Need to Know», Hackr.io Blog, 26-sep-
2018. .
[8] «The State of JavaScript 2018: Connections». [En línea]. Disponible en:
https://2018.stateofjs.com/connections/. [Accedido: 25-may-2019].
[9] «Stack Overflow Developer Survey 2018», Stack Overflow. [En línea]. Disponible
en: https://insights.stackoverflow.com/survey/2018/?utm_source=so-
owned&utm_medium=social&utm_campaign=dev-survey-
2018&utm_content=social-share. [Accedido: 25-may-2019].
[10] «Redux no muerde... ¿Qué es Redux y por qué debes conocerlo?», Enrique Oriol,
16-ago-2018. .
[11] S. Xalambrí, «Introducción a Redux.js», React & Redux, 23-mar-2016. .
[12] «Cómo empezar con Webpack», Carlos Azaustre, 22-sep-2016. [En línea].
Disponible en: https://carlosazaustre.es/primeros-pasos-con-webpack/.
[Accedido: 25-may-2019].
126
Bibliografía
[13] R. Borillo, «Da potencia y flexibilidad a tus tests con Jest», Genbeta, 27-jun-2018.
[En línea]. Disponible en: https://www.genbeta.com/desarrollo/da-potencia-
flexibilidad-tus-tests-jest. [Accedido: 25-jun-2019].
[14] «Jest · 🃏 Delightful JavaScript Testing». [En línea]. Disponible en: https://jestjs.io/.
[Accedido: 25-jun-2019].
[15] «REST», Documentación web de MDN. [En línea]. Disponible en:
https://developer.mozilla.org/es/docs/Glossary/REST. [Accedido: 26-may-2019].
[16] «Express Web Framework (Node.js/JavaScript)», Documentación web de MDN. [En
línea]. Disponible en: https://developer.mozilla.org/es/docs/Learn/Server-
side/Express_Nodejs. [Accedido: 26-may-2019].
[17] «Express - Infraestructura de aplicaciones web Node.js». [En línea]. Disponible en:
https://expressjs.com/es/. [Accedido: 26-may-2019].
[18] yANyZx Rock, «MongoDB: ¿qué es, cómo funciona?», yANyZx Rock, 06-jul-2017. .
[19] «Cross-domain Ajax with Cross-Origin Resource Sharing - Human Who Codes». [En
línea]. Disponible en: https://humanwhocodes.com/blog/2010/05/25/cross-
domain-ajax-with-cross-origin-resource-sharing/. [Accedido: 03-jun-2019].
[20] «cross-site xmlhttprequest with CORS – Mozilla Hacks - the Web developer blog»,
Mozilla Hacks – the Web developer blog. [En línea]. Disponible en:
https://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors.
[21] «Qué es SCRUM», Proyectos Ágiles, 04-ago-2008. .
[22] A. Mammut, «Empezar proyectos agiles “Agile Inception”», Agile Mammut, 08-
ago-2017. .
[23] «El manifiesto ágil - Scrum Manager BoK». [En línea]. Disponible en:
https://www.scrummanager.net/bok/index.php?title=El_manifiesto_%C3%A1gil.
[24] s|ngular, «¿Trabajas con Scrum? ¿Te suena “Inception Deck”?» [En línea].
Disponible en: http://blog.sngular.team/trabajas-con-scrum-te-suena-inception-
deck. [Accedido: 09-jun-2019].
[25] «The Agile Inception Deck», The Agile Warrior, 06-nov-2010. .
127
ANEXO A. GUÍA DE ESTILO
Anexo A: guía de estilo
Figura 39. Colores guía de estilos.
Figura 40. Tablas guía de estilos.
129
Figura 17. Botones guía de estilos.
Figura 41 - Botones solo contorno - guía de estilos.
Figura 42. Grupo de botones - guía de estilos.
130
Figura 43. Botones con funcionalidad - guía de estilos.
Figura 44. Elementos de formulario - guía de estilos.
Figura 45. Elementos de formulario extra - guía de estilos.
131
Figura 46. Alertas - guía de estilos.
Figura 47. Barras de progreso - guía de estilos.
Figura 48. Información sobre botones - guía de estilos.
132
Figura 49. Badges - guía de estilos.
Figura 50. Navegación - guía de estilos.
Figura 51. Barras de progreso - guía de estilos.
Figura 52. Paginación y migas de pan - guía de estilos.
133
Figura 53. Colapsables y carousel - guía de estilos.
Figura 54. Tipografías - guía de estilo.
Figura 55. Texto en bloque - guía de estilo.
Figura 56. Listados - guía de estilo.
134
Figura 57. panel tipo cartas - guía de estilo.
Figura 58. Navegación de cartas - guía de estilo.
Figura 59. Variación de cartas - guía de estilo.
135
Figura 60. Seleccionables - guía de estilo.
Figura 61. Etiquetas - guía de estilo.
Figura 62. Jumbotron - guía de estilo.
136

Adopcion Mascotas

Cargado por

Copyright:

Formatos disponibles

Adopcion Mascotas

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Adopcion Mascotas

Cargado por

Copyright:

Formatos disponibles

MÁSTER UNIVERSITARIO EN INGENIERÍA WEB

Plataforma web para la adopción y gestión

TRABAJO FIN DE MÁSTER

Curso 2018 – 2019 Madrid, JULIO 2019

A mis padres, por apoyarme día a día.

1.1. Contexto ............................................................................................................. 3

1.2. Motivación ......................................................................................................... 7

1.3. Objetivos ............................................................................................................ 7

2. GESTIÓN DEL PROYECTO Y TECNOLOGÍAS ................................................................. 8

2.1. Plan de empresa ................................................................................................. 9

2.1.1. Público objetivo ....................................................................................................... 9

2.1.2. Competencia ........................................................................................................... 9

2.1.3 Marketing ............................................................................................................... 12

2.1.4. Fuente de ingresos y viabilidad económica ............................................................ 13

2.1.5. Viabilidad técnica .................................................................................................. 13

2.1.6. Estrategia de evolución .......................................................................................... 14

2.1.7. Estrategia de expansión ......................................................................................... 15

2.1.8. Plan de contingencia .............................................................................................. 15

2.2. Tecnologías para la gestión ............................................................................... 16

2.2.1. Trello ..................................................................................................................... 16

2.2.2. Google Drive .......................................................................................................... 17

2.2.3. Heroku .................................................................................................................. 17

2.2.4. Git - Github ............................................................................................................ 18

2.2.5. Amazon web services - Storage Service (Amazon - S3) ........................................... 19

2.3. Arquitectura y tecnologías utilizadas ................................................................ 20

2.3.1. Tecnologías - cliente (Frontend) ............................................................................. 20

2.4.1. API REST ................................................................................................................ 34

2.4.2. Node package manager (NPM) .............................................................................. 34

2.4.3. Node.js y Express ................................................................................................... 34

2.4.4. MongoDB - Mongoose - Mongolab ........................................................................ 36

2.4.5. Heroku .................................................................................................................. 36

2.4.6. CORS ..................................................................................................................... 37

3. PLANIFICACIÓN DEL PROYECTO ............................................................................... 39

3.1. Requisitos no funcionales ................................................................................. 40

3.2. Requisitos funcionales ...................................................................................... 41

3.3. Metodología ágil - Scrum .................................................................................. 42

3.3.1. Manifiesto ágil ....................................................................................................... 42

3.3.2. SCRUM .................................................................................................................. 43

3.3.3. Planificación del proyecto. ..................................................................................... 45

a) Inception Deck ..................................................................................................... 45

4.1. Conclusiones ................................................................................................... 123

4.2. Trabajo futuro ................................................................................................ 123

ANEXO A. GUÍA DE ESTILO......................................................................................... 128

Figura 2. Motivos para el abandono de animales de compañía. Fuente Fundación

Figura 3. Motivos para no adoptar un animal de compañía en personas inicialmente

Figura 4 - Motivos de fracaso de la adopción. Fuente Fundación Affinity. ..................... 6

Figura 5 - Actores de la plataforma ............................................................................... 9

Figura 6 - Esquema viabilidad tecnológica. .................................................................. 13

Figura 7. Mapa organización de la Comunidad de Madrid. .......................................... 15

Figura 8. Tecnologías más populares en 2018. Fuente: Stackoverflow. ........................ 20

Figura 9. Tabla comparativa entre React y Angular...................................................... 22

Figura 10. Frameworks, bibliotecas y herramientas más utilizadas en 2018. Fuente:

Figura 12. Ejemplo de transpilado de ficheros. Fuente: webpack.js.org. ...................... 26

Figura 13. Estructura componente React - Redux. ....................................................... 31

Figura 14. Ejemplo jerarquía de componentes. ........................................................... 33

Figura 15. Procesos de una metodología Scrum. Fuente: Scrum.org. ........................... 45

Figura 21. AlerConfirmComponent. ............................................................................. 85

Figura 22. CardProtectoraComponent. ........................................................................ 85

Figura 23. AdminComponent. ..................................................................................... 86