Embed Size (px)
Citation preview
Aplicación para la
gestión de alojamientos
turísticos (YeiAPP)
Grado en Ingeniería Multimedia
Trabajo Fin de Grado
Autor: Jaume Lloret Enríquez
Tutor/es: Jaume Aragonés Ferrero
mayo 2019
1
2
Resumen
Hoy en día Internet y los avances tecnológicos son herramientas de uso cotidiano para la
mayoría de nosotros en los distintos ámbitos de nuestra vida, llegando a ser prácticamente
imprescindibles no sólo en el trabajo sino también (y con frecuencia incluso más) en nuestro
tiempo de ocio.
Este proyecto presenta el desarrollo de una aplicación para la gestión de alojamientos
vacacionales que sea multiplataforma y multidispositivo, para facilitar la experiencia del usuario
sin tener que acceder a otras plataformas o descargase distintas aplicaciones e
independientemente de la tecnología empleada. Desde la aplicación, por una parte, los
propietarios podrán publicitar sus alojamientos para alquilar y contratar la gestión del alquiler y
mantenimiento de sus propiedades; por otra, los posibles huéspedes podrán reservar estancias
y servicios mientras que, aún por otro lado, los gestores de los alojamientos podrán realizar las
tareas propias de la industria hotelera: marketing, registro de reservas, comunicación a
autoridades, atención al cliente, transmisión de información entre empleados, oferta de
servicios complementarios, facturación, cobro de estancia, emisión de recibos, etc.
Resum
Actualment Internet i els avanços tecnològics són eines d'ús quotidià per a la majoria de
nosaltres en els diferents àmbits de la nostra vida, arribant a ser pràcticament imprescindibles
no només en el treball sinó també (i amb frequència fins i tot més) en el nostre temps d’oci.
Aquest projecte presenta el desenvolupament d'una aplicació per a la gestió d'allotjaments
vacacionals que siga multiplataforma i multidispositiu, per facilitar l'experiència de l'usuari sense
haver d'accedir a altres plataformes o haver-se de descarregar diferents aplicacions i
independentment de la tecnologia emprada. Des de l'aplicació, d'una banda, els propietaris
podran publicitar els seus allotjaments per llogar-los i contractar la gestió del lloguer i el
manteniment; per una altra, els possibles clients poden reservar estades i serveis mentre que,
encara per un altre lloc, els gestors dels allotjaments podran realitzar les tasques pròpies de la
indústria hotelera: màrqueting, registre de reserves, comunicació a autoritats, atenció a client,
transmissió d’informació entre empleats, oferta de serveis complementaris, facturació,
cobrament de l'estada, emissió de rebuts, etc.
3
Abstract
Today Internet and technological inventions are tools for everyday use for most of us in the
different spheres of our lives, having become practically essential not only at work but also (and
frequently even more) in our leisure time.
This project presents the development of an application for the management of holiday
accommodation that is multi-platform and multi-device, in order to facilitate the user’s
experience without having to access other platforms or download different applications, and
regardless of the technology used. From the application, on the one hand, interested owners
can advertise their accommodations to let and hire the rental management and the
maintenance of their properties; on the other hand, potential guests can book rooms and
services, while, on yet another hand, accommodation managers can perform the typical tasks
of the hotel industry: marketing, booking registrations, communication to authorities, customer
service, transmission of information between employees, offers of complementary services,
billing, changing of stays, issuance of receipts, etc.
4
Motivación, justificación y objetivo general
Este proyecto surge como una oportunidad ante varias coincidencias. Se daba la circunstancia
de que algunos familiares y conocidos estaban alquilando sus propiedades a larga o corta
temporada mediante plataformas online, tales como yaencontre.com, fotocasa.es, niumba.com
o booking.com. Mis propios padres poseen dos apartamentos y mi hermano había iniciado junto
a un amigo una empresa de alquiler vacacional. Al mismo tiempo, yo trabajaba de programador
para un complejo hotelero y empecé a conocer las necesidades del sector y las carencias que
tenían en software.
Mi hermano necesitaba una página web para su empresa y software que facilitase realizar las
tareas de gestión del alquiler de apartamentos turísticos. Juntos intentamos buscar alguna
aplicación que encajase con sus necesidades, pero no la encontramos. Existe una gran cantidad
de plataformas para publicitar alojamientos y ayudar a propietarios y huéspedes a comunicarse
y gestionar reservas, algunas facilitando la sincronización de calendarios e incluso el pago online,
pero poco a poco fue surgiendo la idea de algo más completo y ambicioso. Además de estas
funcionalidades, interesaba una intranet para la administración de la empresa, la gestión
contable y el marketing, incluyendo como productos no solo los alojamientos turísticos sino una
gran variedad de servicios propios de la industria hotelera y de ocio en la comarca. De ahí surgió
la idea de desarrollar una aplicación que aglutinase todas estas funciones y que fuese accesible
desde distintos dispositivos. Cabe decir que conforme más información recopilaba y más
analizábamos su aplicabilidad más interesante y motivador resultaba el proyecto.
Por otra parte, gracias a la intervención de mi tutor, que me planteó usar un lenguaje de
programación relativamente nuevo y su framework pensado para mejorar la velocidad de
programación, como son Dart y Flutter, he tenido la oportunidad de aprender algo nuevo y de
poder crear algo útil para un posible negocio futuro.
Cuando empecé a desarrollar la idea para la aplicación, vi que hay mucho por hacer y mucho
que mejorar y, por ello, tuve que recortar las características para este demo inicial, pero
claramente es un proyecto viable: solo se necesita tiempo, ganas de aprender, mucho trabajo y
un servidor donde alojar el contenido.
Al principio el proyecto iba a ser la base de una plataforma de alquiler de pisos turísticos,
necesaria para la empresa de mi hermano, pero pronto vimos las posibilidades de proyección
que tiene el proyecto, ya que, en lugar de desarrollar una aplicación para una empresa concreta,
5
se puede generar una herramienta de gestión de alojamientos, útil para cualquier empresa de
alquiler vacacional e incluso dirigirse a todo tipo de empresas del sector, por tanto incluyendo
hoteles y residencias, alojamientos para estudiantes, etc. Y teniendo en cuenta la magnitud de
trabajo de programación, revisión, pulido y actualización que esta nueva visión conlleva, he
pensado que además resulta conveniente generar una empresa informática que desarrolle el
proyecto y realice las distintas funciones asociadas al mismo. En verdad, ya forma parte del
desarrollo de este proyecto la creación de una empresa y ya están muchos de mis esfuerzos
puestos en ella.
Tanto por el hecho de poder desarrollar un software de mi iniciativa que pueda ser útil en el
mundo real, así como por poder incorporar mi experiencia en el trabajo que estaba realizando
estos dos últimos años, me parece un proyecto muy personal, apasionante y enriquecedor. Al
mismo tiempo me emociona poder aprender y usar nuevas tecnologías, el reto de poder elegir
servidor o plataformas cloud o el mero hecho de plantear el proyecto y de hacer que este
evolucione.
Actualmente he dejado mi empleo de informático en el sector hotelero porque confío en este
proyecto y necesitaba centrarme plenamente en él. Creo que tiene futuro, que puedo
desarrollar una herramienta útil y que puede crecer junto a mi para convertirse en algo
importante en el sector turístico que nos rodea.
El proyecto viene de una visión comercial propia de mi hermano y mía, pero sin lugar a duda se
apoya en los consejos y observaciones de nuestra familia y amigos y, por supuesto, en el estudio
y análisis de otras ideas o proyectos como son Booking, Airbnb o los diferentes PMS o CRT que
hay en el mercado.
Como se puede observar será un proyecto que requerirá que me esfuerce al máximo y ponga
en práctica todo lo aprendido durante estos duros años de ingeniería. Tendré que ser capaz de
desarrollar un proyecto cuya finalidad es la construcción de una herramienta de gestión
haciendo uso de todo el conocimiento que he conseguido adquirir durante mis años de estudio
y formación. Además, tendré que evolucionar junto al proyecto y crecer con él, aprender mucho,
descubrir qué he de mejorar, sin duda, usando las diferentes técnicas y conocimientos que he
adquirido como ingeniero.
6
Agradecimientos
A mis abuelas,
por ser ejemplo y fuente de inspiración. A mi abuela Vicenta, que ya no se encuentra con
nosotros, por su buen ánimo y espíritu emprendedor, y a mi abuela Ana, ahora de 93 años,
por no perder el interés por aprender y estar al día con las nuevas tecnologías -de hecho,
no para de acribillarme a preguntas y disfruta conversando con los asistentes de voz
virtuales.
A mis padres,
Por sus consejos y su paciencia y apoyo en mis estudios. A mi madre, por su continuo
seguimiento en que yo no desista en mi formación y en alcanzar mis metas, y, a mi padre,
por haber despertado en mí el interés por la ciencia y la tecnología y estar a mi lado
siempre que lo he necesitado.
A mi hermano y mis amigos, de mis estudios y personales,
por su comprensión y su colaboración. A los no relacionados con este proyecto, por su
paciencia conmigo y mi entusiasmo por este tema; a los que sí lo han compartido, por
escucharme, entusiasmarse conmigo y atreverse a emprender una aventura que sin duda
será enriquecedora para todos.
A mi tutor,
Por sus consejos y atención ya que sin la ayuda de sus conocimientos, su paciencia para
escucharme y guiar mi trabajo así como su practicidad, sensatez y actitud positiva, no
hubiese sido posible acabar con éxito este trabajo que me ha producido tanta satisfacción
y del que me siento tan orgulloso.
7
Citas
Durante mis estudios en ingeniería multimedia me topé con la siguiente cita, la cual ha sido un
gran aliciente para mí y desde ese momento ha motivado mis esfuerzos y trabajo, y no dudo que
continuaré teniendo en cuenta en el futuro:
Si amas lo que haces y estás dispuesto a hacer lo que sea necesario,
está a tu alcance. Y valdrá la pena cada minuto que pases solo por la
noche pensando y pensando qué es lo que quieres diseñar o construir.
Valdrá la pena, lo prometo.
Steve Wozniak
Junto a la creencia de que con esfuerzo conseguiré llegar a mi meta, me planteo la posibilidad
de mejorar lo existente a partir de lo conocido, intentando guiarme en nuestros científicos:
La creatividad es ver lo que todo el mundo ve y después pensar algo que nunca nadie antes
había pensado y lograr expresarlo de alguna forma.
Neil deGrasse Tyson
Al realizar este apartado viene a mi mente el recuerdo de una persona muy querida para mí y
mi familia. Se trata de un amigo, profesor de informática, que con frecuencia sacaba de algún
apuro a mis padres cuando yo era pequeño y cuya máxima era “Si no funciona, reinicia”, palabras
que frecuentemente he oído repetir a mis compañeros de sistemas durante mis años de trabajo
como informático en la empresa privada y me ha sorprendido encontrar en la guía para este TFG
[119]. De ahí que, además de evocador de tantas vivencias, suele resultar práctico el siguiente
consejo:
Si algo se vuelve demasiado complicado, se atasca o no te convence: reinicia.
José Vicente Berná
8
Índice de contenidos
Resumen ........................................................................................................................................ 2
Resum ............................................................................................................................................ 2
Abstract ......................................................................................................................................... 3
Motivación, justificación y objetivo general ................................................................................. 4
Agradecimientos ........................................................................................................................... 6
Citas ............................................................................................................................................... 7
Índice de figuras .......................................................................................................................... 10
Índice de tablas ........................................................................................................................... 13
1. Introducción ........................................................................................................................ 16
2. Estudio de viabilidad ........................................................................................................... 19
2.1. Análisis DAFO .............................................................................................................. 19
2.2. Lean Canvas ................................................................................................................. 22
2.3. Análisis de riesgos ....................................................................................................... 25
3. Planificación y Metodología ................................................................................................ 37
4. Estado del arte. ................................................................................................................... 45
5. Objetivos ............................................................................................................................. 50
6. Análisis y especificación ...................................................................................................... 52
6.1. Funciones del producto ............................................................................................... 52
6.2. Características de los usuarios .................................................................................... 53
6.3. Restricciones, suposiciones y dependencias ............................................................... 54
6.4. Funciones futuras ........................................................................................................ 55
6.5. Requisitos .................................................................................................................... 56
6.6. Casos de Usos .............................................................................................................. 64
7. Diseño .................................................................................................................................. 66
7.1. Diseño de la persistencia ............................................................................................. 66
7.2. Diseño arquitectura conceptual .................................................................................. 80
9
7.3. Diseño API Rest y Backend .......................................................................................... 81
7.4. Diseño Interfaces, Frontend y Experiencia de Usuario ............................................... 91
7.5. Guías de estilos.......................................................................................................... 103
8. Implementación ................................................................................................................ 105
8.1. Entorno de trabajo .................................................................................................... 105
8.2. Desarrollo de la API ................................................................................................... 106
8.3. Implementación del Frontend ................................................................................... 108
8.4. Patrón BLOC .............................................................................................................. 109
9. Pruebas y validación .......................................................................................................... 111
10. Resultados ..................................................................................................................... 113
11. Conclusiones y trabajo futuro ....................................................................................... 118
Referencias ................................................................................................................................ 119
Apéndice I .................................................................................................................................. 122
Apéndice II ................................................................................................................................. 123
Apéndice III ................................................................................................................................ 124
Apéndice IV ............................................................................................................................... 125
Apéndice V ................................................................................................................................ 126
Apéndice VI ............................................................................................................................... 141
Apéndice VII .............................................................................................................................. 156
Apéndice VIII ............................................................................................................................. 157
10
Índice de figuras
Figura 1 Análisis DAFO. ................................................................................................................ 19
Figura 2. Cuadro del análisis Lean Canvas para el proyecto ....................................................... 22
Figura 3. Categorías por tiempo en la primera fase .................................................................... 39
Figura 4. Horas Trabajo por mes ................................................................................................. 39
Figura 5. Tareas y tiempo en la primera fase .............................................................................. 39
Figura 6. Tareas y tiempo segunda fase proyecto ...................................................................... 40
Figura 7. Primer Sprint F2 ............................................................................................................ 41
Figura 8. Tercer Sprint F2 ............................................................................................................ 41
Figura 9. Segundo Sprint F2 ........................................................................................................ 41
Figura 10. Porcentaje de tiempo trabajado por tag F2 ............................................................... 42
Figura 11. Horas trabajadas por mes F2 ...................................................................................... 42
Figura 12. Porcentaje de tipo por tag en F3 ................................................................................ 42
Figura 13. Horas trabajadas mes F3 ............................................................................................ 42
Figura 14. Tareas y tiempo de la tercera fase ............................................................................. 43
Figura 15. Porcentaje de tiempo por TAG ................................................................................... 44
Figura 16. Tiempo por mes proyecto .......................................................................................... 44
Figura 17. disponible en https://chekin.io/blog/software-para-apartamentos-turisticos-
diferencias-entre-pms-channel-manager-ota-y-metabuscador/ ................................................ 49
Figura 18. Caso de uso sistema Guest ......................................................................................... 64
Figura 19. Caso de uso del sistema Host ..................................................................................... 65
Figura 20. Logo Oficial Mysql ...................................................................................................... 66
Figura 21. Diseño de la Base de datos ......................................................................................... 68
Figura 22. Diseño conceptual de la aplicación ............................................................................ 81
Figura 23. Arquitectura de la API ................................................................................................ 82
Figura 24. Logo oficial PHP .......................................................................................................... 84
Figura 25. Logo Lumen ................................................................................................................ 84
Figura 26. Logo oficial Dart.......................................................................................................... 91
Figura 27. Logo oficial Flutter ...................................................................................................... 91
Figura 28. Mockup inicio ............................................................................................................. 92
Figura 29. Mockup lista reservas ................................................................................................. 93
Figura 30. Mockup filtro reservas ............................................................................................... 94
Figura 31. Mockup lista reservas mapa ....................................................................................... 94
11
Figura 32. Mockup más información alojamiento ...................................................................... 95
Figura 33. Mockup registro Host ................................................................................................. 95
Figura 34. Mockup realizar reserva ............................................................................................. 96
Figura 35. Mockup realizar pago ................................................................................................. 96
Figura 36. Mockup mis reservas .................................................................................................. 97
Figura 37. Mockup perfil usuario Guest ...................................................................................... 97
Figura 38. Mockup descripción reserva ...................................................................................... 97
Figura 39. Mockup de bienvenida Host ...................................................................................... 98
Figura 40. Mockup inicio sesión .................................................................................................. 98
Figura 41. Mockup registro Host ................................................................................................. 99
Figura 42. Mockup Formulario de inscripción alojamiento ...................................................... 100
Figura 43. Mockup más información empresa .......................................................................... 100
Figura 44. Mockup contacto para alta ...................................................................................... 100
Figura 45.Mockup menú usuario .............................................................................................. 101
Figura 46.Mockup perfil ............................................................................................................ 101
Figura 47.Mockup estadísticas y facturas ................................................................................. 102
Figura 48.Mockup lista alojamientos ........................................................................................ 102
Figura 49.Mockup perfil alojamiento ........................................................................................ 102
Figura 50. Paleta de colores ...................................................................................................... 103
Figura 51. Fuente Kaushan Script .............................................................................................. 104
Figura 52. Fuente Carrois Gothic ............................................................................................... 104
Figura 53. Fuente Carrois Gothic SC .......................................................................................... 104
Figura 54. Logo Linux Mint ........................................................................................................ 105
Figura 55. Logo Android Studio y SDK ....................................................................................... 105
Figura 56. Logo Composer ......................................................................................................... 105
Figura 57.. Logo Visual Studio Code .......................................................................................... 106
Figura 58. Logo XAMPP ............................................................................................................. 106
Figura 59. Implementación APIs................................................................................................ 107
Figura 60. Flutter Hot Reload .................................................................................................... 108
Figura 61. Ejemplo de librerías de Flutter usadas ..................................................................... 109
Figura 62. Implementación de widgets ..................................................................................... 110
Figura 63. Logo Postman ........................................................................................................... 111
Figura 64. Prueba unitaria ruta alojamientos ........................................................................... 112
Figura 65. Captura pantalla Inicio ............................................................................................. 113
Figura 66. Mockup inicio ........................................................................................................... 113
12
Figura 67. Mockup de bienvenida Host .................................................................................... 114
Figura 68. Captura de pantalla Bienvenida Host ....................................................................... 114
Figura 69. Captura de pantalla Menú Perfil .............................................................................. 115
Figura 70. Captura de pantalla contacto ................................................................................... 115
Figura 71. Captura de pantalla Perfil ......................................................................................... 115
Figura 73. Mockup Formulario de inscripción alojamiento ...................................................... 116
Figura 72. Capturas pantalla Formulario alojamiento .............................................................. 116
13
Índice de tablas
Tabla 1. Posibles riesgos .............................................................................................................. 25
Tabla 2. Posibles riesgos por la Tecnología ................................................................................. 27
Tabla 3. Posibles riesgos por las personas .................................................................................. 27
Tabla 4. Posibles riesgos por la organización .............................................................................. 27
Tabla 5. Posibles riesgos por las herramientas ........................................................................... 27
Tabla 6. Posibles riesgos por los requerimientos ........................................................................ 28
Tabla 7. Posibles riesgos por las estimaciones ............................................................................ 28
Tabla 8. Posibles riesgos por otros supuestos ............................................................................ 28
Tabla 9. Riesgo y acciones para superarlo .................................................................................. 29
Tabla 10. Planificación inicial del Proyecto TFG .......................................................................... 39
Tabla 11. Repercusiones de las tecnologías en la gestión de alojamientos turísticos ................ 45
Tabla 12. Tipos de canales y aplicaciones para la gestión del alquiler vacacional ...................... 48
Tabla 13. RF01 ............................................................................................................................. 56
Tabla 14. RF02 ............................................................................................................................. 57
Tabla 15. RF03 ............................................................................................................................. 57
Tabla 16. RF04 ............................................................................................................................. 57
Tabla 17. RF05 ............................................................................................................................. 58
Tabla 18. RF06 ............................................................................................................................. 58
Tabla 19. RF07 ............................................................................................................................. 58
Tabla 20. RF08 ............................................................................................................................. 59
Tabla 21. RF09 ............................................................................................................................. 59
Tabla 22. RF10 ............................................................................................................................. 59
Tabla 23. RF11 ............................................................................................................................. 59
Tabla 24. RF12 ............................................................................................................................. 60
Tabla 25. RF13 ............................................................................................................................. 60
Tabla 26. RF14 ............................................................................................................................. 60
Tabla 27. RF15 ............................................................................................................................. 61
Tabla 28. RF16 ............................................................................................................................. 61
Tabla 29. RF17 ............................................................................................................................. 61
Tabla 30. RF18 ............................................................................................................................. 61
Tabla 31. RF19 ............................................................................................................................. 62
Tabla 32. RF20 ............................................................................................................................. 62
14
Tabla 33. RF21 ............................................................................................................................. 62
Tabla 34. BBDD Tabla principal alojamientos ............................................................................. 69
Tabla 35. BBDD Tabla principal contratos ................................................................................... 70
Tabla 36. BBDD Tabla principal contratoplantillas ...................................................................... 70
Tabla 37. BBDD Tabla principal multimediacontenidos .............................................................. 71
Tabla 38. BBDD Tabla principal reservas ..................................................................................... 71
Tabla 39. BBDD Tabla principal direcciones ................................................................................ 73
Tabla 40. BBDD Tabla principal paises ........................................................................................ 73
Tabla 41. BBDD Tabla principal provincias .................................................................................. 74
Tabla 42. BBDD Tabla principal usuarios ..................................................................................... 74
Tabla 43. BBDD Tabla principal referencias ................................................................................ 75
Tabla 44. BBDD Tabla secundaria servicios ................................................................................. 75
Tabla 45. BBDD Tabla secundaria caracteristicas ........................................................................ 75
Tabla 46. BBDD Tabla secundaria apisexternas .......................................................................... 76
Tabla 47. BBDD Tabla secundaria condiciones............................................................................ 76
Tabla 48. BBDD Tabla secundaria multimediacaracteristicas ..................................................... 76
Tabla 49. BBDD Tabla secundaria datos ...................................................................................... 77
Tabla 50. BBDD Tabla auxiliar servicioalojamientovalores ......................................................... 77
Tabla 51. BBDD Tabla auxiliar caracteristicaalojamientovalores ................................................ 78
Tabla 52. BBDD Tabla auxiliar apiealojamientovalores ............................................................... 78
Tabla 53. BBDD Tabla auxiliar contratocondicionvalores ........................................................... 79
Tabla 54. BBDD Tabla auxiliar caracteristicamultimediavalores ................................................. 79
Tabla 55. BBDD Tabla auxiliar usuariodatovalores ..................................................................... 80
Tabla 56. Respuesta estándar JSON ............................................................................................ 84
Tabla 57. Request a yeiapp.com oath ......................................................................................... 85
Tabla 58. Request a yeiapp.com usuarios GET ............................................................................ 85
Tabla 59. Request a yeiapp.com usuarios GET/id ....................................................................... 86
Tabla 60. Request a yeiapp.com usuarios POST ......................................................................... 86
Tabla 61. Request a yeiapp.com usuarios PATCH ....................................................................... 86
Tabla 62. Request a yeiapp.com alojamientos GET .................................................................... 87
Tabla 63. Request a yeiapp.com alojamientos GET/id ................................................................ 87
Tabla 64. Request a yeiapp.com alojamientos POST .................................................................. 88
Tabla 65. Request a yeiapp.com alojamientos PATCH ................................................................ 88
Tabla 66. Request a yeiapp.com reservas GET ............................................................................ 89
Tabla 67. Request a yeiapp.com reservas GET/id ....................................................................... 89
15
Tabla 68. Request a yeiapp.com reservas POST.......................................................................... 89
Tabla 69. Request a yeiapp.com reservas PATCH ....................................................................... 90
16
1. Introducción
Vivimos en una zona donde el turismo es clave y motor económico en muchos municipios. No
en vano, según un estudio de 2015 publicado por Probuen Advisory en marzo de 2017 [3],
España ocupa el tercer lugar, sólo por detrás de Francia y Estados Unidos, entre los países más
visitados, y la Comunidad Valenciana se encuentra en quinta posición de llegadas turísticas a
cada comunidad autónoma. De acuerdo con el artículo publicado recientemente en la sección
de Economía del diario El Mundo [4], la pasada crisis de consumo no sólo “no hizo mella en el
sector, sino que lo reforzó frente a otras actividades económicas”. De hecho, la aportación del
sector al Producto Interior Bruto (PIB) de la Comunidad aumentó en 4000 millones y casi tres
puntos más de peso en el conjunto de la economía valenciana y el peso sobre el empleo total
aumentó en dos puntos.
Sin embargo, uno de los muchos problemas que ha tenido este sector es la lucha contra el
alquiler turístico basándose principalmente en motivos sociales (debido al surgimiento de
problemas de convivencia, el encarecimiento del precio de las viviendas y del alquiler de larga
duración), pero también ecológicos y culturales (por el problema de la zonificación de los
alojamientos sobre todo en las grandes ciudades), por parte de las instituciones públicas,
presionados por la población civil y la prensa, arengados estos en gran medida por el sector
hotelero, el cual alega que el alquiler turístico no está sujeto a sus mismas normas y requisitos
por lo que revierte en competencia desleal, el incumplimiento de la legalidad o la mala gestión,
como se puede constatar en multitud de programas y noticias en distintos medios de
comunicación, como por ejemplo el artículo “Impactos sociales del alquiler turístico” publicado
en el diario Información el pasado 31 de agosto de 2019 [5] y distintos análisis y estudios como
la “Presentación del Estudio de Impacto social y económico de las viviendas de uso turístico” de
la Federación Española de Asociaciones de Viviendas y Apartamentos Turísticos (FEVITUR) [6] o
el documento de Trabajo “las Viviendas turísticas ofertadas por plataformas on-line: Estado de
la cuestión”, publicado por la Fundación de Estudios de Economía Aplicada (FEDEA) en abril de
2019 [7], por dar algunos ejemplos. De todos modos, el creciente interés por viajar o necesidad
de hacerlo han aumentado la movilidad a nivel internacional y, en consecuencia, la demanda de
alojamientos y servicios por distintos motivos (vacaciones, salud, trabajo, estudios u otros).
Al mismo tiempo vemos como en la última década han crecido los negocios de alquiler online,
sobre todo los operadores Airbnb y Booking, que permiten a los usuarios (en el caso de los
anfitriones) ofrecer en alquiler sus propiedades o (en el de los huéspedes) alquilar alojamientos.
17
Estas plataformas se suelen llevar un porcentaje considerable de la renta solicitada por el
alquiler. Airbnb aplica una tarifa mínima (ya que puede aumentar según distintos
condicionantes) del 3% a la mayoría anfitriones y del 13% a los huéspedes, o bien la tarifa solo
para anfitriones está entre el 14 y 20% si es para hoteles o empresas de la hostelería, como se
puede constatar en su página web [8]. En la ayuda para colaboradores de Booking [9] se indica
que los anfitriones pagan una comisión fija del 15%, que igualmente puede incrementarse según
la ubicación, tipo de alojamiento y distintas campañas de promoción. Sin embargo, estos canales
de alquiler vacacional online tienen poco o ningún contacto directo con los clientes: son simples
intermediarios entre huéspedes y anfitriones, dando lugar a un trato impersonal y robótico.
Cabe tener en cuenta que existen muy pocas herramientas en las cuales la gestión de alquiler
de alojamientos esté mecanizada a nivel profesional como ocurre con los PMS1 de los hoteles y
al mismo tiempo vemos que las herramientas que usan muchas cadenas hoteleras están
anticuadas y con diseños arcaicos. Si nos fijamos en Prestige, podemos decir que es un PMS para
gestión hotelera muy completo, pero tanto a nivel de interfaz como en usabilidad está en otra
época, y por ello tiene una curva de aprendizaje para el personal hotelero elevada, por lo que
no hay duda de que muchos hoteles preferirían sustituirla por una versión más rápida, sencilla
y atractiva. Smoobu [10], por su parte, es de gran utilidad para la gestión de alojamientos
turísticos, ya que facilita muchas tareas a los propietarios o anfitriones -de hecho, permite
aglutinar las reservas directas y las procedentes de distintos portales, registrar información y
datos sobre la reserva y los huéspedes, obtener estadísticas de ocupación e ingresos, gestión de
huéspedes (CRM2), creación de propio sitio web o conexión de su dominio existente, motor de
reservas y calendario de disponibilidad, sincronización de calendarios, aceptación de pagos con
tarjeta de crédito y Paypal, optimización para teléfonos móviles y tabletas, comunicación
centralizada y automatización de mensajería a destinatarios individuales (personal de limpieza,
huésped concreto, comunicación a la Policía o Guardia Civil, etc.). Sin embargo, falta el control
de almacén y necesidades, la gestión económica y contable y, en especial, que se trate de una
aplicación ágil, intuitiva y cómoda de usar, útil para la gestión de todo tipo de alojamientos y, a
su vez, que aporte confianza, inicialmente en nuestro entorno más próximo, por el trato directo
1 Un PMS (en inglés, Property Management System o Sistema de gestión de alojamientos) es un sistema operativo de
gestión o software específico para automatizar las funciones y servicios de un hotel, como la gestión de reservas, el registro de entrada y salida de clientes, asignación de habitaciones, gestión de tarifas, marketing, gestión de los servicios de limpieza y mantenimiento, nóminas y facturación entre otros. 2 Un CRM (en inglés Customer Relationship Management, o Gestión de las relaciones con clientes) es una aplicación que permite centralizar en una única Base de Datos todas las interacciones entre una empresa y sus clientes.
18
en persona, y poco a poco, según vaya ampliándose nuestro radio de acción, por los comentarios
y valoración de los usuarios.
Por otra parte, podemos observar que el mundo ya ha evolucionado a los desarrollos
multiplataforma, y queremos poder usar el mismo programa en distintos dispositivos (sea un
móvil, tablet u ordenador de sobremesa o portátil), y queremos una experiencia de usuario casi
igual, o si es posible la misma, en cada sistema. Por ello, cada vez es más interesante utilizar
lenguajes o frameworks que sean crossplatform que nos permiten hacer desarrollos que facilitan
poder trabajar con un mismo código y diseño en diferentes plataformas sin tener que hacer
cambios en nuestra planificación.
Al mismo tiempo, conviene llevar todo el peso de los procesos de la aplicación a la nube para
que así la experiencia del usuario no dependa del dispositivo ni de las características de éste,
aunque con este traslado (procesos) a la nube haya que afrontar los diferentes problemas que
pueden surgir por una mala conectividad o una baja velocidad de red.
Por todo esto, creo que es interesante desarrollar una aplicación de alquiler vacacional y de
corta estancia o temporada que integre las características necesarias para una buena gestión
del servicio y que facilite la labor al gestor de alojamientos.
19
2. Estudio de viabilidad
En esta sección analizaremos si la ejecución de mi propuesta de trabajo es viable y qué camino
he de tomar para poder realizarlo correctamente. Tendremos en cuenta que se trata de una
aplicación con visión comercial y cómo se desarrollaría el proyecto para terminar siendo una
aplicación profesional que derive en un negocio de futuro.
2.1. Análisis DAFO
Iniciaremos el estudio de viabilidad analizando las características propias o internas del
proyecto, es decir, tanto sus puntos fuertes como los débiles, y su situación externa, que incluye
no solo las oportunidades que nos brinda sino también las posibles amenazas que será necesario
afrontar para alcanzar el objetivo marcado. Esto es, vamos a realizar un Análisis DAFO (acrónimo
de Debilidades, Amenazas, Fortalezas y Oportunidades) del proyecto, esquematizado en la
Figura 1.
Figura 1 Análisis DAFO. (Fuente propia, elaborado con lucidchart.com [15])
20
Para un desarrollo eficiente del proyecto conviene tener en cuenta las siguientes
consideraciones:
a. Destacan como fortalezas:
− El conocimiento del sector hotelero: personalmente, por haber trabajado como
informático en una empresa hotelera de prestigio en la zona, pero, sobre todo, por
contar con el apoyo de empresarios de la zona que han aportado información
específica muy valiosa para el proyecto sobre las necesidades y carencias del sector
y su propia experiencia profesional.
− Cuento con la posibilidad de poder probar la aplicación en una empresa existente,
de manera que es posible ponerla a prueba en un contexto real.
− La integración con los canales de alquiler online permitirá la sincronización de
calendarios y precios, el registro de reservas y cancelaciones, etc. en distintas
plataformas a la vez, facilitando la gestión y optimizando el tiempo del gestor.
− El uso de un lenguaje multiplataforma permitirá trabajar en los distintos sistemas
operativos existentes: Android, IOS, Windows, Linux...
− Desde una única aplicación se podrán realizar las distintas funcionalidades de
manera que los usuarios no tendrán que descargarse ninguna otra aplicación o
entrar en un canal distinto.
− Mi experiencia laboral con programas de gestión hotelera me permite tener una
idea bastante ajustada de cómo mejorar las existentes ahora en el mercado para
poder atender las necesidades de la empresa target u objetivo y posibles futuros
clientes de nuestra área.
b. No podemos subestimar sus posibles debilidades:
− Se trata de un proyecto que puede resultar demasiado ambicioso para una sola
persona por la multitud de funcionalidades que puede llegar a incluir la aplicación y
su necesidad de revisión, actualización y ampliación constante que requerirá en el
futuro. Por ello, en estos momentos se ha limitado a las necesidades inmediatas de
la empresa cliente.
− Las aplicaciones de gestión hotelera más conocidas y usadas llevan operando desde
la aparición de las primeras aplicaciones y se encuentran muy instauradas. Las
cadenas hoteleras de la zona pueden tener reticencias al cambio, prefiriendo las ya
conocidas frente a otras más innovadoras.
− Es necesario conseguir una buena aplicación y mantener una buena campaña de
comercialización para darla a conocer a la multitud de clientes posibles.
21
− La aplicación depende de una buena infraestructura online. Si esta falla, fracasará el
proyecto.
c. Debemos aprovechar las oportunidades que se nos presentan:
− Las aplicaciones del sector están anticuadas y, aunque van incorporando cambios,
se trata de parches que no las hacen competitivas respecto a una nueva aplicación
que resulte fiable, integral y atractiva.
− Las aplicaciones veteranas no son multiplataforma, lo que sin duda inclinará la
balanza hacia una nueva plataforma que lo sea, aunque actualmente están
cambiando por las tendencias de uso de los móviles.
− El alquiler de corta temporada está en continuo crecimiento por lo que cada día hay
más personas que necesitan gestionar sus alojamientos y les interesará una
aplicación que les facilite el trabajo. Además, el hecho de que esté regulándose
permitirá dar una estabilidad al sector y añade nuevas tareas que resultarán más
fáciles mediante la aplicación.
− Además de los profesionales, cada vez hay más personas no especialistas del sector,
como es el caso de los propietarios privados de apartamentos, que necesitan que
les faciliten la gestión.
− Es una indudable ventaja disponer de una empresa en la que poder hacer pruebas
reales de mercado.
− Las empresas que ya están instauradas tienen precios altos y no se sienten
amenazadas. Además de focalizar la atención en los pequeños hoteles y propietarios
individuales que en general no usan aplicaciones de gestión de alquiler vacacional,
conviene ofrecer precios competitivos para intentar atraer también a clientes más
potentes.
− Existen en el mercado internacional otras aplicaciones con herramientas más
actuales para la gestión que podrían considerase como posibles rivales, pero son
muy poco conocidas en nuestra zona.
− El turismo sigue siendo un negocio en alza y que ofrece crecientes oportunidades
para desarrollar nuevas funcionalidades a la aplicación de gestión de alquiler de
alojamientos y hoteles.
d. Tampoco podemos obviar las posibles amenazas, tales como:
− Fracasar durante el desarrollo del proyecto por no gestionar bien el tiempo
22
− No llegar a ningún cliente por perder la confianza de la empresa cliente o resultar
que la aplicación no se adapta a las necesidades de otros clientes o no les es
atrayente o fiable.
− Hacer una mala gestión en la elección de servidores o plataformas cloud, con lo que
finalmente la aplicación es inoperativa.
− No planificar correctamente la escalabilidad.
− Muchas aplicaciones hacen cosas parecidas, pero no todas a la vez. Es esencial llegar
a transmitir la multiversalidad de la aplicación.
2.2. Lean Canvas
Teniendo en cuenta que este proyecto pretende mejorar otras aplicaciones ya existentes y con
el fin de obtener un estudio más completo, recurrimos también a la herramienta Lean Canvas
que permite analizar el proyecto desde diferentes perspectivas de interés como muestra la
Figura 2. Cuadro del análisis Lean Canvas para el proyecto.
Figura 2. Cuadro del análisis Lean Canvas para el proyecto (Fuente propia, elaborado con lucidchart.com [15])
• Problema: Me planteo qué hace falta y cuál es la situación actual.
- Necesitamos una aplicación para la gestión de pisos turísticos.
23
- Hay WebApps parecidas, pero no satisfacen nuestras necesidades.
- Los programas de gestión del sector hostelero están desfasados o utilizan
tecnologías antiguas.
- No hay aplicaciones multiplataforma útiles.
• Solución: Esta es mi propuesta para la necesidad planteada.
Puedo crear una aplicación multiplataforma cuyos datos sean online y que integre los
distintos requisitos que requiere la empresa de alquiler objetivo.
• Métrica clave: Se tendrán en cuenta:
- el número de reservas que se realicen mediante la aplicación
- el número de alojamientos que estén registrados en la misma
- el número de clientes (visitas), entendiendo aquí por “clientes” los usuarios que
visitan la aplicación.
• Proposición de valor única:
Proporciono una herramienta para gestión de alquiler turístico que integra todo lo
necesario para facilitar el trabajo a los gestores de nuestra empresa objetivo. Además,
la aplicación es multiplataforma y multidispositivo para que no estén ligados a una sola
tecnología.
• Ventaja especial de la que parto:
- Dispongo de experiencia como informático de sistemas y programador del sector
turístico.
- Cuento con una empresa inicial con la cual hacer las pruebas de mercado
• Canales: Se dará a conocer mediante
- El boca a boca, presentar en persona la aplicación a los potenciales clientes de la
zona y que estos vayan transmitiendo el mensaje a posibles nuevos usuarios,
también en persona y/o mediante valoraciones y comentarios online.
- Entrevistas con empresas.
- Publicidad en Internet.
• Segmento de clientes: Los tipos de clientes o usuarios son
- el anfitrión (Host), usuario que desea que la empresa de gestión vacacional se haga
cargo de su alojamiento
- el huésped (Guest), persona que desea reservar un alojamiento vacacional
- Gestores de la empresa, administradores de los servicios de los alojamientos
vacacionales
24
• Estructura de costes: la estimación es la siguiente:
- Servidor: aproximadamente 30 € / mes
- Sueldo del programador: 1600 € / mes
- Formación: 200 €
• Flujo de ingresos: Se contará con:
- Un pago único acordado por la utilización de la licencia por parte de la empresa
solicitante
- Un porcentaje anual acordado con la empresa por superar una cota determinada de
reservas desde la aplicación
- Mensualidades por mantenimiento de la aplicación y servicios
- un pago único por plug-ins personalizados, acordado según requisitos y carga de
trabajo en cada caso.
De mi solución del Lean Canvas en la Figura 2 se puede pensar que podría suponer un problema
para el éxito de la aplicación la existencia de otro software que pueda hacer una labor similar.
Aunque es cierto que sí hay distintas aplicaciones similares, cabe tener en cuenta que no sirven
para exactamente lo mismo y, con frecuencia, lo hacen por separado, es decir, no hay ninguna
aplicación multiplataforma que sea para la gestión integral de las necesidades del alquiler de
alojamientos. Además, en el mercado hotelero vemos plataformas PMS que ya están muy
instauradas en el sistema, pero resultan obsoletas y desfasadas para el usuario.
Creo que sería una buena solución crear una aplicación que integre todo lo necesario para el
desempeño del alquiler y que vaya creciendo por módulos para que no se alargue en el tiempo
de forma frustrante e inasumible económicamente, lo cual llevaría al fracaso por no poder llegar
a producir ningún producto. Interesa además que ésta sea multiplataforma y multidispositivo,
con una interfaz útil, usable y reconocible en todos ellos. También conviene que el cómputo
total de la aplicación se tenga en la nube.
Para llegar a conocer correctamente el desempeño de la aplicación, cabe tener en cuenta la
estadística de uso de la misma, además de estas tres métricas: como serían las visitas a la parte
Guest y Host, el número de reservas y el control de accesos a la parte del PMS. Interesa obtener
igualmente el control de otros datos como son la nacionalidad de los usuarios, su edad, el tiempo
de búsqueda, qué precios les interesan más, entre otros muchos datos, para poder dar a la
aplicación el mejor uso posible y hacerla más interesante.
Contando con estos factores conseguiré una aplicación que facilite el trabajo a las agencias de
gestión de alojamientos mediante el desarrollo de su labor de gestión y reduciendo la pérdida
25
de tiempo que conllevaría usar diferentes programas. Al mismo tiempo pienso que en el futuro
resultará interesante también para el sector hotelero ya que muchos de las tareas y necesidades
coinciden.
Para conseguir esto, tengo una clara ventaja como es mi experiencia en el sector turístico y la
capacidad de probar mi producto en vivo con la empresa de alquiler turístico para la cual estoy
desarrollado la aplicación, que será de gran ayuda para cumplir objetivos, conocer aciertos y
errores y así llegar a la meta propuesta.
Este conocimiento del mercado me permite tener además una puerta de entrada para poder
distribuir mi producto y comercializarlo ya que espero en un futuro no muy lejano poder ofrecer
este mismo servicio, con sus mejoras, a otras entidades. Llegado ese momento, convendrá hacer
una buena campaña de marketing online para dar a conocer la aplicación.
Hablando de los clientes, a los cuáles están orientados mis esfuerzos en esta aplicación tenemos,
en un primer nivel, la agencia de alquiler vacacional a la cual está orientada la aplicación, y como
segunda estancia, los clientes de la aplicación serían los usuarios que desean reservar un
alojamiento y contratar algún servicio ofrecido por la empresa de alquiler de alojamientos, los
usuarios propietarios que quieren ofrecer su alojamiento en alquiler desde la plataforma y que
sea la empresa de alquiler quien lo gestione y, por último, los usuarios que deben gestionar esta
aplicación para la empresa de gestión de alquileres de temporada.
2.3. Análisis de riesgos
El propósito de este apartado es nombrar los posibles problemas y riesgos que puedan surgir
durante el desarrollo del proyecto y cómo podemos minimizar el riesgo o qué planes de
contingencia tenemos respecto a ellos.
Voy a categorizar los riesgos en seis grupos específicos y un séptimo grupo para aquellos posibles
riesgos que no puedan ser abarcados por estos. Los grupos son: la tecnología, personas,
organización, herramientas, requerimientos, estimaciones y, el último, otros. En total, siete
como marca la plantilla para identificar riesgos del Estado [17].
Tabla 1. Posibles riesgos
TIPO DE RIESGO POSIBLE RIESGO
TECNOLOGÍA Caída del servidor Fuga de datos por hackeo o fallo del servidor Pérdida de información y datos por error en backup Fallo del software utilizado
26
Incapacidad de obtención de las tecnologías necesarias para desarrollar el proyecto Pérdida de la base de datos o inconsistencias en ella Fallos de seguridad Olvido o pérdida de contraseñas Virus informático que corrompe el código o el hardware. Corrupción involuntaria de código, datos o software
PERSONAS Enfermedad de corta duración Enfermedad de larga duración Aparición de un empleo incompatible Desmotivación por metas inalcanzables Fallecimiento Pérdida del tutor por motivos ajenos al proyecto
ORGANIZACIÓN Incumplimiento de fechas Cambios en los objetivos iniciales Falta de previsión de la complejidad de las tareas Incorrecta jerarquizan de las tareas Problemas para concretar o cumplir las reuniones con el tutor
HERRAMIENTAS Roturas de los equipos con que se trabaja Pérdida del repositorio del código Modificación en los términos de uso del lenguaje usado o software Problemas de uso de Git Falta de conocimiento sobre el uso de las herramientas o tecnologías.
REQUERIMIENTOS Cambios tardíos en los requerimientos funcionales Cambios tardíos en los requerimientos no funcionales La aplicación es modificada para ajustarse mejor a la visión del cliente en las diferentes fases del desarrollo Se modifican los objetivos de la aplicación No se llegan a cumplir todos los requerimientos
ESTIMACIONES Planificación no realista Mala asignación de tareas por etapa Preferencias mal establecidas Retrasos en tareas No considerar algún riesgo No cumplir finalmente una tarea
OTROS Cambios en la estructura del TFG Problemas con los suministros: cortes de luz, caída de la red, etc. Desastres naturales y acontecimientos inesperados.
Los comentados anteriores [Tabla 1. Posibles riesgos] son los riesgos que considero que pueden
hacer peligrar el proyecto y, de los cuales hay que valorar su incidencia sobre el proyecto. Con
este fin asignaré una puntuación del 1 al 5 a cada tipo de riesgo para señalar la probabilidad de
ocurrencia y también del 1 al 5 para indicar qué efectos tendrían dichos riesgos sobre el
proyecto.
27
Tabla 2. Posibles riesgos por la Tecnología
Posible riesgo a causa de la tecnología Probabilidad Efecto
Caída del servidor 4 2
Olvido o pérdida de contraseñas 4 1
Fuga de datos por hackeo o fallo del servidor 3 5
Pérdida de la base de datos o inconsistencias en ella 3 5
Pérdida de información y datos por error en backup 3 5
Fallos de seguridad 3 5
Corrupción involuntaria de código, datos o software 2 5
Incapacidad de obtención de las tecnologías necesarias para desarrollar el proyecto
1 4
Virus informático que corrompe el código o el hardware. 1 3
Fallo del software utilizado 1 2
Tabla 3. Posibles riesgos por las personas
Posible riesgo a causa de las personas Probabilidad Efecto
Enfermedad de corta duración 5 1
Desmotivación por metas inalcanzables 4 2
Fallecimiento 3 5
Aparición de un empleo incompatible 3 3
Enfermedad de larga duración 2 4
Pérdida del tutor por motivos ajenos al proyecto 1 5
Tabla 4. Posibles riesgos por la organización
Posible riesgo a causa de la organización Probabilidad Efecto
Falta de previsión de la complejidad de las tareas 4 3
Incorrecta jerarquizan de las tareas 4 3
Cambios en los objetivos iniciales 4 2
Incumplimiento de fechas 3 4
Problemas para concretar o cumplir las reuniones con el tutor 2 3
Tabla 5. Posibles riesgos por las herramientas
Posible riesgo a causa de las herramientas Probabilidad Efecto
Falta de conocimiento sobre el uso de las herramientas o tecnologías.
4 2
Pérdida del repositorio del código 2 5
Modificación en los términos de uso del lenguaje usado o software
2 4
28
Roturas de los equipos con que se trabaja 2 4
Problemas de uso de Git 2 3
Tabla 6. Posibles riesgos por los requerimientos
Posible riesgo a causa de los requerimientos Probabilidad Efecto
Cambios tardíos en los requerimientos funcionales 5 2
Cambios tardíos en los requerimientos no funcionales 5 1
La aplicación es modificada para ajustarse mejor a la visión del cliente en las diferentes fases del desarrollo
4 3
Se modifican los objetivos de la aplicación 4 2
No se llegan a cumplir todos los requerimientos 2 4
Tabla 7. Posibles riesgos por las estimaciones
Posible riesgo a causa de las estimaciones Probabilidad Efecto
Planificación no realista 3 4
Mala asignación de tareas por etapa 2 3
Preferencias mal establecidas 2 3
Retrasos en tareas 4 2
No considerar algún riesgo 5 3
No cumplir finalmente una tarea 2 4
Tabla 8. Posibles riesgos por otros supuestos
Posible riesgo a causa de otros supuestos Probabilidad Efecto
Cambios en la estructura del TFG 1 4
Problemas con los suministros: cortes de luz, caída de la red, etc.
3 2
Desastres naturales y acontecimientos inesperados. 1 5
En estas tablas [Tabla 2. Posibles riesgos por la Tecnología, Tabla 3. Posibles riesgos por las
personas, Tabla 4. Posibles riesgos por la organización, Tabla 5. Posibles riesgos por las
herramientas, Tabla 6. Posibles riesgos por los requerimientos, Tabla 7. Posibles riesgos por las
estimaciones y Tabla 8. Posibles riesgos por otros supuestos] podemos comprobar los efectos y
la probabilidad que tendría cada posible riesgo. Como más destacados por área está la posible
fuga de datos o pérdida de ellos en el área tecnológica lo que causaría un gran daño a la imagen
de la aplicación como lo haría una investigación de si todos los procedimientos han sido
correctos para intentar reducir al máximo este riesgo y de no ser así provocaría multas elevadas.
Otro riesgo por evitar es la pérdida del código del producto o su corrupción en los repositorios
de almacenamiento ya que esto haría inviable la finalización del proyecto y tendría que volver a
29
empezar. Por último, quedaría planificar cómo prevenir los riesgos o minimizarlos y, en el caso
de no ser posibles estas actuaciones, sería necesario identificar cuál sería su plan de
contingencia.
Tabla 9. Riesgo y acciones para superarlo
Riesgo Acciones
Caída del servidor Prevención: Disponer de un VPS (virtual private server) que nos
permita que pueda soportar el tráfico de la aplicación.
Minimización: Contratar servicio de mantenimiento de tu servidor
para que se solucione en el menor plazo posible.
Plan de Contingencia: Tener un servidor B que pueda suplir la caída
del servidor A.
Olvido o pérdida de
contraseñas
Prevención: Tener un repositorio de password como seria KeePass y
tenerlas organizadas.
Plan de Contingencia: En caso de ser contraseñas de servidor y
puertos de acceso, ponerse en contacto con el administrador del
sistema, en este caso, del servidor. Si, por el contrario, se trata de
contraseñas de acceso a plataformas web, solicitar un cambio de
contraseña mediante un doble factor e informar al equipo.
Fuga de datos por
hackeo o fallo del
servidor
Prevención: Informarse de la política de protección de datos
adecuadamente y realizar un cifrado de datos adecuado para cada
situación.
Plan de Contingencia: Recurrir a los profesores y, en caso extremo,
acudir a un especialista que pueda asesorarme para obtener la mejor
solución.
Pérdida de la base
de datos o
inconsistencias en
ella
Prevención: Tener actualizada la seguridad propia del servidor.
Minimización: Seguir la estrategia de copias de seguridad, no tener la
información alojada en un único servidor y cambiar contraseñas y
accesos de manera periódica.
Plan de Contingencia: Recurrir a otro servidor para recuperar la
información posible e intentar recuperar la información perdida
mediante las copias de seguridad previamente realizadas.
Pérdida de
información y datos
por error en Back-up
Prevención: Hacer un uso adecuado de las operaciones relacionadas
con la BD.
30
Minimización: Seguir una estrategia de copias de seguridad en la BD
de manera periódica.
Plan de Contingencia: Recurrir a las copias de seguridad para
recuperar la información perdida.
Fallos de seguridad Prevención: Instalar y comprobar todas las medidas de seguridad en
todos los servidores. También conviene cambiar las contraseñas de
manera periódica en las diferentes aplicaciones usadas.
Plan de Contingencia: Pedir disculpas a los posibles afectados,
investigar el nivel de incidencia del fallo y analizar las soluciones.
Modificar contraseñas y keys para prevenir problemas.
Corrupción
involuntaria de
código, datos o
software
Minimización: Seguir el plan detallado de copias de seguridad, así
como la recuperación posterior de alguno de los archivos para
asegurar el buen funcionamiento de esta.
Plan de Contingencia: Recurrir a las copias de seguridad para obtener
el archivo más reciente que no haya corrompido.
Incapacidad de
obtención de las
tecnologías
necesarias para
desarrollar el
proyecto
Prevención: Utilizar tecnologías de software libre.
Minimización: Pagar por aquellas tecnólogas lo acordado.
Plan de Contingencia: Buscar otras que puedan hacer la misma
función o parecida y adaptarlas.
Virus informático
que corrompe el
código o el
hardware.
Prevención: Evitar el acceso a páginas peligrosas mediante el equipo
personal, así como tener instalado y actualizado un antivirus de
confianza.
Minimización: Realizar copias de seguridad periódicamente del
ordenador personal.
Plan de Contingencia: Utilizar antivirus y procedimientos para
detectar el virus y eliminar los daños causados. En caso de no poder
solucionarlo, acudir urgentemente a un especialista.
Fallo del software
utilizado
Prevención: Estudiar en los foros y documentaciones los problemas
que pueden tener el software usado y elegirlo en consecuencia.
Minimización: Intentar trabajar con las versiones estables
recomendadas y actualizas.
Plan de Contingencia: Decidir si cambiar a otro software.
31
Enfermedad de corta
duración
Prevención: Intentar no estar en situaciones que puedan influir en
este tipo de problemas.
Minimización: Documentar los avances periódicamente para que
cuando se reanude el desarrollo no se pierda tiempo investigando
qué se había hecho.
Plan de Contingencia: Intentar avanzar en el proyecto a un menor
ritmo durante ese periodo.
Desmotivación por
metas inalcanzables
Prevención: Intentar que las metas sean realistas y que se vean
resultados de progreso diarios.
Minimización: Hacer que las tareas de los sprint sean cortas y que se
vea como avanza el proyecto de forma clara.
Fallecimiento Prevención: No tentar a la suerte.
Minimización: No tentar a la suerte.
Plan de Contingencia: No hay.
Aparición de un
empleo incompatible
Prevención: Si se tiene reuniones para búsqueda de empleo informar
de la situación en la reunión.
Minimización: Trabajar en las horas libres que se disponga.
Enfermedad de larga
duración
Prevención: Intentar no estar en situaciones que puedan influir en
este tipo de problemas.
Minimización: Documentar los avances periódicamente para que
cuando se reanude el desarrollo no se pierda tiempo investigando
qué se había hecho.
Plan de Contingencia: Pensar posible cambio de fecha de entrega del
proyecto acorde con los implicados.
Pérdida del tutor por
motivos ajenos al
proyecto
Plan de Contingencia: Solicitar la asignación de otro tutor y cambiar
la previsión de entrega del proyecto.
Falta de previsión de
la complejidad de las
tareas
Prevención: Analizar profundamente todos los objetivos y
funcionalidades requeridas para hacer una buena catalogación de las
tareas que se desarrollaran en el proyecto.
Minimización: Ajustar en la planificación esta tarea y todas aquellas
que puedan estar relacionadas para hacer una mejor previsión del
futuro.
32
Plan de Contingencia: Dejar más tiempo por fase y sprint para
posibles problemas de complejidad y mala evaluación de tareas.
Incorrecta
jerarquización de las
tareas
Prevención: Analizar profundamente todos los objetivos y
funcionalidades requeridas para hacer una buena catalogación de las
tareas que se desarrollaran en el proyecto.
Minimización: Reordenar las tareas según la nueva información para
la próxima fase.
Plan de Contingencia: Dejar más tiempo por fase y sprint para
posibles problemas de complejidad y mala evaluación de tareas.
Cambios en los
objetivos iniciales
Prevención: Hacer reuniones con los clientes para dejar claros los
objetivos y no empezar el proyecto hasta que esté todo claro.
Minimización: Reuniones periódicas para ver el avance de este y
poder modificar la ruta del proyecto para alcanzar los nuevos
objetivos.
Plan de Contingencia: Dejar en la planificación tiempo sobrante para
poder modificar este tipo de aspectos del proyecto.
Incumplimiento de
fechas
Prevención: Una correcta planificación de las tareas a realizar.
Minimización: Dejar más tiempo por fase y tarea.
Plan de Contingencia: Si no se llega a la fecha deseada de entrega se
tendría que pensar en un cambio de la entrega del TFG o realizar las
últimas semanas en Crunch para poder llegar a la meta a tiempo (No
recomendable).
Problemas para
concretar o cumplir
las reuniones con el
tutor
Prevención: Buscar fechas que ambos puedan asistir.
Plan de Contingencia: Cambiarla de fecha u hora a una que les venga
bien a todas las partes implicadas.
Falta de
conocimiento sobre
el uso de las
herramientas o
tecnologías.
Prevención: Utilizar tecnologías ya conocidas o estudiar sobre el uso
de ellas.
Minimización: Planificar un tiempo en el proyecto que solo sea
asignado a formación del desarrollador.
Pérdida del
repositorio del
código
Prevención: Utilizar de manera adecuada el repositorio digital.
Minimización: Seguir la estrategia de copias de seguridad y cambiar
contraseñas de manera periódica.
33
Plan de Contingencia: En caso de haber copias de seguridad, recurrir
a estas. Si no hubiera copias, intentar recuperar versiones locales.
Modificación en los
términos de uso del
lenguaje usado o
software
Prevención: Tener claro las licencias de software e intentar usar
licencias que den garantías.
Minimización: Si cambiara una licencia de uso estudiar si la aplicación
cumple con su uso.
Plan de Contingencia: Cambiar a un software que sea más amigable.
Roturas de los
equipos con que se
trabaja
Prevención: Realizar un uso y mantenimiento adecuado de los
equipos. No depositar líquidos cerca del equipo ni dejarlo de manera
prolongada expuesto a altas temperaturas.
Minimización: Revisar de manera periódica los elementos de
hardware propensos a averías.
Plan de Contingencia: Solicitar reparación lo antes posible y buscar
un equipo alternativo.
Problemas de uso de
Git
Prevención: Realizar un uso adecuado de la herramienta Git.
Minimización: Hacer copias de seguridad locales en cada uno de los
equipos (no solo disponer de las versiones en el repositorio).
Plan de Contingencia: Recurrir a las copias de seguridad locales. En
caso de no haberlas, intentar obtener los archivos perdidos a través
de otros medios. Si no se pueden recuperar, obtener la versión
anterior a la perdida e intentar recomponerla.
Cambios tardíos en
los requerimientos
funcionales
Prevención: Acordar y detallar exhaustivamente todas las
funcionalidades del proyecto junto a los clientes.
Plan de Contingencia: Analizar la repercusión de dicho cambio en el
proyecto y valorar el tiempo disponible, así como todos los cambios
que provocaría. En caso de realizar el cambio, ajustar la planificación
y, en caso necesario, prescindir de otras tareas menos relevantes.
Cambios tardíos en
los requerimientos
no funcionales
Prevención: Acordar y detallar exhaustivamente todas las
funcionalidades del proyecto junto a los clientes.
Plan de Contingencia: Analizar la repercusión de dicho cambio en el
proyecto y valorar el tiempo disponible, así como todos los cambios
que provocaría. En caso de realizar el cambio, ajustar la planificación
y, en caso necesario, prescindir de otras tareas menos relevantes.
34
La aplicación es
modificada para
ajustarse mejor a la
visión del cliente en
las diferentes fases
del desarrollo
Prevención: Concertar reuniones directamente con el cliente para
obtener el mayor feedback posible a partir de cada uno de los avances
del proyecto (mockups, interfaces, prototipo de aplicación, etc.).
Plan de Contingencia: Detallar profundamente en un informe las
partes y funcionalidades del proyecto que no se ajustan, por qué y
cómo podrían solucionarse. A partir de ese informe, priorizar las
tareas a corregir, repartirlas y corregir de más importantes a menos
hasta el deadline.
Se modifican los
objetivos de la
aplicación
Prevención: Acordar y detallar exhaustivamente los objetivos del
proyecto junto a los clientes.
Plan de Contingencia: Analizar la repercusión de dicho cambio en el
proyecto y valorar el tiempo disponible, así como todos los cambios
que provocaría. En caso de realizar el cambio, ajustar la planificación
y, en caso necesario, prescindir de otras tareas menos relevantes.
No se llegan a
cumplir todos los
requerimientos
Prevención: Cuando se realice el análisis de requisitos, procurar hacer
que sean reales para el periodo de tiempo disponible y dejar los otros
para la futura implementación.
Planificación no
realista
Prevención: Sumar las horas asignadas a cada miembro del equipo
por iteración y comprobar que es viable. Tener en cuenta si algún
miembro del equipo trabaja, o si no puede dedicar el 100% de su
tiempo al ABP.
Minimización: Investigar las horas necesarias para la realización de
cada una de las tareas. Tener en cuenta las tareas retrasadas, así
como posibles días festivos, rendimiento de los miembros del equipo
o participación en otro tipo de proyectos.
Plan de Contingencia: Reajustar tareas o horas asignadas, así como
porcentaje de realización. En caso de no poder cumplir con las
deadlines, retrasar la tarea a una siguiente iteración.
Mala asignación de
tareas por etapa
Prevención: Un buen análisis de las tareas para hacer una buena
planificación temporal del proyecto.
Minimización: Intentar cumplir con los plazos y, si no se consigue,
ajustar los tiempos en la siguiente fase.
Preferencias mal
establecidas
Prevención: Hacer el mayor número de reuniones posibles con los
clientes antes de realizar el proyecto para que todos tengan claro qué
35
se quiere conseguir durante el proyecto y qué se dejara para más
adelante.
Minimización: Reuniones periódicas con los clientes para enseñar los
avances y tener claro que ese es el rumbo deseado.
Retrasos en tareas Prevención: Cada vez que se planifica una nueva fase, revisar las
tareas que se quieran realizar en esta y las dependencias de éstas, así
como establecer una reunión al comienzo de cada fase o sprint con
los diferentes miembros del proyecto (desarrollador y clientes) para
que sean conocedores de las tareas y la importancia de cada una de
ellas.
Minimización: Revisar las tareas repartidas y asignadas, así como la
correcta realización de estas.
Plan de Contingencia: Hacer un análisis de la importancia de dicha
tarea para poder ajustar la planificación e introducirla lo antes
posible. En caso de ser necesario, descartar tareas de menor
importancia y dar prioridad a la tarea olvidada.
No considerar algún
riesgo
Prevención: Intentar hacer el mayor análisis de riesgo posible.
Minimización: Si sucede algo fuero de lo esperado, pedir consejo y
valorarlo para el futuro.
Plan de Contingencia: Analizar las incidencias del riesgo y valorar
cómo avanzar si realizado el proyecto en base al fallo o aplazarlo en
el tiempo para corregirlo.
No cumplir
finalmente una tarea
Prevención: Todas las tareas estarán bien catalogadas y evaluadas
para que se puedan cumplir en el periodo planificado.
Minimización: Intentar que no sea de carácter funcional.
Plan de Contingencia: Incluir en las tareas de continuación y mejora
del proyecto y analizar por qué no se ha conseguido realizar durante
el desarrollo del proyecto.
Cambios en la
estructura del TFG
Prevención: Leer las normativas de la universidad de Alicante y de la
escuela politécnica superior sobre los TFG y las directrices del grado
en ingeniería multimedia.
Plan de Contingencia: Si se cambian durante la realización del
proyecto, analizar si dispongo de suficiente tiempo para adaptarme
al nuevo modelo o aplazar la entrega a la siguiente convocatoria.
36
Problemas con los
suministros: cortes
de luz, caída de la
red, etc.
Plan de Contingencia: Disponer de SAIs y otras formas de suministro
de red para prevenir las posibles incidencias y no perder la
información con la que se trabaja. Cambiar de lugar de trabajo
durante el tiempo que transcurre la incidencia.
Desastres naturales y
acontecimientos
inesperados.
Minimización: Desconectar los equipos de la red eléctrica en la
medida de lo posible. Tener las copias de seguridad alojadas en
diferentes lugares.
Plan de Contingencia: Según la gravedad del desastre natural,
plantear el cambio geográfico del equipo para seguir trabajando en
otro lugar no afectado por dicho desastre.
Por último, en la tabla anterior [Tabla 9. Riesgo y acciones para superarlo] podemos ver cómo
enfrontaría todas las incidencias que he considerado posibles durante el desarrollo del proyecto
para así reducir al máximo los posibles problemas y terminarlo con éxito.
37
3. Planificación y Metodología
Considerando que uno de los factores más importantes para la planificación del proyecto es la
metodología usada, he optado por unir ambos aspectos en un mismo punto.
Para el desarrollo del proyecto he pensado en basarme en un desarrollo ágil (Agile) [25] ya que
es el más usado últimamente en el mundo laboral y el que nosotros hemos usado en la carrera.
En 2001 varios desarrolladores crearon un manifiesto sobre las técnicas y buen uso del
desarrollo ágil [23] con doce principios que lo definen. Yo resaltaría cuatro ideas principales, que
son la motivación en el proyecto, la creación de demos continuos, la capacidad de modificar los
requisitos en cualquier momento y la comunicación entre todas las partes implicadas en el
proyecto.
Para adherirme a estos estándares y valores tengo que elegir una metodología que me permita
tener un marco con el que avanzar utilizando estos factores entre las posibles metodologías,
entre las cuales, en mi opinión, la óptima es Scrum [24] o una adaptación personalizada de ésta,
dándole énfasis al proceso interactivo y a la consecución de demos para mi proyecto.
La metodología Scrum se basa en el desarrollo ágil de software y su parte fundamental son los
sprints. Estos son los periodos en los cuales se deben finalizar las tareas. Se trata de periodos
cortos de tiempo, donde los integrantes de un equipo deben finalizar las tareas para esa etapa
concreta. En mi caso, se trata de una adaptación ya que es un proyecto individual, pero no se
puede obviar que, aunque no sean desarrollador son miembros del equipo mi tutor y el
coordinador de la empresa a la que va dirigido el proyecto.
Además del trabajo en sprints, también forma parte fundamental de la metodología las
reuniones. En una primera reunión se deben definir los objetivos y las funcionalidades
principales que debe tener la aplicación. En esta reunión también se deciden las tareas del
primer sprint y se definen los criterios que nos permitan evaluar los sprints para confirmar si
estos se desarrollan correctamente y cumplen con el funcionamiento esperado.
Como hemos comentado, Scrum, aparte de tener el sistema de intervalos (sprints) y tareas,
también dispone de cuatro tipos de reuniones. La primera de ellas es la Daily Meeting, que es lo
primero que se realiza cada día. Esta se hace para que el equipo de desarrollo pueda ponerse al
día con las tareas realizadas y así saber de los posibles problemas encontrados y sus soluciones.
38
Las reuniones de Planning Meeting se realizan al principio de cada sprint para determinar las
posibles nuevas funcionalidades y para organizar las tareas del próximo sprint, la fecha de
finalización del sprint y sus objetivos. En esta reunión está presente tanto el equipo de desarrollo
como el cliente. Dentro del Planning Meeting también se habrán contemplado unas fechas para
otro tipo de reuniones donde se puede ver el producto en funcionamiento en la etapa que
corresponde. Esas reuniones se llaman “Demo”. Normalmente están ubicadas al final de cada
sprint. Van dirigidas a todos los interesados en el producto y su objetivo es obtener feedback de
los clientes y de la dirección del equipo sobre el producto en este sprint.
Por último, está la reunión Retrospective Meeting, pensada para mejorar la gestión del
desarrollo del proyecto y en la que vuelve a participar tanto el equipo de desarrollo como los
clientes. De la reunión sale un listado con las mejoras para el proceso de desarrollo y cómo
aplicarlo para incrementar los resultados y aumentar el ritmo de trabajo. El listado se obtiene
con las aportaciones de los miembros del equipo de desarrollo de ese sprint, eligiéndose las que
el equipo en conjunto crea que son más ventajosas para el próximo sprint.
Como podemos observar, la gran ventaja de Scrum es que en esta metodología no solo se
involucra al equipo de desarrollo sino también al cliente. Además de la ventaja comentada
también va unida a una planificación por etapas y tareas, que se realizan de forma individual por
cada miembro del grupo, que nos propone realizar un desarrollo rápido y flexible,
permitiéndonos adaptarnos a las posibles modificaciones de los requisitos y obtener muestras
de la aplicación visibles en periodos de tiempo menor.
Mi proyecto está pensado para ser entregado en la convocatoria C1 de enero 2020 y empezó en
febrero del año 2019. Uno de los principales motivos de demorarlo tanto en el tiempo era
porque a la vez de estar desarrollándolo, trabajaba, y temía no poner plazos realistas para las
distintas fases del proyecto por si al final no podía cumplir con las fechas propuestas.
He dividido el proyecto en tres fases y aplico el modelo de desarrollo ágil Scrum con las
adaptaciones pertinentes a las características propias de desarrollo de mi proyecto personal ya
que se trata de un desarrollo individual, existen dos clientes (uno que sería el propio tribunal del
TFG y el otro la empresa de alquiler vacacional a la cual va orientada mi propuesta de trabajo)
y, por último, comparto la dirección y gestión del proyecto con mi tutor.
En la Tabla 10 podemos observar la planificación temporal inicial con las tres fases de desarrollo
señalando las partes que debería tener cada fase y qué es lo que quiero realizar en ellas durante
el desarrollo del proyecto.
39
Tabla 10. Planificación inicial del Proyecto TFG
Contenidos Tiempo total Fecha límite fin
Fase 1: primeras ideas, formación y tecnologías 4 meses 19 mayo 2019
Fase 2: bocetos, definiciones e implementaciones 7 meses 3 noviembre 2019
Fase 3: implementaciones, pruebas y resultados 3 meses 13 enero 2020
La primera fase de la planificación consiste en la concreción de la idea a poner en marcha y la
selección de las tecnologías que voy a usar. También, se ha dedicado parte de esta fase a
aprender sobre estas tecnologías realizando cursos de formación. La Figura 5 nos muestra la
temporalización de la fase 1 del proyecto.
Figura 5. Tareas y tiempo en la primera fase (Fuente propia, elaborado con everhour.com [18])
En esta primera fase no he seguido del todo el
modelo Scrum ya que he invertido gran parte de los primeros cuatro meses en formarme en las
tecnologías que iba a utilizar para el desarrollo del proyecto y en la puesta a punto del entorno
% Tiempo del TAG
#Aprendizaje #Desarrollo
#Documentación #Punto 0
#Punto 1 #Punto 12
#Punto 13 #Reuniones
Figura 3. Categorías por tiempo en la primera fase
(Fuente propia, elaborado con everhour.com [18])
Figura 4. Horas Trabajo por mes
(Fuente propia, elaborado con everhour.com [18])
40
de trabajo con la instalación de un nuevo lenguaje (DART) y sus complementos, así como de las
herramientas necesarias para llevarlo todo a cabo en los diferentes sistemas operativos que son
objetivo. Al mismo tiempo he tenido que configurar un servidor http, primero en local para
pruebas y luego online. Por otra parte, sí que he realizado tanto las Planning Meeting con el
cliente y el tutor como las Daily Meeting, de manera individual, para estructurar qué es lo que
debía estudiar cada día. En la Figura 5 se detallan las tareas realizadas durante esta primera fase,
mientras que la Figura 4 muestra las horas de trabajo invertidas cada mes y la Figura 3 de
acuerdo a los tags (“etiquetas”, en inglés) asignadas a cada tarea.
Figura 6. Tareas y tiempo segunda fase proyecto (Fuente propia, elaborado con everhour.com [18])
Una vez ya con la idea clara y con los conocimientos suficientes para iniciar el proyecto, empecé
la Fase 2, la cual está totalmente desarrollada en Scrum. Esta segunda fase la he orientado a la
documentación de la memoria y al análisis del proyecto. Además, empiezo en ella la
implementación de pequeñas partes del proyecto. En la Figura 6 se muestra la planificación de
esta segunda fase para su comparación con el ritmo real de las tareas.
El primer sprint de la Fase 2 dura un mes, en el cual realizo el estudio del mercado y, mediante
reuniones con el tutor y el cliente, se determinan las funcionalidades básicas del proyecto y sus
especificaciones. También realizamos la Planning Meeting en la cual planifico los siguientes
41
sprints de esta fase. En la Figura 7, Figura 9, Figura 8 se detallan las tareas realizadas durante
esta segunda fase en cada uno de sus Sprints, En la Figura 11 se concreta las horas de trabajo
por mes, mientras que la Figura 10 las muestra de acuerdo a las tags asignadas.
Figura 8. Tercer Sprint F2 (Fuente propia, elaborado con everhour.com [18])
Figura 7. Primer Sprint F2 (Fuente propia, elaborado con everhour.com [18])
Figura 9. Segundo Sprint F2 (Fuente propia, elaborado con everhour.com [18])
42
En el segundo sprint, empecé con los bocetos de la aplicación y continué escribiendo parte de la
memoria. En estos momentos realizo los primeros bocetos del diseño de la aplicación, el diseño
de la base de datos y el diseño de la estructura de la API. En el tercer Sprint terminé todos los
bocetos y continué con la implementación de la API y por último creé un pequeño demo que
respondía a las llamadas de la API.
Los sprint 2 y 3 coincidieron con los meses de julio y agosto, meses que bajé el ritmo y utilicé
para mis vacaciones personales coincidiendo con las de mi empleo.
Finalizado el tercer sprint hice una Demo Meeting con el tutor y la Planning Meeting de la
siguiente fase. En esta quería implementar la parte del host y del guest de mi aplicación para el
demo final y disponer de tiempo para subsanar posibles errores en caso necesario.
% Tiempo por TAG
#Api #Desarrollo
#Documentación #Fluter
#Punto 0 #Punto 2: Estudio de viabilidad
#Punto 3 #Punto 5
#Punto 6 #Punto 7: Diseño
#Punto 8: Implementación #YeiGateway
#YeiPMS
Figura 10. Porcentaje de tiempo trabajado por tag F2 (Fuente propia, elaborado con everhour.com [18])
% Tiempo por TAG
#Desarrollo #Documentación
#Flutter #Guest
#Host #Punto 8: Implementación
Figura 12. Porcentaje de tipo por tag en F3 (Fuente propia, elaborado con everhour.com [18])
0,00
20,00
40,00
60,00
80,00
100,00
120,00
140,00
160,00
Noviembre Diciembre
Horas de trabajo por mes
Figura 13. Horas trabajadas mes F3 (Fuente propia, elaborado con everhour.com [18])
Figura 11. Horas trabajadas por mes F2 (Fuente propia, elaborado con everhour.com [18])
43
Figura 14. Tareas y tiempo de la tercera fase (Fuente propia, elaborado con everhour.com [18])
Igualmente, en la Figura 14 se puede ver la planificación temporal de la Fase 3 y el tiempo
aplicado en cada tarea. Como se puede ver el periodo de tiempo de esta tercera fase ha sido
mucho menor pero el número de horas invertidas en él es igual o incluso mayor. Esta última fase
se pensó como un gran sprint de un mes y medio donde terminar el desarrollo de la aplicación
y realizar las pruebas pertinentes. Además, como de antemano no se conocía la fecha exacta de
entrega del proyecto, dejé un periodo de tiempo libre al final de la fase para mejoras del
proyecto o modificar y completar la documentación. Por último, en la Figura 13 y la Figura 12
44
podemos ver, como en las anteriores fases, el trabajo realizado por mes y el tiempo invertido
por etiqueta, las cuales equivalen a los apartados de este TFG de esta fase tres.
Para concluir, quiero comentar que el proyecto me ha supuesto más de 500 horas, muchas de
las cuales fueron de formación y de reuniones con el cliente y tutor. También estuve mucho
tiempo documentando el proyecto, haciendo bocetos de todo lo que quería decir, dibujando
cómo quería que fuera la Arquitectura, la API y el Interfaz, entre otras cosas. Creo que realizar
la planificación e intentar desarrollarla como también sintetizarla después aquí me ha servido
de mucha ayuda para poder tener una visión global para posibles nuevos proyectos y para la
continuación de este en su parte comercial.
Después de estas últimas figuras (Figura 16y Figura 15) solo me quedaría añadir que he realizado
unas 73 tareas en un plazo de 500 horas y 11 meses.
% Tiempo por TAG
#Api #Aprendizaje
#Desarrollo #Documentación
#Fluter #Flutter
#Guest #Host
#Punto 0 #Punto 1
#Punto 12 #Punto 13
#Punto 2: Estudio de viabilidad #Punto 3
#Punto 5 #Punto 6
#Punto 7: Diseño #Punto 8: Implementación
#Reuniones #YeiGateway
#YeiPMS
Figura 15. Porcentaje de tiempo por TAG (Fuente propia, elaborado con everhour.com [18])
Tiempo por mes
Febrero Marzo
Abril Mayo
Junio Julio
Agosto Septiembre
Octubre Noviembre
Diciembre
Figura 16. Tiempo por mes proyecto (Fuente propia, elaborado con everhour.com [18])
45
4. Estado del arte.
Al igual que internet y los avances tecnológicos han cambiado nuestras vidas, no cabe duda de
que estos han supuesto una revolución en el sector turístico, ya que, además de facilitar las
tareas de administración y gestión, han transformado de manera radical el sistema de
distribución y comercialización, multiplicando de forma exponencial las oportunidades y
creando un entorno que facilita al cliente final el acceso a la contratación directa [11].
Encontramos en Internet inagotables ejemplos e información sobre la influencia y efectos de la
web en el sector. Por ejemplo, resultan relevantes para este proyecto las reflexiones del
Observatorio eCommerce del análisis de Webloyalty, lider internacional en la creación y
desarrollo de estrategias online, sobre el impacto de internet en el sector turismo [12] o el
artículo sobre turismo y tecnología de la prestigiosa Agencia de Marketing Digital WAM (We are
Marketing) del pasado 5 de diciembre de 2019 [13], que hace referencia también a las últimas
tecnologías que ya empiezan a influir y serán cruciales en el futuro. En la primera columna de la
siguiente tabla [Tabla 11. Repercusiones de las tecnologías en la gestión de alojamientos ] cito
las observaciones que destaco de ambos artículos, mientras que en la segunda columna
establezco su conexión con la aplicación desarrollada en mi proyecto.
Tabla 11. Repercusiones de las tecnologías en la gestión de alojamientos turísticos
Observaciones sobre el impacto de Internet
en el sector turismo
Repercusiones en la creación de una
aplicación para la gestión de alojamientos
turísticos
Internet es la mayor fuente de información
para inspirarse, buscar y planificar tanto
viajes de ocio como de negocio. Se destaca la
función de los blogs y las redes sociales. [12]
La aplicación debe ser fuente de inspiración
(atraer hacia el producto: marketing), facilitar
la información y la organización a los usuarios
y ser accesible desde las redes sociales.
El 75% de los viajeros reserva sus vacaciones
a través de canales online,
independientemente de sus conocimientos
digitales. [12]
Ha de ser fácil de usar y ser visible, ofertarse
y sincronizarse en multitud de canales (inter-
y multicanalidad)
Los principales motivos por los que el
consumidor acude al canal online para
reservar sus vacaciones son el precio y la
facilidad en la reserva. [12]
La aplicación debe facilitar a la empresa
gestora del alquiler vacacional información
sobre los precios de sus competidores para
46
mejorar su oferta. También debe resultar
especialmente fácil realizar una reserva.
Con las nuevas tecnologías mejoran los
procesos, los servicios, la relación con el
cliente y la creación de nuevos modelos de
negocio. [12]
Desde la aplicación se podrá registrar
alojamientos, obtener información sobre
ellos, reservarlos, contratar un servicio,
comunicar una necesidad, etc. de forma
sencilla y rápida, adaptándose a la demanda
y buscando fidelizar clientes
El móvil se ha convertido en nuestro guía
turístico, agencia de viaje, localizador de los
mejores restaurantes, mapa, etc. Es por ello
que surge la necesidad de adaptar la
comunicación y servicios de la empresa a este
dispositivo. [13]
La aplicación ha de estar preparada para la
tecnología móvil, permitiendo realizar
multitud de acciones (búsqueda y análisis de
propiedades e información, comunicación
huésped-anfitrión o gestor, reserva, pago
online, envío/recepción de información sobre
la reserva, etc.) desde la misma aplicación sin
necesidad de cambiar de aplicación o portal.
Mejor, tiene que ser multidispositivo, de
manera que el usuario pueda interaccionar
desde su móvil, tableta u ordenador.
La realidad aumentada o realidad virtual
también se ha colado en el mundo del
turismo y, lo cierto es que, es una tendencia
al alza por todas las posibilidades que ofrece.
Hoy en día es posible “teletransportarse” a
los lugares más remotos del planeta sin
moverse del sofá. [13]
Además de ver las fotos y algún vídeo de un
alojamiento y la zona donde está ubicado, se
pretende que la aplicación en un futuro
próximo podrá ofrecer a sus usuarios
experimentar la sensación de una visita
virtual al lugar y sus alrededores.
El Internet de las Cosas (IoT) es una
tecnología que promete traer grandes
novedades al sector del turismo. De hecho, el
instituto Tecnológico Hotelero (ITH) aseguró
que el Internet de las Cosas “va a ser el mayor
factor de transformación en la
personalización de la experiencia del cliente
en los próximos años. [13]
Efectivamente, pronto está pensado
posibilitar el control del uso del aire
acondicionado y la calefacción desde Internet
o el acceso a los alojamientos sin llaves y
paulatinamente se pretende ir incorporando
nuevas funcionalidades a la aplicación que
tienen en cuenta esta tecnología.
47
Asistentes de voz: Los hoteles también
empiezan a contar con esta “ayuda” gracias a
la creación de asistentes de voz creados
específicamente para este entorno. IBM ha
lanzado hace poco Watson Assistant, un
asistente con Inteligencia Artificial que crea
una experiencia personalizada e interactiva
para los clientes. [13]
Se trata de otra útil función para un futuro
próximo de la aplicación ya que puede
resolver muchas de las preguntas frecuentes
de los huéspedes, normas de la casa,
pequeños consejos, sugerencias concretas
para cada alojamiento, ciudad y alrededores,
aligerando la tarea a los gestores o
anfitriones a la vez que contribuye a una
experiencia satisfactoria para los huéspedes.
Muchas empresas del sector turismo ya están
sacando partido del big data. Es el caso, por
ejemplo, de Meliá Hoteles que utiliza la
información de sus clientes para determinar
cuál es el target más adecuado para una
campaña. De este modo, consiguen
segmentar mejor sus campañas para
aumentar su éxito y optimizar la inversión.
[13]
Por supuesto, el uso de los datos manejados
en la aplicación es una prioridad para el éxito
del proyecto y rentabilizar los esfuerzos y la
inversión, siempre teniendo en cuenta la
normativa sobre protección de datos y la
privacidad de los usuarios.
El blockchain es una tecnología que promete
transformar el mundo tal y como lo
conocemos hoy en día. Se cree que podría ser
útil para la identificación de viajeros en el
aeropuerto, para garantizar la transparencia
en la opinión de los turistas o los pagos fáciles
y seguros. [13]
Todas estas funcionalidades son de gran
interés para el alquiler vacacional ya que hay
que identificar a los viajeros durante el check-
in y enviar los datos a las autoridades, el éxito
de las reservas y, por tanto, de la plataforma
depende en gran medida de las
La tecnología en el sector turístico se abre
paso de la mano de las redes 5G. Estas
prometen velocidades de carga y descarga
mucho más rápidas, coberturas más amplias
y conexiones mucho más estables. El 5G
permitirá el desarrollo e implementación de
tecnologías que estaban limitadas por el 4G.
[13]
Tan pronto como podamos disfrutar del 5G se
podrán aplicar fácilmente las funcionalidades
antes mencionadas de realidad virtual y el
Internet de las Cosas, así como nuevas
tecnologías que se desarrollen en el futuro.
48
Estas reflexiones nos permiten hacernos una idea más ajustada del tipo de aplicación que se
quiere llegar a desarrollar. Sin embargo, muchas de las funciones se acometerán en módulos y
fases posteriores. Ahora ha resultado necesario centrarse en la demanda inicial del cliente (la
empresa para la cual se desarrolla la aplicación y brinda la oportunidad práctica a este proyecto),
interesado en una aplicación donde alojar las propiedades de sus clientes, que facilite las
reservas y la gestión de las mismas así como la comunicación con los distintos intervinientes
(gestores, propietarios, huéspedes, personal de limpieza, etc.) y con un buscador propio que le
permita tener cada vez mayor independencia respecto a Booking, AirBnB y otras plataformas
para poder ser accesible no solo a posibles viajeros sino a más propietarios y en un futuro
próximo a otras empresas de gestión vacacional, hostales y hoteles.
Por otra parte, hay que tener en cuenta que existen multitud de canales y aplicaciones digitales
relacionadas con el alquiler vacacional y que continuamente aparecen nuevas aplicaciones y las
existentes adquieren nuevas funcionalidades. Por sintetizar la gran variedad de posibilidades
existentes en estos momentos, en la Tabla 12 se esquematiza la distinción ofrecida por Chekin
[14].
Tabla 12. Tipos de canales y aplicaciones para la gestión del alquiler vacacional
Canales Características
Metabuscadores Sistemas que buscan y seleccionan información según los criterios de
interés del usuario y facilitan en mayor o menor medida la conexión entre
huésped y el anfitrión, pero que no tienen motor de reserva propio. Incluye
plataformas como vibbo.com, yaencontre.com y milanuncios.com
(muchas de las cuales se dedican también al alquiler de larga duración, la
venta de inmuebles y otros productos, etc.)
Agencias de viaje
online
(OTAs, acrónimo en inglés de Online Travel Agency) Se trata de
plataformas que funcionan como las agencias de viajes tradicionales, pero
con la ventaja que ofrece la inmediatez de los canales digitales como
Booking o Expedia o webs tipo Airbnb.
Canales de gestión
de alojamientos
Son canales tipo Smoobu,
Guesty, Chekin o AvaiBook,
que cuentan con un PMS
(Property Management
System en inglés) y con un
Channel Manager.
El PMS o sistema de gestión de alojamientos
puede implementar multitud de funciones
necesarias para los gestores vacacionales
como son la gestión de tarifas y reservas,
supervisión de alojamientos y su
mantenimiento, disponibilidad, pagos,
49
facturación, análisis e informes, traslado de
datos a autoridades, etc.
El Channel Manager es una herramienta de
centralización de productos, la cual permitirá
al gestor gestionar todos los canales de
distribución desde una misma plataforma.
Conviene advertir que muchos de las plataformas existentes se están asociando con otros o
contratando usos de aplicaciones para poder atender la demanda de los usuarios (y no acabar
desapareciendo o siendo absorbidos por otros más potentes, situación nada infrecuente). Así,
rentalia.com, por ejemplo, para la gestión de pagos recurre a AvaiBook. En la Figura 17 podemos
observar el flujo de información del PMS mediante el Channel Manager a las distintas OTAs o
viceversa.
Frente a tanta variación y posibles combinaciones en continuo cambio choca la realidad
existente en mi localidad y en una zona tan importante como es la Costa Blanca, que incluye al
motor turístico a nivel nacional y referente mundial que es Benidorm. La industria hotelera se
mantiene fiel a software veterano por temor al cambio mientras que los anfitriones privados y
las pequeñas empresas de gestión vacacional apenas usan ninguna tecnología excepto los
metabuscadores y las OTAS, bien por desconocimiento o por desconfianza en las distintas
aplicaciones existentes. Cabe añadir que los canales de gestión de alojamientos son en su
mayoría de procedencia extranjera, y teniendo en cuenta que la aplicación se desarrolla para
una empresa concreta local y que en breve se pretende ampliar a otras de la zona, pienso que
puede ser una gran ventaja el hecho de que se trate de una herramienta autóctona, que tiene
en cuenta las necesidades de nuestro entorno y que trasmite confianza gracias a poder ofrecer
a las empresas de los alrededores un trato directo al poder contactar y atender personalmente
a los clientes. La satisfacción de estos primeros usuarios reflejada en su valoración y comentarios
en la aplicación servirá de trampolín para atraer a clientes de zonas más alejadas.
Figura 17. disponible en https://chekin.io/blog/software-para-apartamentos-turisticos-diferencias-entre-pms-channel-manager-ota-y-metabuscador/
50
5. Objetivos
Este proyecto persigue la consecución de un objetivo final que es la creación de una aplicación
digital multiplataforma y multidispositivo que facilite la gestión del alquiler de alojamientos
vacacionales o de temporada y la contratación de servicios relacionados con los mismos y que
pueda adaptarse al devenir del tiempo y el progreso. Debido a la gran cantidad de
funcionalidades que deberá ser capaz de cumplir dicha aplicación, ya en la actualidad, pero
también las nuevas que irán surgiendo de forma continua en el futuro, resulta evidente la
complejidad que conllevará su desarrollo e implementación, así como sus posteriores revisiones
y actualizaciones con la aparición de las nuevas necesidades del sector y la continua innovación
tecnológica.
Teniendo en cuenta estas consideraciones ha sido necesario acotar en el tiempo la consecución
de este objetivo final y concentrarme para este trabajo en dos subobjetivos iniciales
imprescindibles para la consecución del objetivo final. El primer subobjetivo consiste en la
preparación de la aplicación para que más adelante puedan desarrollarse las nuevas
funcionalidades que se quieran añadir, y se tiene que realizar de forma previa al inicio del
siguiente. El segundo subobjetivo consiste en el desarrollo de una aplicación de tecnología móvil
para la gestión vacacional que cumpla las funcionalidades solicitadas por la empresa cliente
(empresa que la ha solicitado y en la que se pondrá a prueba la aplicación).
Con la finalidad de conseguirlos se deberán realizar las siguientes tareas:
• Buscar una infraestructura online que nos pueda dar soporte tanto ahora como en el
futuro y así tener en conciencia la escalabilidad del proyecto.
• Investigar las tecnologías actuales y las que están por venir para planificar cómo estas
podrían mejorar y modificar el proyecto.
• Realizar una interfaz gráfica fácil de usar y claramente reconocible que pueda estar en
los diferentes entornos virtuales que existan.
• Que la herramienta permita facilitar la puesta en alquiler y después gestionar la reserva
y contratación de servicios relacionados con los alojamientos al usuario o empresa que
usa esta aplicación.
• Se deben poder realizar reservas desde la aplicación.
• Los usuarios estarán totalmente identificados y para poder realizar interacciones con la
aplicación deben cumplir el requisito de disponer de un token que los valide.
51
• La API estará pensada para poder ser separada en diversos servicios alojados en
diferentes máquinas para así en un futuro tener mayor capacidad de seguridad y de
desacoplamiento ente las diferentes partes de la aplicación.
• Será una aplicación multiplataforma y en esta primera etapa se presentará un
frontoffice para usuarios desde el móvil y un pequeño backoffice controlado desde la
web.
El producto estará diseñado para trabajar en múltiples entornos tanto como aplicación de
móvil (Android y IOS) como aplicación de escritorio (Linux, Windows y Mac) y aplicación
web, aunque en esta primera fase del desarrollo me centraré en presentar la aplicación en
formato móvil con las funcionalidades deseadas por el cliente. Como se tratará de una
aplicación multisistema y dispositivo, su utilización será de forma descentralizada y no
dependiente del sistema en el que se encuentre. En un futuro interaccionará con
aplicaciones de terceros y, por ello, se debe asegurar que el sistema mantendrá un uso
autónomo con independencia de los sistemas de terceros, ya que estos pueden tener
conflictos propios como: estar offline o denegar el acceso. Por ello la aplicación deberá ser
capaz de almacenar información que puedan necesitar los sistemas de terceros para
asegurar su funcionamiento.
52
6. Análisis y especificación
Ponemos nuestra atención ahora en la aplicación a desarrollar y sus funcionalidades.
6.1. Funciones del producto
La aplicación dispondrá de una serie de funciones que el cliente considera necesarias para su
funcionamiento. Además, en un futuro próximo se espera ampliar el número de funciones para
transformar este programa en una herramienta imprescindible para el alquiler y gestión
vacacional.
• Registro: El usuario podrá registrarse. Mediante este registro podrá realizar las
diferentes funciones de la web. También dispondrá de una vista solo para él que le
mostrará información útil, así como su historial. Se distinguen dos tipos de usuario: un
primer tipo, el usuario Guest que son los usuarios que solo reservan alojamientos y los
de tipo Host que son aquellos que dan sus alojamientos para reservar.
• Lista Reservas: El usuario verá una lista de las diferentes ofertas de alojamientos
que existen para poder reservarlos según la fecha que el usuario haya elegido.
Esta lista podrá ser filtrada por diferentes parámetros que elija el usuario como
serian la ubicación, el precio, el número de personas, entre otros campos. Una
vez seleccionado el alojamiento que desee podrá leer una ampliación de la
descripción de este y ver qué características posee.
• Mapa Reservas: El cliente podrá ver los alojamientos disponibles para reservar desde
un mapa que los ubique en la zona donde se encuentran.
• Añadir Servicios: El usuario podrá contratar los servicios que ofrece la empresa en el
momento de la reserva o después de ella. Estos servicios se pagarán junto a la reserva
si se hace en ese momento o después si ya se ha realizado la reserva.
• Reservar: El usuario podrá hacer efectiva su reserva efectuando el pago de esta. En el
momento que el usuario realiza el pago, el alojamiento pasa a no estar disponible en
esas fechas para nuevos usuarios, y la reserva pasa a poderla visualizar en su lista de
reservas.
• Perfil: Según si se trata de un de un usuario tipo Guest o Host, podrá ver o sus reservas
o sus alojamientos
• Subir alojamientos en alquiler: El usuario podrá subir alojamientos para que la empresa
los gestione y los otros usuarios puedan alquilarlos. Al subir un alojamiento la empresa
53
evaluará si este es interesante para la plataforma y según los criterios de beneficio del
cliente, la empresa le ofrecerá diferentes tipos de contratos.
• Ver estadísticas de los alojamientos: En el perfil de usuario Host, este podrá ver y
descargarse sus facturas y, según su tipo de contrato, las estadísticas de funcionamiento
de sus alojamientos.
• Pagar o recibir pagos: Desde la aplicación los usuarios podrán pagar sus reservas o los
diferentes servicios. También podrán consultar el pago de sus alojamientos mediante
las facturas que se realizan de estos.
6.2. Características de los usuarios
En el sistema existen tres tipos básicos de usuarios, y uno de esos tipos se subdivide también
en otros tres según las funciones que realiza. Cada tipo puede realizar un tipo de acciones
en la aplicación.
• Desarrolladores: Estos usuarios son los encargados del desarrollo de la aplicación.
Estos usuarios son los usuarios de mayor nivel de acceso y son responsables de que
el sistema propuesto funcione correctamente tanto por estar libre de errores como
por asegurar que el uso por parte del resto de usuarios es correcto. Este usuario
suele tener un alto grado técnico, ya que es experto en el sistema desarrollado.
Además, poseerá funciones avanzadas que permitirán un control absoluto sobre el
funcionamiento de la plataforma, su puesta en marcha, su reinicio o parada
completa.
• Administradores: Son los usuarios encargados de la gestión de la aplicación. Serán
aquellos que controlen las reservas, pongan los precios, modifiquen y adapten los
alojamientos para que sean interesantes para reservar. También se encargan de
aceptar o no los posibles nuevos usuarios y sus alojamientos. Son los usuarios de la
empresa a la cual va dirigido el software y, por lo tanto, tienen casi un control total
de este. En principio serán conocedores de todas las funciones que se pueden
realizar en él y también efectuarían un seguimiento para saber en todo momento si
la aplicación funciona correctamente. Estos usuarios también podrán pedir que se
incluyan nuevos módulos a la aplicación para facilitar su trabajo.
• Clientes: serán de dos tipos principales con registro, Guest y Host, y un tercer grupo
que serán los visitantes aún no registrados. Todos ellos serán los que den vida a la
aplicación, indicando tendencias, realizando reservas o aportando sus alojamientos
para alquilar. Para poder realizar muchas de las acciones de la aplicación estos
54
tendrán que registrarse en la aplicación. Son personas externas a la aplicación y que
no tienen por qué tener ningún tipo de conocimiento sobre esta y por ello son los
más sensibles a cometer errores o poner al límite la consistencia de la aplicación
- Guest: Son los usuarios que pueden alquilar alojamientos mediante el
sistema de reservas. También deben poder pagar sus reservas, así como
poder elegir servicios relacionados a la reserva que han efectuado y pagar
estos servicios. También podrán gestionar sus reservas y su perfil del panel
de usuario.
- Host: Son los usuarios que pueden poner en alquiler sus alojamientos. Para
que estos alojamientos se suban a la plataforma y sean visibles en reservas
se deberá concretar un contrato entre el usuario y la empresa que usa la
plataforma. Por otro lado, dispondrá de un perfil donde podrá ver datos y
estadísticas de sus alojamientos como también ver el historial de cobros que
ha recibido por parte de la plataforma según el contrato elegido.
- Visitante serán los usuarios que entren por primera vez a la plataforma. Los
posibles huéspedes (Guest) podrán ver el listado de alojamientos a reservar
y ver las características de estos, pero para poder efectuar la reserva,
tendrán que registrarse. Por la parte de Host podrán ver los beneficios de
utilizar la plataforma y la empresa destino como su plataforma de alquiler
vacacional. Para poder subir los alojamientos también necesitará
registrarse.
6.3. Restricciones, suposiciones y dependencias
Partiendo de que es un proyecto para una empresa que está en funcionamiento, cabe tener en
cuenta que necesita unas funcionalidades básicas muy concretas y que dicha empresa me ha
encargado que como primera fase del proyecto realice solo la estructura tanto frontend como
backend para el alquiler de los alojamientos además de la de la parte del host donde los posibles
nuevos clientes puedan indicar a la empresa que tienen alojamientos en alquiler.
Por otra parte, puedo utilizar las que considere necesarias para el desarrollo del proyecto
siempre que sean tecnologías de futuro y a partir de las cuales podamos crecer. La empresa
disponía de un hosting online que en un primer momento pensamos en usar para la API, pero
por motivos del diseño de nuestra infraestructura creo necesario cambiar ya que no la puedo
ubicar ahí. Además, creemos que hoy en día sería interesante utilizar tecnologías cloud como
55
Azure de Microsoft que nos permitirá un mayor crecimiento futuro e integración con sus nuevas
tecnologías.
Para finalizar, la única restricción real es la necesidad de cumplir la fecha de entrega del proyecto
que en este caso se trata de la fecha de entrega del TFG.
6.4. Funciones futuras
Como he comentado a lo largo del proyecto, este está enfocado al uso por parte de una empresa
de alquiler turístico que actualmente es el cliente para el que se desarrolla el proyecto y por ello
está pensado en diferentes módulos.
En un futuro se integrarán las APIs de las webs de reservas más importantes para poder hacer
la actualización desde esta misma plataforma (Chanel Manager). Además, se intentará integrar
la domótica para la gestión de los diferentes alojamientos disponibles en la aplicación mediante
el uso de las extensiones de Azure. Se quiere añadir un sistema de acceso a los alojamientos
mediante reconocimiento facial o dactilar o mediante el uso de una contraseña en la misma
aplicación o en la propia puesta de manera que se pudiera hacer el chech-in (entrada de
huéspedes) y el check-out (salida) de forma autónoma por parte de los huéspedes sin tener que
estar presente el anfitrión ni hacer uso de una llave física. Al mismo esto mejoraría la seguridad
de los alojamientos y la gestión de los recursos de las casas porque en todo momento se podría
saber quién y cuándo ha entrado o salida de un alojamiento. También evitaría la necesidad de
hacer copias de llaves al reducirse la posibilidad de su pérdida. Otra funcionalidad por desarrollar
tan pronto sea posible es el encendido y apagado de luces y electrodomésticos, así como la
calefacción y la refrigeración de las casas, lo que permitiría una importante reducción del
consumo energético y, en consecuencia, un necesario ahorro económico en el gasto de la
electricidad. En este sentido, por ejemplo, se podría mantener los alojamientos a una
temperatura determinada según el momento del día y la época del año.
También interesa integrar la aplicación con los asistentes virtuales de voz, como son Alexa de
Amazon, Okey Google de Google y Siri de Apple. Considero que comenzaremos con Alexa y sus
skills3 ya que será la forma más fácil de empezar con asistentes de voz. Además, Alexa ya nos
suministra algunas herramientas que nos pueden facilitar algunas de las funciones que
queremos poner en marcha, como pueden ser la compra de productos o una interacción más
directa entre los alojamientos y la empresa ya que nos permitiría hablar con los huéspedes sin
3 Aplicaciones de Alexa
56
tener que utilizar líneas telefónicas, pudiéndose programar que les dé la bienvenida, les
pregunte si necesitan un servicio de despertador, les indique dónde hay tiendas próximas o les
recomiende algún restaurante, entre otras muchas funcionalidades.
Por último, se está pensando en crear un modelo de negocio a partir de este primer proyecto
para realizar un software para todas aquellas empresas de alquiler que lo necesiten, así como
para los hoteles.
6.5. Requisitos
En este punto voy a hablar de los diferentes tipos de requisitos que se necesitan para el correcto
funcionamiento de la aplicación. Hay dos tipos de requisitos, los funcionales y los no funcionales.
Podemos definir a los requisitos como las características y las funciones del sistema. Son las
expectativas del software para el cliente. Los requisitos definen cómo va a interactuar el
software sobre los entornos donde actúa y sobre la interacción con los usuarios.
• Requisitos funcionales (RF): Son los procedimientos que prestarán los servicios del
sistema, en la forma en que reaccionará con las entradas. También deben establecer
explícitamente lo que el sistema no debe hacer. Describen el comportamiento o función
particular de un sistema o software cuando se cumplen ciertas condiciones. Estos
incluyen funciones desempeñadas por pantallas específicas, descripciones de los flujos
de trabajo que realiza el sistema y otras funciones de negocio, siempre teniendo en
cuenta la seguridad.
En el caso de esta aplicación concreta podemos observar estos requisitos funcionales:
Tabla 13. RF01
Número de requisito RF01
Nombre de requisito Autentificación de usuario
Tipo Requisito
Finalidad del requisito Identificar al usuario que accede
Prioridad del requisito Alta
Los Usuarios para poder acceder a la aplicación deberán identificarse. Para esto se debe
desarrollar un sistema de autentificación donde el usuario que se conecte introducirá
su nombre y la contraseña de acceso.
57
Tabla 14. RF02
Número de requisito RF02
Nombre de requisito Registro de usuario
Tipo Requisito
Finalidad del requisito Obtener información sobre el usuario
Prioridad del requisito Alta
Hacer un sistema de registro de los usuarios. Para esto se buscarán una serie de
preguntas sobre los usuarios que nos ofrecerán información sobre ellos como puede ser
la nacionalidad, sexo y edad, entre otras.
Tabla 15. RF03
Número de requisito RF03
Nombre de requisito Información de usuario
Tipo Requisito
Finalidad del requisito Ofrecer información sobre el usuario
Prioridad del requisito Alta
Se creará una vista donde se muestre la información y estadísticas del usuario. Esto será
de uso propio del usuario y solo se permitirá que otros usuarios puedan ver los campos
permitidos por el usuario propietario.
Tabla 16. RF04
Número de requisito RF04
Nombre de requisito Registro de alojamiento
Tipo Requisito
Finalidad del requisito Obtener información sobre el
alojamiento
Prioridad del requisito Alta
Se hará un formulario de registro de alojamientos para que los usuarios propietarios de
alojamientos puedan registrar su alojamiento en el sistema y así poder aparecer en la
lista de reservas y la empresa gestione su propiedad. Para esto se harán una serie de
preguntas sobre información del alojamiento a registrar.
58
Tabla 17. RF05
Número de requisito RF05
Nombre de requisito Información del alojamiento
Tipo Requisito
Finalidad del requisito Ofrecer información sobre el alojamiento
Prioridad del requisito Alta
Habrá una vista de la información del alojamiento donde aparecerán sus características,
servicios ofrecidos, calendario de reserva y sus precios. En esta vista habrá una parte
pública y una privada. La pública será la información que los posibles clientes que
quieran reservar el alojamiento necesiten conocer y la privada serán estadísticas sobre
los alojamientos que puedan ser de utilidad para una mejor promoción futura.
Tabla 18. RF06
Número de requisito RF06
Nombre de requisito Modificar información del usuario
Tipo Requisito
Finalidad del requisito Actualizar información sobre el usuario
Prioridad del requisito Alta
El usuario podrá modificar su información o incluir nueva.
Tabla 19. RF07
Número de requisito RF07
Nombre de requisito Modificar información del alojamiento
Tipo Requisito
Finalidad del requisito Actualizar información sobre el
alojamiento
Prioridad del requisito Alta
El usuario propietario y el administrador podrá modificar su información o incluir nueva
sobre el alojamiento. Como restricción, solo la información modificada por el usuario
para que sea visible en publicado deberá ser aprobada por el administrador.
59
Tabla 20. RF08
Número de requisito RF08
Nombre de requisito Geolocalizador del alojamiento
Tipo Requisito
Finalidad del requisito Ubicar el alojamiento en un mapa
Prioridad del requisito Alta
La aplicación dispondrá de un mapa donde estarán localizados los alojamientos
disponibles para poder realizar reservas según la ubicación.
Tabla 21. RF09
Número de requisito RF09
Nombre de requisito Lista de alojamientos
Tipo Requisito
Finalidad del requisito Proporcionar una lista de alojamientos
Prioridad del requisito Alta
Poner a disposición de los usuarios una lista de los alojamientos disponibles para
reservar.
Tabla 22. RF10
Número de requisito RF10
Nombre de requisito Pago para las reservas
Tipo Requisito
Finalidad del requisito Proporcionar un servicio de pago
Prioridad del requisito Alta
El sistema dispondrá de un sistema de pagos con el cual los usuarios que desean realizar
reservas puedan hacer el pago por su importe.
Tabla 23. RF11
Número de requisito RF11
Nombre de requisito Baja de alojamientos
Tipo Requisito
Finalidad del requisito Eliminar los alojamientos que no
renueven su contrato
Prioridad del requisito Alta
60
Cuando se realiza un alta de alojamiento se crea un contrato que estará relacionado con
un usuario y un alojamiento. Este tendrá un periodo de vigencia que será el tiempo
durante el cual la empresa podrá realizar la gestión de este alojamiento.
Tabla 24. RF12
Número de requisito RF12
Nombre de requisito Obtención de estadísticas
Tipo Restricción
Finalidad del requisito Obtener estadísticas de los datos
Prioridad del requisito Alta
La aplicación podrá obtener estadísticas de los distintos datos almacenados, por
ejemplo, número de reservas por usuario o por alojamiento, media de número de
noches por reserva, ingresos por mes, etc….
Tabla 25. RF13
Número de requisito RF13
Nombre de requisito Buscador de reservas
Tipo Requisito
Finalidad del requisito Mostrar los alojamientos con las
características seleccionadas
Prioridad del requisito Alta
La aplicación permitirá la búsqueda de alojamientos según criterios de los filtros
marcados en la búsqueda.
Tabla 26. RF14
Número de requisito RF14
Nombre de requisito El acceso al API será mediante Oauth y
tokens
Tipo Requisito
Finalidad del requisito Identificar al usuario que realiza una
petición
Prioridad del requisito Alta
Cada usuario dispondrá de un token de acceso a la API y se sabrá en todo momento qué
usuario está realizando las peticiones.
61
Tabla 27. RF15
Número de requisito RF15
Nombre de requisito Separación de la API en servicios
Tipo Requisito
Finalidad del requisito Proporcionar seguridad e independencia
Prioridad del requisito Alta
La API estará separada en diferentes servicios para así tener una mayor seguridad y
reducir la dependencia de las partes.
Tabla 28. RF16
Número de requisito RF16
Nombre de requisito Modificación de reservas
Tipo Requisito
Finalidad del requisito Solicitar la modificación de una reserva
Prioridad del requisito Alta
El usuario podrá modificar las reservas que ha realizado de acuerdo con las condiciones
de éstas.
Tabla 29. RF17
Número de requisito RF17
Nombre de requisito Contratación de servicios
Tipo Requisito
Finalidad del requisito Solicitar y contratar servicios
Prioridad del requisito Alta
El usuario al realizar su reserva podrá añadir servicios ofrecidos por la empresa o, una
vez ya realizada la reserva, podrá contratar estos servicios.
Tabla 30. RF18
Número de requisito RF18
Nombre de requisito Facturas
Tipo Requisito
Finalidad del requisito Ver o descargar facturas
Prioridad del requisito Alta
El usuario propietario de un alojamiento podrá descargar o ver las facturas que se hayan
producido como beneficio del contrato de gestión de su alojamiento.
62
Tabla 31. RF19
Número de requisito RF19
Nombre de requisito Cancelación de reservas
Tipo Requisito
Finalidad del requisito Cancelar o solicitar la cancelación de
reservas
Prioridad del requisito Alta
El usuario podrá cancelar las reservas según las condiciones con las que se ha realizado
la misma.
Tabla 32. RF20
Número de requisito RF20
Nombre de requisito Aceptación de Propiedad por parte
empresa
Tipo Requisito
Finalidad del requisito Aceptar las solicitudes de nuevos
alojamientos
Prioridad del requisito Alta
La empresa podrá aceptar o rechazar las solicitudes de los alojamientos que los usuarios
quieran dar de alta.
Tabla 33. RF21
Número de requisito RF21
Nombre de requisito Creación de PDF de contratos
Tipo Requisito
Finalidad del requisito Validación de los contratos con firma
Prioridad del requisito Alta
Los contratos se crearán en un documento PDF cuando los Hosts lleguen y firmen el
acuerdo con la empresa.
• Requisitos no funcionales: Son aquellos que no se refieren directamente a las funciones
específicas que realiza el software, sino a las propiedades relacionadas con éste, como
la fiabilidad, la respuesta en el tiempo, la capacidad de almacenamiento y la seguridad.
63
El sistema tiene que ser lo suficientemente compacto y eficiente para realizar las
acciones a través de las llamadas a la API. Dichas acciones, que se realizan en la
aplicación en físico en los diferentes dispositivos que estén utilizándola (como reservar,
subir alojamientos, modificar reservas o añadir servicios) se deben realizar de manera
instantánea. Utilizaré diferentes técnicas criptográficas para preservar la seguridad del
sistema.
Hay que añadir que otro punto en la seguridad será que todos los usuarios que quieran
realizar cualquier movimiento en la aplicación deberán estar registrados, y así podré
controlar todos los movimientos que ellos realicen desde el backoffice para poder trazar
rutas de errores o de vulnerabilidades del sistema y que dicha información no esté
disponible para cualquier persona. Además, todos los usuarios deberán validar su email
para evitar el uso spam y controlarlos más exhaustivamente.
Para garantizar la fiabilidad se realizará una descripción completa de los entornos donde
la aplicación estará almacenada, utilizándose y en mantenimiento. Además, se pagarán
los servicios de distintos especialistas para arreglar los posibles fallos que surjan
rápidamente. La disponibilidad del sistema tiene que ser inmejorable, debido a que
nuestros usuarios pueden realizar las distintas acciones a cualquier hora del día. Para
que esto se cumpla será muy importante la plataforma donde se alojará el sistema que
debe asegurarnos como mínimo un 98% de tiempo online ya que sino el sistema nos
podría producir graves perjuicios al no responderle correctamente a los usuarios.
Con la mantenibilidad del sistema lo que intentaré conseguir es una optimización de la
aplicación sin que se comprometa la seguridad. El mantenimiento más apropiado para
el software y que utilizaré será el mantenimiento preventivo cuya función es aprovechar
los periodos de no uso del sistema para realizar las operaciones de mantenimiento
realizando las revisiones o reparaciones adecuadas para el buen funcionamiento de la
aplicación.
Para que la aplicación satisfaga posibles y esperadas demandas de rendimiento cada vez
mayores, he pensado en utilizar las ya crecientes tecnologías cloud. En este caso Azure
de Microsoft me proporciona no solo un lugar donde alojar el backend de la aplicación
sino también toda una serie de herramientas y recursos para poder evolucionar y hacer
un adecuado uso de la aplicación. Creo que es un gran entorno donde desarrollar el
sistema y llevarlo a nuevas fronteras y además gracias a su sistema de pagos solo
pagaremos lo que usemos, permitiéndonos no tener que contratar servidores que no
64
estén en uso ya que en ese momento no hay suficientes usuarios o sencillamente no es
el momento.
6.6. Casos de Usos
Pasamos a analizar los casos de usos de la aplicación de acuerdo con las interacciones que se
realizan desde los dos puntos de vista que he desarrollado, los cuales se podrían considerar dos
sistemas por sí solos y serían el sistema Guest y el sistema Host.
Figura 18. Caso de uso sistema Guest (Fuente propia, elaborado con lucidchart.com [15])
La Figura 18 representa los casos de uso que tendría la parte de la aplicación de Guest donde un
actor entraría a reservar un alojamiento y habría un segundo actor que sería la pasarela de cobro
para efectuar la reserva. Como podemos ver el actor principal entraría en la aplicación y buscaría
los alojamientos que desee reservar. Para efectuar la reserva el actor tendría que estar
registrado o registrarse en ese momento, y a continuación podría hacer la reserva realizando el
pago previo. Este mismo actor tiene poder sobre su reserva y su perfil, por lo que puede
cancelarlos o modificarlos como necesite además de ver información sobre ellos.
65
Figura 19. Caso de uso del sistema Host (Fuente propia, elaborado con lucidchart.com [15])
En el caso de la Figura 19 hablo de los actores que desearían poner un piso en alquiler
en la plataforma. Como en el anterior caso, hay un actor más que sería la pasarela de
pago (banco o Paypal), pero en este caso de uso aparece también un tercer actor que
sería el empleado de la empresa de alquiler vacacional. Los actores principales aquí
entran a la plataforma y pueden dar un alojamiento en alta para que sea posible el
alquiler de este, pero, igual que en el otro caso, para efectuar el alta deberá tener un
perfil de usuario y deberá registrarse si no dispone de uno o iniciar sesión cuando la
aplicación lo solicite. Pero aquí se debe cumplir un tercer paso para que un alojamiento
sea visible en la parte de Host, o sea que este en alquiler un empleado deberá aceptar
la petición y negociar y firmar un contrato con el usuario para el aprovechamiento de
este alojamiento. Como es habitual los usuarios tendrán control de su perfil, pero en el
caso de los alojamientos una vez que se haya firmado el contrato tendrán un control
supervisado por la empresa ya que los clientes podrán modificar datos de ellos, pero
para que se vean efectivos en el Host, estas modificaciones tendrán que ser aprobadas
también por algún empleado de la empresa.
66
7. Diseño
El diseño es el apartado más importante en el desarrollo de la aplicación, con él se dará
respuesta a los requisitos funcionales y no funcionales del software planteados en su análisis. La
tarea del diseño es compleja e intervienen aspectos de diferentes niveles del proyecto como son
la base de datos, los diseños de interfaces, el diseño del servidor…. Todos estos aspectos
englobarán la aplicación, tendrán la intención de resolver la problemática de propuesta y darán
como resultado un ente común y funcional tanto a nivel arquitectónico como visual.
Este apartado intentará dar respuesta a todos los aspectos del software siendo estos agrupados
en 5 puntos que reflejarán cada uno de los conceptos necesarios para realizar la aplicación y
como se planificarán y desarrollarán. Por lo tanto, este apartado será la guía que nos marque
los pasos a seguir para producir la aplicación deseada.
7.1. Diseño de la persistencia
Mi sistema se tratará de un sistema con miras al crecimiento y a estar desacoplado como
veremos en el diseño de la API. Por lo tanto, he elegido para el lenguaje de la base de datos SQL.
La base de datos estará separada en diferentes módulos que no dependan de ellos para facilitar
el crecimiento y también en un futuro para mejorar la seguridad y velocidad.
La tecnología de base de datos que he elegido es MySQL [19]. De ésta podemos decir que se
trata de un sistema de gestión de bases de datos relacional, multihilo, multiusuario y que usa el
lenguaje SQL. Tengo diferentes motivos para elegir MySQL como mi sistema para la gestión de
las bases de datos, algunos intrínsecos al propio sistema como que es un sistema muy rápido al
momento de ejecutar consultas SQL, que se trate de un proyecto de software libre y que es
actualmente la base de datos más popular del mundo y es utilizado por grandes del negocio
online como son Wikipedia, Google o Facebook [20] y que es multiplataforma.
Figura 20. Logo Oficial Mysql (Fuente https://ca.wikipedia.org/wiki/MySQL#/media/Fitxer:MySQL.svg)
67
Y como motivos extrínsecos de la base de datos, pero propios míos está que ha sido el software
de gestión de base de datos que más he usado y por tanto tengo mayor conocimiento sobre él,
cosa que me facilita el trabajo un poco y me permite desarrollar un mejor producto. También el
hecho de que considero que es muy fácil de instalar en el servidor que he elegido y que, si tengo
que migrar de servidor en el futuro, también será muy fácil hacerlo. Otro punto a favor de usar
MySQL es la integración que tiene con PHP y Lavarel (en el backend y API hablaré de ellos). Y,
por último y también muy importante, no puedo obviar el tema económico. Al tratarse de
software libre, no se necesitará hacer una inversión en una licencia de uso y, de momento tanto
para mí como para mi cliente, es un punto que no podemos pasar por alto ya que unos grandes
costes de mantenimiento siempre pueden arruinar proyectos interesantes pero que aún tienen
que crecer. Y en este caso disponemos de una gran comunidad detrás del sistema que nos puede
ayudar en aquellos problemas que puedan surgir.
Una vez comentada la tecnología elegida y razonados los motivos de su elección, voy a comentar
las características de mi base de datos. Se trata de una base de datos dinámica que obtiene sus
datos mediante las peticiones que realizan los usuarios a través de la API, con un modelo de
datos relacional característico de las bases de datos SQL. Aunque dentro de este modelo debería
matizar que también está construida un poco como un modelo orientado a objetos ya que la
mayoría de las tablas hacen referencia a modelos que después se usarán en la lógica de la
aplicación. Y por último la base de datos está pensada como una gran base única pero realmente
se trata de varias bases de datos particionadas con una distribución heterogénea que dispondrá
de distintas partes en diferentes servidores para así agilizar el trabajo de la propia base de datos
y mejorar su seguridad.
Respecto a los datos representados en la Figura 21, vemos que hay un total de 22 tablas, de las
cuales 9 representan objetos y las demás son las características dinámicas que pueden tener
estos objetos. La Tabla usuario no estará ubicada en la misma base de datos ya que ésta será
perteneciente al servicio Gateway para así mejorar la velocidad de este servicio y mediante
programación haré que los enlaces de esta tabla hagan referencia a las otras tablas de las APIs.
Esta misma tabla será la única que tendrá un campo necesariamente cifrado que será la
contraseña del usuario. Las demás tablas estarán protegidas en su nube y solo podrán ser
accedidas mediante una API y la Key secreta que ésta tiene.
68
Figura 21. Diseño de la Base de datos (Fuente propia, elaborado con lucidchart.com [15])
Para la creación de las bases de datos, uso las herramientas que me facilita el framework de
microservicios Lumen con las migraciones y sus clases para hacer relaciones. Para adaptarme
correctamente al uso de lumen y al ORM 4Eloquent que este usa tendré que usar el patrón de
diseño de bases de datos de llaves subrogadas5 y además como explico a continuación voy a
utilizar también un patrón del tipo entidad-atributo-valor6. Como he comentado antes hay unas
tablas que serán principales y otras que están destinadas más a una función estructural de
crecimiento de la base de datos. Esto es porque los campos de las tablas pueden ser variados o
modificados según los intereses de la empresa. Para ello pensé que la solución a esto es que las
tablas principales inicialmente tuvieran pocos campos (o solo los estrictamente necesarios y que
serán siempre obligatorios) y que existieran unas tablas secundarias que actuaran como campos
de las tablas principales. Los valores de los campos de estas nuevas tablas se introducirán en la
relación entre ellas y las tablas principales, creando así un tercer tipo de tablas auxiliares con los
4 Object-Relational mapping es un modelo de programación que consiste en la transformación de las tablas de una base de datos en entidades que simplifiquen las tareas básicas de acceso y modificación de los datos al programador. 5 Patrón de diseño de bases de datos donde se decide generar una llave primara única para cada entidad en vez de usar un atributo identificador en el contexto dado -para esto se suelen usar enteros. 6 Patrón de diseño de bases de datos que intenta un acercamiento del modelo de orientado a objetos al modelo relacional. Se intenta realizar una representación de un modelo flexible donde se puedan representar objetos con sus atributos.
69
valores y los identificadores de ambas tablas. Esta forma de actuar me facilita diferentes
ventajas como es el hecho de que si se tiene que añadir algún campo a una tabla inicial no será
necesario modificar la tabla. Solo se añadiría el nombre del campo en la tabla secundaria y luego
sencillamente, mediante la relación de las dos, se introduciría el valor deseado. Por otra parte,
me permitirá que no todas las tablas hayan de tener esos campos con valor o con estado null.
Todo esto me parece una gran ventaja a la hora del mantenimiento y actualización de la base
de datos y un gran avance para el futuro si se desease que según usuario los campos a rellenar
fueran diferentes para así personalizar la aplicación para otros usuarios.
La Tabla 34 hace referencia a los alojamientos que los usuarios subirán a la plataforma.
Tabla 34. BBDD Tabla principal alojamientos
Tabla Alojamientos
Atributo Tipo Otras características
id Integer Clave primaria,
autoincrement
direccion_id Integer Clave ajena referenciada a la
tabla direcciones (Tabla 39),
campo: id
fecha_alta Date
estado Boolean
cod_registro_turistico Varchar Nullable
nombre Varchar
descripcion Text
n_personas Integer
mascotas Boolean
magic integer
70
referencia_id Integer Clave ajena referenciada a la
tabla referencias (Tabla 43),
campo: id
Tabla 35 para los contratos entre los usuarios que quieran poner en alquiler sus alojamientos y
la empresa.
Tabla 35. BBDD Tabla principal contratos
Tabla Contratos
Atributo Tipo Otras características
id Integer Clave primaria,
autoincrement
alojamiento_id Integer Clave ajena referenciada a la
tabla alojamientos (Tabla 34),
campo: id
usuario_id Integer Clave ajena referenciada a la
tabla usuarios (Tabla 42),
campo: id
contratoplantilla_id Integer Clave ajena referenciada a la
tabla contratoplantillas
(Tabla 36), campo: id
fecha_firma Date
fecha_inicio Date
fecha_expiracion Date
ruta_documento Varchar
Tabla 36 con la información de los contratos base que dispone la empresa.
Tabla 36. BBDD Tabla principal contratoplantillas
Tabla Contratoplantillas
71
Atributo Tipo Otras características
id Integer Clave primaria,
autoincrement
nombre Varchar
descripcion Text
ruta_plantilla Varchar
Tabla 37 para los contenidos multimedia. En ella se guarda la ruta global de donde está el
archivo.
Tabla 37. BBDD Tabla principal multimediacontenidos
Tabla Multimediacontenidos
Atributo Tipo Otras características
id Integer Clave primaria,
autoincrement
nombre Varchar
ruta Varchar
tipo Varchar
referencia_id Integer Clave ajena referenciada a la
tabla referencias (Tabla 43),
campo: id
Tabla 38 almacena la información referente a las reservas de los usuarios.
Tabla 38. BBDD Tabla principal reservas
Tabla Reservas
Atributo Tipo Otras características
72
Id Integer Clave primaria,
autoincrement
fecha_entrada Date
fecha_salida Date
deposito Boolean
cantidad_deposito Integer Nullable
precio_noche Integer
noches Integer
usuario_id Integer Clave ajena referenciada a la
tabla usuarios (Tabla 42),
campo: id
alojamiento_id Integer Clave ajena referenciada a la
tabla alojamientos (Tabla 34),
campo: id
pagado boolean
descuento double
n_alojados Integer
cuna boolean
idioma Varchar
observaciones Text Nullable
forma_pago Varchar
Tabla 39 guarda las direcciones de los alojamientos y usuarios.
73
Tabla 39. BBDD Tabla principal direcciones
Tabla Direcciones
Atributo Tipo Otras características
id Integer Clave primaria,
autoincrement
pais_id Integer Clave ajena referenciada a la
tabla paises (Tabla 40),
campo: id
provincia_id Integer Clave ajena referenciada a la
tabla provincias (Tabla 41),
campo: id
poblacion Varchar
cod_postal Varchar
tipo_via Varchar
nombre_via Varchar
numero Integer
puerta Char
piso Char
Tabla 40 que almacena los países disponibles.
Tabla 40. BBDD Tabla principal paises
Tabla Paises
Atributo Tipo Otras características
Id Integer Clave primaria,
autoincrement
74
nombre Varchar
Tabla 41 almacena las provincias o estados del país.
Tabla 41. BBDD Tabla principal provincias
Tabla Provincias
Atributo Tipo Otras características
Id Integer Clave primaria,
autoincrement
pais_id Integer Clave ajena referenciada a la
tabla paises (Tabla 40),
campo: id
nombre Varchar
Tabla 42 almacena los usuarios de la aplicación.
Tabla 42. BBDD Tabla principal usuarios
Tabla Usuarios
Atributo Tipo Otras características
Id Integer Clave primaria,
autoincrement
nombre Varchar
apellidos Varchar
dni Varchar
fecha_nacimiento Date
password Varchar Encripted
telefono_movil Varchar
75
direccion_id Integer Clave ajena referenciada a la
tabla direcciones (Tabla 39),
campo: id
referencia_id Integer Clave ajena referenciada a la
tabla referencias (Tabla 43),
campo: id
Tabla 43 es un “comodín” para poder indexar muchos contenidos multimedia con muchos
usuarios o alojamientos.
Tabla 43. BBDD Tabla principal referencias
Tabla Referencias
Atributo Tipo Otras características
Id Integer Clave primaria,
autoincrement
Tabla 44 para los posibles servicios incluidos los alojamientos (Ejemplos: cunas, despensa
llena…).
Tabla 44. BBDD Tabla secundaria servicios
Tabla Servicios
Atributo Tipo Otras características
Id Integer Clave primaria,
autoincrement
nombre Varchar
Tabla 45 con los campos adicionales para definir un alojamiento (Ejemplos: cerca del mar,
orientación...).
Tabla 45. BBDD Tabla secundaria caracteristicas
Tabla Caracteristicas
Atributo Tipo Otras características
76
Id Integer Clave primaria,
autoincrement
nombre Varchar
Tabla 46 para las APIs de otras páginas con las que podemos estar relacionados (ejemplos:
Booking, AirBB…).
Tabla 46. BBDD Tabla secundaria apisexternas
Tabla Apiexternas
Atributo Tipo Otras características
Id Integer Clave primaria,
autoincrement
nombre Varchar
Tabla 47 para crear posibles condiciones de los contratos para así poder suplir todas las posibles
características que no tengan los contratos básicos.
Tabla 47. BBDD Tabla secundaria condiciones
Tabla Condiciones
Atributo Tipo Otras características
Id Integer Clave primaria,
autoincrement
nombre Varchar
Tabla 48 para complementar datos de los contenidos multimedia (ejemplos: duración, aspecto,
peso…).
Tabla 48. BBDD Tabla secundaria multimediacaracteristicas
Tabla Multimediacaracteristicas
Atributo Tipo Otras características
77
Id Integer Clave primaria,
autoincrement
nombre Varchar
Tabla 49 almacenara datos referentes al usuario (ejemplo: sexo, telefono_fijo, idioma…).
Tabla 49. BBDD Tabla secundaria datos
Tabla Datos
Atributo Tipo Otras características
Id Integer Clave primaria,
autoincrement
nombre Varchar
Tabla 50 con los valores de un servicio en relación con un alojamiento.
Tabla 50. BBDD Tabla auxiliar servicioalojamientovalores
Tabla Servicioalojamientovalores
Atributo Tipo Otras características
Id Integer Clave primaria,
autoincrement
alojamiento_id Integer Clave ajena referenciada a la
tabla alojamientos (Tabla 34),
campo: id
servicio_id Integer Clave ajena referenciada a la
tabla servicios (Tabla 44),
campo: id
valor Varchar
Tabla 51 con los valores de una característica con relación con un alojamiento.
78
Tabla 51. BBDD Tabla auxiliar caracteristicaalojamientovalores
Tabla Caracteristicaalojamientovalores
Atributo Tipo Otras características
Id Integer Clave primaria,
autoincrement
alojamiento_id Integer Clave ajena referenciada a la
tabla alojamientos (Tabla 34),
campo: id
caracteristica_id Integer Clave ajena referenciada a la
tabla caracteristicas (Tabla
45), campo: id
valor Varchar
Tabla 52 con las keys de una API turística en relación con un alojamiento.
Tabla 52. BBDD Tabla auxiliar apiealojamientovalores
Tabla Apiealojamientovalores
Atributo Tipo Otras características
Id Integer Clave primaria,
autoincrement
alojamiento_id Integer Clave ajena referenciada a la
tabla alojamientos (Tabla 34),
campo: id
api_id Integer Clave ajena referenciada a la
tabla apiexternas (Tabla 46),
campo: id
valor Varchar
Tabla 53 con el valor de una condición para un contrato.
79
Tabla 53. BBDD Tabla auxiliar contratocondicionvalores
Tabla Contratocondicionvalores
Atributo Tipo Otras características
Id Integer Clave primaria,
autoincrement
contrato_id Integer Clave ajena referenciada a la
tabla contratos (Tabla 35),
campo: id
condicion_id Integer Clave ajena referenciada a la
tabla condiciones (Tabla 47),
campo: id
valor Varchar
Tabla 54 de los valores de una característica y un contenido multimedia.
Tabla 54. BBDD Tabla auxiliar caracteristicamultimediavalores
Tabla Caracteristicamultimediavalores
Atributo Tipo Otras características
Id Integer Clave primaria,
autoincrement
multimediacontenido_id Integer Clave ajena referenciada a la
tabla multimediacontenidos
(Tabla 37), campo: id
multimediacaracteristica_id Integer Clave ajena referenciada a la
tabla
multimediacaracteristicas
(Tabla 48), campo: id
valor Varchar
80
Tabla 55 almacenara los valores de cada dato que tenga un usuario.
Tabla 55. BBDD Tabla auxiliar usuariodatovalores
Tabla Usuariodatovalores
Atributo Tipo Otras características
Id Integer Clave primaria,
autoincrement
usuario_id Integer Clave ajena referenciada a la
tabla usuarios (Tabla 42),
campo: id
dato_id Integer Clave ajena referenciada a la
tabla datos (Tabla 49),
campo: id
valor Varchar
Por último, he de indicar que los logs de errores de la API y base de datos se guardarán en cada
servidor por separado y en el Gateway. Además, éste tendrá una ubicación para guardar los
fallos que se produzcan en la aplicación. De cada dispositivo donde se produzca el error se
guardará el modelo, la versión del programa y la acción que se realizaba.
Para el guardado de los logs y de toda la información cuando el usuario se dé de alta en el
sistema, deberá aceptar los términos y condiciones de uso, como marca la ley orgánica de
protección de datos 3/20018 del 5 diciembre [22].
7.2. Diseño arquitectura conceptual
La aplicación está pensada para ser multidispositivo y multisistema. Por ello, el frontend de la
misma se debe adaptar según el sistema. Por otra parte, desde este frontend se realizarán
peticiones a un servicio en la nube que será el encargado de autorizar y dirigir la petición a la
ruta que desee. Esa ruta apuntará a otro servicio que estará en otra nube aislada del Gateway e
inaccesible a cualquiera que no conozca su key secreta. Cuando llegue a ese servicio se realizarán
los procesos pertinentes y se consultará a la base de datos según sea necesario. Cada servicio y
nube tendrá su propia base de datos.
81
Como podemos ver en la Figura 22 se esquematiza el concepto de la aplicación haciendo el
recorrido conceptual que representará el sistema. Por el simple análisis podemos observar que
la aplicación tendrá una doble capa de seguridad, la primera la autentificación por OAuth en el
Gateway y una segunda que será la key secreta que tendrá cada servicio en cada nube que solo
conocerá el propio Gateway haciendo que todas las peticiones tengan que pasar por él.
Figura 22. Diseño conceptual de la aplicación (Fuente propia, elaborado con lucidchart.com [15])
7.3. Diseño API Rest y Backend
El Backend está formado por diferentes servicios separados en nubes diferentes7. Estos tendrán
la estructura de una API Rest. La intención es trabajar con servicios que no dependan de ellos y
que las posibles dependencias las gestione una fachada que sirva tanto para llamar a los servicios
concretos necesarios como de puerta con contraseña del Backend. Por lo tanto, el esquema será
tratado como si trabajásemos con microservicios cada uno en su nube, pero adaptado a mis
necesidades.
7 Por nube me refiero al concepto que el servicio este alojado en un servidor (este puede estar virtualizado o no) y el caso de mi estructura está pensada para que cada servicio que compone el sistema esté en un servidor independiente a las demás. Este concepto se puede entender mejor observando la Figura 23. Arquitectura de la API que representa como están separados los servicios y como funcionara el sistema.
82
Trabajar con la fachada creo que mejorara la seguridad de mis servicios ya que las llamadas de
las peticiones solo se realizarán a esta fachada y ella será la que sabrá a que ruta y servicio tiene
que encaminar la petición y al mismo tiempo será ella misma la que conteste la petición. Por lo
tanto, los servicios serán menos vulnerables a posibles ataques ya que nadie conocerá sus rutas
o incluso su existencia. También hay que decir que estos servicios estarán bloqueados con una
key única que solo conocerá la fachada.
Otro punto interesante que veo es el hecho de la escalabilidad del sistema en si ya que en
cualquier momento puedo crear nuevos servicios o duplicarlos y solo necesitaré modificar las
rutas en la fachada y el frontend no tendrá ninguna necesidad de enterarse. Al poder duplicar
podría crear servicios de solo consulta o con las funciones CRUD reducida para aquellas
peticiones de solo consulta o para perfiles de usuarios muy concretos, esto mejoraría la
velocidad de respuesta de mi sistema. Además, respecto a la seguridad y copia del sistema,
podría tener servicios que solo se dedicaran a replicar las bases de datos o incluso fraccionar
estas en varios servicios según los intereses que hubiera en ese momento.
Figura 23. Arquitectura de la API (Fuente propia, elaborado con lucidchart.com [15])
83
Para prevenir la posible saturación del servicio que hace de fachada, haré que el servidor donde
corra este servicio tenga mayor capacidad y con el ancho de banda mayor que podamos obtener
y que sea necesario. Para esto debería hacer estudios continuos de las demandas que recibe el
sistema. Otro punto negativo es el hecho de tener que desarrollar un sistema en la fachada para
gestionar esta división de los servicios y más aún cuando las bases de datos sean duplicadas o
fraccionadas en servicios más pequeños.
Como podemos ver en la Figura 23, el backend constará de una primera nube con servicio que
hace las funciones de Fachada o Gateway -yo lo he llamado YeiGateway- y será el encargado de
recibir las peticiones desde los diferentes entornos donde correrá la aplicación. Al mismo tiempo
tendrá una capa de seguridad propia que será mediante tokens de usuario. El protocolo de
seguridad será por OAuth2. Cuando un usuario registrado haga una petición desde la aplicación,
la petición llegara al Gateway. Este primero comprobará que el token de seguridad que incluye
la petición sea válido y, si es así, el Gateway hará los procesos pertinentes con esta petición y
realizará una petición a uno de los servicios internos del sistema que puede haber. Suponiendo
que la petición era ver un alojamiento que el usuario tiene reservado, la petición será relanzada
a el servicio de PMS -en mi sistema YeiPMS-, donde además de haber sido validada la petición
primero en el Gateway por el token de seguridad, aquí la petición irá acompañada por una key
secreta que solo conoce el Gateway y el propio servicio. Si todo fuera correcto, el servicio
devolvería la respuesta al Gateway y éste respondería a la aplicación. Hay que añadir que
ninguna petición que no tenga la key del servicio pasará el propio middleware del servicio
destino. Para definir un poco más de qué constará el proyecto, quiero decir que para este trabajo
de momento se desarrollará el Gateway y el servicio interno del PMS ya que es lo que he
acordado con el cliente y también es lo más necesario para tener un frontend funcional.
Para la programación de las APIs utilizaré PHP [26] y como framework Lumen. PHP es un lenguaje
de código interpretado que se usa desde el lado del servidor de licencia libre. Actualmente es el
lenguaje más utilizado para el desarrollo backend porque es fácil de aprender y tiene una gran
cantidad de módulos que nos facilitan el trabajo con él.
84
Figura 24. Logo oficial PHP (Fuente https://ca.wikipedia.org/wiki/PHP#/media/Fitxer:PHP-logo.svg)
Lumen [27] es un microframework desarrollado a partir de Laravel. Se pensó para aquellos que
no necesitaban de todas las funciones que dispone Laravel, pero sí querían utilizar el rico
entorno que éste dispone. Gracias a reducir los componentes que usa, Lumen es actualmente
uno de los frameworks con los que se pueden crear microservicios más rápidos. Además, tiene
muchas de las ventajas de su hermano mayor como es Eloquent, facilitándonos el trabajo y otras
librerías de Laravel, como es Passport para el trabajo con OAuth.
Figura 25. Logo Lumen (Fuente https://lumen.laravel.com/docs/6.x)
Por último, voy a definir las rutas que utilizarán de momento mis dos APIs. Como he comentado
en unos párrafos más arriba, en el proyecto tengo dos servicios que están separados entre ellos
y que podrían estar en el mismo servidor, pero trabajando en puertos diferentes, o en servidores
diferentes. Para empezar, voy a hablar de lo que devuelven ambos servicios que se trata de una
respuesta en JSON con el siguiente formato básico:
Tabla 56. Respuesta estándar JSON
HTTP/1.1 [código de respuesta]
Content-Type: application/json;charset=utf-8
{
“data”: [
{
85
“id”:23;
“Nombre”:Pepito Grillo;
…..
}
…..
]
}
Como se puede ver siempre devolverá el código de la respuesta y los datos dentro de una matriz
de nombre ‘Data’. Ahora ya voy a comentar un ejemplo de un CRUD de los servicios YeiGetaway
y YeiPMS.
Tabla 57. Request a yeiapp.com oath
Ruta /yeigateway/oauth/token
Método POST
Parámetros grant_tipe
client_id
client_secret
scope
Respuesta Key de seguridad
Tabla 58. Request a yeiapp.com usuarios GET
Ruta /yeigateway/usuarios/
Método GET
Parámetros Authorization
Respuesta Listado de usuarios
86
Tabla 59. Request a yeiapp.com usuarios GET/id
Ruta /yeigateway/usuarios/id
Método GET
Parámetros Authorization
Respuesta Usuario según la id
Tabla 60. Request a yeiapp.com usuarios POST
Ruta /yeigateway/usuarios/
Método POST
Parámetros Authorization
nombre
apellidos
dni
fecha_nacimiento
password
password_repited
telefono_movil
direccion_id
referencia_id
Respuesta Devuelve el usuario creado
Tabla 61. Request a yeiapp.com usuarios PATCH
Ruta /yeigateway/usuarios/
Método PUT / PATCH
87
Parámetros Authorization
nombre
apellidos
dni
fecha_nacimiento
password
password_repited
telefono_movil
direccion_id
referencia_id
Respuesta Devuelve el usuario modificado
Tabla 62. Request a yeiapp.com alojamientos GET
Ruta /yeigateway/alojamientos/
Método GET
Parámetros Authorization
Respuesta Listado de alojamientos
Tabla 63. Request a yeiapp.com alojamientos GET/id
Ruta /yeigateway/alojamientos/id
Método GET
Parámetros Authorization
Respuesta Alojamiento según la id
88
Tabla 64. Request a yeiapp.com alojamientos POST
Ruta /yeigateway/alojamientos/
Método POST
Parámetros Authorization
Activo
fecha_alta
cod_registro_turistico
nombre
descripcion
n_personas
mascotas
magic
Respuesta Devuelve el alojamiento creado
Tabla 65. Request a yeiapp.com alojamientos PATCH
Ruta /yeigateway/alojamientos/
Método PUT / PATCH
Parámetros Authorization
Activo
fecha_alta
cod_registro_turistico
nombre
descripcion
n_personas
mascotas
magic
Respuesta Devuelve el alojamiento modificado
89
Tabla 66. Request a yeiapp.com reservas GET
Tabla 67. Request a yeiapp.com reservas GET/id
Tabla 68. Request a yeiapp.com reservas POST
Ruta /yeigateway/reservas/
Método GET
Parámetros Authorization
Respuesta Listado de reservas
Ruta /yeigateway/reservas/id
Método GET
Parámetros Authorization
Respuesta Reserva según el id
Ruta /yeigateway/reservas/
Método POST
Parámetros Authorization
fecha_entrada
fecha_salida
deposito
cantidad_deposito
precio_noche
noches
usuario_id
alojamiento_id
pagado
forma_pago
descuento
n_alojados
90
Tabla 69. Request a yeiapp.com reservas PATCH
cuna
idioma
observaciones
Respuesta Reserva creada
Ruta /yeigateway/reservas/
Método PUT / PATCH
Parámetros Authorization
fecha_entrada
fecha_salida
deposito
cantidad_deposito
precio_noche
noches
usuario_id
alojamiento_id
pagado
forma_pago
descuento
n_alojados
cuna
idioma
observaciones
Respuesta Reserva modificada
91
7.4. Diseño Interfaces, Frontend y Experiencia de Usuario
Para el diseño del frontend investigué los diferentes lenguajes que había y sus frameworks
teniendo en mente en todo momento que los usuarios de tecnologías cada vez utilizan más los
móviles para realizar sus tareas y funciones. Al mismo tiempo en el sector empresarial aún se
utilizan el software de escritorio y por norma suele estar en los entornos más profesionales y los
usuarios de estos lugares están más acostumbrados a ello. Por ello pensé que lo mejor y más
conveniente era usar una tecnología que nos permitirá desarrollar para ambos formatos con el
mínimo número de cambios y con el mismo código para todos los sistemas, ya que con estas
ventajas reduciría los costes tanto temporales como económicos de lo que es desarrollar para
múltiples plataformas y dispositivos.
Entre todos los lenguajes y frameworks que me ofrecían soluciones para la programación
multiplataforma, elegí la solución que ofrecía Google con Dart y Flutter porque vi que puede ser
una tecnología de futuro e innovadora la cual su empresa madre está destinando muchos
recursos para que crezca y sea muy competente. Dart [29] es un leguaje creado por Google
orientado a objetos y con una clara optimación de la parte cliente. Actualmente se usa sobre
todo para el desarrollo de aplicaciones web, móvil y el internet de las cosas (IoT).
Figura 26. Logo oficial Dart (Fuente https://dart.dev/)
Otra de las muchas características de Dart es que es un lenguaje muy rápido y con una
comunidad que actualmente está creciendo y que dispone una gran cantidad de paquetes que
facilitan la programación y nos ayudan a realizar un trabajo más rápido. Como he dicho, junto
con Dart uso su framework para el diseño de aplicaciones de escritorio, web y móvil más
importante de su sistema y también apoyado por Google que es Flutter.
Figura 27. Logo oficial Flutter (Fuente https://ca.wikipedia.org/wiki/Flutter#/media/Fitxer:Google-flutter-logo.png)
92
Actualmente Flutter [28] ha evolucionado a ser un kit de desarrollo de software (SDK) ya que
ofrece más ventajas que solo ser un framework de Dart. Flutter está pensado para ir diseñando
tu aplicación en capas de las más altas a las más bajas con un sistema que ellos llaman Widgets
y estos van englobando otros para realizar las interfaces de usuario. Una gran ventaja que tiene
es que la misma interfaz que diseñes o programes para un sistema se verá igual en cualquier
otro y al mismo tiempo tus aplicaciones parecerán que son nativas de ese sistema. También
ofrece mecanismos de debug rápido donde, mediante un ‘hot reload’ podrás ver los cambios
que implementes en tu código de una forma rápida y sin tener que compilarlo entero acelerando
así la programación de la aplicación y reduciendo los tiempos de espera. Además, dispone de
una gran cantidad de widget ya precontruidos para poder hacer tus diseños más rápidos con su
librería Material Design que hará que en poco tiempo puedas hacer interfaces vistosas y
profesionales. Por todo esto creo que tanto Dart como Flutter eran mi mejor opción para el
diseño de esta aplicación y para poder continuar creciendo con ella en el futuro.
Figura 28. Mockup inicio (Fuente propia, elaborado con fluidui.com [30])
93
Una vez analizados los casos de uso de la aplicación, me puse a diseñar los mockups de la misma.
Para ello primero miré los widgets de Material design de Flutter para saber cómo eran y qué
lógica visual tenían para así, cuando implementara la aplicación, el trabajo de realizar estos
diseños a la interfaz gráfica de la aplicación móvil fueran los más fidedignos posibles y al mismo
tiempo pudiera hacer la conversión lo más rápido posible y sin tener que crear muchos widgets
personalizados que entorpecieran el desarrollo.
Para el diseño de los Mockup utilicé la herramienta online de FluidUI [30], la cual me permitía
crear pantallas muy realistas al producto final y además me daba la posibilidad de dar a estos
bocetos un poco de lógica de navegación mediante la creación de enlaces entre las diferentes
partes de la aplicación y así poder ver mejor el conjunto de ella. Este prototipado mediante los
bocetos nos ayudó tanto a mi como a mi cliente en ver la aplicación y a él a aceptar mi diseño.
La Figura 28 es la primera pantalla que verán los usuarios al abrir la aplicación. Aquí lo que
intento es hacer que ellos elijan una de las dos modalidades que tienen el sistema Guest o Host.
Le doy el mayor énfasis en color a la parte Host ya que la empresa cliente actualmente en lo que
más quiere incidir es en conseguir nuevos alojamientos. He intentado que sea un diseño lo más
Figura 29. Mockup lista reservas (Fuente propia, elaborado con fluidui.com [30])
94
claro y sencillo posible sin mucha información en la pantalla para no distraer la atención del
objetivo perseguido. En la Figura 29 vemos la siguiente ventana que un usuario Guest vería. Aquí
intento mostrar en un primer vistazo los alojamientos que la empresa tiene mayor interés en
alquilar. Como en la primera vista y en todas las demás, intento que la información visual sea la
mínima posible para que el cliente se fije en lo que se le ofrece. Y en los casos que no puedo
reducir la información, la delimito y enmarco para que esté claro lo que interesa.
En la Figura 31 se podrán ver los alojamientos que hay en la lista de reservas situados en el mapa
donde se ubican. Para esto utilizaré las herramientas de Google Maps. Se podrán filtrar los
alojamientos por diferentes parámetros, tales como el número de personas que caben en él, el
precio, si disponen de determinados servicios, como se muestra en la Figura 30. Para poder ver
los filtros tendrás que pulsar el botón de filtro o deslizar el dedo desde el borde izquierdo de la
pantalla a la derecha.
El mockup de la Figura 33 es una representación del registro de usuario por parte del Host. He
hecho dos mockups diferentes en el diseño para el Guest y el Host para que cada uno tenga sus
propias características en diseño de colores, aunque esto puede ser que lo cambie en el futuro
y deje un solo registro para toda la aplicación y así reutilizar vistas y no cargar innecesariamente
la aplicación. La Figura 32 es la vista que mostrará la información del alojamiento con su
Figura 31. Mockup lista reservas mapa (Fuente propia, elaborado con fluidui.com [30])
Figura 30. Mockup filtro reservas (Fuente propia, elaborado con fluidui.com [30])
95
descripción y las características de éste. Una parte fundamental de esta vista será el calendario
que mostrará las fechas que están ocupadas y no son seleccionables como también las fechas
que el usuario ha elegido para la reserva y en todas ellas el usuario podrá ver el precio de la
noche en el día concreto.
La Figura 34 es la vista donde el cliente ya se dispone a realizar su reserva. Aquí también ve una
breve descripción del alojamiento, su ubicación y un resumen de las fechas de la estancia
indicándole el número de noches que serán como el precio medio por noche que le saldrá y el
precio total que tiene la reserva. Otro cuadro muy importante aquí es que le aparecerán los
Figura 33. Mockup registro Host (Fuente propia, elaborado con fluidui.com [30])
Figura 32. Mockup más información alojamiento (Fuente propia, elaborado con fluidui.com [30])
96
servicios que la empresa ofrece y que él puede contratar. Estos servicios serán individuales por
alojamiento ya que unos alojamientos los pueden tener y otros no. Como es normal al lado de
cada servicio aparecerá el precio de éste y, según los que seleccione, en el siguiente cuadro le
aparecerá el precio total de todos los servicios, así como el montante total de la reserva, la cual
podrá realizar pulsando el botón “Reservar”. Como pequeño inciso cabe indicar que un usuario
podría llegar a este punto sin haberse registrado aún. Por lo tanto, antes de que le aparezca la
vista de realizar pago, pasará por el registro o por el inicio de sesión y de ellas saltará a realizar
el pago. La vista de la Figura 35 es donde podemos ver cómo será representada esta pantalla.
En ella, el cliente ve la fecha de entrada y salida, la descripción de los servicios contratados y el
precio total a pagar. También le aparece un selector para elegir el método de pago y dos
Figura 34. Mockup realizar reserva (Fuente propia, elaborado con fluidui.com [30])
Figura 35. Mockup realizar pago (Fuente propia, elaborado con fluidui.com [30])
97
botones: uno para realizar modificaciones en la reserva y el otro para efectuar el pago pasando
a la pasarela de pago.
Cuando el cliente ha realizado la reserva podrá ver todas las que tiene en la vista de la Figura 36
donde le aparecerá un listado de todas ellas y en este caso también podrá filtrarlas. Esta vista
Figura 36. Mockup mis reservas (Fuente propia, elaborado con fluidui.com [30])
Figura 38. Mockup descripción reserva (Fuente propia, elaborado con fluidui.com [30])
Figura 37. Mockup perfil usuario Guest (Fuente propia, elaborado con fluidui.com [30])
98
también hará de vista menú de usuario. Con los botones de la parte inferior podrá ir a ver su
perfil para así poder modificar las cosas que crea conveniente, como se muestra en la Figura 37.
En este caso pasa lo mismo que en el registro de usuario ya que hay dos vistas para el mismo
uso, una para Guest y otra para Host. O desde los botones del menú de usuario también podrá
ver las reservas que aún están activas ubicadas en el mapa.
Por último, en la parte Guest de la aplicación, cuando el usuario pulse sobre una de sus reservas
podrá entrar en ella y ver sus características y los servicios contratados. Al mismo tiempo podrá
cancelarla o modificarla según las condiciones del alojamiento y disponibilidad. El ejemplo de la
vista es la Figura 38.
Ahora voy a mostrar y detallar los mockups de la parte de Host de la aplicación. Lo primero que
verá el cliente, será una breve explicación de lo que ofrece la aplicación y qué ventajas tendría
al trabajar con nosotros, como se muestra en la Figura 39. La Figura 40 es el mockup del diseño
del inicio de sesión. Será igual en toda la aplicación solo cambiará el texto que aparezca en
‘comunidad de propietarios’ o ‘comunidad de amigos’. Ese texto hará de enlace al registro de
usuarios. La vista para este registro es la Figura 41, que, como podemos ver, es igual a la de
registro de usuario solo cambiando los tonos (Figura 33).
Figura 39. Mockup de bienvenida Host (Fuente propia, elaborado con fluidui.com [30])
Figura 40. Mockup inicio sesión (Fuente propia, elaborado con fluidui.com [30])
99
La navegación del usuario después de la página de ‘Bienvenida’, se haya logado o no o se haya
registrado o no, será la siguiente. Si no está logado y pulsa el botón más, la siguiente vista que
vera será la Figura 42. Este es un formulario básico con los datos del alojamiento que el cliente
desea subir. Este formulario no será el más completo para el alojamiento ya que solo será un
pequeño resumen de lo que es el alojamiento para que la empresa tenga constancia de la
solicitud e investigue sobre si es interesante incluirlo en la oferta de apartamento y que contrato
se le ofrecerá al cliente para negociar. Junto a esta vista podrá pasar mediante el menú inferior
a una donde la empresa tenga más información sobre ella, de la forma de trabajar que tiene, del
tipo de ofertas o de cómo sería ventajoso para el cliente conseguir que su inmueble forme parte
del paquete de alojamientos de la YeiApp. Esta vista se muestra en la Figura 43.
A continuación, el cliente tendría la opción de registrarse en la plataforma, Figura 41, o, si no lo
desea aún, podrá poner un nombre y apellido, un teléfono de contacto y un email para que una
vez revisada la solicitud de que su apartamento para ser incluido en la plataforma, la empresa
pueda comunicarse con él y hacerle la correspondiente oferta. En ese momento el cliente
recibirá un correo con un enlace para terminar de realizar su inscripción como usuario. El
mockup correspondiente a esta tarea es el de la Figura 44. Usa vez terminados estos pasos la
Figura 41. Mockup registro Host (Fuente propia, elaborado con fluidui.com [30])
100
propuesta de registro del alojamiento pasará a manos de la empresa que se pondrá en contacto
con él.
Figura 42. Mockup Formulario de inscripción alojamiento (Fuente propia, elaborado con fluidui.com [30])
Figura 43. Mockup más información empresa (Fuente propia, elaborado con fluidui.com [30])
Figura 44. Mockup contacto para alta (Fuente propia, elaborado con fluidui.com [30])
101
Ya para finalizar los diseños de la parte Host hice una serie de mockups para la cuenta de cliente
donde éste, desde un menú lateral, Figura 45, puede ir a diferentes vistas que le permitirán
modificar su perfil o cancelarlo, ver estadísticas y las facturas de sus ganancias o acceder al
listado de sus alojamientos y entrar en ellos para editarlos.
El perfil de usuario es el mismo que para la parte Guest pero con el tema de más oscuro de Host.
Este se puede contemplar en la Figura 46. En la Figura 47 muestra como el cliente podrá ver
datos pertinentes a sus alojamientos, a las ganancias obtenidas hasta el momento y muchas más
estadísticas según el tipo de contrato que tenga. Aquí también tendrá disponible todas las
facturas, tanto si son de contratos donde es él quien paga una mensualidad a la empresa o si
son ingresos que él tiene desde la plataforma.
Para finalizar con los interfaces los dos últimos mockups que forman parte de mi diseño son los
del listado de alojamientos que puede tener un usuario (mostrado en la Figura 48). En este
listado le aparecerán todos los alojamientos que dispone tanto los que ya son activos en la
plataforma como aquellos que han solicitado su inclusión. Si pulsa sobre uno de ellos entraría
en la vista del alojamiento. (Figura 49). Aquí, igual que en el perfil de usuario, podrá modificar y
añadir todo lo que desee, pero, antes de ser visible en la parte Host, esto tiene que ser aprobado
por la empresa. Otro punto diferente que existe es que aquí también tiene la posibilidad de
contratar servicios adicionales para su alojamiento que previamente no estuvieran en el
contrato.
Figura 45.Mockup menú usuario (Fuente propia, elaborado con fluidui.com [30])
Figura 46.Mockup perfil (Fuente propia, elaborado con fluidui.com [30])
102
Figura 47.Mockup estadísticas y facturas (Fuente propia, elaborado con fluidui.com [30])
Figura 48.Mockup lista alojamientos (Fuente propia, elaborado con fluidui.com [30]) Figura 49.Mockup perfil alojamiento
(Fuente propia, elaborado con fluidui.com [30])
103
7.5. Guías de estilos
Al tratarse de una aplicación para una empresa concreta tuve que acordar con mi cliente los
estilos que él quería para la aplicación. Esto supuso una negociación entre ambos para elegir
tanto colores como fuentes y un poco el estilo visual, aunque en este respecto estábamos
condicionados por Material Disegn de Flutter.
Para la paleta de colores (Figura 50) conseguimos llegar al acuerdo de utilizar naranjas y negros
para así resaltar sobre los demás. El color naranja fue elegido por la localidad donde se ubica la
empresa ya que ésta tradicionalmente ha sido un pueblo donde en los meses de diciembre,
enero y febrero se ve mucho este color por la gran cantidad de naranjos que había además que
también hacemos referencia con él al sol. Por otra parte, el negro fue elegido por darle mucho
contraste al naranja. Otros colores que fueron elegidos para ser utilizados son los grises y
blancos.
Figura 50. Paleta de colores (Fuente propia, elaborado con https://color.adobe.com/es/create/color-wheel/)
104
Para las fuentes elegí: la fuente Kaushan Script para aquellas palabras o títulos que quisiera
resaltar(Figura 51), la Carrois Gothic (Figura 52) para los títulos y la Carrois Gothic SC (Figura 53)
para el texto en general. Las tres fuentes las obtuve de la librería Fonts de Google [31] que nos
ofrece una gran cantidad de fuentes gratuitas para nuestros diseños y creaciones.
Figura 51. Fuente Kaushan Script (Fuente https://fonts.google.com/specimen/Kaushan+Script)
Figura 52. Fuente Carrois Gothic (Fuente https://fonts.google.com/specimen/Carrois+Gothic)
Figura 53. Fuente Carrois Gothic SC (Fuente https://fonts.google.com/specimen/Carrois+Gothic+SC)
105
8. Implementación
Sobre la implantación voy a tratar 3 puntos principales: el primero de ellos seria la adecuación
de un entorno de trabajo, el segundo el desarrollo de la API y el tercero el desarrollo de la
aplicación. Creo que con estos tres puntos haré un buen repaso de lo que he tenido que hacer y
de las labores e incidencias que me han ido surgiendo durante el desarrollo del software.
8.1. Entorno de trabajo
Una vez todo planificado, diseñado y pensado, acometo esta parte, tan necesaria para llevar a
cabo el resto de las tareas, pero, en mi opinión, una de las más arduas, ya que en cualquier
momento pueden surgir problemas inesperados. Para el desarrollo de la aplicación el Sistema
Operativo (SO) que he utilizado es un sistema Linux, concretamente Linux Mint (Figura 54), que
es una de las distribuciones más populares del momento por su flexibilidad, adaptabilidad y
sencillez y todo esto sin perder en ningún momento la consistencia y solidez que por ejemplo
caracterizan a Ubuntu.
Figura 54. Logo Linux Mint (Fuente https://linuxmint.com/)
A Linux Mint tuve que instalarle la última versión de PHP y Composer que es un gestor de
paquetes para este lenguaje. Composer (Figura 56) era necesario para luego poder instalar
Lumen y trabajar con las herramientas que este te ofrece, como ‘php artisan’, que es muy útil
para poder realizar las migraciones y crear diferentes utilidades, así como también para hacer
funcionar un pequeño servidor. Para la configuración de Dart y Flutter primero tuve que instalar
Dart en el sistema. Una vez instalado para facilitar la instalación del SDK de Android, instalé
Figura 56. Logo Composer (Fuente https://getcomposer.org/)
Figura 55. Logo Android Studio y SDK (Fuente https://developer.android.com/)
106
Android Studio (Figura 55) y mediante sus complementos también instalé Flutter. Haber
instalado estos complementos de Android me permitieron poder usar una máquina virtual que
emulara un teléfono móvil y también mediante conexión USB hacer el debug en mi propio móvil.
El siguiente paso fue instalar XAMPP (Figura 58) para Linux. Esto me permitió tener un servidor
apache con una base de datos MariaDB. Aunque en un principio quería tener MySQL, utilicé ésta
porque es la que venía junto al paquete. Sin embargo, este cambio no supuso ninguna
complicación ya que ambos sistemas de base de datos son idénticos. Con MariaDB creé 2 bases
de datos, una para la API YeiGateway y una segunda para la API YeiPMS.
Para trabajar y programar elegí el editor de texto Visual Studio Code (Figura 57), editor que tiene
muchas características interesantes y que actualmente también es muy usado y que me permitió
instalar los complementos necesarios tanto para trabajar con PHP y Lumen como para trabajar
con Dart y Flutter. Para finalizar el entorno de trabajo utiliza Git y mi repositorio Git es GitLab
debido a que éste me permitía tener un repositorio privado sin ningún cobro y sin problemas de
espacio.
8.2. Desarrollo de la API
Vamos a empezar con el segundo punto. Como ya he comentado antes, he desarrollado dos API
diferentes (Figura 59) con sus propias bases de datos. Realmente no he tenido muchas
complicaciones en el desarrollo de estas. Sencillamente mediante el uso de las herramientas
que me suministraba Lumen, avanzaba muy rápido en su implantación. A parte de las diferencias
comentadas en el diseño sobre las keys, tokens y el hecho que el Gateway en sus componentes
gestione las peticiones de una manera un poco diferente ya que tiene que comprobar ciertas
reglas para que la comunicación entre ambas sea perfecta. Si encontré un problema cuando
estaba programando el sistema de tokens con OAuth del Gateway. Para hacerlo utilicé Passport,
una librería para autentificación mediante OAuth. Este funciona correctamente, pero tuve que
modificar mis rutas y crear nuevas por una falta de consenso que actualmente tienen los
Figura 57.. Logo Visual Studio Code (Fuente https://code.visualstudio.com/)
Figura 58. Logo XAMPP (Fuente https://www.apachefriends.org/index.html)
107
desarrolladores de la librería sobre el uso de OAuth. Esto me supuso investigar y preguntar al
equipo de desarrollo de la librería los motivos por los que pasaba esto y como solucionarlo.
Las tablas de la base de datos creada previamente con phpMyAdmin se realizaron con las
migraciones de Lumen. Lumen utiliza para trabajar y manipular las bases de datos Eloquent que
es una herramienta de Lavarel para hacer una conversión directa de la respuesta de la base de
datos a un objeto para así facilitar el trabajo con los datos simplificando en su manipulación y
modificación. Esto conlleva a que para poder diseñar correctamente el MVC8 con el que se
trabaja con Lumen y Eloquent se tuvieran que realizar unas pequeñas adaptaciones al diseño de
la base de datos inicial. Una de ellas fue el hecho de cambiar el nombre de las tablas por la
nomenclatura propuesta por Lavarel para el buen uso de Eloquent. Otro fue el hecho que las
relaciones no se realizaron mediante claves ajenas como dicta lo normal en las bases de datos
relacionales, sino que se utilizaron las funciones hasOne(‘MODEL’), belongsTo(‘MODEL’),
HasMany(‘MODEL’) y belongsToMany(‘MODEL’) que proporciona Eloquent cuando se
programan los Modelos asociados a las tablas correspondientes.
Figura 59. Implementación APIs (Fuente propia)
Para mejorar la implementación de las tablas dinámicas, ya que todas ellas se guardan como
string (varchar) y esto podía provocar problemas para luego trabajar estos datos, he añadido un
nuevo campo en las tablas ‘Servicios’, ‘Caracteristicas’, ‘Condiciones’, ‘Datos’ y
‘Multimediacaracteristicas’ Además de guardar el nombre de la característica a la que hacen
8 Modelo vista controlador (MVC)
108
referencia, ahora guardan también el tipo de dato que se desea guardar. He puesto la restricción
de que el campo ‘tipo_dato’, campo nuevo de tipo string, solo pueda almacenar estos tres
strings [‘String, ‘Numero’, ’Bool’] así cuando en un futuro desde la API o desde la Aplicación
necesite utilizar este dato, podré saber con certeza de qué tipo de valor se trata y realizar el cast
de éste con mayor facilidad y evitando errores.
Estos fueron los sucesos más interesantes cuanto a la programación de las APIs. Considero que
con Lumen la tarea de realizarlas se redujo mucho y pude avanzar rápido.
8.3. Implementación del Frontend
Cabe indicar que, como con el desarrollo de la API, el hecho de utilizar el framework Flutter, ha
agilizado la implementación y no ha surgido ningún contratiempo.
La característica más interesante que tiene este framework -ya que a mí me facilitó mucho el
trabajo- es el Hot Reload, gracias al cual podía dejar la aplicación ejecutándose en la máquina
virtual e ir yo haciendo cambios en el código de ésta y verlos al instante en mi dispositivo. La
verdad es que es muy fluido todo el proceso y me permitía saber en todo momento qué estaba
haciendo.
Figura 60. Flutter Hot Reload (Fuente propia)
Otra cosa que sí que tuve que investigar un poco fue el tema de utilizar dependencias de librerías
para Flutter. Hay muchas desarrolladas y todas ellas están en una plataforma llamada Pud [32]
109
y para incluirlas en tu proyecto solo hay que ponerlas en el archivo pubspec.yaml [Figura
61Figura 61. Ejemplo de librerías de Flutter usadas] de tu proyecto y se instalan al momento.
Para el proyecto utilicé varias de ellas y en Pud [32] está muy bien explicado todo sobre ellas.
Otra ventaja que me ha sorprendido gratamente mientras he estado desarrollando la aplicación
es el uso de los widgets (Figura 62) y la gran cantidad de los que ya te ofrece el Material Design.
Gracias a esto en muchas pantallas solo he tenido que ir anidando widgets con otros para formar
los diseños que tenía pensados en los mockups y luego solo he necesitado programar un poco
la lógica de los métodos para que todo funcionara como yo quería. Solo he tenido un
contratiempo al ir anidando widgets. En algunos momentos no sabes en cuál estas o, puesto que
hay muchos dentro de otros, a veces esto te puede hacer perder la perspectiva de lo que estás
haciendo en ese momento.
Figura 61. Ejemplo de librerías de Flutter usadas (Fuente propia)
8.4. Patrón BLOC
Para finalizar con la implementación voy a comentar que la parte más complicada para mí a la
hora de programar la aplicación ha sido implementar el patrón BLOC. Este patrón es un diseño
que desarrolló Google para mejorar el traspaso de datos dentro de las aplicaciones de Flutter ya
que en muchos casos los datos se pueden compartir entre vistas y al mismo tiempo si son
modificados en una, deberían serlo también en la siguiente. Para esto creó un patrón basado en
streams que es muy útil pero un tanto complicado de entender al principio. Otro punto a favor
110
que tiene este patrón es el hecho de poder funcionar perfectamente junto a otros patrones,
como es mi caso que he utilizado MCV al mismo tiempo.
Figura 62. Implementación de widgets (Fuente propia)
111
9. Pruebas y validación
Para verificar que la API cumplía sus funciones y devolvía correctamente lo que pretendía,
realicé pruebas unitarias (Figura 64) de cada una de las rutas que había creado y también creé
diferentes factories9 de Laravel, herramienta que me permitió hacer pruebas de modelos y de
datos de mis servicios. Comprobé que en todo momento estos respondieron correctamente y
mediante el software Postman realicé trazas de todas las rutas.
Figura 63. Logo Postman (Fuente https://www.getpostman.com/)
Postman [21] es una herramienta que se suele usar para el testeo de APIs REST y que nos facilita
otras funcionalidades para testing como es el caso de consumir y depurar endpoints, de
monitorizar la API, escribir pruebas automatizadas para ellas, documentarlas y hacer mockups
de éstas. Este software nos permite que con poca experiencia hagamos grandes pruebas de
testeo y podamos mejorar nuestras APIs permitiéndonos reducir el tiempo que necesario para
programar la API, así como aprender cómo se haría un debug si no se dispusiera de este software
y además realizar las pruebas para comprobar que no hay errores y que todo funciona
correctamente.
Por otra parte, también comprobé la seguridad de los tokens y su tiempo de vida y pude ver que
sin un toquen válido no se podían realizar las llamadas y la API devolvía el mensaje esperado de
no autorizado. Otro punto interesante en la seguridad era comprobar que las Keys secretas de
cada servicio funcionaban y que solo el Gateway podía acceder a estos servicios en nubes
diferentes ya que éste es conocedor de esta key y como en el caso anterior la API respondió
como era esperado, negando el acceso a la ruta de la petición.
9 Los Model Factories nos permiten crear registros de prueba, ya sea para cargar nuestra base de datos con “información falsa” o “información de prueba” o para crear las condiciones necesarias para ejecutar pruebas automatizadas [39].
112
Figura 64. Prueba unitaria ruta alojamientos (Fuente propia)
Por último, la pruebas que realicé en la aplicación fueron pruebas de uso por cada una de las
vistas de la aplicación. Estas las hice desde dos dispositivos móvil diferentes para asegurarme
que no importaba el dispositivo de funcionamiento para un correcto desempeño. Aquí observé
como se realizaban correctamente las peticiones que realizaba desde la aplicación a la API y que
ésta, cuando obtenía la respuesta de la API, rellenaba correctamente la pantalla con la
información obtenida y que se actualizaba como correspondía.
113
10. Resultados
Para finalizar voy a mostrar los resultados conseguidos siguiendo el diseño del proyecto. Como
comento en varios puntos, gracias a las tecnologías empleadas he conseguido obtener
resultados casi idénticos a lo diseñado y si existen pequeñas modificaciones es debido a que
durante la propia implantación del producto se ha considerado que esos cambios eran
favorables para el resultado final o que facilitaban el propio desarrollo de la aplicación.
A continuación, mostraré algunas capturas de pantalla desde un dispositivo móvil y como era el
mockup desde el cual estaba diseñado.
Como se puede observar en la Figura 65, con Flutter se consigue el resultado deseado en el
diseño de una forma rápida y sencilla. En esta primera captura se pude ver que he incluido en la
ventana de inicio un botón más para poder iniciar sesión desde el primer momento.
Como se puede ver en la Figura 68 respecto a la Figura 67, el diseño de la interfaz gráfica es muy
parecida aunque en la versión de la aplicación se han elegido tamaño de fuentes más pequeños
y se ha variado un poco con los colores y los iconos que se muestran.
Figura 65. Captura pantalla Inicio (fuente propia)
Figura 66. Mockup inicio (Fuente propia, elaborado con fluidui.com [30])
114
Las siguientes capturas muestran, en la primera, el formulario reducido de registro del usuario
(Figura 70) para que éste pueda dar de alta su propiedad en la aplicación y, en las dos siguientes,
el perfil de usuario (Figura 71), que al final será el único tanto para la parte de Guest como para
la de Host, y también la captura del menú lateral que le aparecerá al usuario cuando esté en la
parte de la aplicación de Host (Figura 69). Se puede comparar las figuras anteriores también con
sus respectivos mockups. Si comparamos la Figura 70 con la Figura 44, podemos ver que los
cambios son sobre todo la eliminación de las formas cuadradas por bordes redondeados como
también que ahora ya no existe el menú inferior de navegación que ha sido sustituido por un
botón “continuar” que creo que dejará más claro el recorrido al usuario. La Figura 71 equivale a
la Figura 46 aquí podemos ver que los cambios son claramente mínimos. Solo se diferencia un
poco en las tonalidades y que se han eliminado los botones para editar ya que todos los campos
serán editables y ahora cuando algún campo es cambiado y se cambia de vista, el usuario será
informado que se van a actualizar los cambios y, si acepta, esto se producirá. A continuación, en
la Figura 69 se puede ver el menú lateral, que es exactamente igual que en la Figura 45.
Figura 67. Mockup de bienvenida Host (Fuente propia, elaborado con fluidui.com [30])
Figura 68. Captura de pantalla Bienvenida Host (Fuente propia)
115
Figura 70. Captura de pantalla contacto (Fuente propia)
Figura 71. Captura de pantalla Perfil (Fuente propia)
Figura 69. Captura de pantalla Menú Perfil (fuente propia)
116
Por último, podemos ver la captura de pantalla del formulario de inscripción de un alojamiento.
Si comparamos las dos figuras (Figura 73 y Figura 72), podemos ver como apenas hay diferencias
entre ambas, aunque, en el caso de la aplicación, decidí modificar el número de fotos que se
pueden añadir al formulario a solo 4 a fin de reducir el peso de la información que se envía para
crear un alojamiento y también porque las imágenes se ven mejor. Podemos observar otras
Figura 73. Capturas pantalla Formulario alojamiento (fuente propia)
Figura 72. Mockup Formulario de inscripción alojamiento (Fuente propia, elaborado con fluidui.com [30])
117
pequeñas diferencias en las Cards, ya que finalmente he elegido colores más claros, o en los
iconos de las características, puesto que ahora son de color negro en lugar del naranja.
En conclusión, creo que he conseguido obtener resultados muy parecidos a los mockups y esto
ha sido posible gracias a las herramientas que me facilita Flutter que además me permiten crear
una interfaz gráfica muy rápida y con un bonito acabado.
118
11. Conclusiones y trabajo futuro
Para concluir este trabajo, no puedo evitar comparar lo que ha significado su realización con
otra experiencia que me es próxima. Soy una persona que me gusta hacer ejercicio y, en
particular, correr. Esta es una actividad que al principio cuesta. Te has decidido a hacerlo, pero
da mucha pereza empezar. Cuando ya por fin comienzas a correr, a los pocos minutos estás
cansado y luego con molestias por todo el cuerpo. Poco a poco, consigues estar más tiempo,
gustándote más y encontrándote mejor. Al final, correr de forma habitual es casi una necesidad
para encontrarte bien.
Con el desarrollo de este proyecto me ha ocurrido algo parecido. Al principio fue duro: cuesta
decidirte por el proyecto concreto al que dedicarte, buscar toda la información necesaria,
escoger las tecnologías, aprender el uso de nuevos lenguajes y aplicaciones, planificar procesos,
hacer diseños y pruebas y empezar a redactar el trabajo, pero, conforme más me adentraba en
el tema, más conseguía concentrarme y entusiasmarme en mi cometido.
Tanto ha sido el interés y motivación que ha despertado en mí que me ha animado a
comentárselo a mis amigos, informáticos y de otros sectores, y juntos estamos decididos a iniciar
una empresa dedicada a mejorar y desarrollar este producto, de manera que realmente sea
multidispositivo (actualmente va dirigida al móvil) y completando el resto de funcionalidades
que no eran prioridad inicial para la empresa cliente, añadiendo nuevas que se consideren
interesantes y ampliando la cartera de clientes no sólo en el ámbito local sino internacional (y,
por tanto, multilenguaje).
119
Referencias
1. Berná Martinez, J. V. Guía para el Desarrollo de TFG. Grado en Ingeniería Multimedia.
Universidad de Alicante. Mayo 2019.
2. Libro de Estilos para la redacción de trabajos TFG/TFM de la EPS. Disponible en:
https://maktub.eps.ua.es/servicios/gestorContenidos/contenidos/normativaEPS/Pdf/9
910.pdf
3. “El Turismo: Su importancia para la economía española”, Probuen Advisory, marzo de
2017. Disponible en https://www.probuen.es/blog/la-importancia-del-turismo-para-la-
economia-espanola
4. “Así ha crecido el turismo, la industria valenciana de los 16000 millones”, diario El
Mundo, Economía, 28/09/2019. Disponible en https://www.elmundo.es/comunidad-
valenciana/alicante/2019/09/28/5d8e3cebfc6c83d6238b4593.html
5. “Impactos sociales del alquiler turístico”, diario Información, 31/08/2019. Disponible en
https://www.diarioinformacion.com/opinion/2019/09/01/impactos-sociales-alquiler-
turistico/2182098.html
6. “Presentación del Estudio de Impacto social y económico de las viviendas de uso
turístico” de la Federación Española de Asociaciones de Viviendas y Apartamentos
Turísticos (FEVITUR). Disponible en
https://www.fevitur.com/index.php?option=com_content&view=article&id=277:estud
io-impacto-social-y-economico-de-las-viviendas-de-uso-
turistico&catid=19:destacado&Itemid=164&lang=es
7. Ortuño, A. y Jiménez, J. L. Las Viviendas turísticas ofertadas por plataformas on-line:
Estado de la cuestión, Ed. FEDEA, abril 2019. Disponible en
http://documentos.fedea.net/pubs/dt/2019/dt2019-04.pdf
8. “¿Qué es la tarifa de servicio de Airbnb? Centro de Ayuda de airbnb. Disponible en
https://www.airbnb.es/help/article/1857/qu%C3%A9-es-la-tarifa-de-servicio-de-
airbnb?_set_bev_on_new_domain=1574889294_NGQ1YjY0OTRhOWUw
9. ¿Cuánta comisión pago? Ayuda para colaboradores. Disponible en
https://partner.booking.com/es/ayuda/comisi%C3%B3n-facturas-e-
impuestos/%C2%BFcu%C3%A1nta-comisi%C3%B3n-pago
10. Smoobu: Software de alquiler vacacional para la gestión de tus propiedades y tus
reservas. Disponible en https://www.smoobu.com/
120
11. “El poder de las OTA’s, artículo sobre turismo del blog de la Universidad a distancia de
Madrid (Udima). Disponible en https://blogs.udima.es/turismo/el-poder-de-las-otas/
12. “Impacto de Internet en el sector turismo”, blog We are Marketing Global Growth
Agents, Observatorio eCommene Transformación Digital, 7 de noviembre de 2019.
Disponible en https://observatorioecommerce.com/impacto-internet-turismo/
13. “Turismo y tecnología: cómo la tecnología revoluciona el sector turístico”, artíciulo de
Belen Vidal publicada en el blog We are marketing Global Growth Agents, 5 de diciembre
de 2018. Disponible en https://www.wearemarketing.com/es/blog/turismo-y-
tecnologia-como-la-tecnologia-revoluciona-el-sector-turistico.html
14. Software para apartamentos turísticos: diferencias entre PMS, Channel Manager, OTA y
Metabuscador, Checkin, 5 de enero de 2019. Disponible en
https://chekin.io/blog/software-para-apartamentos-turisticos-diferencias-entre-pms-
channel-manager-ota-y-metabuscador/
15. Lucidchart es una herramienta para la comunicación visual y la colaboración
multiplataforma. Se pueden crear diagramas de flujo profesionales, mapas de procesos,
modelos UML, organigrama …, entro otros. Disponible en https://www.lucidchart.com/
16. Postman. Herramienta para análisis de API REST. En forma de plugin para Chrome y
aplicación. Disponible en: https://www.getpostman.com/
17. Pagina proporcionada por el estado Español para servir de guía en el análisis y estudio
de los riesgos existente en el desarrollo tecnológico
https://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Meto
dolog/pae_Magerit.html#.XfrTM2RKiUk
18. Everhour herramienta online para la gestión de proyecto y monitorización de ellos. Su
web es: https://everhour.com/
19. Página oficial de Mysql. La dirección es https://www.mysql.com/why-mysql/
20. Página Mysql de Wikipedia. La dirección es https://es.wikipedia.org/wiki/MySQL
21. Página oficial de Postman. Su dirección es https://www.getpostman.com/
22. Enlace permanente a la ley orgánica 3/2018 de 5 de diciembre sobre la protección de
datos. https://www.boe.es/eli/es/lo/2018/12/05/3/con
23. Manifestó sobre el desarrollo ágil. Su web es https://agilemanifesto.org/
24. Antonio Martel. Gestión práctica de proyectos con Scrum: Desarrollo de software ágil
para el Scrum Master (Aprender a ser mejor gestor de proyectos nº 1)
25. Rafael de las Heras del Dedo, Alonso Álvarez García y Carmen Lasa Gómez. Métodos
Ágiles. Scrum, Kanban, Lean (Manuales Imprescindibles) 1st Edition, Versión Kindle
Anaya
121
26. Pagina PHP de Wikipedia https://es.wikipedia.org/wiki/PHP
27. Página Oficial sobre la documentación de Lumen. https://lumen.laravel.com/docs/6.x
28. Página de la comunidad de habla española de Flutter. La web es https://flutter-es.io/
29. Página oficial de Dart. La web es https://dart.dev/
30. FluidUI herramienta para diseñar prototipos de aplicaciones mediante mockup de las
pantallas. Disponible en https://www.fluidui.com/
31. Google Font repositorio de fuentes de Google. Disponible en https://fonts.google.com/
32. Pub web para los paquetes de Dart y Flutter. Disponible en https://pub.dev/
33. Paul Redmond. Lumen Programmig Guide, Apress, 2016
34. Kelt Dockins. Desig Patterns in PHP ans Laravel, Apress, 2017
35. Moises Belchin y Patricia Juberias. Web Programming with Dart, Apress, 2015
36. Prajyot Mainkar y Salvatore Giordano. Google Flutter Mobile Development Quick Start
Guide, Packt, 2019
37. Matt Stauffer. Laravel Up & Running Second Edition, O’Reilly, 2019
38. Mark Clow, Learn Google Flutter Fast, Amazon Great Britain
39. Styde, Generar registros usando Model Factories en Laravel, disponible en
https://styde.net/generar-registros-con-model-factories-en-laravel/
122
Apéndice I
123
Apéndice II
124
Apéndice III
125
Apéndice IV
126
Apéndice V
USUARIOS:
➔ Gestores aplicación web
Funciones (=¿Qué pueden hacer?) Administrador
Web
Gestión de la aplicación ✓
Aceptar o rechazar solicitudes de registros de empresas de gestión vacacional.
✓
Aceptar o no la gestión de la protección de datos y encargarse de la misma si se acepta.
?
➔ Administradores y otros trabajadores de la Empresa de Gestión de Alquiler
Vacacional (ej. De Yeihost)
Ad (=Administrador), Ge (Gestor), AP (Asistente Personal), L (Limpieza alojamiento), Ro
(Lavandería y Cambio ropa), Re (Reparaciones); F (Formulario)
Funciones (=¿Qué pueden hacer en la aplicación?) A
d
G
e
A
P
L R
o
R
e
Aceptar o rechazar solicitudes de registros de propiedades o servicios. (F1-2)
✓
Revisar la información facilitada por propietarios y por empresas o autónomos que ofrecen servicios para sus propiedades, y modificar la redacción para hacerla más atractiva cara al público. (F3-4)
✓ ✓
Registrar las propiedades en distintas plataformas de publicidad online si se estima conveniente y gestionarlas en las mismas.
✓ ✓
Gestionar todas las propiedades y servicios en la web de la empresa: registro, precios, calendario, reservas...
✓ ✓
Decidir sobre precios y publicar ofertas. Ofertas: Con opciones concretadas en la aplicación (que elige el Ad … cuando quiere), pero además la posibilidad de crear nuevas ofertas (Op1)
✓ ✓
Comunicarse con los distintos usuarios a través del chat interno entrando en la plataforma, mediante la web, correo electrónico o whatsapp.
✓ ✓ ✓
127
Comunicarse con el administrador y editor a través del chat ✓ ✓ ✓ ✓
Generar y firmar (digitalmente) contratos con propietarios de pisos y empresas de servicios (Doc 1-2)
✓
Generar y firmar (digitalmente) contratos con huéspedes en representación del propietario (aquest haurà autoritza l’empresa per signar en el seu nom) (Doc 3)
✓ ✓
Funciones (=¿Qué pueden hacer en la aplicación?) A
d
G
e
A
P
L R
o
R
e
(Generar facturas para propietarios, empresas de servicios y huéspedes. Revisar/Modificar si hay que añadir algo y dar el OK (Doc 4)
✓ ✓
Anotar comentarios en la ficha interna (tipus Smoobu) de una estancia: una petición o observación sobre los huéspedes (Ej. Necesitan cuna, pero no sabanitas)
✓ ✓ ✓
Anotar observaciones o avisos a los trabajadores de la empresa mediante un formulario: Ej. para R: 1,35 + 0,90 + cuna); para A de L: 1 bombilla fundida, falta más detergente, puerta que no cierra… (F5)
✓ ✓ ✓ ✓ ✓ ✓
Rellenar un formulario con el pedido, aviso o instrucciones (por ej. Qué apartamento debe limpiar, si hay cambio de hora habitual (por defecto, a las 10:00h), a qué hora ha de quedar limpio (por defecto a las 13:00h, pero modificable, por si hace falta); qué reparación hay que hacer, dónde…)... (F 8-9)
✓ ✓ ✓
Ver sus conversaciones y mensajes en el chat de la empresa ✓ ✓ ✓ ✓
Asumir las funciones del Asistente Personal (u otros trabajadores) si hace falta
✓ ✓
Marcar servicio realizado (deberá indicar día, hora y persona): entrada/salida, entrega ropa, limpieza apartamento, entrega encargo, reparación...(F10)
✓ ✓ ✓ ✓
Poder añadir un comentario (si hace falta) al mensaje automático previo a la entrada (lo recibirá el huésped 3 días antes del inicio de la estancia) para concretar la hora de llegada, nº de teléfono donde llamar si hay algún retraso, quién recibe...
✓
Informar, asesorar clientes sobre alojamiento/servicio ofrecido, en el chat interno (además de personalmente o por móvil)
✓
128
Facilitar información cultural, gastronómica y turística a los huéspedes en el chat.
✓
Contratar servicios a petición del huésped (ej. reservar un taxi, alquilar una moto acuática, concertar una cita al dentista…) El huésped rellena un formulario con la solicitud que llega al A.P. (F6)
✓
Imprimir el contrato para el check-in. ✓
Funciones (=¿Qué pueden hacer en la aplicación?) A
d
G
e
A
P
L R
o
R
e
(Anfitrión, responsable de llaves) Marcar que se ha realizado el check-in: recibir a los huéspedes, informar sobre propiedad y condiciones, entregarles el contrato y las llaves, cobrar la estancia si no se ha hecho previamente...
✓
Revisar y modificar si hace falta el mensaje automático previo a la salida (lo recibirá el huésped el día anterior al término de la estancia) con las condiciones de la misma: horario, limpieza, donde dejar las llaves...
✓
(Anfitrión/Responsable de llaves) Marcar que se ha hecho el Check-out, cuando se tenga que devolver fianza y que se ha devuelto, o cuánto o si se ha retenido en caso de desperfectos o incidencias y descripción de las mismas. F10
✓
(Anfitrión/Responsable de llaves) Comunicar urgencias (marcar alarma) o incidencias durante el check-in/check-out o comentarios de interés para la empresa en el chat interno mediante el móvil (Op 4)
✓ ✓ ✓ ✓
Gestión del almacén: ver y anotar existencias, balance de entradas y salidas (Op 5)
(Encargar/comprar/contratar suministros y servicios para la empresa y realizar pagos)
✓ ✓ ✓
Gestión contable: ver y anotar gastos e ingresos (Op 6)
Realizar ingresos a clientes (propietarios y a empresas de servicios) ✓ ✓
Realizar devoluciones de cobros ✓ ✓
Elegir las modalidades de cancelación de reservas de alojamientos o servicios para su empresa
✓
129
Comentar sobre los clientes y valorarlos internamente y en otras plataformas (Booking, etc.)
✓ ✓
Atender las quejas o reclamaciones de los clientes (huéspedes o propietarios) recogidas mediante formulario (F11)
✓ ✓
Visualizar datos y estadísticas ✓ ✓
Exportar datos y gestionarlos ✓
Realizar el registro de usuario-propietario de los propietarios que lo soliciten (sobre todo, opción “Relax”). El propietario podrá cambiarse la contraseña.
✓ ✓
Funcionalidad chat:
- Reenviar mensajes/parte de conversaciones del chat y/o seleccionar partes, para copiar modificar y enviar un mensaje nuevo a otros.
➔ Propietarios alojamientos
(Descrición de las modalidades en la pàgina web de Yeihost)
❖ Tipo 1: con las siguientes modalidades sujetas al pago de un porcentaje a la
empresa por estancia + IVA, según los servicios incluidos.
Servicios incluidos según modalidad
Opción
FULL: 25%
Opción*
STANDARD: 15%
Opción*
BASIC: 10%
Registro y publicación del alojamiento en la web ✓ ✓ ✓
Disponibilidad de modelos de Pago de Reserva/Fianza, Contrato de alquiler vacacional y acceso a facturas de cobro.
✓ ✓ ✓
Creación y/o optimización del perfil del alojamiento en las principales plataformas de alquiler vacacional (airbnb, booking…)
✓ ✓ ✓
Atención a los (posibles) huéspedes online: antes, durante y después de la estancia. ( Y uso del chat interno)
✓ ✓ ✓
Contratación o gestión de contratación de ✓ ✓ ✓
130
servicios para los huéspedes
Información turística a los huéspedes durante la estancia
✓ ✓ ✓
Check-in/Check-out: entregar / recoger llaves... ✓ ✓
Gestión* reparaciones, reemplazo de enseres… (*Incluye solo la gestión. Las reparaciones, etc. se facturan al propietario)
✓ ✓
Limpieza alojamiento ✓
Mantenimiento básico (reposición detergentes…)
✓
Lavandería y cambio de ropa. ✓
*Si la empresa detecta una mala gestión de la
limpieza y/o mantenimiento del alojamiento por
parte del propietario, éste asumirá los costes de
subsanación y/o reparación de daños debiendo
de actuar de inmediato o, de lo contrario, lo
gestionará YEIHOST y le cobrará el servicio al
propietario. De tratarse de una situación
reiterada (en más de dos ocasiones en menos de
un trimestre, se le ofrecerá cambiar a la opción
Full o Relax y, de no estar de acuerdo, se
resolverá de inmediato el contrato de gestión de
alquiler vacacional que YEIHOST tiene con el
propietario. Se atenderán las reservas existentes
hasta el momento pero se cerrará la posibilidad
de nuevas reservas.
El A.P. activará el envío de un mensaje de la situación al propietario recordándole (está en las condiciones =contrato de propietario) que tiene que actuar de inmediato o se encargará la empresa y le pasará la factura.
La aplicación registra las veces que se repite la situación (lo puede visualizar el A.P, Co-Ad y Ad para tomar la decisión de ofrecerle el cambio de modalidad o proceder a resolver el contrato. En ambos casos, se enviará un mensaje al propietario (hacen falta los modelos).
el A.P, Co-Ad y AD podrán realizar el cambio de modalidad y cerrar la aceptación de reservas en la plataforma, continuando la gestión de las reservas ya registradas.
Limpieza a fondo de cambio de temporada (limpiar cortinas, mantas, edredones, alfombras, persianas,
retirar/preparar ropa y utensilios de temporada (cosas de playa, ventiladores/ estufas, edredones…), y
sustituir menaje y ropa en mal estado, etc. … (Antes de Semana Santa y a finales de octubre), lo incluye
131
solo la modalidad “Relax”. Se trata de un servicio obligatorio para los propietarios (constará en el
contrato) que se facturará como un servicio extra a la empresa. Indicar precio.
Otros métodos de cobro y pago.
❖ Tipo 2 (“Opción Relax”): reciben una cuota mensual, independientemente de
que haya reservas o no. (Incluye todos los servicios. El propietario se
despreocupa totalmente). Incluye limpieza de cambio de temporada.
Información importante
Funciones ( = ¿Qué pueden hacer?) Propietario tipo 1 Propietario
tipo 2
Registrarse como usuario-propietario ✓ ✓
Solicitar el registro del alojamiento en la web y elegir el tipo y modalidad de alquiler vacacional, completando el formulario inicial sobre la propiedad y autorizando la cesión de datos para ese fin (la interacción entre empresa y propietario y el uso de los datos de la propiedad para su registro y publicación para alquilarla a terceros si la empresa acepta registrarla)
✓ ✓
Comunicarse con los administradores del alojamiento mediante un chat interno desde correo electrónico, facebook y/o whatsapp (o cualquier otra aplicación).
✓ ✓
Propiedad: Completar toda la información sobre la propiedad, datos del propietario, método de pagos, etc. una vez aceptada la propiedad.
✓ ✓
Visualizar e imprimir sus facturas. ✓ ✓
Bloquear períodos en temporada baja para uso personal previa aceptación del administrador (Lavandería y limpieza a cargo del propietario o facturación de servicio).
✓ ✓
Acceder al calendario y visualizar las reservas y cancelaciones
✓
Consultar datos sobre ingresos y pagos. (estadística)
✓
Comentar internamente sobre los huéspedes y valorarlos (1-5) (Propietario o empresa A.P)
✓
132
Contratar servicios
➔ Usuario no registrado (=Cualquier navegador que entre a la web)
Funciones (=¿Qué pueden hacer?) Pu
ed
e
Ver la información sobre los alojamientos y los servicios ofrecidos
Ver el calendario con la ocupación y fechas libres de cada alojamiento en su anuncio (= página donde se publica dicho alojamiento)
Registrarse en la web de la empresa como 1. Huésped, 2. Propietario, 3. Empresa de servicios,
Solicitar Reservar alojamiento y entonces se registra.
➔ Huéspedes
Funciones (=¿Qué pueden hacer?) Pu
ed
e
Registrarse en la web de la empresa para participar en el chat, ver su historial de reservas, recibir ofertas, consultar reservas o pedidos, imprimir factura...
Ver sus conversaciones y mensajes recibidos en el chat de la empresa con el (co)administrador o el asistente personal.
Reservar un alojamiento o servicio.
Cancelarlo según las cláusulas de la empresa
Pagar un alojamiento o servicio
➔ Gestores de otros servicios que quieren ofrecerlos en la web para los huéspedes
(limpiadores, entrenadores personales, cuidadores de niños o personas mayores,
enfermeros, cocineros, chóferes, paseadores perros...??)
Funciones (=¿Qué pueden hacer?) Pu
ed
e
Registrarse como usuario-Empresa de Servicios
133
Solicitar el registro del servicio en la web e informar sobre el tipo de servicio completando el formulario inicial y autorizando la cesión de datos para ese fin (la interacción entre empresa vacacional y empresa de servicios y el uso de los datos de esta última para su registro y publicación para ofrecer los servicios a los huéspedes)
Comunicarse con los administradores de la empresa de alojamientos mediante el chat interno desde correo electrónico, facebook y/o whatsapp (o cualquier otra aplicación).
Completar toda la información sobre el servicio, datos de la empresa que los ofrece, método de pagos, etc. (si el servicio es aceptado)
Acceder al registro de pedidos (con comentarios, si los hubiere) y visualizarlos así como las cancelaciones (si se permiten)
Consultar datos sobre ingresos y pagos.
Comentar internamente sobre los huéspedes clientes del servicio y valorarlos (1-5)
➔ “Servicios Extra”: Servicios adicionales que los huéspedes pueden contratar (encargar
comida, reservar restaurante, limpieza durante la estancia, compra entrada al teatro,
acompañar al médico …) o los propietarios de forma adicional
¿Quién, cómo y qué pueden encargar? ¿Quién o cómo se gestiona o encarga?
El huésped, desde la web, rellenando una
solicitud: Encargar una compra al
supermercado, farmacia, comida para
llevar…
(F4)
Se encarga el Asistente Personal. Se entrega en el alojamiento (por parte del supermercado, etc. o hace la compra y la entrega el A.P.) Pagan la gestión en la plataforma* y en persona cuando reciben lo encargado.
El huésped, desde la web, rellenando una solicitud: Reservar una comida/cena en un restaurante, hora en una peluquería, el taxi para un desplazamiento...
Lo encarga el Asistente Personal. Pagan la gestión en la plataforma* y el servicio en persona in situ.
El huésped, desde la web, rellenando una solicitud: Limpieza del alojamiento durante la estancia, de ropa, planchado, babysitter, acompañante para ir al médico, etc.
Lo encarga el Asistente Personal. Pagan la gestión y el servicio en la plataforma*
El huésped, clicando desde la web: Compra de entrada al teatro, cine...
Enlace desde la plataforma, seleccionan y pagan ellos. (Sugerencias o promociones)
El propietario, clicando desde la web: Solicitud de asesoramiento. El
134
Asesoramiento contable y fiscal sobre ingresos de su alojamiento.
administrador recibirá un mensaje (del propietario identificándolo) y concertará una cita mediante el chat interno.
El propietario, clicando desde la web: Asesoramiento sobre decoración y realización fotos/video para publicitar el alojamiento
Solicitud de asesoramiento y sesión de fotos. El administrador recibirá un mensaje (del propietario identificándolo) y concertará una cita mediante el chat interno.
El propietario, clicando desde la web: Gestión de la contratación de un seguro para alquiler vacacional
Solicitud de la gestión. El administrador recibirá un mensaje (del propietario identificándolo) y concertará una cita mediante el chat interno.
Servicio puntual de limpieza y/o cambio de ropa (en el caso de un propietario modalidad “Standard”) y/o check-in, check-out (en el caso de un propietario de la modalidad “Basic”) desde la web rellenando una solicitud, en la que constará la fecha y hora cuando se necesita el servicio.
Depende de aceptación por parte del Administrador: solo se podrá contratar si hay disponibilidad. El Ad. aceptará/rechazará la solicitud (mediante mensaje automático -el ad. elige “aceptar”o ”rechazar”. El mensaje de aceptación podrá incluir “observaciones” del Ad. e indicaciones de cómo realizar el pago. Cuando realiza el pago, rellenará los datos del propietario, la dirección del alojamiento y las observaciones que estime pertinentes para la correcta realización del servicio.
Requisito de calidad de servicio incluido en el contrato de gestión vacacional:
Servicio de limpieza integral de cambio de temporada (en primavera): mantas, edredones, cortinas, estores, alfombras, etc.
El Ad/Co-ad organiza cuándo (e informa a los propietarios de las modalidades Basic y Standard) y pasa el cobro al propietario
En la modalidad “relax”, está incluido en el contrato y ni se informa de cuándo se hace ni tiene que pagar nada el propietario.
A petición del propietario o por sugerencia de la empresa, desde la web, rellenando una solicitud/aviso de: cambio de vasos, batería, toallas, sábanas, etc. en mal estado,
Pueden reponerlo personalmente los propietarios o encargarlo a la empresa (comprará similares nuevos), que enviará el cargo al propietario. En caso de negarse a reponer las carencias o deterioros, podrá no renovarse el contrato del alojamiento para la siguiente temporada.
*Ver modos de pago
135
★ Tarifas y Modos de pago
PROPIETARIO: Las condiciones de pago de la Opción Relax se acuerdan personalmente con el propietario dependiendo de las características y situación de cada propiedad.
La empresa paga al propietario la mensualidad acordada mediante transferencia bancaria. Habrá un modelo de contrato en el que se añadirán los términos acordados y que se firmará digitalmente
PROPIETARIO: Las tarifas de las opciones Basic, Standard y Full se encuentran reflejadas en el Sitio Web y serán susceptibles de ser modificadas en cualquier momento y sin previo aviso. El precio de estas opciones será un porcentaje sobre el importe total de la reserva de alquiler (Ingreso bruto), ya excluida la tarifa de servicio aplicada por las plataformas de alquiler de inmuebles. El precio mínimo dependerá de la opción contratada y del ajuste de precios de servicios, pudiendo variar sin previo aviso, siendo en estos momentos: Basic 20€, Standard 40€ y Full 60-80€ (dependiendo del tipo de alojamiento).
La empresa paga mensualmente mediante transferencia bancaria al propietario las reservas del mes anterior descontada su tarifa y el cargo de otros servicios si los hubiere. El Ad y Ge puede modificar el porcentaje de las tarifas y añadir servicios realizados.
El porcentaje se aplica al ingreso final de la reserva (ingreso que llega a YEIHOST directamente del huésped o del canal de alquiler de inmuebles, por tanto, ya descontada su tarifa), y su resultado deberá ser superior a 20, 40 y 60-80, según opción Basic, Standard o Full.
HUÉSPED: El precio de la estancia está indicado en el calendario de reservas, aplicándose directamente ofertas o promociones si las hubiera (y reflejándose en la factura al huésped.
El huésped puede pagar* a la empresa mediante la aplicación de “pago seguro” ???
*Otros métodos de pago son (EN ESTOS CASOS EL AD, GE O AP REGISTRARÁN EN LA APLICACIÓN QUE SE
HA EFECTUADO EL PAGO Y ADJUNTARÁN JUSTIFICANTE (BANCARIO O UN RECIBO DIGITAL O FIRMADO A
MANO) :
1. Los canales de alquiler vacacional (Booking, airbnb…) pagan a la empresa mediante
transferencia.
2. El huésped realiza una transferencia*, paga con el datáfono o en mano.
En algunos servicios se realizará el pago fraccionado, por ejemplo, en estancias de temporada de
invierno que duran varios meses, los huéspedes pueden hacer un ingreso mensual.
★ Solicitud de registro de alojamiento
Propietarios Está aquí
★ Ficha de registro (propietario / huésped / empresa que ofrece servicios)
136
★ Información sobre protección de datos y autorización para la cesión de los mismos
Mirar al final “Cookies” y “Política de privacidad”
★ Responsable de llaves o anfitriones (A.P o propietarios y anfitriones externos)
- Datos sobre entradas y salidas
137
El propietario/anfitrión ve la información sobre su alojamiento en su perfil en la plataforma. (Ver ejemplo
de Booking, más abajo)
Además recibe un aviso (mediante correo electrónico de la próxima salida/entrada con 2 días de
antelación.
Ejemplo de mensaje automàtico de airbnb:
XXX Exemple de booking on està la pàgina d’inici. (Aquesta pàgina d’inici l’haurien de poder vore
a) dels apartaments de les modalitats “Full” i “Relax”, els A.P. i b) dels apartaments de les
modalitats “Standard” i “Basic”, els propietaris. A més, l’Ad i Ge haurien de poder vore-ho tot,
triant la funció d’A.P. o “Propietari”.) Es veu ( a més de les dades de cada allotjament):
- ID: número. Crec que sí hauríem d’assignar un número (0001), que no es puga canviar.
- NOMBRE: Una vegada posat, que només el puga modificar l’Administrador o (Co-) per decisió
de promoció i per petició del propietari si es considera adient, sempre de forma excepcional.
- Ubicació: Sí, amb el país (malgrat els de Yeihost seran tots d’ací)
- Estado: molt interessant, poder tenir-ho tancat, per si està revisant-se, o cal tancar-lo
temporalment perquè estan fent una reforma, etc, però que no es borre.
- Entradas/salidas para hoy y mañana: està molt bé que avise amb antelació, per poder fer
preparatius. Si es clica sobre el numeret en color blau (imatge 1) porta al resum de reserves. (imatge 2)
- Mensajes de los clientes. Amb un numeret indica quants missatges hi ha i si cliques damut,
porta als missatges.
138
- Mensajes de Booking: Igual que dalt. Ací serien els avisos de Yeihost per al propietari
(modalitats “Standard i Basic) o a l’Assistent Personal (modalitats “Full” i Relax”)
- Calendario ver todos los alojamientos (se puede reservar, bloquear...y se entra)
ejemplo airbnb
En Smoobu està molt bé: https://login.smoobu.com/es/cockpit
139
- Responsabilidades del anfitrión (check-in /check-out y durante la estancia)
Antes del check-in
(Puede hacerlo “el anfitrión” (quien recibe y entrega las llaves) o “la gobernanta o la camarera de hotel” (quien se encarga de la limpieza y cambio de ropa)
El anfitrión o asistente personal responsable de llaves deberá hacer o comprobar que se han realizado las siguientes tareas o encargarse de que estén hechas antes de la entrada de los huéspedes:
- Comprobar el horario de entrada y número y tipo de clientes (edades, ej. 3 personas todo camas individuales…) y si hay algún aviso: cama extra, cuna, trae animales…
- Comprobar que hay ropa de cama sábanas y toallas suficientes (al menos un juego para cada huésped para estancias de hasta 8 noches y dos juegos por persona a partir de 9 noches.)
- Conectar la electricidad, el agua, el termo para el agua caliente (o poner una bombona de butano llena) y enchufar la nevera.
- Reponer papel higiénico, servilletas de papel, jabón de manos, gel y champú, lavavajillas y productos para lavavajillas eléctrico, detergente para vitrocerámica y hoja de espátula nueva, detergente lavadora y suavizante, otros productos de limpieza (al menos, detergente suelos, detergente aseo y limpiacristales) y bolsas de basura.
- Comprobar que está todo limpio y ordenado y que el alojamiento tiene un aspecto acogedor y un aroma agradable.
- Llegar puntual al alojamiento para recibirles (antes de la hora acordada). Si se retrasan, contactar y esperarles el tiempo necesario.
Durante el check-in
- Sea amable e informe de los datos más relevantes sobre el alojamiento (normas de la comunidad, instrucciones de uso de electrodomésticos, etc.) y facilite algún dato de interés que pueda serle útil sobre la localidad (playas, instalaciones deportivas, supermercados, restaurantes, etc). Indíquele cómo puede encontrar más información en nuestra web.
- Recuerde al huésped la hora de salida (o acuérdela con él si lo solicita y es posible: no hay una entrada el mismo día o los próximos huéspedes entran más tarde)
- Entregar el contrato para terminar de rellenar los datos y firmarlo en papel (entregue una copia al huésped y la otra al propietario/empresa) o digitalmente.
- Si no han pagado la estancia con antelación, deberán hacerlo a la entrega de llaves y firma del contrato en metálico o mediante tarjeta electrónica o transferencia bancaria in situ.
- Si han entregado un depósito para la reserva, haga referencia al contrato donde explica que queda como fianza y se devolverá a la salida después de comprobar que el alojamiento queda en buenas condiciones y sin desperfectos. Si tienen que entregarla o la fianza es una cantidad mayor, se cobrará en metálico o con tarjeta o transferencia en ese momento.
- Solicite permiso y haga una foto con el móvil de ambas caras del documento de identificación de cada huésped.
140
- Proporcione su número de teléfono o el del Asistente Personal que atenderá a los huéspedes durante su estancia (si no va a ser usted) y anímeles a contactar para lo que necesiten.
Durante el check-out
Para asegurarse de una salida satisfactoria, deberá:
- Comprobar el horario de salida y si hay algún aviso. Si hay alguna duda, deberá contactar al menos el día anterior con el huésped.
- Llegue puntualmente a la hora fijada y realice el control necesario. Controle el estado general de la vivienda y, en especial, el inventario.
- Cobre los gastos extra -si los hubiera- en metálico, tarjeta o transferencia bancaria al momento.
- En caso de fianza, si hay desperfectos devuélvala de la misma manera (en metálico, tarjeta o transferencia). Si los hubiera, y se pacta una cantidad, réstela y devuelva el remanente. Si se tiene que solicitar un servicio y/o realizar una compra, se enviará la factura y cargará en la cuenta del huésped.
- Si el huésped desea realizar una nueva reserva, puede hacerlo directamente en nuestra aplicación. Si el huésped paga en metálico o con tarjeta, también lo puede registrar el A.P. en la aplicación y si prefiere que no se le devuelva la fianza para que quede para la próxima reserva, el anfitrión lo hará constar en la aplicación.
En el caso que se haya acordado con los huéspedes que pueden salir sin esperar la visita del anfitrión, si hay algún gasto o desperfecto se les cargará directamente en la cuenta y si han entregado fianza se les devolverá (descontados los gastos o desperfectos si los hubiera) dentro de un período de 48 h.
Después del check-out
- Se limpiarán todas las habitaciones y zonas que puedan usar los huéspedes, en especial, los dormitorios, los baños, la cocina y la sala de estar.
- Se retirará la basura y todo lo que hayan dejado los anteriores huéspedes. Si hay algo que se considere de valor o de interés para los mismos, se contactará con los anteriores huéspedes por si pueden recogerlo. En caso de no contactar o de no poder recogerlo, se informará y entregará a Yeihost para que gestione su devolución.
- Se repondrán los productos de limpieza y aseo - Se anotarán los desperfectos y faltas y se comunicarán a la empresa.
141
Apéndice VI
A) FORMULARIOS (F1, F2 …)
1. Solicitud de registro de alojamiento vacacional
Datos de contacto
Nombre* … Apellido(s)* ….
Correo electrónico* …..
Teléfono* ……..
¿Dónde está ubicada tu casa de vacaciones?* (Localidad) ……………...
Tipo de inmueble (apartamento, casa rural…)* ………………………….
Antigüedad:
Estado* Seleccionar nuevo / buen estado / por reformar / por redecorar
Características principales* (En desplegable. Se puede elegir más de una opción): 1a línea al mar,
vistas al mar, en la playa, en el centro de la ciudad, en el campo, parking, aire acondicionado, WIFI,
piscina; otros (especificar)......................
Observaciones: …
¿Dispone de código de registro turístico? Sí / No.
Adjuntar fotos (entre 5 y 8)
También puedes contactar con nosotros:
Por email: [email protected]
Por teléfono: 675766276 y 694464714
En nuestras oficinas: (dirección) calle Constitución, nº3, Bajo 3 de Villajoyosa
Horario de 10:00 a 13:00 h y de 17:00 a 19:00 h.
142
2. Solicitud de registro de servicios para alojamientos vacacionales
Datos de contacto
Nombre* … Apellido(s)* ….
Correo electrónico* …..
Teléfono* ……..
¿Dónde realizas tu actividad?* (Localidad) ……………...
Tipo de servicio (reparaciones y obras, limpieza, baby-sitter…) ………………………….
Características principales del servicio: …..
Observaciones: …
Adjuntar currículum
También puedes contactar con nosotros:
Por email: [email protected]
Por teléfono: 675766276 y 694464714
En nuestras oficinas: (dirección) calle Constitución, nº3, Bajo 3 de Villajoyosa
Horario de 10:00 a 13:00 h y de 17:00 a 19:00 h.
3. Registro de alojamiento vacacional
Formulario alojamientos
4. Registro de servicios para alojamientos vacacionales
Formulario servicios
5. Solicitud de servicio para anfitrión de alojamiento vacacional
(Desde su usuario hacen el pedido y sus datos se autorellenan a la solicitud. Cuando
teclean el nombre del alojamiento, aparece automáticamente el número de referencia
del mismo. O bien se abre un desplegable con las propiedades que tiene el anfitrión y
elige)
143
Datos de contacto del propietario/anfitrión
Nombre xxxxx Apellido(s) xxxxxxx
Correo electrónico xxxxxxxxxxxxxxx Teléfono xxxxxxxxx
Alojamiento …………………….. Referencia xxxxxxxxxxx
Servicio que solicita (limpieza de final de temporada, check-in…) ………………………….
¿Para cuándo lo solicita? (fecha) .. / .. / ....
(horario) A las : …. h. / Entre las …. y …… h.
Observaciones: …
También puedes contactar con nosotros:
Por email: [email protected]
Por teléfono: 675766276 y 694464714
En nuestras oficinas: (dirección) calle Constitución, nº3, Bajo 3 de Villajoyosa
Horario de 10:00 a 13:00 h y de 17:00 a 19:00 h.
6. Solicitud de servicio para huéspedes
(Como en la ficha anterior) Ejemplos de servicios: reservar un taxi, alquilar una moto acuática, concertar una cita al dentista…) El huésped rellena un formulario con la solicitud que llega al A.P. e indica la fecha en que se ha realizado la solicitud.
Datos de contacto del huésped
Nombre xxxxx Apellido(s) xxxxxxx
Correo electrónico xxxxxxxxxxxxxxx Teléfono xxxxxxxxx
Alojamiento xxxxxxxxxxxxx Referencia xxxxxxxxxxx
144
Estancia actual xxxxxxxxx
Servicio que solicita (limpieza durante la estancia, baby-sitter…) ………………………….
¿Para cuándo lo solicita? (fecha) .. / .. / ....
(horario) A las : …. h. / Entre las …. y …… h.
Observaciones: …
También puedes contactar con nosotros:
Por email: [email protected]
Por teléfono: 675766276 y 694464714
En nuestras oficinas: (dirección) calle Constitución, nº3, Bajo 3 de Villajoyosa
Horario de 10:00 a 13:00 h y de 17:00 a 19:00 h.
7. Parte de daños y avisos sobre reservas (carencias, desperfectos...)
Rellena AP, L, Ro e incluso el huésped si detecta algo; lo recibe el Ge (ve también AP)
Fecha de registro
¿Quién registra? (Elegir: huésped/AP/anfitrión/limpieza/Otro….
Nombre y apellidos de la persona que informa
Alojamiento
(Nombre o nº Registro)
Incidente o daños detectados
¿Desde cuándo?/¿Cuántas veces?
Alojamiento
8. Registro (calendario) de servicios de lavandería y limpieza o lavandería+limpieza
Con un documento tipo excel (para que se pueda ordenar según la columna que
interese: el alojamiento, la fecha de entrada…), que se vaya actualizando (documento
de trabajo colaborativo tipo google) con nuevas reservas y cancelaciones, y con la
145
posibilidad de que distintas “personas” solo puedan ver la información que les
concierne: sobre la ropa (empresa encargada de la lavandería, Yeihost o empresa
externa), o sobre la limpieza del alojamiento (igual), el A.P. lo podrá ver todo, un
anfitrión externo o propietario solo lo que él se encargue de sus alojamientos
(modalidad “Standard”).
En la columna del encargado, figurará el nombre de la persona que hará de anfitrión,
o de la mujer de la limpieza o la “camarera de hotel”, o de la responsable de la
lavandería, etc. y cada nombre de responsable llevará un enlace que llevará a las
“Observaciones” con las instrucciones que sean necesarias. (1ª tabla: para Ad/Ge/A.P))
Estaría bién que esta tabla se desdoblara en distintas tablas según la persona a la que
va dirigida (ver tabla 2(Persona de limpieza: Isabel), 3(Propietaria Opción Standard:
Mariana)...
REGISTRO DE SERVICIOS DE CHECK-IN, CHECK-OUT, LIMPIEZA Y/O LAVANDERÍA
Fecha de actualización: - - / - - / - - - -
Alojamiento Entrada Salida Lavandería Limpieza
Nombre Nº Reg.
Fecha y hora
Encargado/nº p.
Fecha y hora
Encargado. Fianza?
Tope de entrega
Encargado
Fecha y hora
Encargado
Gavina Azul
A001 23-12-19
17:00
Josep
2+1 (7)
06-01-20
10:00
Josep 06-01-20
09:00
Yeihost*1 20-01-20
10:00
Isabel*3
Palasiet A003 01-01-20
13:00
Jaume
2
29-02-20
10:00
Jaume ? Yeihost*2 02-03-20 Isabel*4
Varadero
A004 04-01-20
10:00
Josep
2
18-01-20
10:00
Jaume 18-01-20
10:30
Mariana 18-01-20
10:30
Mariana
Gavina Azul
A001 06-01-20
13:00
Josep
2+2 (8,5)
20-01-20
10:00
Josep 20-01-20
09:00
Yeihost*1 20-01-20
10:00
Isabel*3
Varadero
A004 01-02-20
13:00
Jaume*5
3
29-02-20
10:00
Josep 29-02-20
10:30
Mariana 29-02-20
10:30
Mariana
146
Paraíso A005 02-03-20
13:00
Josep
4
23-03-20
10:00
Josep 21-03-20
12:00
Tintorería Cantó
23-03-20
10:00
María
Varadero
A004 29-02-20
15:00
Jaume*6
3+1(0.6)
16-03-20
10:00
Jaume 29-03-20
10:30
Mariana 29-03-20
10:30
Mariana
Exemples de què hauria en el link: *1 Próxima entrada hoy. Huéspedes: 2 adultos + 2 niños (8, 5)
*2 Se limpia y ponen lavadoras en el apartamento. No hacer camas.
*3 Te recogerá Josep delante de “Los Argentinos” a las 9:50 h...
*4 Te espera Jaume en el apartamento a las 10:30h ...
*5 Tareas pendientes: Lavandería y hacer camas.
*6 Hace falta cuna.
REGISTRO DE SERVICIOS DE CHECK-IN, CHECK-OUT, LIMPIEZA Y/O LAVANDERÍA
Fecha de actualización: - - / - - / - - - -
Alojamiento Limpieza
Nombre Nº Registro Fecha y hora Encargado Observaciones
Gavina Azul
A001 06-01-20
10:00
Isabel Te recogerá Josep delante de “Los Argentinos” a las 9:50 h. Entran hoy. Retirar ropa y hacer camas.
Gavina Azul
A001 20-01-20
10:00
Isabel Te recogerá Josep delante de “Los Argentinos” a las 9:50 h. Entran mañana. Poned alguna lavadora para secar en oficina. Haced camas.
Palasiet A003 02-03-20 Isabel Te espera Jaume en el apartamento a las 10:30h. No hay entrada próxima. No se hacen camas. Poned lavadoras y tender ropa. Limpieza más a fondo.
REGISTRO DE SERVICIOS DE CHECK-IN, CHECK-OUT, LIMPIEZA Y/O LAVANDERÍA
Fecha de actualización: - - / - - / - - - -
Alojamiento Entrada Salida Lavandería Limpieza Observaciones
Nombre Nº Reg.
Fecha y hora
Encargado/nº p.
Fecha y hora
Encargado. Fianza
Fechaentrega
Encargado
Fecha y hora
Encargado
147
Varadero A004 04-01-20
10:00
Josep
2
18-01-20
10:00
Jaume 18-01-20
10:30
Mariana 18-01-20
10:30
Mariana
Fecha sugerida de limpieza
Varadero A004 01-02-20
13:00
Jaume
3
29-02-20
10:00
Josep 29-02-20
10:30
Mariana 29-02-20
10:30
Mariana
Entrada hoy.
Varadero A004 29-02-20
15:00
Jaume
3+1(0.6)
16-03-20
10:00
Jaume 29-03-20
10:30
Mariana 29-03-20
10:30
Mariana
9. Registro (calendario) de servicios de reparación y/o reposición de artículos
(Información sobre reparaciones solo al electricista, fontanero, cerrajero...concreto
(la persona o empresa) (a un correo electrónico y/o móvil). El A.P. También ve esta
información y además qué hace falta reponer del almacén, comprar, etc. -también
el propietario (si se encarga él).
10. Recordatorio tareas, confirmación de que se han realizado (con fecha, horario y
identificación de quién confirma) y comentarios (sobre los huéspedes, alguna
sugerencia, etc. -no el parte de daños que és el F8): check-in, check-out...
11. Quejas o reclamaciones (de huéspedes o propietarios)
QUEJAS O RECLAMACIONES
Nombre …………. Apellidos ……………..
Correo electrónico ……………………………………… teléfono …………………..
Huésped ⟏ / Propietario ⟏
Indique el alojamiento y estancia (fecha de entrada): --/--/---- y/o fecha de los hechos o de detección
de la situación: --/--/----
Describa brevemente la situación o qué ha ocurrido: …
Indique qué solicita: …
Intentaremos ponernos en contacto lo más rápido posible.
148
Atentamente
Yeihost S.C.
12. Registro de “Gestión deficiente” por parte del anfitrión/propietario
13. ….
B) OPCIONES EN LA APLICACIÓN, que elige o crea el Ad/Ge/AP (O1, O2 ....)
1. Estancias (ficha tipo “Smoobu” con la información
En “Estado”, botón para activar las reservas canceladas. Por defecto ✓ (= sincronizado sin
errores.
Llegada Salida Alojamiento
Huésped Portal de reserva
Creado Estado
Antes hay otro botón de “Añadir reserva”
Link que abre la información siguiente
Lleva a un enlace donde se puede: añadir más
información, editar la reserva o cancelarla
Al clicar sobre editar, se puede rellenar:
Reserva: Portal (reserva directa / Booking…), Alojamiento
(desplegable para elegir entre los alojamientos registrados),
llegada, salida, Nombre (del huésped), (núm de) adultos,
niños, bebés (hasta 2 años),
149
Detalles: email, teléfono, idioma, (hora de) entrada, salida,
precio, un recuadro para marcar si pagado, depósito, un
recuadro para marcar si pagado, Notas, Nota para
colaboradores.
Botones de “Guardar” y “Cancelar”.
Los datos se pueden exportar a un documento de excel.*
*Columnas del excel: A Núm. de reserva, B llegada, C Salida, D Alojamiento, E Huésped, F Portal de reserva,
G Creado, H email, I teléfono, J Dirección, K Adultos, L Niños, M Bebés, N hora check-in, O hora Check-out,
P Notas, Q Precio, R Pagado, S Depósito, T Pagado, Núm. de noches, Estado, Nota para colaboradores
2. Ofertas
Periodo (en que se aplica = fechas en que las reservas tienen el descuento si aceptan
las condiciones -en caso de que las haya): ………….
Designación: madrugador (si se reserva con más de 6 meses de antelación), última
hora, final de temporada, escapada, puente, Black Friday, semanal, mensual, larga
temporada... …… (desplegable con nombres de ofertas y posibilidad de poner nuevos
nombres inventados)
Descuento: % (aplicable a la tarifa de cada noche)
150
Condiciones: No reembolsable / 1ª noche no reembolsable / …… noches mínimo /
tarifa mínima 80€ / tarifa mínima 60€ / X (mismas condiciones que tarifa estándar).
(desplegable que se pueda elegir más de una opción)
Alojamiento (al que se aplica, poder elegir más de uno a la vez): ………. (desplegable
con todos los alojamientos ofertados)
Además hace falta:
Fecha de publicación de la oferta en la web (cuándo quieren que empiece a verse la
oferta)
Fechas para hacer la reserva (desde cuándo pueden empezar a reservar y hasta
cuándo): …. (¿Desde día de publicación en la web hasta noche anterior a terminar la
oferta/ estancia mínima estándar de las fechas elegidas?)
Obtener estadísticas de cómo ha funcionado la oferta (ex. Booking)
3. Envío mensajes automáticos:
* Para reservas internas, no las que se han hecho mediante canales de alquiler como
Booking, airbnb, etc. ya que ellos ya lo hacen)
3.1 Recordatorio al anfitrión de la próxima entrada*
Lo recibirá el anfitrión (es decir, la persona que recibe a los huéspedes, sea el propietario -opción “BASIC”-
o el A.P. -para las demás opciones) 3 días antes del inicio de la estancia.
151
(Nombre del huésped) xxxxx llega el (día de la semana: lunes...) xxxxx, (fecha) xx de (mes) xxxx
¡Asegúrate de que el alojamiento está limpio y preparado!
Además, no te olvides de enviar un mensaje a (nombre del huésped) para explicarle cómo llegar al alojamiento y concretar la hora de llegada, dónde y cómo te localizarán y otros detalles que puedan ayudar a personalizar su estancia y que sea más cómoda y agradable.
Alojamiento (nombre) xxxx y referencia (número de registro) xxxx
Estancia: del (dia) xx de (mes) xxxxx de (año) xxxx al (dia) xx de (mes) xxxxx de (año) xxxx
Hora aproximada de llegada: xx:xx h ; Hora aproximada de salida: xx:xx h
Huéspedes: xx adultos, xx niños (edad(es) xx, xx,….)
Completa:
Anfitrión (nombre de quien recibirá)..................... nº tf móvil ………………………...
(Espacio para escribir el mensaje)
Enviar
(La información con xxxx se autorellena de los datos de la reserva. Por tanto, el anfitrión solo tiene que
rellenar la información de la tabla. Esta información se pasará automáticamente al mensaje que se envía
al huésped 2 días antes de la entrada.) l
3.2 Recordatorio al huésped de la proximidad de la estancia*
(Lo recibirá el huésped 2 días antes del inicio de la estancia) para concretar la hora de
llegada, nº de teléfono donde llamar si hay algún retraso, quién recibe…
152
Nº de referencia del alojamiento en Yeihost: (número de registro) xxxxx
Estancia: del (dia) xx de (mes) xxxxxx de (año) xxx al (dia) xx de (mes) xxxxx de (año) xxxx.
Huéspedes: xx. adultos, xx niños (edad(es): xx, xx ...)
Hola, (Nombre del huésped) el (día de la semana: lunes...) xxxx, (fecha) xx de (mes) xxxx le(s) esperamos en (nombre) xxxxx (y dirección del alojamiento) xxxxxx
La persona que les recibirá se llama (nombre del anfitrión) xxxxx y le ha enviado un mensaje (enlace al mensaje de O3.1 o que se vea aquí) xxxxxxxxx
Contacte con su anfitrión cuando se encuentre a una distancia de media hora del alojamiento, o en caso de retraso... y siempre que lo necesite. Nº de tf móvil: xxx
Para que se encuentren más cómodos durante su estancia, necesitamos su colaboración:
Marque con una X las habitaciones y/o camas que necesitarán:
Habitación 1, con cama doble: ⟏
Habitación 2, con 2 camas individuales: una cama ⟏, las dos camas ⟏
Habitación 3, con 2 camas individuales: una cama ⟏, las dos camas ⟏ *
Cama supletoria ⟏ o cuna ⟏.
Consulte la hora aproximada de llegada y salida. ¿Es correcta? Marque el tick.
Hora aproximada de llegada: xx:xx h (botón con tick)
Hora aproximada de salida: xx:xx. h (botón con tick)
¿Necesita proponer algún cambio? Envíe un mensaje y pregunte a su anfitrión si es posible el cambio de horario. Aproveche para plantear otras dudas que tenga.
Esperamos que tengan un buen viaje y estamos deseosos de recibirles.
Hasta pronto
(* Esta opción se debería activar automáticamente para alojamientos de 3 habitaciones. Sería
conveniente que se pudieran añadir más filas, por si después hay pisos de 4 o más habitaciones.
Si las filas no se pueden vincular al número de habitaciones, debería ser el Ad, Ge y/o AP quien
pudiera marcar qué filas se ven. Igualmente, la fila de cama supletoria se debería ver solo si se
ha acordado previamente, es decir, el Ad/Ge o AP lo marcará (si se lo han solicitado) después de
comprobar que hay disponibilidad.)
153
3.3 Recordatorio al anfitrión de la próxima salida*
3.4 Recordatorio al huésped de la próxima salida*
3.5 Invitación al huésped a valorar su estancia para Yeihost
3.6 Invitación al anfitrión a valorar a los huéspedes para Yeihost
3.7 Mensaje al propietario por gestión deficiente
*Si la empresa detecta una mala gestión de la limpieza y/o mantenimiento del alojamiento por
parte del propietario, éste asumirá los costes de subsanación y/o reparación de daños
debiendo de actuar de inmediato o, de lo contrario, lo gestionará YEIHOST y le cobrará el
servicio al propietario. De tratarse de una situación reiterada (en más de dos ocasiones en
menos de un trimestre, se le ofrecerá cambiar a la opción Full o Relax y, de no estar de acuerdo,
se resolverá de inmediato el contrato de gestión de alquiler vacacional que YEIHOST tiene con
el propietario. Se atenderán las reservas existentes hasta el momento, pero se cerrará la
posibilidad de nuevas reservas.
El A.P. activará el envío de un mensaje de la situación al propietario recordándole (está en las condiciones =contrato de propietario) que tiene que actuar de inmediato o se encargará la empresa y le pasará la factura.
La aplicación registra las veces que se repite la situación (lo puede visualizar el A.P, Co-Ad y Ad para tomar la decisión de ofrecerle el cambio de modalidad o proceder a resolver el contrato. En ambos casos, se enviará un mensaje al propietario (hacen falta los modelos).
el A.P, Co-Ad y AD podrán realizar el cambio de modalidad y cerrar la aceptación de reservas en la plataforma, continuando la gestión de las reservas ya registradas.
Limpieza a fondo de cambio de temporada (limpiar cortinas, mantas, edredones, alfombras, persianas,
retirar/preparar ropa y utensilios de temporada (cosas de playa, ventiladores/ estufas, edredones…),
y sustituir menaje y ropa en mal estado, etc. … (Antes de Semana Santa y a finales de octubre), lo
incluye solo la modalidad “Relax”. Se trata de un servicio obligatorio para los propietarios (constará en
el contrato) que se facturará como un servicio extra a la empresa. Indicar precio.
154
4. Registro de “Gestión deficiente” por parte del anfitrión/propietario
Ver 3.7 (arriba), contar las veces y a la 3ª enviar aviso para cambio de Opción del
propietario.
5. Marcar alarma (y enviar mensaje)
En el caso de una urgencia en cualquier momento, la marca quien tiene la información y
escribe un mensaje y lo recibe quién debe gestionarla. Admite respuesta.
6. Gestión del almacén
Registro de existencias (qué, tipo, cuántos, medida, descripción, fecha de adquisición,
ubicación, observaciones, fecha de baja
Compras y adquisiciones: balance de entradas y salidas: (qué y fecha de adquisición-
enlazado con el documento anterior-, precio, proveedor, datos del proveedor
7. Gestión contable
Excel? Con salidas (gastos y devoluciones) e ingresos (Veure el link) mensual y anual
¿Pueden cargarse automáticamente los ingresos de las reservas? ¿Puede repetirse un
gasto mensualmente (por ejemplo, el sueldo de un empleado) y modificar la cantidad (si
cambia el sueldo) o anularlo (si es despedido)?
Contabilidad
https://docs.google.com/spreadsheets/d/15Dk-
BkraaSgq1gIn0yYfjGAZzZYXw1C8i8EWM42fYs4/edit?usp=sharing
Datos totales por reserva (todo lo relativo a una reserva debería estar junto)
https://docs.google.com/spreadsheets/d/1FQifcoypVT0899n6IUQd95GGtWtveaY9V7v_
E_1i9Ww/edit#gid=634683453
Facturas
155
Factura
C) DOCUMENTOS
1. Contrato con el propietario/arrendador/anfitrión
2. Contrato de servicios
3. Contrato con el huésped (Modelo facilitado a propietarios)
4. Facturas para propietarios, empresas de servicios y huéspedes.
5. Modelo de pattye de entrada de viajeros (Guardia Civil?)
https://drive.google.com/file/d/1yyVI978RJb0wdtGlo4OZjt7G2n9e745d/view?usp=sha
ring
6. Contrato de reserva /entrega de fianza
156
Apéndice VII
FACTURA Nº
Fecha:
Nombre: Yeihost S.C. Domicilio: Calle constitución n3 Bajo 3
Provincia: Alicante
C.I.F o N.I.F: J-42600676
Cliente:
N.I.F
Domicilio:
C.P. /Municipio/Provincia
Telf: /Fax.
Correo electrónico:
CANTIDAD CONCEPTO PRECIO TOTAL
SUMA
IVA EXENTO
SUMATOTAL 7
157
Apéndice VIII
CONTRATO DE ARRENDAMIENTO VACACIONAL
Villajoyosa a …… de ……..……… de 2019
REUNIDOS
De una parte Yeihost SC, empresa con domicilio en calle Constitución, nº3, Bajo 3 de
Villajoyosa, correo electrónico [email protected] y n.º tf 694464714 y 696158314, con
CIF J42600676, actuando en representación del propietario del inmueble (en adelante
denominado “El Propietario o Parte Arrendadora”).
Y de otra parte Don/Dña. ………………………………………………………….. mayor de edad,
con domicilio en
........................................….........…........…............…..............….......................................... y
con DNI / PASAPORTE .................................., correo electrónico
……………………………………………………….… y n.º de teléfono..................................,
(acompañado/a de las siguientes personas (nombre y DNI/Pasaporte) en adelante
denominado(s) “El arrendatario o Parte Arrendataria”):
Ambas partes se reconocen capacidad legal suficiente para este acto y libremente,
EXPONEN
I. Que el Propietario es titular de la siguiente finca en perfecto estado de uso:
VIVIENDA: Dirección: , Villajoyosa, 03570,
(Alicante), en las condiciones y con los muebles y servicios cuya descripción y
fotografías se exponen en la página web yeihost.com, con nombre de referencia
……………………..
La vivienda se encuentra limpia, en perfecto estado de uso, conservación y habitabilidad y los
suministros y servicios que posee la misma se encuentran en funcionamiento.
II. Ambas partes han acordado concertar el arrendamiento por temporada de la finca antes
descrita, por lo que establecen el presente contrato, que se regirá por lo dispuesto en las
siguientes,
CLÁUSULAS
PRIMERA.- OBJETO
El Propietario cede en arrendamiento de temporada por la duración que se indica en la
cláusula tercera a la Parte Arrendataria, que acepta, la finca descrita.
SEGUNDA.- RENTA Y FIANZA
2.1 La renta de la temporada es de……………………………. euros (.....….€), pagados a
(plataforma) ………………….. con anterioridad a la entrada en la finca por la Parte Arrendataria/
al Propietario a la llegada / con anterioridad. La fianza de ……….... € se devolverá después de
comprobar que el piso queda limpio y en condiciones antes de la salida.
TERCERA - DURACIÓN
158
Este contrato se otorga por la temporada de ……….. noches, desde el día ….. de …………. de
19.. , a partir de las 13.00 am, y quedará automáticamente resuelto sin necesidad de aviso
alguno, el día ….. de …………. de 19.. a las 10:00 a.m. y sin que quepa prórroga del mismo
salvo acuerdo escrito entre las partes, a las 10.00 pm debiendo la Parte Arrendataria entregar
las llaves con anterioridad.
CUARTA - OBLIGACIONES DE LAS PARTES
4.1 La Parte Arrendataria se obliga a conservar la vivienda en perfecto estado durante el plazo
de duración libremente pactado entre ambas partes y a la finalización del contrato dejará el
alojamiento en el estado en que lo encontró, todo limpio y recogido y libre de basura, comida,
revistas u otros objetos pertenecientes al inquilino y con los servicios de que dispone en perfecto
estado. Puede dejar un juego de sábanas y toallas por huésped preparados para la lavadora.
4.2 La Parte Arrendataria no podrá realizar en la vivienda actividades molestas, insalubres,
nocivas, peligrosas, ilícitas o contrarias a los Estatutos de la Comunidad. Tampoco podrá
almacenar materias inflamables, explosivas o corrosivas en la vivienda y/o desarrollar en la
misma actividades mercantiles o de industria.
4.3 La Parte Arrendataria será directa y exclusivamente responsable y exime de toda
responsabilidad a la propiedad por:
- Los daños que puedan ocasionarse a personas o cosas y sean derivados de mal uso por la
Parte Arrendataria de instalaciones para servicios y suministros de la casa de temporada
arrendada.
- Los daños, deterioros o pérdidas que se produzcan en la misma, ya sean causados por la
Parte Arrendataria o por las personas que convivan en la vivienda.
4.4 La Parte Arrendataria no podrá hacer obras, ni introducir modificación alguna sin permiso
escrito del Propietario. En ningún caso podrá hacer taladros o agujeros en las paredes.
4.5 El Arrendatario permitirá el acceso a la vivienda en cualquier momento al propietario o un
represente, a fin de inspeccionar cualquier servicio o instalación, o comprobar el cumplimiento
de las obligaciones contractuales.
4.6 No se permiten animales dentro del apartamento.
4.7 No se permite fumar dentro del apartamento.
4.8 El arrendatario se obliga a no subarrendar, ceder o traspasar el inmueble.
4.9 El Propietario mantendrá los suministros de agua y luz, etc., al corriente de pago y en pleno
funcionamiento así como el seguro de la vivienda vigente.
QUINTA - CLÁUSULA PENAL
El incumplimiento de la obligación de abandonar la Vivienda en el plazo pactado obligará a la
Parte Arrendataria a satisfacer en concepto de cláusula penal, la cantidad de: 100€ por cada día
de más hasta la libre disponibilidad de la vivienda por el Propietario, sin perjuicio de las costas,
gastos y demás indemnizaciones que fueran a su cargo, incluyendo los perjuicios que ocasione
por la siguiente reserva e incluso minutas de abogado y procurador, aunque no fuera preceptiva
su intervención.
SEXTA – JURISDICCIÓN
159
Las partes integrantes se someten a la jurisdicción y competencia de los tribunales y juzgados
del lugar donde está situada la vivienda, con renuncia expresa a su fuero propio.
SÉPTIMA – TRATAMIENTO DE DATOS
Las Partes de este Contrato conocen y se obligan a cumplir el Reglamento (UE) 2016/679 del
Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las
personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación
de estos datos (RGPD), así como en lo que resulte contrario a la normativa europea, la LOPD
(Ley de Protección de Datos) española, y /o aquellas que las pudieran sustituir o actualizar en el
futuro. De esta forma, las Partes son conscientes de que mediante la firma de este Contrato
consienten que sus datos personales recogidos en el presente Contrato, así como aquellos que
se pudiesen recoger en el futuro para poder dar cumplimiento o una correcta ejecución del
mismo, puedan ser incorporados por la otra Parte a su propio fichero automatizado o no de
recogida de datos con el fin de ejecutar correctamente la relación contractual y, eventualmente,
para una gestión administrativa y/o comercial.
En cualquier caso, las Partes se comprometen a que estos datos personales no serán
comunicados en ningún caso a terceros, aunque, si se hiciese algún tipo de comunicación de
datos personales, se comprometen siempre y de forma previa, a solicitar el consentimiento
expreso, informado, e inequívoco de la Parte que es titular de dichos datos de carácter personal.
De esta cláusula no resulta ninguna limitación o restricción respecto a los derechos de acceso,
rectificación, supresión, limitación, portabilidad u oposición con los que pudieran contar.
Ambas partes se ratifican en el presente contrato y firman por duplicado, a un solo efecto, en el
lugar y fecha indicados en el encabezamiento.
El Propietario o Parte Arrendadora Inquilino o Parte Arrendataria
