Xamarin: estudio del framework y desarrollo de una app

Xamarin: estudio del framework y desarrollo de una app Memoria final Autor Cristian Roa Fortes Director Xavier Franch Gutiérrez Dept. d’Enginyeria de Serveis i Sistemes d’Informació (ESSI) Especialidad Ingeniería del Software Grado en Ingeniería Informática Fecha de entrega: 22/01/2021 2020Q1 Resumen Este proyecto consiste en el desarrollo de una aplicación móvil para Android utilizando Xamarin. La idea de la aplicación es crear una plataforma en la que los usuarios puedan crear guías turísticas en los lugares que deseen y hacerlas públicas. En primer lugar, se realiza la gestión del proyecto, definiendo el problema a la vez que se determinan los objetivos y requisitos. Además, se detalla el alcance, se planifica temporalmente y se elabora un presupuesto económico para el proyecto. Para finalizar la gestión, se realiza un análisis de sostenibilidad en sus diferentes ámbitos. Por último, se detallan los aspectos de la metodología, se explica la arquitectura del sistema y se explica el desarrollo del proyecto por fases. Resum Aquest projecte consisteix en el desenvolupament d'una aplicació mòbil per Android utilitzant Xamarin. La idea de l'aplicació és crear una plataforma en què els usuaris puguin crear guies turístiques en els llocs que desitgin i fer-les públiques. En primer lloc, es realitza la gestió de el projecte, definint el problema i alhora es determinen els objectius i requisits. A més, es detalla l’abast, es planifica temporalment i s’elabora un pressupost econòmic per al projecte. Per finalitzar la gestió, es realitza una anàlisi de sostenibilitat en els seus diferents àmbits. Finalment, es detallen els aspectes de la metodologia, s’explica l’arquitectura de sistema i s’explica el desenvolupament de el projecte per fases. Abstract This project consists of the development of a mobile application for Android using Xamarin. The idea of the application is to create a platform in which users can create tourist guides in the places they want and make them public. First, the project management is carried out, defining the problem while determining the objectives and requirements. In addition, the scope is detailed, temporally planned and an economic budget is prepared for the project. To finalize the management, a sustainability analysis is carried out in its different areas. Finally, the aspects of the methodology are detailed, the system architecture and the development of the project is explained in phases. Índice de contenido 1. CONTEXTO ......................................................................................................................................... 5 1.1 INTRODUCCIÓN ....................................................................................................................................... 5 1.2 PROBLEMAS A RESOLVER ........................................................................................................................... 5 1.2.1 Formación en aplicaciones móviles ............................................................................................. 5 1.2.2 Elección del tema ........................................................................................................................ 6 1.3 SECTOR TURÍSTICO ................................................................................................................................... 6 1.4 ACTORES IMPLICADOS .............................................................................................................................. 7 2. JUSTIFICACIÓN ................................................................................................................................... 8 2.1 SOLUCIONES EXISTENTES ........................................................................................................................... 8 2.2 JUSTIFICACIÓN DE LA ELECCIÓN .................................................................................................................. 9 3. ALCANCE .......................................................................................................................................... 10 3.1 OBJETIVOS ........................................................................................................................................... 10 3.2 REQUISITOS FUNCIONALES....................................................................................................................... 10 3.3 REQUISITOS NO FUNCIONALES .................................................................................................................. 11 3.4 OBSTÁCULOS Y RIESGOS .......................................................................................................................... 12 4. METODOLOGÍA Y RIGOR .................................................................................................................. 13 4.1 HERRAMIENTAS UTILIZADAS ..................................................................................................................... 13 5. PLANIFICACIÓN TEMPORAL ............................................................................................................. 14 6. ESTIMACIÓN DEL PROYECTO ............................................................................................................ 15 6.1 TAREAS ............................................................................................................................................... 15 6.1.1 Gestión de proyecto .................................................................................................................. 15 6.1.2 Sprint1 ....................................................................................................................................... 15 6.1.3 Sprint2 ....................................................................................................................................... 15 6.1.4 Sprint3 ....................................................................................................................................... 16 6.1.5 Periodo de documentación ....................................................................................................... 16 6.2 RECURSOS ........................................................................................................................................... 16 6.3 TABLA RESUMEN ................................................................................................................................... 17 7. ESTIMACIONES Y GANTT .................................................................................................................. 18 8. GESTIÓN DEL RIESGO: PLANES ALTERNATIVOS Y OBSTÁCULOS ........................................................ 20 9. PRESUPUESTO .................................................................................................................................. 21 9.1 IDENTIFICACIÓN Y ESTIMACIÓN DE LOS COSTES ............................................................................................ 21 9.1.1 Recursos humanos .................................................................................................................... 21 9.1.2 Recursos materiales .................................................................................................................. 22 9.1.3 Contingencias ............................................................................................................................ 23 9.1.4 Imprevistos................................................................................................................................ 24 9.1.5 Costes generales o indirectos .................................................................................................... 24 9.1.6 Presupuesto final ...................................................................................................................... 24 9.2 CONTROL DE GESTIÓN ............................................................................................................................ 25 10. INFORME DE SOSTENIBILIDAD ....................................................................................................... 26 10.1 DIMENSIÓN ECONÓMICA ...................................................................................................................... 26 10.2 DIMENSIÓN AMBIENTAL........................................................................................................................ 27 10.3 DIMENSIÓN SOCIAL .............................................................................................................................. 27 11. GESTIÓN DE LA METODOLOGÍA ..................................................................................................... 28 11.1 REPOSITORIOS .................................................................................................................................... 28 11.2 METODOLOGÍA SCRUM ........................................................................................................................ 28 11.3 HISTORIAS DE USUARIO Y DEFINITIONS OF DONE ........................................................................................ 29 11.3 TESTING ............................................................................................................................................ 30 11.3.1 Testing en backend ................................................................................................................. 30 11.3.2 Testing en frontend ................................................................................................................. 31 12. ARQUITECTURA DEL SISTEMA ........................................................................................................ 32 12.1 COMPONENTES DEL SISTEMA ................................................................................................................. 32 12.2 ESQUEMA DE LA BASE DE DATOS ............................................................................................................. 33 12.3 NAVEGACIÓN DE LA APLICACIÓN ............................................................................................................. 34 12.4 PATRONES DE DISEÑO EMPLEADOS .......................................................................................................... 36 12.4.1 MVVM ..................................................................................................................................... 36 12.4.2 DTO ......................................................................................................................................... 36 12.4.4 Singleton ................................................................................................................................. 37 12.4.5 Publish-subscribe .................................................................................................................... 37 13. DESARROLLO .................................................................................................................................. 39 13.1 SPRINT 1 ........................................................................................................................................... 39 13.1.1 Resumen de tareas ................................................................................................................. 39 13.1.2 Burndown chart ...................................................................................................................... 40 13.2 SPRINT 2 ........................................................................................................................................... 41 13.2.1 Resumen de tareas ................................................................................................................. 41 13.2.2 Burndown chart ...................................................................................................................... 42 13.3 SPRINT 3 ........................................................................................................................................... 43 13.3.1 Resumen de tareas ................................................................................................................. 43 13.3.2 Burndown chart ...................................................................................................................... 44 14. VALIDACIÓN DEL PROYECTO .......................................................................................................... 45 14.1 OBJETIVOS ......................................................................................................................................... 45 14.2 REQUISITOS FUNCIONALES .................................................................................................................... 45 14.3 REQUISITOS NO FUNCIONALES ................................................................................................................ 46 15. CONCLUSIONES .............................................................................................................................. 50 15.1 CONSOLIDACIÓN DE COMPETENCIAS TÉCNICAS .......................................................................................... 50 15.2 TRABAJO FUTURO ................................................................................................................................ 52 16. REFERENCIAS ................................................................................................................................. 53 Índice de figuras FIGURA 1: PREVISIÓN DE LA EVOLUCIÓN DEL TURISMO ............................................................................. 6 FIGURA 2: CAPTURA DE PANTALLA DE YOUR GUIDES .................................................................................. 8 FIGURA 3: CAPTURA DE PANTALLA DE POCKETSIGHT .................................................................................. 8 FIGURA 4: DIAGRAMA DE GANTT ............................................................................................................... 19 FIGURA 5: COMPONENTES DEL SISTEMA ................................................................................................... 32 FIGURA 6: ESQUEMA DE LA BASE DE DATOS ............................................................................................. 33 FIGURA 7: NAVEGACIÓN DE LA APLICACIÓN .............................................................................................. 34 FIGURA 8: MVVM PATTERN........................................................................................................................ 36 FIGURA 9: PUBLISH-SUBSCRIBE PATTERN .................................................................................................. 37 FIGURA 10: SPRINT1 BURNDOWN CHART .................................................................................................. 40 FIGURA 11: SPRINT2 BURNDOWN CHART .................................................................................................. 42 FIGURA 12: SPRINT3 BURNDOWN CHART .................................................................................................. 44 FIGURA 13: UPTIME HEROKU ..................................................................................................................... 47 Índice de tablas TABLA 1: FECHAS PARA CADA ETAPA DEL PROYECTO ................................................................................ 14 TABLA 2: RESUMEN DE LAS TAREAS ........................................................................................................... 17 TABLA 3: GESTIÓN DEL RIESGO .................................................................................................................. 20 TABLA 4: SALARIOS PARA CADA ROL DEL PROYECTO................................................................................. 21 TABLA 5: COSTES DE RECURSOS HUMANOS POR TAREAS ......................................................................... 22 TABLA 6: COSTES DE RECURSOS HARDWARE ............................................................................................. 23 TABLA 7: COSTES DE RECURSOS SOFTWARE .............................................................................................. 23 TABLA 8: COSTES CON CONTINGENCIAS .................................................................................................... 23 TABLA 9: COSTES DE IMPREVISTOS ............................................................................................................ 24 TABLA 10: PRESUPUESTO FINAL ................................................................................................................. 24 5 1. Contexto 1.1 Introducción El trabajo de Fin de Grado “Xamarin: estudio del framework y desarrollo de una app” pertenece a los estudios de Grado en Ingeniería Informática de la Facultat d’Informàtica de Barcelona [1], perteneciente a la Universitat Politècnica de Catalunya, en la especialización de Ingeniería de Software. El proyecto pretende desarrollar una aplicación para dispositivos Android 5.0 o superior en el ámbito del turismo, utilizando las tecnologías que Microsoft [2] brinda a los usuarios de su framework Xamarin [3]. 1.2 Problemas a resolver 1.2.1 Formación en aplicaciones móviles El campo de la Ingeniería es muy extenso y, debido a ello, cada día aparecen nuevas tecnologías que facilitan el trabajo de muchas personas. Algo que a priori puede parecer positivo, realmente tiene su parte negativa y puede verse agravado en futuras generaciones. Sin concretar en los informáticos ya que es algo que aplica a todos por igual, las tecnologías mejoran en todos los ámbitos y, el problema surge cuando los estudios relacionados no abarcan más allá de las capacidades analíticas, metodologías y procedimientos a seguir para ser un buen ingeniero. También es el caso de la informática, en el que no se llega a entrar en detalle en ningún framework de desarrollo ni la gran mayoría de tecnologías que las empresas buscan en sus nuevas incorporaciones. Es por esto que, como alumno con ganas de formarse en el desarrollo de aplicaciones móviles, decido realizar un proyecto en este ámbito. La elección de Xamarin es debida a que actualmente hay una gran cantidad de empresas que desarrollan aplicaciones móviles con esta tecnología y que además tiene una gran multinacional al mando como es Microsoft. 6 1.2.2 Elección del tema Teniendo clara la elección del proyecto surge el problema de la temática de la aplicación. Y es que realmente existen aplicaciones para prácticamente todo, pero no de la forma que a todo el mundo le gusta, ya sea por estética, funcionalidades o experiencia de usuario. Tras investigar en el ámbito del turismo a través de la Play Store [4] de Google, es fácilmente observable que existen miles de aplicaciones con esta temática, pero siempre se centran en aquellos lugares que son más turísticos y muestran guías alrededor de ellos. Partiendo de esta base, no tendría mucho sentido crear una aplicación centrada en guías turísticas, pero hay un detalle que se les escapa a estas aplicaciones. Se trata de que las personas residentes conocen muy bien los lugares donde viven y aquellos rincones que no suelen ser tan transitados por turistas. Por ello, la idea de la aplicación se fundamenta en crear una plataforma donde los usuarios tendrán la capacidad de crear guías en los lugares que ellos deseen y otros usuarios de la aplicación podrán visualizarlas y darles una valoración. 1.3 Sector turístico El sector turístico es probablemente uno de los grandes motores de la economía mundial, y se prevé que aumente aún más durante los próximos años, según la World Tourism Oranization [5]. Es por esto que existe un gran tráfico a través de internet con búsquedas de información para viajar, a cualquier lugar del mundo. Figura 1: Previsión de la evolución del turismo 13 4. Metodología y rigor Para garantizar un desarrollo continuo y escalado se hará uso de la metodología ágil Scrum [11]. Esta se basa en la definición de iteraciones, también conocidas como sprints, en las que se implementan las funciones establecidas para ese periodo. Normalmente en un proyecto Scrum se dividen las tareas entre los diferentes roles del equipo, pero en este caso solo habrá uno, el de full-stack developer. 4.1 Herramientas utilizadas Para llevar a cabo un desarrollo con Scrum exitoso se requieren herramientas para facilitar la gestión. Este es el listado de ellas: • Git [12]: Es el sistema de control de versiones más utilizado por los desarrolladores de software, que permite compartir el código y gestionar las versiones a partir de repositorios. • Github [13]: Es una plataforma que permite almacenar y gestionar repositorios de Git. • Taiga [14]: Es una plataforma gratuita que permite gestionar proyectos a partir de historias de usuarios, backlog e issues. • Visual Studio [15]: Es la IDE que se utilizará durante el desarrollo tanto de frontend como de backend, que ya cuenta con sistemas integrados como serían el emulador o una interfaz para subir cambios a Github. • Testing: Se diseñarán pruebas que el código deberá pasar para poder continuar con el desarrollo. En cuanto al front se utilizará un emulador de Android para probar las funcionalidades y en el back se usará Postman. 14 5. Planificación temporal La duración aproximada del proyecto será de 4 meses, que comienzan el día 21 de septiembre de 2020 con la gestión del proyecto (GEP) y finalizan en el turno de lectura de la semana del 25 al 29 de enero de 2021. La primera fase es la gestión del proyecto, que inicia el 21 de septiembre y acaba el 19 de octubre. Durante este periodo se analiza el contexto del proyecto, se evalúa su alcance y se planifica temporalmente, además de analizar sus aspectos de sostenibilidad y evaluar posibles riesgos. Esta fase consta de 75 horas de trabajo, aproximadamente 18 horas semanales. A partir del 20 de octubre y hasta el 21 de diciembre el proyecto se dividirá en Sprints para llevar a cabo su desarrollo siguiendo la metodología Scrum, constando de un total de 395 horas de trabajo, aproximadamente 44 horas semanales. Por último, resta el periodo de documentación y preparación de cara a la lectura del proyecto, esta empieza el 22 de diciembre y finaliza el 25 de enero. Fase Fecha de inicio Fecha de finalización Gestión de proyecto 21/09/2020 19/10/2020 Sprint 1 20/10/2020 09/11/2020 Sprint 2 10/11/2020 30/11/2020 Sprint 3 01/12/2020 21/12/2020 Periodo de documentación 22/12/2020 25/01/2021 Tabla 1: Fechas para cada etapa del proyecto 15 6. Estimación del proyecto 6.1 Tareas Las tareas para el proyecto se han clasificado en 4 tipos distintos, en primer lugar, GEP, que son todas aquellas tareas relacionadas con la gestión del proyecto. Por otro lado, las tareas DES son las relacionadas con el desarrollo, DOC son aquellas relacionadas con documentación y por último V, validación de proyecto y lanzamiento. 6.1.1 Gestión de proyecto • GEP1: Contextualización y alcance del proyecto. • GEP2: Planificación temporal del proyecto y definición de tareas. • GEP3: Planificación económica e informe de sostenibilidad. • GEP4: Definición del proyecto, juntando y corrigiendo los archivos anteriores. • GEP5: Definición de historias de usuario con el software de gestión Agile (Taiga). 6.1.2 Sprint1 • DES1: Aprendizaje inicial del framework Xamarin: Aprender su funcionamiento a partir de tutoriales y documentación en internet. • DES2: Creación y preparación del entorno de trabajo (frontend y backend). • DES3: Diseño del logo, mock-ups y navegación de la aplicación: Se diseñará el apartado gráfico y navegación entre las pantallas de la aplicación. • DES4: Backend - Register, Login y verificación por email: Se implementarán las funciones en la API REST basada en node.js y MongoDB. • DES5: Backend - Perfil de usuario: Al igual que DES4, es una extensión de funcionalidades en el backend, relacionadas con el perfil de usuario. • GEP6: Retrospective del Sprint1: Evaluar si se han cumplido los objetivos del Sprint, analizar y solucionar problemas durante el desarrollo. • DOC1: Documentación del Sprint1: Redactar lo referente a las funcionalidades implementadas en el Sprint. 6.1.3 Sprint2 • DES6: Frontend - Pantallas de Register y Login: Implementar las primeras pantallas del frontend relacionadas con register y login. • DES7: Frontend - Pantalla de Perfil: Implementar la pantalla de perfil de usuario. • DES8: Aprendizaje sobre el uso de mapas de Google en Xamarin. • DES9: Frontend - Pantalla de Mapa: Implementar la pantalla principal del mapa donde aparecerán las guías. • DES10: Backend – Guías: Funcionalidad para crear guías en backend. 16 • GEP7: Retrospective del Sprint2: Evaluar si se han cumplido los objetivos del Sprint, analizar y solucionar problemas durante el desarrollo. • DOC2: Documentación del Sprint2: Redactar lo referente a las funcionalidades implementadas en el Sprint. 6.1.4 Sprint3 • DES11: Frontend - Pantalla de creación de guías: Implementar la pantalla que permitirá a los usuarios crear las guías. • DES12: Backend - Sistema de valoraciones: Implementar el sistema que permitirá a los usuarios valorar las guías. • DES13: Frontend - Pantalla de valoraciones: Implementar la pantalla de valoraciones de guías. • DES14: Frontend - Funcionalidad para ver otros perfiles de usuario: Implementar la funcionalidad para acceder a los perfiles de otros usuarios. • V1: Validación del proyecto - Comprobar que se han cumplido los requisitos: Comprobar que todos los objetivos del proyecto han sido cumplidos. • V2: Desplegar el proyecto en Heroku: Después de validar el proyecto se despliega en un servidor Heroku para que funcione las 24h del día. • GEP8: Retrospective del Sprint3: Evaluar si se han cumplido los objetivos del Sprint, analizar y solucionar problemas durante el desarrollo. • DOC3: Documentación del Sprint3: Redactar lo referente a las funcionalidades implementadas en el Sprint. 6.1.5 Periodo de documentación • DOC4: Finalización de la memoria y preparación de la lectura. 6.2 Recursos En cuanto a los recursos requeridos por el proyecto, este es el listado: • Recursos humanos: jefe de proyecto (1), equipo de desarrollo (2) • Recursos materiales: Ordenador con internet (1), Microsoft Office Word (2), Microsoft Office Excel (3), Lucidchart (4), Taiga (5), Visual Studio (6), Github (7), iPad (8), Procreate (9), Emulador Android (10), Postman (11), Heroku (12). 17 6.3 Tabla resumen Tarea Duración (h) Dependencias R. Humanos R. Materiales GEP1 25 - 1 1,2 GEP2 12.5 GEP1 1 1,2,4 GEP3 12.5 GEP2 1 1,2,3 GEP4 20 GEP3 1 1,2 GEP5 5 GEP4 1 1,5 DES1 20 GdP 2 1 DES2 10 - 2 1,6,7,10 DES3 30 - 2 1,8,9 DES4 40 DES2 2 1,6,7,11 DES5 20 DES4 2 1,6,7,11 GEP6 5 DES1-DES5 1 1,2,5 DOC1 10 - 1 1,2 DES6 25 Sprint1 2 1,6,7,10 DES7 25 DES6 2 1,6,7,10 DES8 15 - 2 1 DES9 20 DES8 2 1,6,7,10 DES10 25 DES9 2 1,6,7,11 GEP7 5 DES6-DES10 1 1,2,5 DOC2 10 - 1 1,2 DES11 30 Sprint2 2 1,6,7,10 DES12 15 DES11 2 1,6,7,11 DES13 25 DES12 2 1,6,7,10 DES14 20 DES7 2 1,6,7,10 V1 20 - 2 1,6,7,10 V2 10 V1 2 1,12 GEP8 5 DES11-DES14, V1, V2 1 1,2,5 DOC3 10 - 1 1,2 DOC4 30 Sprint3 1 1,2 TOTAL 500 - - - Tabla 2: Resumen de las tareas 18 7. Estimaciones y Gantt En la siguiente figura, podemos observar el diagrama de Gantt planteado para el proyecto, donde cada etapa está diferenciada con su color particular. Respecto a tareas concurrentes, el aspecto de la documentación es el que se mantiene durante todo el proyecto, mientras el desarrollo va avanzando durante sus etapas. No hay tareas concurrentes de desarrollo ya que se ha optado por programar las funcionalidades de backend y asegurarse de que funcionan para luego pasar a implementarlas en el frontend. Si la granularidad de las tareas fuera menor podríamos llegar a ver un mayor número de tareas concurrentes, véase por ejemplo DES4, que implementa funcionalidades de Register, Login y verificación por email, agrupadas todas en la misma tarea. Si la visualización del diagrama en la siguiente página no es muy clara se puede acceder al diseño original para una mejor resolución a través de este enlace: <https://app.lucidchart.com/invitations/accept/5df0b0e1-a009-49b9-9de2cbc08185e7cf> 19 Figura 4: Diagrama de Gantt 20 8. Gestión del riesgo: Planes alternativos y obstáculos A continuación, en la siguiente tabla se especifican los posibles riesgos que podrían aparecer durante el desarrollo y cómo solventarlos a partir de planes alternativos. Riesgo Impacto Probabilidad Plan alternativo Inexperiencia con las tecnologías Alto Media Se han añadido horas destinadas al aprendizaje de las tecnologías para mitigar estos efectos. Mala planificación temporal Bajo Media Se ha destinado un mes a la documentación final y preparación de la lectura. Es un período algo excesivo con tal de poder ser empleado para posibles contingencias y tareas atrasadas de los Sprints. Alcance variable Bajo Baja Al haber distribuido el proyecto en distintos Sprints se pueden reubicar las nuevas tareas sin comprometer la integridad del desarrollo Tabla 3: Gestión del riesgo 21 9. Presupuesto 9.1 Identificación y estimación de los costes Para elaborar un correcto presupuesto para el proyecto, es necesario el proceso de identificación de recursos en todos sus ámbitos. Esto implica analizar varios aspectos como los recursos humanos, los recursos materiales, contingencias e incluso imprevistos. Una vez estos recursos han sido identificados se les asigna un coste y se calcula el total para el proyecto. 9.1.1 Recursos humanos En primer lugar, se encuentran los costes de personal. Para poder calcular el coste del personal es necesario asignar un sueldo por hora a cada rol que participe durante el transcurso. En la tabla se muestran los salarios, tanto en bruto como en neto, debido a los costes de seguridad social entre otros. En cuanto a cómo se han obtenido, estos han sido establecidos en base a información obtenida de la plataforma de glassdoor [16]. Rol Salario neto / hora Salario bruto / hora Jefe de proyecto 20€ 25€ Arquitecto de software 20€ 25€ Analista de software 18€ 22,5€ Desarrollador 13€ 16,25€ Tester 14€ 17,5€ Tabla 4: Salarios para cada rol del proyecto Una vez establecidos los sueldos de los empleados podemos calcular los costes de personal, teniendo en cuenta cuantas horas participará cada uno de ellos en cada tarea. 22 Tarea Jefe de proyecto (h) Arquitecto de software (h) Analista de software (h) Desarrollador (h) Tester (h) Coste total (€) GEP1 25 625 GEP2 12.5 313 GEP3 12.5 313 GEP4 20 500 GEP5 5 125 DES1 10 10 412 DES2 10 162 DES3 20 10 725 DES4 5 5 28 2 728 DES5 4 4 10 2 388 GEP6 5 125 DOC1 10 250 DES6 5 5 13 2 484 DES7 5 5 13 2 484 DES8 5 10 288 DES9 2.5 2.5 13 2 365 DES10 5 2.5 15 2.5 469 GEP7 5 125 DOC2 10 250 DES11 5 5 18 2 565 DES12 2.5 2.5 8 2 284 DES13 5 5 13 2 484 DES14 4 4 10 2 388 V1 12 4 4 490 V2 6 4 215 GEP8 5 125 DOC3 10 250 DOC4 30 750 TOTAL 162h 88h 54.5 172.5h 23h 10682€ 500h Tabla 5: Costes de recursos humanos por tareas A partir de la Tabla 5, obtenemos el coste total de recursos humanos: 10682€ 9.1.2 Recursos materiales Respecto a los recursos materiales, hay dos tipos a tener en cuenta: hardware y software. En cuanto al hardware, hay dos dispositivos a considerar. En primer lugar, un iPad Pro (2018), que será utilizado para los diseños de la aplicación. Por otro lado, un PC de sobremesa con una CPU Ryzen 5 3600 y placa base B450M DS3H, además de otros componentes de gama media-alta. 29 11.3 Historias de Usuario y definitions of done Las funcionalidades que debe cumplir el proyecto de cara a un usuario se han agrupado por historias de usuario de la siguiente forma. Además, para considerar una historia de usuario completada debemos haber completado todas aquellas tareas relacionadas con esta (definition of done). Todas estas historias de usuario se pueden visualizar en el proyecto de Taiga, pero aquí hay un breve resumen de ellas. Además, estas historias de usuario se consideran completas en el momento que ya no queda ninguna subtarea (en Taiga) más por implementar y han pasado con éxito las pruebas de test correspondientes. El listado es el siguiente, donde además se incluye entre paréntesis su nombre respectivo en el proyecto Taiga: • Un usuario podrá registrarse en la aplicación mediante su correo electrónico, usuario y contraseña (Register). • Un usuario podrá verificar su cuenta a través de un mensaje por correo electrónico (Email verification). • Un usuario podrá modificar / recuperar su contraseña en caso de haberla olvidado. (Password recovery) • Un usuario podrá acceder a la aplicación con sus credenciales tras verificar su cuenta por correo electrónico. (Login) • Un usuario podrá ver y modificar su información de perfil en cualquier momento que lo desee. (Profile) • Un usuario podrá visualizar el mapa con las guías creadas por otros usuarios de la aplicación. (Mapa) • Un usuario podrá crear una guía, añadiendo puntos de interés con título y descripción en el lugar que desee. (Crear guías) • Un usuario podrá acceder a la información de la guía que desee a través de la pantalla del mapa. (Ver información de guía) • Un usuario podrá ver la valoración general de una guía y añadir la suya propia. (Sistema de valoraciones) • Un usuario podrá acceder al perfil de otros usuarios a través de una guía creada. (Ver perfil de otros usuarios) 30 11.3 Testing En cuanto al testing durante el proyecto, se ha ido realizando de forma incremental a medida que se iban añadiendo las funcionalidades al software. Para llevarlo a cabo se ha dividido en las dos partes y se han seguido distintos procedimientos para cada una de ellos. 11.3.1 Testing en backend Primeramente, para la aplicación backend se han diseñado pruebas con el software Postman, que testean cada funcionalidad para su correcta validación a medida que se van implementando. Al tratarse de un documento algo extenso, he preferido adjuntar un documento aparte para ello. Se puede encontrar un resumen de los tests a través del siguiente enlace: https://drive.google.com/file/d/1SOBFKOsFnvsogLXuQwewQ_RpSnBSjzfw/view?usp= sharing Estas pruebas han sido realizadas durante las tareas de backend en el transcurso de los sprints. Debido a que la organización del proyecto se ha basado en finalizar las funcionalidades de backend, para luego incluirlas en frontend, ha sido necesario asegurarse de su correcto funcionamiento antes de este segundo paso. Durante el primer sprint se han hecho las pruebas relacionadas con registro, login y perfil. Luego, durante el segundo sprint se han hecho las de creación y eliminación de puntos de interés más la publicación de guías. Por último, en el tercer sprint se han hecho aquellas relacionadas con las valoraciones y se han validado las realizadas con anterioridad. 31 11.3.2 Testing en frontend En cuanto al testing de frontend, se ha basado en probar las funcionalidades con el emulador, paso a paso cada vez que se ha incorporado algún pequeño cambio en la funcionalidad. Además de esto, se ha instalado la aplicación en distintos dispositivos móviles de los Testers de UX con tal de recibir feedback respecto a la experiencia de usuario y detección de posibles bugs al probarlo en diferentes dispositivos. Los resultados obtenidos en estas sesiones de testing se han reflejado en los apartados correspondientes de cada Sprint. Resumidamente, las sesiones de testing en frontend han reflejado claramente muchos errores que no eran apreciables en el emulador tales como layouts incorrectos, rotación del dispositivo o incluso tamaños y estilos de fuente. Esto se ha debido mayoritariamente a que los valores se modifican en función del tamaño de fuente y tema de colores escogido en el dispositivo de cada usuario, cosa que obliga a establecer los valores en el código y no dejarlo en manos de cada dispositivo. Otro aspecto que se ha buscado en las sesiones de testing ha sido la detección de bugs, para solventarlos con la mayor brevedad posible. Uno de ellos ha sido muy claro, la conexión con el backend tenía un timeout establecido en 5 segundos, pero el hecho de desplegar el servidor en heroku ha generado un retraso en las peticiones llegando a causar timeouts aunque realmente estaba cerca de recibir una respuesta por parte del servidor. La solución a esto es clara, aumentar este tiempo de timeout a un valor de 10 segundos. Por otro lado, otro bug bastante grave es el de no bloquear los botones de cara al usuario cuando se está trabajando con la información de forma interna. Cuando un usuario envía datos al servidor y se está esperando una respuesta de este mismo, es una obligación del desarrollador bloquear todos los botones para evitar cierres inesperados de la app. Además de los bugs, se ha modificado levemente la navegación de la aplicación en las ventanas de creación de guías y puntos de interés. Anteriormente cuando se creaba un punto desde el mapa de la guía se volvía a la página principal de creación de guías, cosa que obligaba al usuario a volver a acceder al mapa para añadir otro punto. La nueva navegación consiste en permanecer en el mapa para poder añadir una cantidad indefinida de puntos hasta que el usuario decida volver atrás, esto sin duda es un aspecto que realmente mejora la experiencia de usuario tras un largo periodo de uso. 32 12. Arquitectura del sistema En este apartado se tratarán los distintos aspectos de la arquitectura del sistema, tal como el diagrama de los componentes que lo forman, la base de datos o la navegación de ventanas dentro de la aplicación. 12.1 Componentes del sistema Figura 5: Componentes del sistema En el diagrama de los componentes de sistema podemos observar cómo se interconectan las distintas partes del proyecto. En primer lugar, el usuario utiliza la aplicación para conectarse a los servicios, dónde puede utilizar la API de Google Maps para la visualización de los mapas y hacer peticiones a Heroku para el resto de información. Heroku es el servicio de host para la API del proyecto y a su vez se comunica con otros servicios como el de MongoDB Atlas para la base de datos y la API de Gmail para enviar correos a los usuarios. 33 12.2 Esquema de la base de datos Figura 6: Esquema de la base de datos La base de datos del sistema está alojada en MongoDB, que no es un sistema relacional. Pese a esto, la información que se modifica se actualiza en los distintos grupos de documentos: Usuarios, Puntos de interés (stops), Perfiles… de forma manual para mantener la integridad y consistencia en los datos almacenados. El modelo no es excesivamente grande en variedad de clases, pero permite una gran flexibilidad en cuanto a añadir futuras actualizaciones tales como comentarios o guías favoritas. 34 12.3 Navegación de la aplicación Figura 7: Navegación de la aplicación La navegación de la aplicación es un aspecto importante a tener en cuenta y ha sido elaborado pensando en la experiencia de usuario con la colaboración de los UX Testers. Durante el desarrollo de los sprints ha ido siendo modificada para obtener este resultado final. La navegación se divide en dos grandes bloques, en primer lugar está el bloque de la Splash screen (o pantalla de carga) más las pantallas de login, registro y recuperación de contraseña. Por otro lado, cuando el usuario hace login correcto se le dirige a la ventana principal del mapa con las guías. Desde esta ventana hay distintas opciones, usar la barra de navegación inferior para acceder a la creación de guías o perfil, o acceder a la información de alguna guía. 35 Desde la pantalla de información de una guía hay distintas funcionalidades que se han obviado en el diagrama de navegación, una de ellas es la función de valorar, que simplemente abre un popup en el que introducir un valor para la guía, y la funcionalidad de ver los puntos de la guía situados en el mapa. En la pantalla de crear una guía, se ha considerado que todo usuario tiene una guía borrador en su cuenta, y se considera guía no publicada. Cuando un usuario decide añadir puntos de interés o modificar el título lo hace sobre este borrador. De esta manera se consigue que la información que haya introducido se mantenga entre distintas sesiones de la aplicación. La funcionalidad de añadir puntos de interés a una guía muestra un mapa con los puntos que ya tiene el borrador, el usuario podrá marcar un nuevo punto en el mapa y se le abrirá una ventana emergente dónde podrá definir un título y descripción para ese lugar, o por el contrario volver atrás y deshacer esa elección. Para eliminar algún punto de interés en un borrador se hace desde la ventana de creación de guías. En cuanto a la ventana de perfil, contiene un botón que va cambiando entre editar y guardar. Este botón habilita los campos para que puedan ser editados, incluyendo la imagen de perfil, y cuando se vuelve a pulsar se guardan los valores que haya modificado el usuario. En cuanto a la imagen de perfil, para editarla se le proponen dos opciones al usuario. La primera de ellas es tomar una foto con su dispositivo móvil, pudiendo utilizar tanto la cámara frontal como la trasera, o por otro lado puede seleccionar una imagen de su galería multimedia. 36 12.4 Patrones de diseño empleados 12.4.1 MVVM Figura 8: MVVM Pattern El Patrón MVVM es el núcleo del funcionamiento de una app con Xamarin. Se trata de enlazar las views con sus respectivos ViewModels, donde la view podrá ejecutar comandos, eventos y enlazar los datos que se muestran con las variables del ViewModel. En el caso de este proyecto, el elemento del Modelo no se encuentra directamente en la app, ya que se trataría de una base de datos local. Para acceder al modelo e intercambiar información se realiza a través de llamadas a la API del backend. 12.4.2 DTO Continuando la explicación del MVVM, se requiere de la utilización del Data Transfer Object, este se encarga de comunicar la información entre frontend y backend, de la forma más aislada posible del código. Para ello se ha optado por crear una clase con todas las operaciones necesarias: RestService. 37 12.4.4 Singleton Este patrón se basa en una clase que solo es instanciable una única vez durante la ejecución del programa. En esta aplicación se ha utilizado para guardar información con respecto a la información de login del usuario, así como las opciones de autologin y remember me. No se ha implementado de forma directa, sino que se ha utilizado un plugin llamado Settings, que facilita todo este proceso con llamadas get y set, además de guardar la información entre distintas sesiones de la aplicación. 12.4.5 Publish-subscribe El patrón publish-subscribe es un patrón de mensajería, donde el objeto que envía la información no indica a que receptor en concreto va dirigido el mensaje. Para ello, en esta estructura se definen dos roles, publicador y receptor. Un publicador envía un mensaje de un tipo específico sin indicar a quién se dirige. Por otra parte, un suscriptor está alerta a determinados tipos de mensajes para poder recibirlos y tratarlos, también desconociendo quién publica el mensaje. Figura 9: Publish-subscribe pattern Durante el desarrollo ha sido necesario emplear este patrón para comunicar distintas secciones del proyecto que no tienen conexión directa en cuanto a clases o código. Xamarin utiliza una parte de código escrita en C#, denominada código compartido y que es válido para la implementación de cualquier plataforma. Por otro lado, hay parte del código que es específica para cada plataforma y no tiene posibilidad de comunicarse con el código compartido si no es a través del uso de este patrón. En el caso de este proyecto se ha requerido extender la clase que renderiza mapas de Google para poder personalizarlo adecuadamente y, para poder llevarlo a cabo se debe hacer a nivel de Android y no a nivel de código compartido. 38 Esta funcionalidad se ha logrado gracias a un componente ya incluido en los proyectos de Xamarin, llamado MessagingCenter. El MessagingCenter está implementado a través de eventos de .NET y utiliza métodos sencillos y comprensibles como Send, Subscribe y Unsubscribe. Para el caso práctico se ha utilizado el método subscribe para la clase principal de la aplicación en código compartido. Por otra parte, el método Send desde código Android para indicar que se debe abrir la ventana de información de una guía, generando este mensaje al pulsar en ella en el mapa de Google personalizado. 45 14. Validación del proyecto 14.1 Objetivos • Crear una plataforma para guías turísticas: Es un objetivo que se ha cumplido satisfactoriamente al haber completado el proyecto de inicio a fin con la finalidad de crear la plataforma. • Seguir una metodología ágil correctamente: Se ha utilizado el software de gestión agile Taiga, donde se han ido actualizado las user stories y sus tareas correspondientes de forma progresiva. • Gestionar y organizar el proyecto de forma precisa: La desviación final del proyecto ha sido inferior a unas 20 horas por lo que se puede considerar que se han gestionado bien tanto la planificación como los riesgos. • Consolidar las competencias técnicas: Se ha hecho uso de todas las competencias técnicas listadas en el inicio del planteamiento del proyecto, estas se detallan más en el apartado 15.2. 14.2 Requisitos funcionales • Permitir a los usuarios gestionar su sesión ✓ o Tener registro, login y logout. ✓ o Los usuarios utilizarán su email como método de confirmación. ✓ o Los usuarios podrán restablecer su contraseña a través del email. ✓ o Los usuarios podrán escoger un alias para el uso de la aplicación. ✓ o La información sensible (contraseñas) estarán encriptadas en la BD. ✓ • Permitir a los usuarios modificar su perfil y ver el de otros ✓ o Los usuarios podrán introducir y modificar su información personal. ✓ o Los usuarios podrán ver el perfil de usuarios que hayan creado guías. ✓ 46 • Permitir a los usuarios crear guías turísticas y hacerlas públicas ✓ o Los usuarios podrán añadir puntos de interés a su guía. ✓ o Los usuarios podrán eliminar puntos de interés de su guía. ✓ o Los usuarios podrán añadir una descripción a cada punto de interés. ✓ o Los usuarios podrán publicar las guías. ✓ o Los usuarios podrán eliminar sus guías publicadas (no editar). ✓ • Permitir a los usuarios valorar las guías publicadas ✓ o Los usuarios podrán dar una única nota a guías ajenas, entre 1 y 10. ✓ o Las valoraciones se eliminarán si una guía se elimina. ✓ 14.3 Requisitos no funcionales En cuanto a los requisitos no funcionales de la aplicación, se definieron en el apartado 3.2, y así es como se han gestionado durante el desarrollo para cumplirlos. • Legalidad: La aplicación cumplirá las leyes de protección de datos (RGPD [9]). En cuanto al requisito de la legalidad, la aplicación no trata con datos sensibles a nivel personal más allá de información opcional, tales como el nombre o la edad. Por otro lado, todas las contraseñas están encriptadas en la base de datos y la integridad de la base de datos está bajo el respaldo de la plataforma de MongoAtlas, el propio cloud de MongoDB. • Usabilidad: La interfaz será cómoda y amigable para cualquier tipo de usuario. Para cumplirlo se han diseñado las pantallas previamente al desarrollo del código y se ha precisado de ayuda de algún Tester de UX para contrastar distintas opiniones en cuanto a la distribución de las ventanas, colores escogidos, navegación e incluso los iconos. 47 • Disponibilidad: La aplicación estará operativa el máximo de tiempo posible. En un primer planteamiento del proyecto, la idea principal era tener el servidor activo con un servicio VPS, que no es más que un ordenador en remoto que se mantiene activo durante las 24 horas al día. Sin embargo, este servicio era de pago y no ofrecía muchas garantías en cuanto a la disponibilidad. Si la aplicación del backend crasheaba habría que volver a acceder al servidor y reiniciarlo manualmente. Como alternativa a este servicio se optó por Heroku, una opción que realmente supera al servidor VPS en todos sus aspectos ya que, en primer lugar, se trata de un servicio gratuito, lo cual resulta una gran ventaja respecto al otro servicio de pago. Por otro lado, si la plataforma de Heroku cae, reiniciar la aplicación backend es tan sencillo como ejecutar una línea de comando. Además, otro punto a favor es que proporciona una URL dentro del dominio de Heroku, lo cual es mucho más amigable de cara al usuario si lo comparamos con acceder a una ruta en forma de IP y puerto de conexión. Hablando de la disponibilidad en sí misma, Heroku tiene un gran porcentaje de disponibilidad, lo que nos garantiza que nuestra aplicación estará operativa el máximo de tiempo posible. En la siguiente imagen se puede observar la disponibilidad del servicio, tanto para la región de Estados Unidos como la de Europa, dónde ambas están por encima del 99.999% y cumple con excelencia el requisito de la disponibilidad. Figura 13: Uptime heroku 48 Algo a recalcar sobre este gráfico temporal es que los días naranjas y rojos son aquellos dónde ha habido incidencias, que no caídas de servicio, y puede tratarse de simples aumentos en la latencia de respuesta. • Adaptabilidad: La aplicación podrá ser usada por cualquier dispositivo con Android 5.0 o superior. La propia plataforma de Xamarin nos permite escoger la versión a la que va destinada la aplicación y la retrocompatibilidad que esta tendrá respecto a anteriores versiones. En este caso, la aplicación va destinada a la versión 9.0 y tendrá compatibilidad desde la 5.0 en adelante. • Escalabilidad: La aplicación permitirá un aumento en su número de usuarios. La escalabilidad del proyecto no es medible en frontend sino en backend, ya que no afecta de ningún modo la cantidad de personas que estén usando la aplicación a nivel de dispositivo móvil. En cuanto al backend, hay dos aspectos a tener en cuenta: el tamaño de la base de datos y la cantidad de peticiones que se pueden tratar por segundo. En primer lugar, la base de datos, y es que sí es escalable, pero a cambio de costes monetarios. Al estar alojada en el servicio de MongoDB Atlas está limitada a 500MB, lo cual podría llenarse relativamente rápido y habría que obtener un tamaño mayor de almacenamiento para los datos, realizando pagos mensuales por el mantenimiento. Otra alternativa a esto, menos segura pero más económica, sería cambiar el host de Heroku del que previamente se ha hablado a un servidor VPS, para ahí almacenar los datos de forma local en esa máquina. Ambas opciones son válidas, pero requerirían de una mayor inversión. Respecto a las peticiones por segundo es bastante seguro decir que el servidor podría aguantar sin ningún problema. Esto es debido a que el framework Express de node.js puede procesar hasta 38510 peticiones por segundo, lo cual es un margen de crecimiento realmente amplio y no crearía ningún cuello de botella en la escalabilidad. Estos datos han sido obtenidos de Fastify [17] y sus comparativas de diferentes frameworks. 49 • Portabilidad: La aplicación podrá ser trasladada con relativa facilidad a otros sistemas como iOS o Windows Phone. Si hablamos de portabilidad, Xamarin es una plataforma diseñada para ello. Gracias a su código compartido sería posible crear las versiones de otras plataformas como iOS o Windows Phone con relativa facilidad, adaptando ciertas partes a cada una de ellas. 50 15. Conclusiones Como conclusiones finales del proyecto, he considerado algunas de las más importantes para este apartado. La primera de ellas sería que el desarrollo móvil no es tan simple como que la aplicación funcione en el emulador, ya que cuando se prueba una aplicación con distintos dispositivos surgen problemas de todo tipo, ya sea con los tamaños de pantalla, layouts incorrectos etc. Al hacer la planificación inicial de horas pensé que quizás había asignado demasiadas para ciertas tareas, pero resultaron ser más acertadas de lo esperado ya que existe un sinfín de problemas que aparecen al ejecutar la aplicación con la rotación del móvil activada, sin permisos de ubicación, tema oscuro… En cuanto a la plataforma de desarrollo, Xamarin, personalmente creo que es un muy buen trampolín para aquellos que quieran iniciarse en el desarrollo de aplicaciones móviles, tanto para Android como iOS. Ya que, a mi parecer, es algo más sencillo que programar directamente con Kotlin en Android o con Swift en iOS. 15.1 Consolidación de competencias técnicas • CES1.3: Identificar, evaluar y gestionar los riesgos potenciales asociados a la construcción de software que se pudiesen presentar [Bastante] En la fase de gestión de proyectos se evalúan los posibles riesgos que involucran al proyecto y se ponen medidas para minimizar su impacto en el caso de convertirse en un riesgo real. • CES1.5: Especificar, diseñar, implementar y evaluar bases de datos [Bastante] Para gestionar los datos del proyecto se ha diseñado una base de datos desde cero, creando diferentes tablas para cada clase y las relaciones entre ellas. 51 • CES1.6: Administrar bases de datos (CIS4.3) [Un poco] Además de diseñar la base de datos, se ha puesto en línea y se ha tratado con las tecnologías necesarias para llevar esta tarea a cabo. Siendo responsable de los aspectos técnicos, tecnológicos y legales de la base de datos. • CES1.7: Controlar la calidad y diseñar pruebas en la producción de software. [Bastante] Tras cada historia de usuario implementada, se han realizado una serie de pruebas tanto en frontend como backend para cerciorarse del correcto funcionamiento de la aplicación. • CES2.1: Definir y gestionar los requisitos de un sistema software. [Bastante] Al igual que la competencia CES1.3, se ha tratado en la gestión del proyecto con los requisitos funcionales y no funcionales de la aplicación. • CES1.9: Demostrar comprensión en la gestión i gobierno de los sistemas software. [En profundidad] Se ha tratado con distintas tecnologías y patrones de diseño que en conjunto satisfacen los requerimientos del proyecto con éxito, lo que demuestra cierta habilidad en la gestión y gobierno de los sistemas software. 52 15.2 Trabajo futuro El trabajo futuro con el desarrollo del proyecto no tiene límites, más allá de lo que se quiera llegar a implementar en cuanto a funcionalidades. Algunas de ellas podrían ser añadir comentarios a las guías, opción para añadir fotos a los puntos de interés o incluso añadir guías a una lista de favoritos. Otra tarea importante podría ser la de añadir traducciones a diferentes idiomas. Aparte del propio desarrollo de funcionalidades, podría haber otros objetivos adicionales como publicarla en Google Play, realizar un port a iOS o incluso crear un método de monetización dentro de la app. En el hipotético caso de que la app fuera lanzada al mercado y recibiera comentarios por parte de los usuarios, se tendrían en cuenta para mejorar la experiencia de usuario y a su vez añadir funcionalidades propuestas por estos mismos, siempre y cuando sean realmente objetivos alcanzables. Otra tarea a realizar en el caso de que tuviera una cantidad elevada de usuarios sería la de aumentar la capacidad de los servidores e incluso mejorar la latencia en ciertos países desplegando servidores de backend con host en distintos lugares del mundo, ya que actualmente el único que hay se encuentra en EE. UU y es posible tener un poco de latencia en algunas consultas. 53 16. Referencias [1] “Facultat d’Informàtica de Barcelona” [en línea]. [Consulta: 22 septiembre 2020]. Disponible en: <https://www.fib.upc.edu/> [2] “Microsoft - Official Home Page” [en línea]. [Consulta: 22 septiembre 2020]. Disponible en: <https://www.microsoft.com/es-es/> [3] “Xamarin | Open-source mobile app platform for .NET” [en línea]. [Consulta 22 septiembre 2020]. Disponible en: <https://dotnet.microsoft.com/apps/xamarin> [4] “Google Play” [en línea]. [Consulta 22 septiembre 2020]. Disponible en: <https://play.google.com/store> [5] “Home | UNWTO” [en línea]. [Consulta 9 de octubre 2020]. Disponible en: <https://www.unwto.org/> [6] “Departamento de Ingeniería de Servicios y Sistemas de Información. ESSI - UPC. Universitat Politècnica de Catalunya” [en línea]. [Consulta 23 septiembre 2020]. Disponible en: <https://www.essi.upc.edu/es> [7] “Your Guide - World Travel Tour Guide - Aplicaciones en Google Play” [en línea]. [Consulta 23 septiembre 2020]. Disponible en: <https://play.google.com/store/apps/details?id=com.crawberry.yourguide> [8] “PocketSights Tour Guide - Aplicaciones en Google Play” [en línea]. [Consulta 23 septiembre 2020]. Disponible en: <https://play.google.com/store/apps/details?id=com.crawberry.yourguide> [9] “RGPD - Reglamento General de Protección de datos” [en línea]. [Consulta 24 septiembre 2020]. Disponible en: <https://rgpd.es/> [10] “Nuevo coronavirus 2019” [en línea]. [Consulta 2 diciembre 2020]. Disponible en: <https://www.who.int/es/emergencies/diseases/novel-coronavirus-2019> [11] “What is Scrum?” [en línea]. [Consulta 25 septiembre 2020]. Disponible en: <https://www.scrum.org/resources/what-is-scrum> [12] “Git” [en línea]. [Consulta 25 septiembre 2020]. Disponible en: <https://gitscm.com/> 54 [13] “GitHub” [en línea]. [Consulta 25 septiembre 2020]. Disponible en: <https://github.com/> [14] “Taiga.io” [en línea]. [Consulta 25 septiembre 2020]. Disponible en: <https://taiga.io/> [15] “IDE de Visual Studio, editor de código, Azure DevOps y App Center - Visual Studio” [en línea]. [Consulta 25 septiembre 2020]. Disponible en: <https://visualstudio.microsoft.com/es/> [16] “Búsqueda de empleo en Glassdoor | Encuentra el empleo perfecto para ti” [en línea]. [Consulta 16 octubre de 2020]. Disponible en: <https://www.glassdoor.es/index.htm> [17] “Benchmarks”. [Consulta 10 diciembre 2020]. Disponible en: <https://www.fastify.io/benchmarks/>