TFG Sensen Ye

Doble Grado Universitario en Ingeniería Informática y ADE
2020-2021
Trabajo Fin de Grado
“Desarrollo de un módulo de
programación de reuniones
online en un ERP”
Sensen Ye
Tutor/es
Gonzalo Génova Fuster
Colmenarejo. Julio 2021
Esta obra se encuentra sujeta a la licencia Creative Commons Reconocimiento - No

Comercial - Sin Obra Derivada
RESUMEN
La aparición del COVID-19 ha cambiado por completo el comportamiento de millo-

nes de personas. Además, se ha convertido en un acelerador de la transformación digital,
obligando a las empresas a reinventarse y a adaptarse a la nueva normalidad. Una de las
consecuencias ha sido reducir el contacto físico entre personas, aumentando el teletrabajo
y las reuniones online. Por otra parte, se ha incrementado la necesidad de solicitar cita
previa. Sin embargo, en muchos sitios, estas citas se solicitan de manera presencial, por
teléfono o por correo, siendo extremadamente ineficiente. Además, en los picos de de-
manda, su gestión se vuelve muy compleja. Por tanto, se hace imprescindible un sistema
que permita programar y gestionar reuniones online y presenciales de manera fácil.
Por tanto, el objetivo principal del TFG es desarrollar una aplicación open source que
permita digitalizar la programación y gestión de reuniones. Además, es un módulo que
actúa como extensión del software ERP Odoo y que se integra con el módulo Calendario
de Odoo, el módulo Empleados de Odoo, Google Calendar y Google Meet.
El módulo permite a las empresas y organizaciones gestionar distintos tipos de reu-
nión, ya sean reuniones online (a través de Google Meet) o reuniones físicas. Su uso se
puede extender a cualquier proyecto que requiera un sistema de citas, como por ejemplo,
una peluquería, un taller, una clínica, una institución educativa... Además, gracias a la
integración con el módulo Empleados, para cada tipo de reunión, se pueden asignar an-
fitriones (empleado), que serán los encargados de atender a las reuniones. Por otro lado,
cada anfitrión tiene su calendario en Odoo con todas las reuniones programadas.
Por otra parte, los usuarios que quieran asistir a un tipo de reunión, pueden progra-
mar reuniones sin necesidad de crear una cuenta de usuario. Para ello, para cada tipo de
reunión podrán ver la disponibilidad conjunta de todos los anfitriones asignados a dicho
tipo de reunión. De esta manera, podrán seleccionar la fecha y hora que mejor se ajuste a
sus necesidades. Una vez seleccionado el tipo de reunión, la fecha, la hora e introducido
sus datos personales, el sistema asigna la reunión a uno de los anfitriones disponibles en
función de un algoritmo similar a Round Robin, haciendo que la distribución de la carga
de trabajo sea más equitativa y más justa. Por otro lado, se envía una confirmación a su
correo y se guarda el evento en su Google Calendar.
Por tanto, el módulo supone un ahorro de tiempo en la gestión de las reuniones, y un
encaje óptimo de las demandas de los usuarios con la disponibilidad de los empleados.
Palabras clave:
ERP Odoo, módulo reuniones, citas online, gestión de reuniones, gestión de citas.
iii
ÍNDICE GENERAL
1. INTRODUCCIÓN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Visión general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. PLANTEAMIENTO DEL PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Definición de ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. La historia de los ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Clasificación de los ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4. ERP Odoo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.5. Productos similares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Marco regulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Entorno socio-económico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2. Impacto socio-económico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3. DESCRIPCIÓN GENERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Alcance del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Capacidades generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3. Restricciones generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4. Características de los usuarios: roles y capacidades. . . . . . . . . . . . . . . . 17
3.5. Entorno operacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4. REQUISITOS Y PLAN DE PRUEBAS [SECCIÓN NUEVA] . . . . . . . . . . . 20
4.1. Vocabulario del dominio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.1. Vocabulario del modelo de información . . . . . . . . . . . . . . . . . . . . 20
4.1.2. Vocabulario técnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Justificación de la clasificación de requisitos y de las pruebas . . . . . . . . . . 20
ii
4.3. Justificación de la plantilla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.1. Plantilla de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.2. Plantilla de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.1. Visión general de los requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.2. Usuario Asistente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.2.1. Reuniones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.3. Usuario Anfitrión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.4.3.1. Tipos de reuniones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.4.3.2. Reuniones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.3.3. Cuenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.4. Usuario Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.4.1. Tipos de reuniones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.4.2. Reuniones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4.4.3. Cuenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.1. Usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.2. Compatibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5.3. Desarrollo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6. Plan de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6.1. Tipos de reuniones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6.2. Reuniones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6.3. Cuenta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5. ARQUITECTURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1. Vista lógica (o conceptual) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2. Vista de proceso (o de ejecución) . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3. Vista de desarrollo (o de implementación) . . . . . . . . . . . . . . . . . . . . . 48
5.3.1. Contrato de operaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3.1.1. Subsistema “Vista” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3.1.2. Subsistema “Controlador” . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3.1.3. Subsistema “Modelo” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
iii
5.4. Vista física (o de despliegue) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6. DISEÑO DE LA INTERFAZ DE USUARIO. . . . . . . . . . . . . . . . . . . . . 59
6.1. Modelo de navegación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.1.1. Modelo de navegación usuario Asistente . . . . . . . . . . . . . . . . . . . 59
6.1.2. Modelo de navegación usuario Anfitrión. . . . . . . . . . . . . . . . . . . . 59
6.1.3. Modelo de navegación usuario Admin . . . . . . . . . . . . . . . . . . . . . 60
6.2. Diseño de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.2.1. Interfaz del usuario Asistente . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.2.2. Interfaz del usuario Anfitrión . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2.3. Interfaz del usuario Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7. INFORMACIÓN ADICIONAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.1. Despliegue de Odoo Meetings en Amazon Web Services . . . . . . . . . . . . 66
7.2. Dominio para acceder a la versión Demo del módulo . . . . . . . . . . . . . . 66
7.3. Código fuente en Github. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8. MANUAL DE USUARIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.1. Usuario Asistente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.2. Usuario Anfitrión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
8.3. Usuario Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.3.1. ¿Cómo gestionar los tipos de reunión? . . . . . . . . . . . . . . . . . . . . . 71
8.3.2. ¿Cómo gestionar los usuarios y los roles? . . . . . . . . . . . . . . . . . . . 72
BIBLIOGRAFÍA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
ANEXO A. TELETRABAJO EN ESPAÑA (2019)
ÍNDICE DE FIGURAS
1.1 Trabajadores de 15-64 años con teletrabajo. España frente a la UE-28 [3] . 3
3.1 Algoritmo de asignación de reuniones . . . . . . . . . . . . . . . . . . . 17

3.2 Diagrama de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 Clasificación de requisitos funcionales . . . . . . . . . . . . . . . . . . . 21
5.1 Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2 Diagrama de actividades para los tipos de reunión y las reuniones confir-
madas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3 Diagrama de actividades para el perfil de los usuarios . . . . . . . . . . . 47
5.4 Diagrama de actividades para la programación de una reunión . . . . . . 48
5.5 Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.6 Diagrama de despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1 Mapa de navegación del usuario Asistente . . . . . . . . . . . . . . . . . 59

6.2 Mapa de navegación del usuario Anfitrión . . . . . . . . . . . . . . . . . 59
6.3 Mapa de navegación del usuario Admin . . . . . . . . . . . . . . . . . . 60
6.4 Usuario Asistente. Seleccionar tipo de reunión, fecha y hora . . . . . . . 60
6.5 Usuario Asistente. Introducir la información requerida por la empresa . . 61
6.6 Usuario Anfitrión. Menú de más opciones para cada tipo de reunión . . . 62
6.7 Usuario Anfitrión. Introducir la disponibilidad . . . . . . . . . . . . . . . 62
6.8 Usuario Anfitrión. Ver todas las reuniones asignadas en forma de calendario 63
6.9 Usuario Anfitrión. Ver los detalles de cada reunión asignada . . . . . . . 63
6.10 Usuario Admin. Listado de tipos de reuniones existentes . . . . . . . . . 64
6.11 Usuario Admin. Creación de un nuevo tipo de reunión. Información general 65
6.12 Usuario Admin. Creación de un nuevo tipo de reunión. Rango de fechas,
duración y límite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.1 Interfaz de seleccionar el tipo de reunión . . . . . . . . . . . . . . . . . . 68

8.2 Interfaz de introducir datos personales . . . . . . . . . . . . . . . . . . . 68
v
8.3 Interfaz del calendario de Odoo . . . . . . . . . . . . . . . . . . . . . . . 69
8.4 Interfaz de la lista de tipos de reunión . . . . . . . . . . . . . . . . . . . 69
8.5 Interfaz de los detalles de un tipo de reunión . . . . . . . . . . . . . . . . 70
8.6 Interfaz del perfil de usuario . . . . . . . . . . . . . . . . . . . . . . . . 70
8.7 Interfaz de la disponibilidad de un empleado . . . . . . . . . . . . . . . . 71
8.8 Interfaz del listado de tipos de reunión . . . . . . . . . . . . . . . . . . . 71
8.9 Interfaz de los detalles de un tipo de reunión . . . . . . . . . . . . . . . . 71
8.10 Interfaz del directorio de empleados . . . . . . . . . . . . . . . . . . . . 72
8.11 Interfaz para determinar las horas laborables . . . . . . . . . . . . . . . . 72
8.12 Interfaz de los ajustes de Odoo . . . . . . . . . . . . . . . . . . . . . . . 73
8.13 Interfaz de enviar invitación o cambiar contraseña . . . . . . . . . . . . . 73
8.14 Interfaz para gestionar los roles de usuario . . . . . . . . . . . . . . . . . 74
ÍNDICE DE TABLAS
2.1 Presupuesto de los materiales necesarios . . . . . . . . . . . . . . . . . . 12

2.2 Presupuesto de los recursos humanos . . . . . . . . . . . . . . . . . . . . 12
2.3 Presupuesto de los costes indirectos . . . . . . . . . . . . . . . . . . . . 12
2.4 Presupuesto para la elaboración del TFG . . . . . . . . . . . . . . . . . . 13
3.1 Capacidades del “usuario Asistente” . . . . . . . . . . . . . . . . . . . . 18

3.2 Capacidades del “usuario Anfitrión” . . . . . . . . . . . . . . . . . . . . 18
3.3 Capacidades del “usuario Admin” . . . . . . . . . . . . . . . . . . . . . 18
4.1 Plantilla de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Plantilla de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Visión general de los requisitos . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 RF-ASI-01. Seleccionar tipo de reunión, hora y fecha . . . . . . . . . . . 23
4.5 RF-ASI-02. Introducir datos personales . . . . . . . . . . . . . . . . . . 24
4.6 RF-ASI-03. Correo de confirmación . . . . . . . . . . . . . . . . . . . . 24
4.7 RF-ASI-04. Ver una reunión confirmada . . . . . . . . . . . . . . . . . . 24
4.8 RF-ASI-05. Editar una reunión confirmada . . . . . . . . . . . . . . . . . 24
4.9 RF-ASI-06. Cancelar una reunión confirmada . . . . . . . . . . . . . . . 25
4.10 RF-ANF-01. Ver los tipos de reunión creados . . . . . . . . . . . . . . . 25
4.11 RF-ANF-02. Obtener enlace al tipo de reunion en forma de URL . . . . . 25
4.12 RF-ANF-03. Obtener enlace al tipo de reunion en forma de código QR . . 26
4.13 RF-ANF-04. Ver lista de reuniones confirmadas en el calendario de Odoo 26
4.14 RF-ANF-05. Ver los detalles de una reunión confirmada en el calendario
de Odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.15 RF-ANF-06. Modificar una reunión confirmada en el calendario de Odoo 27
4.16 RF-ANF-07. Cancelar una reunión confirmada en el calendario de Odoo . 27
4.17 RF-ANF-08. Iniciar sesión . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.18 RF-ANF-09. Establecer disponibilidad . . . . . . . . . . . . . . . . . . . 27
4.19 RF-ANF-10. Ver el perfil de usuario . . . . . . . . . . . . . . . . . . . . 28
vii
4.20 RF-ANF-11. Modificar el perfil de usuario . . . . . . . . . . . . . . . . . 28
4.21 RF-ANF-12. Cerrar sesión . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.22 RF-ADM-01. Ver los tipos de reunión creados . . . . . . . . . . . . . . . 28
4.23 RF-ADM-02. Crear un nuevo tipo de reunión . . . . . . . . . . . . . . . 29
4.24 RF-ADM-03. Modificar un tipo de reunión . . . . . . . . . . . . . . . . 29
4.25 RF-ADM-04. Eliminar un tipo de reunión . . . . . . . . . . . . . . . . . 29
4.26 RF-ADM-05. Obtener enlace al tipo de reunion en forma de URL . . . . 29
4.27 RF-ADM-06. Obtener enlace al tipo de reunion en forma de código QR . 30
4.28 RF-ADM-07. Ver lista de reuniones confirmadas en el calendario de Odoo 30
4.29 RF-ADM-08. Ver los detalles de una reunión confirmada en el calendario
de Odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.30 RF-ADM-09. Modificar una reunión confirmada en el calendario de Odoo 31
4.31 RF-ADM-10. Cancelar una reunión confirmada en el calendario de Odoo 31
4.32 RF-ADM-11. Iniciar sesión . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.33 RF-ADM-12. Establecer disponibilidad . . . . . . . . . . . . . . . . . . 31
4.34 RF-ADM-13. Ver el perfil de usuario . . . . . . . . . . . . . . . . . . . . 32
4.35 RF-ADM-14. Modificar el perfil de usuario . . . . . . . . . . . . . . . . 32
4.36 RF-ADM-15. Cerrar sesión . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.37 RF-ADM-16. Crear usuarios . . . . . . . . . . . . . . . . . . . . . . . . 32
4.38 RF-ADM-17. Gestionar los roles de los usuarios . . . . . . . . . . . . . . 33
4.39 RNF-01. Tiempo de aprendizaje . . . . . . . . . . . . . . . . . . . . . . 33
4.40 RNF-02. Errores cometidos . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.41 RNF-03. Tiempo de aprendizaje . . . . . . . . . . . . . . . . . . . . . . 34
4.42 RNF-04. Lenguaje de programación Python . . . . . . . . . . . . . . . . 34
4.43 RNF-05. Base de datos PostgreSQL . . . . . . . . . . . . . . . . . . . . 34
4.44 RNF-06. Odoo Community . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.45 P-TIP-01. Ver los tipos de reunión . . . . . . . . . . . . . . . . . . . . . 35
4.46 P-TIP-02. Obtener enlace al tipo de reunión en forma de URL . . . . . . 35
4.47 P-TIP-03. Obtener enlace al tipo de reunión en forma de código QR . . . 36
4.48 P-TIP-04. Crear un nuevo tipo de reunión . . . . . . . . . . . . . . . . . 36
4.49 P-TIP-05. Modificar un tipo de reunión . . . . . . . . . . . . . . . . . . 36
viii
4.50 P-TIP-06. Eliminar un tipo de reunión . . . . . . . . . . . . . . . . . . . 37
4.51 P-REU-01. Seleccionar tipo de reunión, hora y fecha . . . . . . . . . . . 37
4.52 P-REU-02. Introducir datos personales . . . . . . . . . . . . . . . . . . . 37
4.53 P-REU-03. Introducir datos personales no válidos . . . . . . . . . . . . . 38
4.54 P-REU-04. Ver una reunión confirmada . . . . . . . . . . . . . . . . . . 38
4.55 P-REU-05. Editar una reunión confirmada . . . . . . . . . . . . . . . . . 39
4.56 P-REU-06. Cancelar una reunión confirmada . . . . . . . . . . . . . . . 39
4.57 P-REU-07. Ver una lista de reuniones confirmadas en el calendario de Odoo 39
4.58 P-REU-08. Ver los detalles de una reunión confirmada en el calendario de
Odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.59 P-REU-09. Modificar una reunión confirmada en el calendario de Odoo . 40
4.60 P-REU-10. Cancelar una reunión confirmada en el calendario de Odoo . . 41
4.61 P-CUE-01. Iniciar sesión . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.62 P-CUE-02. Establecer disponibilidad . . . . . . . . . . . . . . . . . . . . 41
4.63 P-CUE-03. Ver el perfil de usuario . . . . . . . . . . . . . . . . . . . . . 42
4.64 P-CUE-04. Modificar el perfil de usuario . . . . . . . . . . . . . . . . . . 42
4.65 P-CUE-05. Cerrar sesión . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.66 P-CUE-06. Crear usuarios . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.67 P-CUE-07. Modificar el rol del único usuario Admin . . . . . . . . . . . 43
4.68 P-CUE-08. Modificar el rol de un usuario Admin . . . . . . . . . . . . . 43
4.69 P-CUE-09. Modificar el rol de un usuario Anfitrión . . . . . . . . . . . . 44
5.1 Componente meeting_type_views . . . . . . . . . . . . . . . . . . . . . 50

5.2 Componente meeting_type_templates . . . . . . . . . . . . . . . . . . . 50
5.3 Componente meeting_event_templates . . . . . . . . . . . . . . . . . . . 51
5.4 Componente controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.5 Componente meeting_type_handler . . . . . . . . . . . . . . . . . . . . 52
5.6 Componente meeting_event_handler . . . . . . . . . . . . . . . . . . . . 53
5.7 Componente user_handler . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.8 Componente google_calendar_handler . . . . . . . . . . . . . . . . . . . 55
5.9 Componente meeting_type . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.10 Componente meeting_event . . . . . . . . . . . . . . . . . . . . . . . . 57
ix
7.1 Credenciales de acceso a https://odoomeetings.tk . . . . . . . . . . . . . 67
1. INTRODUCCIÓN
1.1. Visión general
El 31 de diciembre de 2019, la Comisión Municipal de Salud de Wuhan (China) no-

tifica un gran número de casos de neumonía en la ciudad. Más tarde se determina que
han sido producidos por un nuevo coronavirus, denominado SARS-CoV-2. Este virus es
el causante de la enfermedad denominada COVID-19. El 11 de marzo de 2020, debido al
impacto y gravedad del virus, es declarado pandemia por la Organización Mundial de la
Salud [1].
En España. el 14 de marzo se declaró el estado de alarma 1 . Más tarde, el 29 de marzo,
con el objetivo de reducir la movilidad de la población y evitar un incremento de conta-
gios, se publicó un nuevo real decreto-ley 2 . En esta ocasión, se paralizó toda actividad
de los trabajadores que no se consideran esenciales o que no pueden trabajar desde su
residencia habitual. Además, para disminuir el impacto sobre el tejido empresarial y el
empleo, se fomentó el teletrabajo y otras medidas de flexibilidad empresarial. Según una
encuesta llevada a cabo por Eurofound en abril/mayo de 2020, en España, el 29,2 % de los
encuestados había empezado a teletrabajar debido a la crisis sanitaria, sin embargo esta
cifra es mucho menor que la media europea, cuyo valor fue de 40,2 % [2].
De manera histórica, el porcentaje de trabajadores que teletrabajan ha aumentado en
el promedio de los estados miembro de la Unión Europea. Sin embargo, como bien se
puede apreciar en la figura 1.1, este crecimiento no ha sido tan elevado en España.
La opción de teletrabajar depende de varios factores, sobre todo del tipo de trabajo y
del grado de preparación de la empresa. Según el artículo publicado por el Banco de Espa-
ña [3], los autónomos son los que trabajan en casa de manera más frecuente. En relación
a los asalariados, aquellas personas con más experiencia laboral y con mayor cualifica-
ción son los que más teletrabajan. Por ocupación, los militares, los empleados contables
y de administración, los operadores de instalaciones y maquinaria y las ocupaciones ele-
mentales no suelen trabajar desde casa. En general, su utilización es escasa en aquellas
profesiones que requieren un contacto físico con los clientes. En cambio, en sectores co-
mo el de la educación o el científico, su uso es mucho mayor. Hay más información en el
Anexo A. Teletrabajo en España (2019)
Evitar la propagación del virus no es la única ventaja de esta modalidad, por ejemplo,
1
Real Decreto 463/2020, de 14 de marzo, por el que se declara el estado de alarma para la gestión de la
situación de crisis sanitaria ocasionada por el COVID-19 (BOE núm. 67, de 14/03/2020).
2
Real Decreto-ley 10/2020, de 29 de marzo, por el que se regula un permiso retribuido recuperable
para las personas trabajadoras por cuenta ajena que no presten servicios esenciales, con el fin de reducir la
movilidad de la población en el contexto de la lucha contra el COVID-19 (BOE núm. 87, de 29 de marzo
de 2020, páginas 27629 a 27636)
2
Fig. 1.1. Trabajadores de 15-64 años con teletrabajo. España frente a la UE-28 [3]
existen estudios que demuestran que el teletrabajo puede aumentar la productividad. Por
ejemplo, en una agencia de viajes, se pidieron voluntarios para trabajar desde casa durante
9 meses. De estas personas, la mitad pudieron teletrabajar, mientras que la otra mitad tra-
bajó desde la oficina, convirtiéndose en el grupo de control. Tras este período se observó
que las personas que trabajan desde casa completaron un 13,5 % más de llamadas que el
grupo de control [4].
1.2. Motivación
La aparición del COVID-19 ha cambiado por completo el comportamiento de millones

de personas. Además, se ha convertido en un acelerador de la transformación digital,
obligando a las empresas a reinventarse y a adaptarse a la nueva normalidad. Una de las
consecuencias ha sido reducir el contacto físico entre personas, aumentando el teletrabajo
y las reuniones online. Por otra parte, se ha incrementado la necesidad de solicitar cita
previa para numerosos servicios, como, por ejemplo, para la peluquería, para el taller,
para el médico... Sin embargo, en muchos sitios, estas citas se solicitan por teléfono o por
correo, siendo extremadamente ineficiente. Por tanto, se hace imprescindible un sistema
que permita programar y gestionar reuniones online y presenciales de manera fácil.
En relación con la primera consecuencia, el incremento de las reuniones online de-
bido a la consolidación del teletrabajo, el uso de las videoconferencias ha aumentado de
manera exponencial debido a la crisis sanitaria. Por ejemplo, según la empresa de vi-
deoconferencias Zoom, su facturación en el tercer cuatrimestre de 2020 fue de $777,2
millones, es decir un crecimiento interanual del 367 %. Además, el número de empresas
con más de 10 empleados que usaron sus servicios ascendió a aproximadamente 433.700,
lo que supone un crecimiento interanual del 485 % [5].
Por tanto, cada vez se pasa más tiempo en reuniones cara a cara por vídeo, no sólo
con personas de la organización, sino también con personas externas a ella, como por
ejemplo los clientes. Para las reuniones con clientes, ya sean online o presenciales, mu-
3
chas de ellas se programan por teléfono o por correo, lo cual es muy ineficiente, por lo
que sería necesario digitalizar este proceso. El motivo por el cual se recurre a la reserva
presencial, al teléfono o al correo es que no existe un sistema que permita programar las
reuniones de manera online y gracias a Internet. Además, muchas veces el usuario no
sabe la disponibilidad de la empresa, por lo que tiene que llamar o mandar un correo para
saberlo.
Por ejemplo, en un proceso de selección de personal, la mayor parte de las veces, la
empresa le pregunta al candidato si puede acudir a una entrevista a una hora determinada
y no es usual que el candidato pueda ver todas las opciones posibles, es decir, la disponibi-
lidad del reclutador. También es posible encontrar el mismo problema en la vida cotidiana
y en citas presenciales, entre ellos, con las llamadas para pedir cita en el taller del coche,
en un centro de salud o en una peluquería. Además, en algunas ocasiones tan sólo se pue-
de pedir cita por correo o de manera presencial. En estos casos, la experiencia del cliente
podría mejorar considerablemente si éste pudiera ver y seleccionar el momento que mejor
le venga. De esta manera, no sería necesario esperar a que alguien coja el teléfono, sino
que se podría programar una cita en cualquier momento y desde cualquier lugar.
1.3. Objetivos
Para resolver esta problemática y cubrir esta necesidad en los usuarios, se ha planteado
el desarrollo de una aplicación open source que permita digitalizar la programación y
gestión de reuniones. Además, es un módulo que actúa como extensión del software ERP
Odoo y que se integra con el módulo Calendario de Odoo, el módulo Empleados de Odoo,
Google Calendar y Google Meet.
Se ha optado por desarrollar una extensión de Odoo debido a que la plataforma ofrece
un amplio abanico de aplicaciones para empresas, las cuales están completamente inte-
gradas y pueden cubrir todas las necesidades de las organizaciones. Además, cuenta con
más de 950 trabajadores y 5 millones de usuarios [6] en todo el mundo.
El módulo permite a las empresas y organizaciones gestionar distintos tipos de reu-
nión, ya sean reuniones online (a través de Google Meet) o reuniones físicas. Su uso se
puede extender a cualquier proyecto que requiera un sistema de citas, como por ejemplo,
una peluquería, un taller, una clínica, una institución educativa... Además, gracias a la
integración con el módulo Empleados, para cada tipo de reunión, se pueden asignar an-
fitriones (empleado), que serán los encargados de atender a las reuniones. Por otro lado,
cada anfitrión tiene su calendario en Odoo con todas las reuniones programadas.
Por otra parte, los usuarios que quieran asistir a un tipo de reunión, pueden progra-
mar reuniones sin necesidad de crear una cuenta de usuario. Para ello, para cada tipo de
reunión podrán ver la disponibilidad conjunta de todos los anfitriones asignados a dicho
tipo de reunión. De esta manera, podrán seleccionar la fecha y hora que mejor se ajuste a
sus necesidades. Una vez seleccionado el tipo de reunión, la fecha, la hora e introducido
4
sus datos personales, el sistema asigna la reunión a uno de los anfitriones disponibles en
función de un algoritmo similar a Round Robin. Por otro lado, se envía una confirmación
a su correo y se guarda el evento en su Google Calendar.
Para mejorar la precisión de este algoritmo, el módulo se ha integrado con el módulo
Calendario de Odoo. De esta manera, el sistema puede acceder al calendario del anfitrión
y conocer en todo momento cuál es su disponibilidad real. Por ejemplo, si en el mismo
día a un anfitrión le ponen una reunión de 11:00 a 12:00, el sistema sabrá que no dispone
de tiempo a esa hora y lo tendrá en cuenta en el algoritmo de asignación. Gracias a este
algoritmo, la distribución de la carga de trabajo es más equitativa y más justa.
Por tanto, el módulo supone un ahorro de tiempo en la gestión de las reuniones, y un
encaje óptimo de las demandas de los usuarios con la disponibilidad de los empleados.
1.4. Estructura del documento
En primer lugar se presenta el problema, que se divide en el estado del arte, el marco
regulador y el entorno socio-económico. Dentro del estado del arte se contextualiza el
tema teniendo en cuenta otras aplicaciones que ofrecen funcionalidades similares y otros
documentos que traten temas relacionados. Después, en el marco regulador se estudian las
regulaciones aplicables a las reuniones online. Por último, en el entorno socio-económico
se explica la repercusión del proyecto en diferentes ámbitos y se presenta un presupuesto
aproximado.
A continuación, se detalla una descripción del software que se va a desarrollar. Se
incluye la perspectiva del producto, el alcance que tiene, las capacidades y restricciones
generales, los roles de los usuarios, el entorno operacional y las consideraciones éticas.
Seguidamente, se analizan los requisitos funcionales y no funcionales del proyecto.
Además, se diseña un plan de pruebas para garantizar que el software se desarrolla acorde
a su especificación y que cumple con las necesidades de los clientes.
Más adelante, se explica la arquitectura del software, que es la organización funda-
mental de un sistema. Consiste en la descomposición del sistema en cuatro vistas: la vista
lógica, la vista de proceso, la vista de desarrollo y la vista física.
Después, se presenta el modelo de navegación y el diseño de la interfaz de usuario, el
cual será simple e intuitivo para garantizar la satisfacción de los usuarios.
Por último, se muestra información adicional, que incluye el despligue de una ver-
sión demo en Amazon Web Services, cómo acceder a la versión demo, el lugar donde se
encuentra el código fuente y cómo gestionar los usuarios y los roles dentro de Odoo.
5
2. PLANTEAMIENTO DEL PROBLEMA
2.1. Estado del arte
2.1.1. Definición de ERP
Un ERP (Enterprise Resource Planning) es un sistema de gestión empresarial que se

suele emplear para gestionar todas las funciones empresariales dentro de una organiza-
ción, es decir permite integrar la información de los distintos departamentos en un único
lugar. Por tanto, se centraliza toda la información en una base de datos común [7]. Siem-
pre ha sido muy demandado por empresas del sector manufacturero, no obstante, su uso
también se está expandiendo a otros sectores, como por ejemplo, el sector servicios.
2.1.2. La historia de los ERP
La historia de los ERP comienza con la gestión de los inventarios, el cual se hacía
a mano. Siempre se ha intentado optimizar este proceso, pero fue en 1913 cuando el
ingeniero Ford Whitman Harris desarrolló el modelo denominado cantidad económica
de pedido (EOQ por sus siglas en inglés). Según Schwarz [8], la cantidad que hay que
reponer de un producto es aquel que minimiza el coste del pedido en sí y el coste de
almacenamiento. Por ejemplo:
Si se solicita una mayor cantidad de pedido, la frecuencia de pedido disminuye, y

por tanto, el coste de pedido/mes también. No obstante, el inventario es mayor, por
lo que el coste almacenamiento/mes es mayor.
Por otra parte, si se hace una menor cantidad de pedido, el stock es menor, pero la
frecuencia de los pedidos es mayor, por lo que el coste de pedido/mes se incrementa.
Por tanto, la cantidad de pedido que minimiza los gastos es lo que se denomina la
cantidad económica de pedido.
EOQ fue un estándar en la fabricación de productos durante décadas y ha sido con-
siderado por varios autores el predecesor de la planificación de los requerimientos de
material (Material Requirement Planning - MRP) [9]. MRP fue uno de los primeros sis-
temas de gestión de inventario basado en ordenador. Ha sido usado principalmente para
responder tres preguntas relacionadas con las materias primas: ¿Qué se necesita? ¿Cuánto
se necesita? ¿Cuándo se necesita? [10]. Este sistema se puede descomponer en [11]:
Lista de materiales, también conocido como BOM (Bills of materials). Se incluye

toda la materia prima y componentes necesarios para fabricar o reparar un producto.
6
Fichero del estado del inventario. Aquí se presenta el stock disponible en un período
de tiempo determinado.
Programa maestro de producción, también conocido como MPS (Master Production

Schedule). Especifica las cantidades y los momentos en los que se necesitan los
productos terminados. Por tanto, permite coordinar el proceso de fabricación con el
objetivo de adaptarse a la demanda.
Más tarde, en el año 1983, se creó la planificación de recursos de fabricación, denomi-

nada también MRP II (Manufacturing Resource Planning), que a diferencia del anterior
funcionaba con módulos e integraba distintos procesos clave en la fabricación, como por
ejemplo, materiales, programación y gestión de contratos [12]. Todo ello en un mismo
sistema.
El enfoque de la MRP II permitió una reflexión sobre cómo las empresas podían inte-
grar toda la información y aumentar la productividad y eficiencia. Gracias a los avances
tecnológicos, este concepto se aplicó también a otras actividades distintas de la fabrica-
ción, como por ejemplo, las finanzas y contabilidad, la gestión de las relaciones con los
clientes (CRM) y la gestión de los recursos humanos. Fue en el año 1990, cuando sur-
gió el término que se conoce actualmente como planificación de recursos empresariales o
ERP [12].
2.1.3. Clasificación de los ERP
Al principio estos sistemas eran instalados en máquinas locales, no obstante, la gran

mayoría de las soluciones actuales ofrecen la posibilidad de alojarlo en la nube. De esta
manera, es mucho más flexible y se puede adaptar a las necesidades actuales y futuras del
negocio.
Además, históricamente estaban enfocados en las grandes empresas, sin embargo,
esta tendencia sufrió un cambio debido a la aparición de los ERPs open source. Según la
organización Open Source Initiative [13], el término open source no es sólo tener acceso al
código fuente, sino que tiene que cumplir otros criterios relacionados con su distribución.
Algunos de estos criterios son que se pueda redistribuir de manera gratuita y que no se
pueda discriminar a otras personas. Por ejemplo, no se puede impedir que personas de
una determinada raza o etnia hagan uso del software.
Es de vital importancia distinguir el software open source del software comercial,
también conocido como software propietario. Éste último está desarrollado por una em-
presa y su principal propósito es ganar dinero a través del uso del software [14]. Algunos
ejemplos de ERP open source son Openbravo, Apache OFBiz, ERPNext u Odoo (que
también cuenta con una versión comercial). Por otra parte, los mayores proveedores de
ERPs propietarios son SAP, Oracle y Microsoft.
7
Algunos de los principales beneficios de los ERP de código abierto son los siguientes
[15]:
Normalmente son más económicos. Esto es debido a que no es necesaria una licen-
cia. Además, normalmente hacen uso de bases de datos o sistemas operativos open
source, disminuyendo drásticamente su precio.
Las organizaciones tienen un control absoluto sobre el sistema y sobre el código

fuente. De esta manera existe una menor dependencia sobre el proveedor.
La calidad de las soluciones open source suele ser mayor gracias a las contribucio-
nes y mejoras de la comunidad.
No obstante, no todo son ventajas, uno de los principales inconvenientes es el soporte

técnico. Como bien se ha indicado anteriormente, los proyectos open source están res-
paldados por una gran comunidad de desarrolladores, que son los encargados de ofrecer
soporte técnico gratis. Sin embargo, gratis no es lo mismo que rápido, por lo que si surge
algún error muy específico o no tan prioritario, podría ser omitido por la comunidad [16].
Por otra parte, dentro de las principales ventajas de los ERP propietario se pueden
destacar las siguientes [16]:
Una mayor estabilidad. Esto es debido a que las empresas que desarrollan este tipo
de software tienen que mantener y mejorar el software para poder sobrevivir.
Soporte técnico a medida. Parte de los ingresos de estas empresas provienen del
mantenimiento, por lo que es imprescindible ofrecer un servicio de calidad y que se
adapte a las necesidades de cada cliente.
Una mayor usabilidad. El software propietario normalmente está diseñado con me-
nores funcionalidades que el software open source. No obstante, se hace un estudio
exhaustivo del cliente y de sus necesidades, por lo que al final la experiencia de
usuario suele ser mejor.
Por último, como desventajas se encuentran el coste, una gran dependencia en el pro-
veedor del software propietario y que no se tiene acceso al código fuente.
2.1.4. ERP Odoo
Odoo, al igual que otros ERP funciona a través de módulos, también denominados
Odoo Apps. Estos módulos permiten expandir las funcionalidades del sistema según las
necesidades de cada negocio. Desde el punto de vista del desarrollador, un módulo está
compuesto por los siguientes elementos [17]:
8
Objetos de negocio. Son clases escritas en el lenguaje de programación python.
• Vista de objetos. Permiten definir la interfaz gráfica.

• Archivos de información. Normalmente en formato XML o CSV en el que se
declaran los metadatos, por ejemplo la información de configuración.
• Controladores web. Permiten manejar las solicitudes de los navegadores web.
Datos web estáticos. Son imágenes, archivos CSS (Cascading Style Sheets) o ar-
chivos Javascript empleados por el sitio web.
Los módulos se agrupan en varias categorías, por ejemplo contabilidad, gestión de

proyectos, gestión de ventas, recursos humanos, comercio electrónico, punto de venta,
marketing, entre otros [18]. Cabe destacar que la versión comercial del software (Odoo
Enterprise) cuenta con más aplicaciones que la versión open source (Odoo Community).
2.1.5. Productos similares
En el mercado existen múltiples soluciones para programar una reunión online. En es-
tas reuniones se pueden distinguir dos roles: la persona que organiza la reunión (empresa,
profesor, asociación...) y la persona que asiste a la reunión (cliente, alumno, patrocina-
dores...). Para facilitar la comprensión en este apartado, a la primera figura se le va a
denominar anfitrión y a la segunda asistente o invitado.
Una de las soluciones gratuitas más conocidas es Google Calendar. Para ello, el anfi-
trión tiene que crear un nuevo evento, en el que debe incluir los siguientes atributos: título,
hora, ubicación (o videollamada), descripción y los invitados. Una vez creado, se puede
notificar a los invitados por correo electrónico. Éstos pueden aceptar la reunión, rechazar-
la o proponer una nueva hora. El principal problema de esta solución es que el asistente
no es capaz de visualizar la disponibilidad del anfitrión, entonces existe la posibilidad de
que proponga una nueva hora y el anfitrión no disponga de tiempo, por lo que tendría que
proponer otra hora. Esto podría convertirse en un ciclo infinito. Por otra parte, el proceso
es muy manual y no está automatizado, lo que implica que el coste de oportunidad es muy
grande dado que se podría invertir el tiempo en otras tareas más importantes.
Otra solución que está ganando popularidad es Calendly, que cuenta con más de 5
millones de usuarios y es empleado por más de 36.000 empresas [19]. Este software per-
mite la programación de reuniones sin necesidad de enviar emails a los invitados. Cuenta
con una versión gratuita (versión Basic), pero para explotar todo su potencial habría que
pagar $8/usuario en la versión Premium y $12/usuario en la versión Pro [20]. El funciona-
miento es muy simple, en primer lugar, el anfitrión tiene que determinar su disponibilidad
y compartir un link con los asistentes. De esta manera, cada invitado puede seleccionar
la hora que mejor le convenga. Además, para los equipos grandes, permite distribuir las
reuniones automáticamente entre los miembros según la disponibilidad. Por tanto, es un
9
método mucho más eficiente que el anterior. Al ser un software propietario, no se pue-
de acceder al código fuente, por lo que resulta complicado personalizarlo. Sería posible
integrar algunas funcionalidades con Odoo gracias a su API (Application Programming
Interface) pero existe una gran dependencia en el proveedor.
Por último, la versión comercial de Odoo ofrece un módulo denominado Appoint-
ments. Este módulo no está disponible de manera open source y tiene un coste de 6e al
mes. Además, la versión comercial cobra 12,5e/usuario al mes [21]. Los invitados tie-
nen la posibilidad de elegir el tipo de reunión y la persona con la que se quieren reunir.
Después pueden ver las franjas horarias en las que la persona dispone de tiempo, de esta
manera puede elegir una en función de su propia disponibilidad. Por último, se crea un
nuevo evento, que es guardado automáticamente en el calendario de la organización. Sin
embargo, si el usuario quiere guardarlo, tendrá que hacerlo de manera manual. Es una
solución parecida a Calendly, sin embargo, incluye menos funcionalidades, por ejemplo,
no está disponible la distribución automática de reuniones.
Como conclusión, Google Calendar es útil cuando hay pocas reuniones y el equipo de
personas que tiene que atender a las reuniones es pequeño. Si el equipo es grande, la mejor
opción es usar un sistema como Calendly. Sin embargo, si la empresa tiene implementado
el ERP Odoo, no es tan recomendable dado que la integración con otros módulos va a
estar limitada por la API de Calendly. Para ello, si se busca algo básico, se puede emplear
Odoo Appointments, sin embargo, las funcionalidades que tiene son limitadas. Por otra
parte, el uso de Calendly y de Odoo Appointments implica el pago mensual de una cuota.
Además, ninguna de estas soluciones te da acceso al código fuente. Por tanto, la mejor
opción a largo plazo sería un módulo open source que incluya más funcionalidades que
Odoo Appointments.
2.2. Marco regulador
El objetivo del presente trabajo es desarrollar un módulo de programación de reunio-

nes online en el ERP Odoo. Se va a emplear la versión Odoo Community, es decir la de
código abierto. En relación a la base de datos, este sistema hace uso de PostgreeSQL, que
es una base de datos relacional open source con más de 30 años en el mercado [22]. Por
tanto, al ser todo open source, no se va a infringir en ningún momento la Ley de Propiedad
Intelectual 3 .
Este módulo requiere el almacenamiento de la información de los usuarios en la base
de datos. Según la Ley Orgánica de Protección de Datos Personales y Garantía de los
Derechos Digitales 4 , el correcto tratamiento de los datos personales es un derecho fun-
3
Real Decreto Legislativo 1/1996, de 12 de abril, por el que se aprueba el texto refundido de la Ley de
Propiedad Intelectual, regularizando, aclarando y armonizando las disposiciones legales vigentes sobre la
materia (BOE núm. 97, de 22/04/1996).
4
Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos
digitales (BOE núm. 294, de 06/12/2018).
10
damental protegido por la Constitución española. Por lo que, algunos aspectos que hay
que tener en cuenta son: la transparencia, la confidencialidad y el tratamiento basado en
el consentimiento. Esta ley está basada en el Reglamento (UE) 2016/679 de la Unión
Europea 5 , por lo que también es de vital importancia adaptarse a la normativa europea.
El módulo desarrollado será open source y dispondrá de una licencia Creative Com-
mons Reconocimiento - No Comercial 4.0 Internacional. De esta manera, otros usuarios
podrán copiar, distribuir y modificar el código para que pueda ser adaptado a las distintas
necesidades. No obstante, otras organizaciones no podrán usarlo para fines comerciales,
es decir, no podrán usarlo para obtener un beneficio propio [23].
Para incrementar la calidad del código se van a seguir las “Odoo Guidelines” de la
versión 14.0. Esto permitirá mejorar la legibilibidad, además, también facilitará el man-
tenimiento y la corrección del código en el futuro. Esta guía se divide en cinco partes: la
estructura de los módulos, los ficheros XML, consejos sobre Python, aspectos a tener en
cuenta en Javascript y CSS y por último el control de versiones mediante Git [24].
2.3. Entorno socio-económico
2.3.1. Presupuesto
El presupuesto de la elaboración del TFG está compuesto por los costes directos y los
costes indirectos.
En este caso, los costes directos son los materiales empleados y los recursos humanos
necesarios para el desarrollo del proyecto. En relación a los materiales, existen muchas
adquisiciones de bienes que suponen un gran desembolso de dinero, como por ejemplo
un ordenador. Con el tiempo, éstos bienes sufren una depreciación y van perdiendo valor.
Esta depreciación es la amortización [25], que es el coste que aparecería reflejado en la
contabilidad. Para su cálculo, se puede recurrir a la siguiente fórmula:
Precio × Tiempo de uso

Amortización = (2.1)
Período de amortización
El ordenador se ha usado durante 180 días y se va a suponer un período de amortiza-
ción de 4 años:
5
Reglamento (EU) 2016/679 relativo a la protección de las personas físicas en lo que respecta al tra-
tamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva
95/46/CE (Diario Oficial de la Unión Europea, de 27/04/2016).
11
Tabla 2.1.
Presupuesto de los materiales necesarios
Período de
Producto Precio unitario Tiempo de uso Amortización
amortización
Portátil ASUS Laptop
536,36e 180 días 4 años 81,125e
M509DA-EJ385T
Por otra parte, como recursos humanos se encuentra la mano de obra del alumno y la
del tutor académico. El coste aparece reflejado en la siguiente tabla:
Tabla 2.2.
Presupuesto de los recursos humanos
Horas Coste
Concepto Coste/hora
empleadas total
Estudiante 15e/hora 350 horas 5.250,00e
Tutor académico 30e/hora 35 horas 1.050,00e
Los costes indirectos que han sido necesarios para el correcto desarrollo del proyecto
han sido la electricidad, el agua y la fibra óptica durante 6 meses:
Tabla 2.3.
Presupuesto de los costes indirectos
Coste
Concepto Coste mensual
total
Electricidad 40,00e 240,00e
Agua 15,64e 93,84e
Fibra 50,00e 300,00e
Por tanto, aplicando el 21 % de IVA a la suma de los costes directos y los costes
indirectos, se obtiene el presupuesto total para poder desarrollar este proyecto, cuyo valor
es de 8.389,10e:
12
Tabla 2.4.
Presupuesto para la elaboración del TFG
Concepto Coste
Materiales 81,16e
Recursos humanos 6300,00e
Electricidad 240,00e
Agua 93,84e
Fibra 300,00e
Total (antes de impuestos) 7.015,00e
IVA (21 %) 1.473,15e
PRESUPUESTO TOTAL 8.488,15e
2.3.2. Impacto socio-económico
El módulo de programación de reuniones online será open source, es decir será gra-
tuito para todas las personas y organizaciones. De esta manera, no sólo las grandes cor-
poraciones podrán disfrutar de sus ventajas, sino también los autónomos y las PYMES
(Pequeñas y Medianas Empresas). Además, estará respaldado por una comunidad de pro-
gramadores, que serán los encargados de mantener el sistema y de implementar nuevas
funcionalidades.
Al ser el software open source, cualquier persona con conocimientos técnicos de la
sociedad podrá aportar valor al proyecto. Al mismo tiempo, el código fuente será públi-
co, garantizando la transparencia en todo momento. De esta manera, los usuarios serán
capaces de ver cómo se está llevando a cabo el tratamiento de sus datos personales.
El mayor impacto que tendrá el módulo será en el ahorro del tiempo, tanto para el
anfitrión como para el asistente o invitado. Este impacto dependerá de cómo sean los
procesos actuales de la organización.
Dentro de las pequeñas organizaciones, muchos procesos no han sido automatizados,
por lo que siguen usando métodos más tradicionales. Un ejemplo de ello es el teléfono
y el papel para reservar y anotar las reuniones. La principal desventaja para el invitado
es que sólo podrá programar una reunión en horario laborable. Por otra parte, la empresa
tiene que destinar parte (o todo) el tiempo de una persona para atender las llamadas, lo
cual supone un desperdicio de recursos para la compañía.
Gracias al módulo, el invitado será capaz de programar la reunión en cualquier mo-
mento y desde cualquier lugar, siempre y cuando tenga un navegador web y conexión a
Internet. Poco a poco, el usuario adquirirá el hábito de usar la tecnología para programar
las reuniones. Por tanto, no será necesario que una persona dedique parte de su jornada
laboral a atender reservas. Asimismo, si en este tipo de organizaciones se empleara este
software, a largo plazo se podría reducir la huella de carbono que deja el papel.
13
En empresas más digitalizadas, no se emplea el teléfono, sino que se recurre al co-
rreo electrónico. En este caso, los anfitriones de las reuniones buscan y envian un correo
electrónico de manera manual. Además, deben encontrar un momento en el que tanto
el anfitrión como el asistente tengan tiempo. Gracias al módulo, todo esto será delega-
do al invitado, que podrá seleccionar, modificar o cancelar la reunión según su propia
disponibilidad. De esta manera, al igual que en las pequeñas organizaciones, aumenta la
productividad dado que se podrá destinar más tiempo a aquellas actividades de mayor
valor. A nivel empresarial, esto se traduce en una mayor rentabilidad.
14
3. DESCRIPCIÓN GENERAL
3.1. Alcance del software
En este proyecto se va a desarrollar un módulo open source para la programación

de citas online en el ERP Odoo. Este módulo se denominará Odoo Meetings y podrá
ser usado desde cualquier navegador web, el único requisito es disponer de conexión a
Internet.
Este sistema permitirá a las empresas u organizaciones gestionar el equipo de anfitrio-
nes que atenderán a las reuniones (virtuales o físicas). Además, también podrán determi-
nar distintos tipos de reuniones. Por ejemplo, en una universidad se podría tener un tipo
de reunión para consultas sobre la matrícula, otro para los programas de intercambio...
Por otra parte, el sistema tendrá en cuenta el horario de trabajo de los anfitriones y las
reuniones programadas, es decir, se tendrá en cuenta su disponibilidad de manera casi au-
tomática. De esta manera, cualquier persona que quiera tener una reunión podrá ver todas
las franjas disponibles y elegir la que mejor se adapte a sus necesidades.
En un principio, el calendario de Odoo no se integrará con iCal de Apple ni con Mi-
crosoft Outlook, sino que sólo lo hará con Google Calendar. Además se podrán incluir
videollamadas de Google Meet. Otras plataformas de videoconferencias, como por ejem-
plo Zoom, no serán integradas en la primera versión. Además, se integrará con el módulo
de Empleados y el de Calendario de Odoo.
Las tareas de mantenimiento del software no serán incluidas en este proyecto. La me-
jor opción sería que esto fuera llevado a cabo por una comunidad de desarrolladores open
source. Ellos serían los encargados de mantener e implementar nuevas funcionalidades.
El principal beneficio es un ahorro del tiempo, tanto para los anfitriones como para
los asistentes. Además, muchas empresas siguen recurriendo al teléfono para programar
las citas, por lo que se podría digitalizar y automatizar este proceso.
3.2. Capacidades generales
El software desarrollado permitirá expandir las funcionalidades del ERP Odoo. Ade-
más, se podrá explotar todo el potencial de este ERP dado que el módulo se podría comu-
nicar con el resto de aplicaciones de Odoo, integrando todo la información empresarial
en un único lugar. En este proyecto sólo se implementará su integración con el módulo
Empleados y el de Calendario de Odoo.
En relación a los servicios principales que se ofrecen:
Los asistentes podrán ver y seleccionar cualquier tipo de reunión que haya determi-
15
nado la empresa. Por ejemplo, en un hospital puede que existan dos tipos de citas:
una con la enfermera y otra con el médico de familia. Entonces el asistente podrá
ver la disponibilidad global de todos los trabajadores asignados a cada tipo de reu-
nión. Por tanto, será capaz de seleccionar el tipo de reunión pero no la persona que
le va a atender (anfitrión). Además será capaz de modificar, eliminar y ver todas las
reuniones confirmadas.
Las personas que atienden las citas (anfitriones) podrán establecer su disponibili-
dad, así como ver todos los tipos de reunión creados. Además, dentro de cada tipo
podrán ver, modificar o cancelar las reuniones a las que tienen que asistir. Por úl-
timo, podrán obtener un enlace al tipo de reunión en forma de URL y en forma de
código QR. En este enlace, los asistentes podrán ver la disponibilidad de la empresa
para el tipo de reunión en cuestión.
Dentro de las empresas habrá una o varias personas con el rol de administrador,
que serán los encargados de gestionar los tipos de reunión. Son los únicos que
pueden crear, modificar y eliminar tipos de reunión. Asimismo también pueden
asignar empleados a éstos. Además, las personas con este rol también podrán asistir
a las reuniones. Por tanto, tendrán acceso a las mismas funcionalidades que los
anfitriones.
Por tanto, los anfitriones son asignados a tipos de reunión por los administradores y
cada uno podrá determinar su disponibilidad. Por lo que, la disponibilidad que verá el
usuario Asistente para un tipo de reunión será la disponibilidad de todos los anfitriones
(incluyendo la de los administradores) asignados a ese tipo.
Por último, dentro de cada tipo de reunión se encuentran las reuniones en sí. En este
caso, la asignación de anfitriones a reuniones será llevado a cabo de manera automática
empleando un método parecido al algoritmo de planificación Round-robin. El objetivo
es que la asignación sea lo más equitativa posible, por lo que cada vez que el asistente
confirme una reunión (ha indicado tipo de reunión, fecha, hora y sus datos personales),
el sistema revisará quién está disponible. Tan sólo tendrá en cuenta aquellas personas que
están asignadas al tipo de reunión elegido por el asistente.
En relación al algoritmo, como el sistema sabe quién ha sido el último en atender una
reunión de cada tipo (last_employee), creará una lista de anfitriones ordenados por ID
(employee_list) y comparará este ID con el ID del último empleado asignado. Si el ID
del empleado es mayor que el ID del último empleado asignado, esto quiere decir que
tendría que ser el siguiente en atender una reunión, por lo que se añade al final de una
lista (employee_attendance_order). En cambio, si es menor, quiere decir que ha atendi-
do una reunión hace poco, por lo que se añadirán al final de una lista auxiliar (emplo-
yee_attendance_recent). Una vez que se haya comprobado para todos los empleados, se
añadirán los IDs de la lista auxiliar al final de la otra lista. Esta nueva lista representa el or-
den de asignación preliminar (employee_attendance_order). Para facilitar la comprensión
del mismo, se puede observar el siguiente diagrama:
16
employee_list[i] >
3 4
last_employee
last_employee employee_attendance_order
4 1 2 3
1 2 3 4
employee_list[i] employee_attendance_order
1 2 3
<= last_employee
employee_list
employee_attendance_recent
Fig. 3.1. Algoritmo de asignación de reuniones
A continuación, para cada empleado de la lista, se comprueba su disponibilidad y si

tiene algún evento en su calendario de Odoo en la fecha y hora seleccionada por el usuario
asistente. Si dispone de tiempo, el sistema le asigna la reunión y si no dispone de tiempo,
el sistema revisa el siguiente empleado de la lista. En el caso de que no haya ningún em-
pleado disponible para una hora y fecha determinada, el usuario no podrá seleccionarla.
3.3. Restricciones generales
Para desarrollar el sistema existen ciertas restricciones que limitan las opciones de los
desarrolladores:
Hay que emplear la base de datos relacional open source PostgreeSQL para alma-
cenar toda la información. Esto es así debido a que es un requisito del ERP Odoo
para que pueda funcionar correctamente.
El uso del módulo está restringido a aquellas personas que tengan un ordenador con
un navegador web y conexión a Internet.
3.4. Características de los usuarios: roles y capacidades
Dentro del sistema existen tres tipos de usuarios.
Los usuarios que asisten a las reuniones o citas creadas (“Usuario Asistente”).
Las personas que atienden a las reuniones (“Usuario Anfitrión”).
El administrador, que es el encargado de crear, editar y eliminar los tipos de reunio-

nes. Además, tiene acceso a las mismas funcionalidades que el anfitrión (“Usuario
Admin”).
Cada rol requiere distintos servicios o funciones, denominados capacidades. Estas

capacidades aparecen sintetizadas en las siguientes tablas:
17
Tabla 3.1.
Capacidades del “usuario Asistente”
Rol Capacidades
Seleccionar tipo de reunión, hora y fecha
Usuario asistente Ver, modificar o cancelar reuniones
Tabla 3.2.
Capacidades del “usuario Anfitrión”
Rol Capacidades
Establecer disponibilidad
Actualizar perfil de usuario
Usuario Anfitrión Ver tipos de reuniones creados
Ver, modificar o cancelar reuniones confirmadas
Obtener enlace al tipo de reunión en forma de URL o código QR
Tabla 3.3.
Capacidades del “usuario Admin”
Rol Capacidades
Crear, editar y eliminar tipos de reuniones
Gestionar los roles de los usuarios
Establecer disponibilidad
Usuario Admin Actualizar perfil de usuario
Ver, modificar o cancelar reuniones asignadas
Obtener enlace al tipo de reunión en forma de URL o código QR
Los usuarios con el rol de anfitrión y con el rol de admin usarán el software con
mucha frecuencia, llegando a formar parte de su día a día. De esta manera se convertirán
en expertos. Por otra parte, los usuarios asistentes usarán el sistema de manera ocasional,
por lo que será necesaria una interfaz simple e intuitiva.
Por último, para programar y asistir a la reunión no será necesario ningún hardware
específico como una cámara o un micrófono. No obstante, si es una reunión mediante
videoconferencia, éstos dispositivos serán recomendables.
3.5. Entorno operacional
El sistema Odoo Meetings interactuará con los usuarios y con otras entidades externas.
En relación a los usuarios, como bien se indicó en 3.4 Características de los usuarios:
roles y capacidades, existen tres tipos de usuarios: el asistente, el anfitrión y por último
18
el administrador. Por otra parte, dentro de las entidades externas, se encuentran: la base
de datos PostgreeSQL, una API que generará códigos QR y la API de Google Calendar
para crear eventos. Esta última se comunicará con la API de Google Meet para crear
videoconferencias en el caso de que fuera necesario. Por último, también interactuará
con otros módulos de Odoo, en este caso, Calendario y Empleados. Todo esto aparece
resumido en el siguiente diagrama de contexto.
Generador de Módulo de Odoo Módulo de Odoo

PostgreeSQL
códigos QR Calendario Empleados
Usuario
ODOO MEETINGS Gestionar reuniones
Asistente
Gestionar reuniones
Usuario
Actualizar perfil de usuario
Anfitrión
Obtener enlace a los tipos de reuniones
Crear evento
Gestionar reuniones
Actualizar perfil de usuario Usuario
Obtener enlace a los tipos de reuniones Admin
Gestionar tipos de reuniones
Obtener credenciales
Google Calendar
de la API
Crear videoconferencia Leyenda
Sistema Usuarios
Entidades externas Interacción

Google Meet
Fig. 3.2. Diagrama de contexto
19
4. REQUISITOS Y PLAN DE PRUEBAS [SECCIÓN NUEVA]
4.1. Vocabulario del dominio
4.1.1. Vocabulario del modelo de información
Tipo de reunión: permite clasificar las reuniones o citas en grupos para facilitar su
gestión. Por tanto, cada tipo estará formado por un conjunto de reuniones.
Reunión: cita online o física entre un anfitrión y un asistente. Pertenece a un único

tipo de reunión.
4.1.2. Vocabulario técnico
RF: requisito funcional. CUE: cuenta.
RNF: requisito no funcional.

ASI: usuario con el rol de Asistente.
P: prueba.
ANF: usuario con el rol de Anfitrión.
TIP: tipos de reuniones.
REU: reuniones. ADM: usuario con el rol de Admin.
4.2. Justificación de la clasificación de requisitos y de las pruebas
En primer lugar, los requisitos se dividen entre requisitos funcionales (donde se des-
cribe la funcionalidad de la aplicación) y requisitos no funcionales (donde se imponen
restricciones a la aplicación).
En relación a los requisitos funcionales, en primer lugar, éstos se clasifican por rol
de usuario, es decir, en usuario Asistente, usuario Anfitrión o usuario Admin. Esto es así
debido a que las funcionalidades del sistema están íntimamente relacionadas con el rol. A
continuación, dentro de cada rol, los requisitos se ordenan por áreas temáticas, es decir,
según la funcionalidad principal que cubren. La clasificación aparece sintetizada en la
siguiente figura:
20
Requisitos funcionales
Usuario Asistente Usuario Anfitrión Usuario Admin
- Tipos de reuniones - Tipos de reuniones

- Reuniones - Reuniones - Reuniones
- Cuenta - Cuenta
Fig. 4.1. Clasificación de requisitos funcionales
Por otra parte, los requisitos no funcionales se dividen en tres categorías diferentes:
usabilidad, compatibilidad y de desarrollo (restricciones relacionadas con la programa-
ción).
Por último, las pruebas no se clasifican por rol de usuario, sino que se sólo se dividen
en áreas temáticas: tipos de reuniones, reuniones y cuenta.
4.3. Justificación de la plantilla
4.3.1. Plantilla de requisitos
La plantilla que se empleará en cada requisito seguirá la estructura de la siguiente

tabla. Con respecto a los atributos, sólo se han seleccionado aquellos que son realmente
necesarios para el proyecto. Por ejemplo, no se han incluido atributos como el autor, la
importancia o el estado porque el valor para todos los requisitos sería el mismo.
Tabla 4.1.
Plantilla de requisitos
Identificador Compuesto por el tipo de requisito, el rol al que afecta y un

número: (RF | RNF) - (ASI | ANF | ADM) - (Número)
Título Descripción resumida del objetivo del requisito
Fecha Hace referencia a la fecha de creación y puede ser de utilidad
para realizar un seguimiento de los requisitos
Descripción Se profundiza más en el propósito del requisito
Pruebas Indica el identificador de las pruebas que están relacionadas
con el requisito
4.3.2. Plantilla de pruebas
Por otra parte, cada prueba seguirá la estructura de la siguiente tabla:
21
Tabla 4.2.
Plantilla de pruebas
Identificador Compuesto por una letra que indica que es una prueba,
el área temática y un número: (P) - (TIP | REU | CUE) -
(Número)
Título Descripción resumida de la prueba
Precondición Son aquellas condiciones que se tienen que cumplir antes
de comenzar la prueba
Acción Especifica la forma de ejecutar la prueba
Postcondición Describe qué ocurre cuando la prueba ha sido ejecutada
Requisito asociado Indica el identificador de los requisitos que están relacio-
nados con la prueba
4.4. Requisitos funcionales
4.4.1. Visión general de los requisitos
Con el propósito de ofrecer una visión general, en la siguiente tabla se recoge el iden-
tificador y el título de todos los requisitos.
Tabla 4.3.
Visión general de los requisitos
Identificador Título
RF-ASI-01 Seleccionar tipo de reunión, hora y fecha
RF-ASI-02 Introducir datos personales
RF-ASI-03 Correo de confirmación
RF-ASI-04 Ver una reunión confirmada
RF-ASI-05 Editar una reunión confirmada
RF-ASI-06 Cancelar una reunión confirmada
RF-ANF-01 Ver los tipos de reunión creados
RF-ANF-02 Obtener enlace al tipo de reunión en forma de URL
RF-ANF-03 Obtener enlace al tipo de reunión en forma de código QR
RF-ANF-04 Ver lista de reuniones confirmadas en el calendario de Odoo
RF-ANF-05 Ver los detalles de una reunión confirmada en el calendario de Odoo
RF-ANF-06 Modificar una reunión confirmada en el calendario de Odoo
RF-ANF-07 Cancelar una reunión confirmada en el calendario de Odoo
RF-ANF-08 Iniciar sesión
RF-ANF-09 Establecer disponibilidad
RF-ANF-10 Ver el perfil de usuario
22
RF-ANF-11 Modificar el perfil de usuario
RF-ANF-12 Cerrar sesión
RF-ADM-01 Ver los tipos de reunión creados
RF-ADM-02 Crear un nuevo tipo de reunión
RF-ADM-03 Modificar un tipo de reunión
RF-ADM-04 Eliminar un tipo de reunión
RF-ADM-05 Obtener enlace al tipo de reunión en forma de URL
RF-ADM-06 Obtener enlace al tipo de reunión en forma de código QR
RF-ADM-07 Ver lista de reuniones confirmadas en el calendario de Odoo
RF-ADM-08 Ver los detalles de una reunión confirmada en el calendario de Odoo
RF-ADM-09 Modificar una reunión confirmada en el calendario de Odoo
RF-ADM-10 Cancelar una reunión confirmada en el calendario de Odoo
RF-ADM-11 Iniciar sesión
RF-ADM-12 Establecer disponibilidad
RF-ADM-13 Ver el perfil de usuario
RF-ADM-14 Modificar el perfil de usuario
RF-ADM-15 Cerrar sesión
RF-ADM-16 Crear usuario
RF-ADM-17 Gestionar los roles de los usuarios
RNF-01 Tiempo de aprendizaje
RNF-02 Errores cometidos
RNF-03 Tiempo de aprendizaje
RNF-04 Lenguaje de programación Python
RNF-05 Base de datos PostgreSQL
RNF-06 Odoo Community
4.4.2. Usuario Asistente
4.4.2.1. Reuniones
Tabla 4.4.
RF-ASI-01. Seleccionar tipo de reunión, hora y fecha
Identificador RF-ASI-01
Título Seleccionar tipo de reunión, hora y fecha
Fecha 18-02-2020
Descripción El usuario podrá seleccionar el tipo de reunión, la hora y la fe-
cha que prefiera en función de la disponibilidad de la empresa.
Pruebas P-REU-01, P-REU-02
23
Tabla 4.5.
RF-ASI-02. Introducir datos personales
Título Introducir datos personales
Fecha 18-02-2020
Descripción Una vez seleccionado el tipo de reunión, la hora y la fecha, el
usuario tendrá que introducir su nombre, email y algún comen-
tario adicional antes de confirmar la reunión.
Pruebas P-REU-03
Tabla 4.6.
RF-ASI-03. Correo de confirmación
Título Correo de confirmación
Fecha 18-02-2020
Descripción Una vez confirmada la reunión por el usuario, éste recibirá un
correo de confirmación con los detalles de la reunión. Además,
la reunión será asignada a un anfitrión de la empresa.
Pruebas P-REU-03
Tabla 4.7.
RF-ASI-04. Ver una reunión confirmada
Título Ver una reunión confirmada
Fecha 18-02-2020
Descripción El usuario podrá ver las reuniones confirmadas dentro de su
cuenta Google Calendar.
Pruebas P-REU-04
Tabla 4.8.
RF-ASI-05. Editar una reunión confirmada
Título Editar una reunión confirmada
Fecha 18-02-2020
Descripción El usuario podrá editar las reuniones confirmadas a través de
un enlace que se encontrará dentro de la descripción del evento
de Google Calendar.
Pruebas P-REU-05
24
Tabla 4.9.
RF-ASI-06. Cancelar una reunión confirmada
Título Cancelar una reunión confirmada
Fecha 18-02-2020
Descripción El usuario podrá cancelar las reuniones confirmadas a través de
un enlace que se encontrará dentro de la descripción del evento
de Google Calendar.
Pruebas P-REU-06
4.4.3. Usuario Anfitrión
4.4.3.1. Tipos de reuniones
Tabla 4.10.
RF-ANF-01. Ver los tipos de reunión creados
Identificador RF-ANF-01
Título Ver los tipos de reunión creados
Fecha 18-02-2020
Descripción El usuario ver todos los tipos de reuniones que han sido asig-
nados por el administrador.
Pruebas P-TIP-01
Tabla 4.11.
RF-ANF-02. Obtener enlace al tipo de reunion en forma de URL
Título Obtener enlace al tipo de reunion en forma de URL
Fecha 18-02-2020
Descripción El usuario podrá obtener un enlace a la disponibilidad del tipo
de reunión en forma de URL.
Pruebas P-TIP-02
25
Tabla 4.12.
RF-ANF-03. Obtener enlace al tipo de reunion en forma de código QR
Fecha 18-02-2020
de reunión en forma de código QR.
Pruebas P-TIP-03
4.4.3.2. Reuniones
Tabla 4.13.
RF-ANF-04. Ver lista de reuniones confirmadas en el calendario de Odoo
Título Ver lista de reuniones confirmadas en el calendario de Odoo
Fecha 18-02-2020
Descripción El usuario podrá ver una lista de todas las reuniones confirma-
das de las cuales es anfitrión en el calendario de Odoo.
Pruebas P-REU-07
Tabla 4.14.
RF-ANF-05. Ver los detalles de una reunión confirmada en el calendario
de Odoo
Título Ver los detalles de una reunión confirmada en el calendario de
Odoo
Fecha 18-02-2020
Descripción El usuario podrá ver los detalles de todas las reuniones confir-
madas de las cuales es anfitrión en el calendario de Odoo.
Pruebas P-REU-08
26
Tabla 4.15.
RF-ANF-06. Modificar una reunión confirmada en el calendario de Odoo
Título Modificar una reunión confirmada en el calendario de Odoo
Fecha 18-02-2020
Descripción El usuario podrá modificar las reuniones confirmadas de las
cuales es anfitrión en el calendario de Odoo.
Pruebas P-REU-9
Tabla 4.16.
RF-ANF-07. Cancelar una reunión confirmada en el calendario de Odoo
Título Cancelar una reunión confirmada en el calendario de Odoo
Fecha 18-02-2020
Descripción El usuario podrá cancelar las reuniones confirmadas de las cua-
les es anfitrión en el calendario de Odoo.
Pruebas P-REU-10
4.4.3.3. Cuenta
Tabla 4.17.
RF-ANF-08. Iniciar sesión
Título Iniciar sesión
Fecha 18-02-2020
Descripción Para acceder a las funcionalidades del módulo, el usuario podrá
iniciar sesión mediante correo electrónico y contraseña.
Pruebas P-CUE-01
Tabla 4.18.
RF-ANF-09. Establecer disponibilidad
Título Establecer disponibilidad
Fecha 18-02-2020
Descripción El usuario podrá establecer su disponibilidad de manera ma-
nual para cada día de la jornada laboral.
Pruebas P-CUE-02
27
Tabla 4.19.
RF-ANF-10. Ver el perfil de usuario
Título Ver el perfil de usuario
Fecha 18-02-2020
Descripción El usuario podrá ver su información personal en su perfil de
usuario.
Pruebas P-CUE-03
Tabla 4.20.
RF-ANF-11. Modificar el perfil de usuario
Título Modificar el perfil de usuario
Fecha 18-02-2020
Descripción El usuario podrá modificar su información personal en su perfil
de usuario.
Pruebas P-CUE-04
Tabla 4.21.
RF-ANF-12. Cerrar sesión
Título Cerrar sesión
Fecha 18-02-2020
Descripción El usuario podrá cerrar la sesión.
Pruebas P-CUE-01
4.4.4. Usuario Admin
4.4.4.1. Tipos de reuniones
Tabla 4.22.
RF-ADM-01. Ver los tipos de reunión creados
Identificador RF-ADM-01
Título Ver los tipos de reunión creados
Fecha 18-02-2020
Descripción El usuario ver todos los tipos de reuniones que han sido asig-
nados por el administrador.
Pruebas P-TIP-01
28
Tabla 4.23.
RF-ADM-02. Crear un nuevo tipo de reunión
Título Crear un nuevo tipo de reunión
Fecha 18-02-2020
Descripción El usuario podrá crear un nuevo tipo de reunión y asignar em-
pleados a éstos.
Pruebas P-TIP-04
Tabla 4.24.
RF-ADM-03. Modificar un tipo de reunión
Título Modificar un tipo de reunión
Fecha 18-02-2020
Descripción El usuario podrá modificar los parámetros de cada tipo de reu-
nión y ajustar la asignación de empleados.
Pruebas P-TIP-05
Tabla 4.25.
RF-ADM-04. Eliminar un tipo de reunión
Título Eliminar un tipo de reunión
Fecha 18-02-2020
Descripción El usuario podrá eliminar un tipo de reunión creado.
Pruebas P-TIP-06
Tabla 4.26.
RF-ADM-05. Obtener enlace al tipo de reunion en forma de URL
Fecha 18-02-2020
de reunión en forma de URL.
Pruebas P-TIP-02
29
Tabla 4.27.
RF-ADM-06. Obtener enlace al tipo de reunion en forma de código QR
Fecha 18-02-2020
de reunión en forma de código QR.
Pruebas P-TIP-03
4.4.4.2. Reuniones
Tabla 4.28.
RF-ADM-07. Ver lista de reuniones confirmadas en el calendario de
Odoo
Título Ver lista de reuniones confirmadas en el calendario de Odoo
Fecha 18-02-2020
Descripción El usuario podrá ver una lista de todas las reuniones confirma-
das de las cuales es anfitrión en el calendario de Odoo.
Pruebas P-REU-07
Tabla 4.29.
RF-ADM-08. Ver los detalles de una reunión confirmada en el
calendario de Odoo
Título Ver los detalles de una reunión confirmada en el calendario de
Odoo
Fecha 18-02-2020
Descripción El usuario podrá ver los detalles de todas las reuniones confir-
madas de las cuales es anfitrión en el calendario de Odoo.
Pruebas P-REU-08
30
Tabla 4.30.
RF-ADM-09. Modificar una reunión confirmada en el calendario de
Odoo
Título Modificar una reunión confirmada en el calendario de Odoo
Fecha 18-02-2020
Descripción El usuario podrá modificar las reuniones confirmadas de las
cuales es anfitrión en el calendario de Odoo.
Pruebas P-REU-09
Tabla 4.31.
RF-ADM-10. Cancelar una reunión confirmada en el calendario de Odoo
Fecha 18-02-2020
Descripción El usuario podrá cancelar las reuniones confirmadas de las cua-
les es anfitrión en el calendario de Odoo.
Pruebas P-REU-10
4.4.4.3. Cuenta
Tabla 4.32.
RF-ADM-11. Iniciar sesión
Fecha 18-02-2020
Descripción Para acceder a las funcionalidades del módulo, el usuario podrá
iniciar sesión mediante correo electrónico y contraseña.
Pruebas P-CUE-01
Tabla 4.33.
RF-ADM-12. Establecer disponibilidad
Fecha 18-02-2020
Descripción El usuario podrá establecer su disponibilidad de manera ma-
nual para cada día de la jornada laboral.
Pruebas P-CUE-02
31
Tabla 4.34.
RF-ADM-13. Ver el perfil de usuario
Fecha 18-02-2020
Descripción El usuario podrá ver su información personal en su perfil de
usuario.
Pruebas P-CUE-03
Tabla 4.35.
RF-ADM-14. Modificar el perfil de usuario
Fecha 18-02-2020
Descripción El usuario podrá modificar su información personal en su perfil
de usuario.
Pruebas P-CUE-04
Tabla 4.36.
RF-ADM-15. Cerrar sesión
Fecha 18-02-2020
Descripción El usuario podrá cerrar la sesión.
Pruebas P-CUE-05
Tabla 4.37.
RF-ADM-16. Crear usuarios
Título Crear usuarios
Fecha 18-02-2020
Descripción El usuario podrá crear nuevos usuarios con el rol de Anfitrión
o el de Admin, que serán empleados de la empresa.
Pruebas P-CUE-06
32
Tabla 4.38.
RF-ADM-17. Gestionar los roles de los usuarios
Título Gestionar los roles de los usuarios
Fecha 18-02-2020
Descripción El usuario podrá cambiar el rol de cualquier empleado siempre
y cuando haya por lo menos un usuario con el rol de Admin.
Pruebas P-CUE-07, P-CUE-08, P-CUE-09
4.5. Requisitos no funcionales
4.5.1. Usabilidad
Tabla 4.39.
RNF-01. Tiempo de aprendizaje
Identificador RNF-01
Título Tiempo de aprendizaje
Fecha 18-02-2020
Descripción El tiempo de aprendizaje del sistema por un usuario con el rol
de Admin o con el rol de Anfitrión deberá ser inferior a 4 horas.
Una vez concluido el tiempo de aprendizaje, el usuario será
capaz de usar todas las funcionalidades del sistema.
Pruebas ***
Tabla 4.40.
RNF-02. Errores cometidos
Título Errores cometidos
Fecha 18-02-2020
Descripción Después del tiempo de aprendizaje de los usuarios con el rol
de Admin o con el rol de Anfitrión, el número medio de errores
cometidos no podrá ser superior a dos por día .
Pruebas ***
33
4.5.2. Compatibilidad
Tabla 4.41.
RNF-03. Tiempo de aprendizaje
Título Compatibilidad de navegadores web
Fecha 18-02-2020
Descripción El sistema será compatible con los siguientes navegadores:
Chrome (versión 49 en adelante), Firefox (versión 48 en ade-
lante) y Safari (versión 9 en adelante).
Pruebas ***
4.5.3. Desarrollo
Tabla 4.42.
RNF-04. Lenguaje de programación Python
Título Lenguaje de programación Python
Fecha 18-02-2020
Descripción El sistema será desarrollado empleando al menos la versión 3.6
del lenguaje de programación Python.
Pruebas ***
Tabla 4.43.
RNF-05. Base de datos PostgreSQL
Título Base de datos PostgreSQL
Fecha 18-02-2020
Descripción El sistema tendrá que emplear al menos la versión 10.0 de la
base de datos PostgreSQL para almacenar la información.
Pruebas ***
34
Tabla 4.44.
RNF-06. Odoo Community
Título Odoo Community
Fecha 18-02-2020
Descripción El sistema será desarrollado sobre la versión 14.0 de Odoo
community.
Pruebas ***
4.6. Plan de pruebas
4.6.1. Tipos de reuniones
Tabla 4.45.
P-TIP-01. Ver los tipos de reunión
Identificador P-TIP-01
Título Ver los tipos de reunión
El usuario tiene el rol de Anfitrión o el de Admin y se
Precondición
encuentra en la pantalla de la lista de tipos de reuniones.
Acción ***
El usuario podrá ver todos los tipos de reunión creados por
Postcondición
la empresa.
Requisito asociado RF-ANF-01, RF-ADM-01
Tabla 4.46.
P-TIP-02. Obtener enlace al tipo de reunión en forma de URL
Título Obtener enlace al tipo de reunión en forma de URL
Precondición
El usuario selecciona la opción de obtener un enlace a la
Acción disponibilidad en forma de URL para un tipo de reunión
determinado.
El sistema copia la URL y el usuario podrá pegarla donde
Postcondición
quiera.
35
Tabla 4.47.
P-TIP-03. Obtener enlace al tipo de reunión en forma de código QR
Título Obtener enlace al tipo de reunión en forma de código QR
Precondición
El usuario selecciona la opción de obtener un código QR a
Acción la disponibilidad en forma de URL para un tipo de reunión
determinado.
El sistema genera el código QR y lo descarga automática-
Postcondición
mente en el ordenador del usuario.
Tabla 4.48.
P-TIP-04. Crear un nuevo tipo de reunión
Título Crear un nuevo tipo de reunión
El usuario tiene el rol de Admin y se encuentra en la pan-
Precondición
talla de la lista de tipos de reuniones.
El usuario crea un nuevo tipo de reunión y asigna emplea-
Acción
dos a éstos.
El usuario y los empleados asignados al tipo de reunión
Postcondición
pueden ver este tipo en la lista de tipos de reuniones.
Requisito asociado RF-ADM-02
Tabla 4.49.
P-TIP-05. Modificar un tipo de reunión
Título Modificar un tipo de reunión
Precondición
Acción El usuario modifica un tipo de reunión existente.
El usuario y los empleados asignados al tipo de reunión
Postcondición pueden ver la actualización en la lista de tipos de reunio-
nes.
36
Tabla 4.50.
P-TIP-06. Eliminar un tipo de reunión
Título Eliminar un tipo de reunión
Precondición
Acción El usuario elimina un tipo de reunión existente.
El usuario y los empleados asignados al tipo de reunión no
Postcondición
pueden ver este tipo en la lista de tipos de reuniones.
4.6.2. Reuniones
Tabla 4.51.
P-REU-01. Seleccionar tipo de reunión, hora y fecha
Identificador P-REU-01
Título Seleccionar tipo de reunión, hora y fecha
El usuario se encuentra en la página de programar una reu-
Precondición
nión.
El usuario selecciona un tipo de reunión, una hora y una
Acción
fecha y hace click en el botón de continuar.
El sistema redirige a una pantalla en la que el usuario pue-
Postcondición
de introducir sus datos personales.
Requisito asociado RF-ASI-01
Tabla 4.52.
P-REU-02. Introducir datos personales
Título Introducir datos personales
Precondición
nión.
El usuario no selecciona un tipo de reunión, una hora o
Acción
una fecha y hace click en el botón de continuar.
El sistema no redirige a la siguiente pantalla y el botón de
Postcondición continuar se encuentra inactivo hasta que el usuario haya
seleccionado un tipo de reunión, una hora y una fecha.
37
Tabla 4.53.
P-REU-03. Introducir datos personales no válidos
Título Introducir datos personales no válidos
Precondición nión y ha seleccionado un tipo de reunión, una hora y una
fecha.
El usuario introduce sus datos personales y confirma la
Acción
reunión.
El sistema valida la información introducida, por ejemplo
comprueba que el formato del correo electrónico es co-
rrecto. Si hay algún error, se lo muestra al usuario y la
Postcondición reunión no se confirma. En caso contrario, la reunión es
confirmada y el usuario recibe un correo de confirmación.
Además, el sistema asigna la reunión a un anfitrión (o ad-
ministrador) y actualiza su calendario de Odoo.
Requisito asociado RF-ASI-02, RF-ASI-03
Tabla 4.54.
P-REU-04. Ver una reunión confirmada
Título Ver una reunión confirmada
Precondición El usuario se encuentra en Google Calendar.
Acción El usuario selecciona una de las reuniones confirmadas.
Postcondición El usuario puede ver los detalles de la reunión.
38
Tabla 4.55.
P-REU-05. Editar una reunión confirmada
Título Editar una reunión confirmada
El usuario selecciona una de las reuniones confirmadas
y hace click en el enlace para modificar la reunión que
Acción aparece en la descripción del evento de Google Calendar.
Después de hacer click, podrá seleccionar un nuevo tipo
de reunión, fecha y día.
El sistema le indica que la reunión se ha modificado con
Postcondición éxito y el calendario de Odoo de los anfitriones (o admi-
nistradores) se actualiza automáticamente.
Tabla 4.56.
P-REU-06. Cancelar una reunión confirmada
Título Cancelar una reunión confirmada
El usuario selecciona una de las reuniones confirmadas y
Acción hace click en el enlace para cancelar la reunión que apare-
ce en la descripción del evento de Google Calendar.
El sistema le indica que la reunión se ha cancelado con
Postcondición éxito y el calendario de Odoo de los anfitriones (o admi-
nistradores) se actualiza automáticamente.
Tabla 4.57.
P-REU-07. Ver una lista de reuniones confirmadas en el calendario de
Odoo
Ver una lista de reuniones confirmadas en el calendario de
Título
Odoo
Precondición
encuentra en el módulo de calendario de Odoo.
Acción ***
Postcondición El usuario puede ver una lista de reuniones confirmadas.
39
Tabla 4.58.
P-REU-08. Ver los detalles de una reunión confirmada en el calendario
de Odoo
Ver los detalles de una reunión confirmada en el calendario
Título
de Odoo
Precondición
Acción El usuario hace click en una de las reuniones confirmadas.
El usuario puede ver los detalles de la reunión selecciona-
Postcondición
da.
Tabla 4.59.
P-REU-09. Modificar una reunión confirmada en el calendario de Odoo
Modificar una reunión confirmada en el calendario de
Título
Odoo
Precondición
El usuario hace click en una de las reuniones confirmadas
Acción
y modifica la información de la misma.
El sistema le indica al usuario que la reunión se ha modifi-
Postcondición cado con éxito. Además, el sistema envía un nuevo correo
al asistente con la información actualizada de la reunión.
40
Tabla 4.60.
P-REU-10. Cancelar una reunión confirmada en el calendario de Odoo
Precondición
El usuario hace click en una de las reuniones confirmadas
Acción
y la cancela.
El sistema le indica al usuario que la reunión se ha cance-
lado con éxito. Además, el sistema envía un nuevo correo
Postcondición
al asistente para notificarle que la reunión ha sido cance-
lada.
4.6.3. Cuenta
Tabla 4.61.
P-CUE-01. Iniciar sesión
Identificador P-CUE-01
Precondición El usuario se encuentra en la pantalla iniciar sesión.
Acción El usuario introduce su correo electrónico y su contraseña.
El sistema comprueba en la base de datos si existe un usua-
rio con el correo electrónico y la contraseña introducida.
Postcondición
Si existe, le permite acceder al módulo. En caso contrario,
el sistema le indica que lo vuelva intentar.
Tabla 4.62.
P-CUE-02. Establecer disponibilidad
Precondición
encuentra en la pantalla de su perfil en Odoo.
Acción El usuario establece su disponibilidad.
El sistema le indica al usuario que la disponibilidad se ha
Postcondición
actualizado con éxito.
41
Tabla 4.63.
P-CUE-03. Ver el perfil de usuario
Precondición
Acción ***
Postcondición El usuario puede ver su información personal en su perfil.
Tabla 4.64.
P-CUE-04. Modificar el perfil de usuario
Precondición
Acción El usuario modifica la información personal de su perfil.
El sistema le indica al usuario que su información personal
Postcondición
se ha modificado con éxito.
Tabla 4.65.
P-CUE-05. Cerrar sesión
Precondición El usuario se encuentra en el módulo.
Acción El pulsa en el botón de cerrar sesión.
El sistema cierra la sesión y el usuario no puede acceder al
Postcondición
módulo hasta que no vuelva a introducir sus credenciales.
42
Tabla 4.66.
P-CUE-06. Crear usuarios
Título Crear usuarios
El usuario tiene el rol de Admin y se encuentra en el mó-
Precondición
dulo de empleados de Odoo.
El usuario crea un usuario con el rol de Anfitrión o el de
Acción
Admin.
El nuevo usuario creado recibirá una notificación por co-
Postcondición rreo electrónico para que pueda completar su perfil y ac-
ceder al sistema.
Tabla 4.67.
P-CUE-07. Modificar el rol del único usuario Admin
Título Modificar el rol del único usuario Admin
El usuario tiene el rol de Admin, se encuentra en la panta-
Precondición lla de ajustes de Odoo y en el sistema solo hay un usuario
con el rol de Admin.
Acción El usuario modifica el rol del único usuario Admin.
El sistema le indica que no puede modificar el rol del usua-
Postcondición rio porque tiene que existir por lo menos un usuario con el
rol de Admin.
Tabla 4.68.
P-CUE-08. Modificar el rol de un usuario Admin
Título Modificar el rol de un usuario Admin
El usuario tiene el rol de Admin, se encuentra en la pan-
Precondición talla de ajustes de Odoo y en el sistema hay más de un
usuario con el rol de Admin.
Acción El usuario modifica el rol de un usuario Admin.
El sistema le indica que el rol ha sido actualizado con éxito
Postcondición y éste usuario sólo podrá acceder a las funcionalidades de
los usuarios Anfitriones.
43
Tabla 4.69.
P-CUE-09. Modificar el rol de un usuario Anfitrión
Título Modificar el rol de un usuario Anfitrión
El usuario tiene el rol de Admin, se encuentra en la panta-
Precondición
lla de ajustes de Odoo.
Acción El usuario modifica el rol de un usuario Anfitrión.
El sistema le indica que el rol ha sido actualizado con éxito
Postcondición y éste usuario podrá acceder a las funcionalidades de los
usuarios Admin.
44
5. ARQUITECTURA
La definición de la arquitectura del software consiste en el diseño y en la implementa-

ción de la estructura de alto nivel del software. Para describirla, se va a emplear un modelo
compuesto por distintas vistas (o perspectivas): la vista lógica, la vista de proceso, la vista
de desarrollo y la vista física [26].
5.1. Vista lógica (o conceptual)
La vista lógica o vista de información, también conocida como “modelo conceptual”,

se ha expresado mediante un diagrama de clases. Este diagrama muestra la relación lógica
existente entre las distintas clases (objetos) del sistema [26].
El diagrama está formado por tres clases: “Usuario”, “Tipo de reunión” y “Reunión”.
En relación a la clase “Usuario”, está relacionada con la clase “Tipo de reunión” con
una asociación de 0 a muchos (un usuario puede tener asignados cero o más tipos de
reuniones). Los atributos de esta clase son un identificador, el nombre, el email, la contra-
seña, una matriz columna con la disponibilidad (matriz vertical con una única columna)
y el rol. Cada fila de la matriz de disponibilidad representará un día de la semana. Esta
clase está vinculada con el módulo Empleados de Odoo.
La clase “Tipo de reunión” está relacionada con la clase “Usuario” con una asocia-
ción de 1 a muchos (un tipo de reunión tiene que tener asignado al menos un usuario).
Los atributos que forman esta clase son: un identificador, el nombre del tipo de reunión,
la localización (google meet o físico), la dirección, una breve descripción, la fecha de
comienzo, la fecha de fin, la duración de cada reunión, el último empleado asignado y el
número total de reuniones pendientes. Solo se podrán programar reuniones entre la fecha
de comienzo y la de fin.
Por último, la clase asociación entre las clases “Usuario” y “Tipo de reunión”, que es
necesaria para registrar las reuniones llevadas a cabo. Por defecto en UML, cada asocia-
ción no puede contener tuplas repetidas, por lo que para representar el registro histórico
se ha impuesto la restricción nonunique en cada extremo de la asociación. Los atributos
son un identificador, el nombre del asistente externo, el correo electrónico del asistente
externo, comentarios adicionales, la fecha, la hora y el identificador del evento de google
calendar. Esta clase está vinculada con el módulo Calendario de Odoo.
45
Tipo de reunión
+ id: string
Usuario 1..* * + nombre: string

{nonunique} {nonunique}
+ id: string + localización: string
+ nombre: string + dirección: string
+ email: string + descripción: string
+ contraseña: string + duración: int
+ disponibilidad: string [ ] + fecha_comienzo: date

Reunión
+ rol: string + fecha_fin: date
+ id: string
+ último_empleado: int
+ nombre_asistente: string
+ num_reuniones: int
+ email_asistente: string
+ comentarios: string
+ fecha: date
+ hora: string
+ id_evento_google_calendar: string
Leyenda
{nonunique} Restricción nonunique
Nombre de la clase Asociación
Clase 1..* Multiplicidad desde uno hasta "muchos"
+ atributo: tipo Clase-asociación
* Multiplicidad desde cero hasta "muchos"
Fig. 5.1. Diagrama de clases
5.2. Vista de proceso (o de ejecución)
La vista de proceso es la descomposición de la evolución temporal del sistema en

actividades y se ha definido mediante tres diagramas de actividades.
El primer diagrama está enfocado en la gestión de los tipos de reunión y de las reunio-
nes confirmadas. En primer lugar, el usuario tiene que iniciar sesión para poder acceder a
las funcionalidades del módulo. Para ello tendrá que tener el rol de anfitrión o el de admin
y estar registrado en la base de datos. Si los datos son incorrectos, tendrá que volver a
facilitar sus datos. En cambio, si son correctos, podrá ver una lista con todos los tipos de
reunión creados. Para cada tipo de reunión será capaz de obtener la URL o el código QR
a la disponibilidad y ver las reuniones confirmadas de las cuales el usuario es anfitrión.
Además, podrá modificar o cancelar cualquiera de estas reuniones. Por último, si es un
usuario Admin, podrá crear, modificar o eliminar un tipo de reunión. También será posible
asignar empleados al tipo de reunión.
46
Leyenda
Inicio Actividad [Condición] Texto de condición
Símbolo de Flujo de control

Fin
decisión
Obtener URL o QR
Iniciar sesión
a la disponibilidad
[no es Admin]
Ver lista de tipos Asignar empleados

[datos de reunión creados al tipo de reunión
[datos [es Admin]
incorrectos] correctos]
Crear, modificar o
Ver reuniones Modificar o cancelar
eliminar un tipo de
confirmadas una reunión
reunión
Fig. 5.2. Diagrama de actividades para los tipos de reunión y las reuniones confirmadas
El segundo diagrama hace referencia a aspectos relacionados con el perfil de los usua-
rios Anfitrión y Admin. Al igual que en el caso anterior, el primer paso es iniciar sesión,
si los datos no son correctos, tendrá que volver a intentarlo. En caso contrario, el usuario
podrá ver y modificar la información personal de su perfil. Además, también podrá ac-
tualizar su disponibilidad. Por otra parte, si el rol del usuario es Admin, éste podrá crear
nuevos usuarios dentro del sistema.
Actualizar
disponibilidad
Iniciar sesión Modificar perfil Crear usuarios
[no es Admin]
Ver perfil
[datos [datos
[es Admin]
incorrectos] correctos]
Fig. 5.3. Diagrama de actividades para el perfil de los usuarios
47
El último diagrama está relacionado con la programación de una reunión por parte
del usuario Asistente. En este caso, no es necesario que se registre ni que inicie sesión.
Todo comienza seleccionando un tipo de reunión, una fecha y una hora. A continuación
tendrá que introducir sus datos personales, si el sistema detecta que no son válidos, tendrá
que volver a introducirlos. En caso contrario, el sistema creará una reunión y asignará
un anfitrión a la reunión. Tanto el asistente como el anfitrión podrán asistir, modificar o
cancelar la reunión.
[datos no válidos]
[datos
válidos]
Seleccionar tipo de Introducir datos
Crear reunión
reunión, fecha y hora personales
Asistir, modificar Asignar empleado

o cancelar reunión a reunión
Fig. 5.4. Diagrama de actividades para la programación de una reunión
5.3. Vista de desarrollo (o de implementación)
La vista de desarrollo consiste en la descomposición del código en subsistemas y com-

ponentes. Se ha especificado mediante un diagrama de componentes. Estos componentes
siguen el patrón de diseño modelo-vista-controlador (MVC). En el caso de Odoo, el mo-
delo son las tablas de PostgreSQL, las vistas se definen mediante ficheros XML o HTML
y el controlador son clases de Python. El diagrama se divide en tres subsistemas: “Vista”,
“Controlador” y “modelo”.
En primer lugar, los componentes del subsistema “Vista”. Éstas se dividen en vistas
del backend (según las guidelines de Odoo tienen que tener el sufijo views) y plantillas del
frontend (según las guidelines de Odoo tienen que tener el sufijo templates). El módulo
contendrá una vista para que los usuarios Admin y Anfitrión puedan gestionar los tipos de
reunión y dos plantillas para que el usuario Asistente pueda seleccionar el tipo de reunión
y programar una reunión. Además, se integrará con las vistas del módulo Calendario y
Empleados de Odoo. No obstante, como estas vistas ya están implementadas, no serán
incluidas en el diagrama.
En relación al subsistema “Controlador”, uno de los componentes más importantes es
el controller. Cuando un usuario accede a una URL en el navegador, éste envía una peti-
ción al servidor, que es recibida por el controlador. En función de la URL, el controlador
muestra una plantilla o vista. Además, si es necesario manipular información de la base
de datos, se apoyará en los gestores (handler), que serán los encargados de comunicarse
con los modelos.
48
Por último, el subsistema “Modelo” está formado por dos componentes: uno relacio-
nado con el tipo de reunión y otro relacionado con la reunión. Estos componentes permi-
tirán la interacción con la base de datos y representan una tabla de la misma. El sistema
también interactúa con otros modelos del módulo Calendario y Empleados de Odoo. No
obstante, como estos modelos ya están implementados, no serán incluidos en el diagrama.
<<subsystem>>
Vista
«component» «component» «component»

meeting_type_views meeting_type_templates meeting_event_templates
iMeetingTypeViews iMeetingTypeTemplates iMeetingEventTemplates
<<subsystem>> <<subsystem>>
Controlador Modelo
iMeetingTypeHandler iMeetingType
«component» «component» «component»
controller meeting_type_handler meeting_type
«component»
user_handler
iMeetingEventHandler iUserHandler
iMeetingEvent
«component» «component»
meeting_event_handler meeting_event
«component»
google_calendar_handler
iGoogleCalendarHandler
Leyenda
<<subsystem>> «component»
Subsistema Componente del
Nombre subsistema NombreComponente subsistema "vista"
«component» Componente del «component» Componente del

NombreComponente subsistema "Controlador" NombreComponente subsistema "Modelo"
Interfaz requerida Interfaz proporcionada

Nombre interfaz
Fig. 5.5. Diagrama de componentes
49
5.3.1. Contrato de operaciones
La especificación de interfaces se ha hecho mediante la técnica de diseño por contra-

tos. Además, para facilitar la comprensión, se ha seguido la misma división por subsiste-
mas que el diagrama de componentes anterior:
5.3.1.1. Subsistema “Vista”
Tabla 5.1.
Componente meeting_type_views
Componente meeting_type_views
Propósito Interfaz gráfica con la que interactuará el usuario Admin y el usuario
Anfitrión. Muestra todas las vistas relacionadas con los tipos de reunio-
nes.
Tipo Ejecutable
Dependencias ***
Interfaz iMeetingTypeViews
Contrato de operaciones
render(string screenName)
Descripción El sistema devuelve el código fuente del nombre de la vista pasado co-
mo parámetro.
Precondición El usuario quiere acceder a la pantalla.
Postcondición El navegador le muestra al usuario la pantalla.
Tabla 5.2.
Componente meeting_type_templates
Componente meeting_type_templates
Propósito Interfaz gráfica con la que interactuará el usuario Asistente y que mues-
tra la plantilla para seleccionar un tipo de reunión.
Tipo Ejecutable
Dependencias ***
Interfaz iMeetingTypeTemplates
Descripción El sistema devuelve el código fuente del nombre de la plantilla pasado
como parámetro.
50
Tabla 5.3.
Componente meeting_event_templates
Componente meeting_event_templates
Propósito Interfaz gráfica con la que interactuará el usuario Asistente y que mues-
tra todas las plantillas relacionadas con la programación de las reunio-
nes.
Tipo Ejecutable
Dependencias ***
Interfaz iMeetingEventTemplates
Descripción El sistema devuelve el código fuente del nombre de la plantilla pasado
como parámetro.
5.3.1.2. Subsistema “Controlador”
Tabla 5.4.
Componente controller
Componente controller
Propósito Permite gestionar los componentes externos, las vistas y los modelos.
Tipo Ejecutable
Dependencias iMeetingTypeViews, iMeetingTypeTemplates, iMeetingEventTempla-
tes, iMeetingTypeHandler, iMeetingEventHandler
Interfaz ***
controlador(HttpRequest request)
Descripción El sistema determina el método que hay que invocar en función de la
URL. Este método devolverá un nombre de pantalla.
Precondición El servidor ha recibido la petición del navegador.
Postcondición En función de la URL, el sistema efectúa operaciones con los compo-
nentes externos y los modelos correspondientes. Después, devuelve el
nombre de la pantalla que el sistema debería de mostrar.
show_view(string viewName)
Descripción El sistema muestra al usuario la pantalla correspondiente al nombre de
pantalla pasada como parámetro.
Precondición ***
Postcondición El usuario puede ver la pantalla en el navegador.
51
Tabla 5.5.
Componente meeting_type_handler
Componente meeting_type_handler
Propósito Permite gestionar todo lo relacionado con los tipos de reuniones.
Tipo Ejecutable
Dependencias iUserHandler, iMeetingType
Interfaz iMeetingTypeHandler
meeting_type_index()
Descripción El sistema devuelva la plantilla de la pantalla en la que el usuario puede
seleccionar un tipo de reunión.
Precondición ***
Postcondición El usuario puede seleccionar un tipo de reunión de la interfaz mostrada.
Además, puede ver la descripción y la localización.
meeting_type_details_index()
Descripción El sistema devuelve la plantilla de la pantalla en la que el usuario puede
seleccionar la fecha e introducir sus datos personales.
Precondición ***
Postcondición El usuario puede seleccionar la fecha, introducir sus datos personales y
confirmar la reunión.
copy_url(obj meeting_type)
Descripción El usuario obtiene un enlace al tipo de reunión en forma de URL.
Precondición El usuario tiene que tener el rol de Anfitrión o de Admin.
Postcondición El usuario tiene la URL en el portapapeles del sistema operativo.
download_qr(obj meeting_type)
Descripción El usuario obtiene un enlace al tipo de reunión en forma de código QR.
Precondición El usuario tiene que tener el rol de Anfitrión o de Admin.
Postcondición El sistema muestra el código QR generado en el ordenador del usuario
para que pueda descargarlo.
52
Tabla 5.6.
Componente meeting_event_handler
Componente meeting_event_handler
Propósito Permite gestionar todo lo relacionado con las reuniones.
Tipo Ejecutable
Dependencias iGoogleCalendarHandler, iMeetingTypeHandler, iUserHandler, iMee-
tingEvent
Interfaz iMeetingEventHandler
meeting_event_submit(** kw)
Descripción El sistema guarda en la base de datos la información de la reunión y
genera un evento en el Calendario de Odoo y en Google Calendar.
Precondición El usuario Asistente confirma una reunión.
Postcondición El anfitrión puede ver el evento en el calendario de Odoo y el asistente
recibe un correo electrónico de confirmación con los detalles de la reu-
nión. Además, si el correo del asistente es de Gmail, el sistema crea un
nuevo evento en su Google Calendar.
show_update_meeting_event_screen(obj meetingEvent)
Descripción El sistema devuelve la plantilla de la pantalla en la que el usuario puede
confirmar si quiere modificar o cancelar la reunión.
Precondición ***
Postcondición El usuario puede confirmar si quiere modificar o cancelar la reunión.
delete_meeting_event(obj meetingEvent)
Descripción El sistema borra la reunión del calendario de Odoo del anfitrión y el
evento de Google Calendar del asistente.
Precondición ***
Postcondición El anfitrión ya no puede ver el evento en el calendario de Odoo. Tanto
el asistente como el anfitrión reciben un correo electrónico que informa
de la cancelación del evento.
53
Tabla 5.7.
Componente user_handler
Componente user_handler
Propósito Permite gestionar todo lo relacionado con los usuarios.
Tipo Ejecutable
Dependencias ***
Interfaz iUserHandler
get_resource_resource(obj meeting_type)
Descripción El sistema devuelve los empleados asignados a un tipo de reunión.
Precondición ***
Postcondición El sistema devuelve una lista con la información de los empleados asig-
nados a un tipo de reunión.
get_resource_calendar_sorted(obj resource_resource)
Descripción El sistema devuelve el horario de trabajo de los empleados.
Precondición ***
Postcondición El sistema devuelve el horario de trabajo de los empleados pasados co-
mo parámetro ordenados por id de manera ascendente.
get_availability(int meetingDuration, obj resource_resource, obj resour-
ce_calendar_attendance_sorted)
Descripción El sistema devuelve la disponibilidad de los empleados.
Precondición ***
Postcondición El sistema devuelve la disponibilidad de los empleados pasados como
parámetro.
get_first_available_employee(obj employee_attendance_order, obj resour-
ce_resource, obj resource_calendar_attendance_sorted, string selectedDate,
string selectedDay, string selectedTime, int meetingDuration)
Descripción El sistema devuelve el id del primer empleado disponible para el tipo
de reunión y fecha seleccionados por el usuario Asistente.
Precondición ***
Postcondición El sistema devuelve el id del primer empleado disponible o -1 si no
encuentra ninguno.
is_available(int res_users_id, string selectedDate, string selectedDay, string selected-
Time, int meetingDuration)
Descripción El sistema comprueba si el usuario Anfitrión o Admin tiene otro evento
en el calendario de Odoo en la fecha seleccionada por el asistente.
Precondición ***
Postcondición El sistema devuelve un booleano True si no hay otro evento en el calen-
dario del empleado o False en caso contrario.
54
Tabla 5.8.
Componente google_calendar_handler
Componente google_calendar_handler
Propósito Permite gestionar todo lo relacionado con Google Calendar.
Tipo Ejecutable
Dependencias ***
Interfaz iGoogleCalendarHandler
get_google_calendar_service()
Descripción El sistema gestiona y configura las credenciales de Google Calendar.
Precondición ***
Postcondición El sistema devuelve una variable service que permite acceder a la API
de Google Calendar.
create_google_calendar_event(string event_name, string meetingDescription, string
start_date_time, string end_date_time, string attendeeEmail, string employeeEmail,
string meetingLocation, string meetingAddress)
Descripción El sistema genera un nuevo evento de Google Calendar.
Precondición El usuario Asistente ha seleccionado tipo de reunión, hora y fecha. Ade-
más, ha introducido sus datos personales y ha confirmado la reunión.
Postcondición El usuario Asistente recibe un correo electrónico con los detalles de la
reunión. Además, si el correo del asistente es de Gmail, el sistema crea
un nuevo evento en su Google Calendar.
delete_google_calendar_event(int eventId)
Descripción El sistema borra el evento de Google Calendar del asistente.
Precondición ***
Postcondición El asistente y el anfitrión reciben un correo electrónico que informa de
la cancelación del evento.
55
5.3.1.3. Subsistema “Modelo”
Tabla 5.9.
Componente meeting_type
Componente meeting_type
Propósito Permite gestionar los valores de la base de datos relacionados con el
tipo de reunión.
Tipo Ejecutable
Dependencias ***
Interfaz meeting_type
getId(), getNombre(), getLocalizacion(), getDescripcion(), getEmpleados(), getRan-
go(), getDuracion(), getLimite(), getUrl(), getReuniones()
Descripción El sistema devuelve el valor en la base de datos de la propiedad especi-
ficada en el nombre del método.
Precondición ***
Postcondición El sistema devuelve el valor en la base de datos de la propiedad especi-
setId(string valor), setNombre(string valor), setLocalizacion(string valor), setDes-
cripcion(string valor), setEmpleados(string[] valor), setRango(int valor), setDura-
cion(int valor), setLimite(int valor), setUrl(string valor), setReuniones(string[] va-
lor)
Descripción El sistema actualiza el valor en la base de datos de la propiedad especi-
Precondición ***
Postcondición El sistema ctualiza el valor en la base de datos de la propiedad especifi-
cada en el nombre del método.
56
Tabla 5.10.
Componente meeting_event
Componente meeting_event
Propósito Permite gestionar los valores de la base de datos relacionados con las
reuniones.
Tipo Ejecutable
Dependencias ***
Interfaz iM_Reunion
getId(), getTipoReunion(), getNombreAsistente(), getEmailAsistente(), getComenta-
rios(), getAnfitrion(), getFecha(), getHora(), getEstado()
Descripción El sistema devuelve el valor en la base de datos de la propiedad especi-
Precondición ***
Postcondición El sistema devuelve el valor en la base de datos de la propiedad especi-
setId(string valor), setTipoReunion(string valor), setNombreAsistente(string valor),
setEmailAsistente(string valor), setComentarios(string valor), setAnfitrion(string
valor), setFecha(date valor), setHora(string valor), setEstado(string valor)
Descripción El sistema actualiza el valor en la base de datos de la propiedad especi-
Precondición ***
Postcondición El sistema ctualiza el valor en la base de datos de la propiedad especifi-
cada en el nombre del método.
5.4. Vista física (o de despliegue)
La vista física consiste en la descomposición del sistema en unidades hardware y

los elementos software que contienen cada una de ellas. Para ello se ha recurrido a un
diagrama de despliegue.
En este proyecto, el sistema tiene una arquitectura cliente servidor. Cada vez que el
cliente (navegador web de los usuarios) quiere acceder a una URL, el navegador envía una
petición a un servidor DNS (Domain Name System). Éste es el encargado de indicarle la
dirección IP donde se encuentra la página que quiere acceder. A continuación, el cliente
envía una petición HTTP al servidor de aplicaciones haciendo uso de la dirección IP
facilitada por el servidor DNS. Una vez que el servidor recibe la petición, si es necesario
efectuará operaciones con la base de datos y posteriormente manda una respuesta HTTP.
Este mensaje incluye el código fuente de la pantalla que el usuario quiere ver. Todas las
comunicaciones entre servidor y cliente se llevan a cabo gracias a las redes de routers y
al protoclo IPv4.
57
Servidor
DNS
Cliente
Base de datos
Servidor de
aplicaciones
Fig. 5.6. Diagrama de despliegue
58
6. DISEÑO DE LA INTERFAZ DE USUARIO
6.1. Modelo de navegación
6.1.1. Modelo de navegación usuario Asistente
En el caso del usuario Asistente, primero tendrá que elegir el tipo de reunión, la fecha
y la hora que mejor se adapte a sus necesidades. Por último será necesario que introduzca
sus datos personales.
Seleccionar tipo
reunión, fecha y hora
Introducir datos
Fig. 6.1. Mapa de navegación del usuario Asistente
6.1.2. Modelo de navegación usuario Anfitrión
En relación al usuario Anfitrión, podrá acceder a los tipos de reunión, al módulo de

calendario de Odoo y su perfil de usuario en el módulo Empleados de Odoo. Para cada
tipo de reunión creado, el usuario podrá ver los detalles: título, descripción, número de
reuniones pendientes, empleados asignados... Además, también podrá copiar el enlace o
descargar el código QR del tipo de reunión. Por otra parte, dentro del calendario podrá
ver los detalles de cada reunión asignada y editarlo o cancelarlo. Por último, también será
capaz de determinar su disponiblidad y actualizar sus datos personales.
Módulo Módulo
Tipos de reuniones
Calendario de Odoo Empleado de Odoo
Ver y actualizar sus

Detalles del tipo de Copiar URL o
Detalles del evento datos personales y
reunión descargar código QR
disponibilidad
Fig. 6.2. Mapa de navegación del usuario Anfitrión
59
6.1.3. Modelo de navegación usuario Admin
Con respecto al usuario Admin, como bien se ha indicado en apartados anteriores,

tiene acceso a todas las funcionalidades del usuario Anfitrión. Por tanto, el mapa de nave-
gación es similar. Existen dos diferencias principales: puede crear, modificar y eliminar
tipos de reuniones y puede crear y gestionar los roles de los usuarios.
Módulo Módulo
Tipos de reuniones
Calendario de Odoo Empleado de Odoo
Crear, modificar y Ver y actualizar sus

Detalles del tipo de Copiar URL o Crear y gestionar los
eliminar tipos de Detalles del evento datos personales y
reunión descargar código QR roles de los usuarios
reuniones disponibilidad
Fig. 6.3. Mapa de navegación del usuario Admin
6.2. Diseño de la interfaz
El diseño de la interfaz de usuario para cada uno de los roles definidos se han desarro-
llado mediante una serie de wireframes usando la herramienta Balsamiq.
6.2.1. Interfaz del usuario Asistente
El usuario Asistente tiene que seleccionar el tipo de reunión que quiere programar.
Para ello puede ver la ubicación y una breve descripción.
A Web Page
https://odoomeetings.com
Programar una reunión

Selecciona un tipo de reunión:
Tipo reunión
Ubicación:
Descripción:
Siguiente
Fig. 6.4. Usuario Asistente. Seleccionar tipo de reunión, fecha y hora
Una vez seleccionado el tipo de reunión, tiene que seleccionar la fecha y la hora.
Por último, tiene que introducir sus datos personales y confirmar la reunión. Una vez
60
confirmada, le llegará un correo electrónico de confimarción.
A Web Page
Seleccionar fecha y hora

Selecciona la fecha y hora. La duración es de XX minutos.
Fecha Hora
dd/mm/2021 dd/mm/2021
Introduce tus datos

Nombre * Email *
Comentarios *
Volver Confirmar
Fig. 6.5. Usuario Asistente. Introducir la información requerida por la empresa
Cuando el usuario haga clic en confirmar reunión, le llegará un correo de Google

Calendar en el que aparecerá la creación de un nuevo evento. En la descripción de este
evento se incluirán dos enlaces, uno para modificar la fecha u hora y otro para cancelar la
reunión.
6.2.2. Interfaz del usuario Anfitrión
El usuario puede usar el menú superior para acceder al módulo Calendario de Odoo,
ver los tipos de reunión y acceder a su perfil del módulo Empleados de Odoo. Cuando el
usuario hace clic en Tipos de reunión, puede ver una lista de todos los tipos de reunión
creados. Al hacer clic sobre los tres puntos puede copiar el enlace o descargar el código
QR del tipo de reunión. Por otra parte, puede llegar al calendario a través del menú supe-
rior o haciendo clic en el botón de “X reuniones”. Por último, si hace clic sobre el icono
del perfil en el menú superior, el usuario podrá ajustar su disponibilidad.
61
A Web Page
Odoo Meetings Calendario Tipos de reunión 

Tipo de reunión 1  Copiar enlace
X reuniones
Obtener QR
Fig. 6.6. Usuario Anfitrión. Menú de más opciones para cada tipo de reunión
A Web Page
Disponibilidad
Lunes 09:00 - 17:00
Martes 09:00 - 17:00
Miérc. 09:00 - 17:00
Jueves 09:00 - 17:00
Guardar
Fig. 6.7. Usuario Anfitrión. Introducir la disponibilidad
Como bien se indicó anteriormente, para cada tipo de reunión el usuario puede ver
todas las reuniones confirmadas por el asistente. Por tanto, cada vez que el asistente se-
leccione un tipo de reunión, una fecha, una hora y proporcione sus datos personales, la
reunión será confirmada automáticamente y aparecerá en el calendario de Odoo. Además,
también podrá cancelar la reunión o ver y editar los detalles de cada una.
62
A Web Page

Semana 13
 Hoy Día Semana Mes Año

L M X J V
08:00 Reunión
con Sara
09:00
10:00
11:00
12:00
13:00
14:00Ver todas las reuniones asignadas en forma de calendario

Fig. 6.8. Usuario Anfitrión.
A Web Page

Semana 13
 Hoy Día Semana Mes Año

L M X J V
08:00 Reunión
con Sara
09:00
10:00
Editar Aceptada
11:00
12:00
13:00
14:00Ver los detalles de cada reunión asignada

Fig. 6.9. Usuario Anfitrión.
6.2.3. Interfaz del usuario Admin
El usuario Admin tiene una interfaz parecida al usuario Anfitrión. Cuando el usuario
hace clic en Tipos de reunión, puede ver una lista de todos los tipos de reunión creados.
Al hacer clic sobre los tres puntos, aparte de copiar el enlace y obtener el código QR,
también puede editar, eliminar el tipo de reunión. El botón de “X reuniones” redigirá al
calendario, en el cual puede ver todas las reuniones programadas, incluso si él no es el
anfitrión. Asismismo, puede usar el botón de crear para crear un nuevo tipo de reunión.
63
Por último, si hace clic sobre el icono del perfil en el menú superior, el usuario podrá
ajustar su disponibilidad.
Para crear un nuevo usuario, tiene que acudir al módulo de Empleados de Odoo. No
obstante, como ya está programado, no se diseñará una nueva interfaz, simplemente se
integrará con Odoo Meetings mediante la base de datos.
A Web Page

Crear
Tipo de reunión 1  Editar

X reuniones
Eliminar
Copiar enlace
Obtener QR
Fig. 6.10. Usuario Admin. Listado de tipos de reuniones existentes
Cuando quiera crear un nuevo tipo de reunión tendrá que introducir un nombre iden-
tificativo del mismo, la localización (físico, reunión por Google Meet, teléfono...) y una
pequeña descripción. Éste último, será un campo opcional. Por otra parte, tendrá que asig-
nar empleados al tipo de reunión, que serán los anfitriones. Por último, deberá establecer
la fecha de inicio, la fecha de fin y la duración.
64
A Web Page

Descartar Guardar
Información general
Nombre *
Localización * Selecciona una localización
Descripción
Empleados
Añadir
Nombre del empleado 
XXXX
Siguiente
Fig. 6.11. Usuario Admin. Creación de un nuevo tipo de reunión. Información general
A Web Page

Descartar Guardar
Fechas y duración
Los usuarios pueden programar reuniones:
Fecha de inicio dd/mm/2021
Fecha de fin dd/mm/2021
Duración 90 min
Atrás Siguiente
Fig. 6.12. Usuario Admin. Creación de un nuevo tipo de reunión. Rango de fechas, duración y
límite
La interfaz para editar un tipo de reunión va a ser muy parecida a la creación, por lo
que no se presenta un diseño para la modificación.
65
7. INFORMACIÓN ADICIONAL
7.1. Despliegue de Odoo Meetings en Amazon Web Services
Para poder comprobar el correcto funcionamiento del módulo Odoo Meetings, se ha

instalado Odoo 14 en una instancia EC2 de Amazon Web Services con el sistema operati-
vo Ubuntu 20.04. Dentro de esta instancia se ha instalado también el módulo desarrollado.
Para que todo el mundo pueda acceder a la aplicación web, es necesario tener abiertos los
puertos 80 (HTTP), 443 (HTTPS) y el 8069 (puerto por defecto de Odoo). Por otra parte,
también es necesario el puerto 22 para la conexión a través de SSH a la instancia.
Dado que el puerto por defecto para acceder a Odoo es el 8069, si se quisiera acceder
a la web, la URL sería http://direccionIP:8069. Para que se pueda acceder sin indicar el
puerto, hay que cambiar el puerto de Odoo al 80, que es el puerto por defecto para HTTP.
Para ello se ha instalado y configurado Nginx en la instancia.
Por otra parte, Amazon asigna una dirección IP dinámica, por lo que cada vez que se
reinicia la instancia, la dirección IP cambia. Para una mayor comodidad, se ha configurado
en Amazon Web Services una dirección IP elástica, es decir, una dirección IPv4 estática
y pública (18.133.146.171). Si se introduce esta dirección IP en el navegador, se podrá
acceder a la aplicación web. No obstante, para los usuarios es complicado recordar una
dirección IP, motivo por el cual se crearon los DNS (Domain Name System), que es algo
similar a la agenda telefónica de Internet. De esta manera, los usuarios acceden a las
aplicaciones web a través de un dominio y los navegadores son los encargados de traducir
estos nombres de dominio a direcciones IP gracias a los servidores DNS.
Por tanto, para facilitar el acceso se ha adquirido un dominio en Freenom y se han
configurado los registros DNS para que apunten a la dirección IP elástica asignada por
Amazon. El dominio es: odoomeetings.tk. Además, se ha instalado un certificado SSL
gracias a la autoridad de certificación Let´s Encrypt. De esta manera, los intercambios
de información entre un navegador y el servidor web están cifrados. Para que funcione
correctamente es necesario abrir el puerto 443 (HTTPS).
7.2. Dominio para acceder a la versión Demo del módulo
Se puede acceder al módulo a través de la siguiente dirección: https://odoomeetings.tk.

Una vez que se accede a la aplicación web, se puede programar una reunión sin ne-
cesidad de crear una nueva cuenta. Si se quiere acceder al panel de administración, será
necesario hacer clic en “Registrar entrada”, situado en la parte derecha del menú superior.
Las credenciales son las siguientes:
66
Tabla 7.1.
Credenciales de acceso a https://odoomeetings.tk
Tipo de usuario Email Contraseña

Admin admin@testing.com }4FR*5L_vcFQ$ZpB
Anfitrión anfitrion@testing.com Qn-F2gx($7p<^.z-
El módulo se encuentra dentro del módulo Calendario de Odoo y se accede a través

del menú superior izquierdo.
7.3. Código fuente en Github
El código fuente se encuentra en Github y contiene una descripción detallada de cómo

se ha configurado Odoo y Amazon Web Services en el “Readme.md”. Se puede acceder
a través del siguiente enlace: https://github.com/sensenye/odoo-meetings.
67
8. MANUAL DE USUARIO
8.1. Usuario Asistente
Para ver el funcionamiento del módulo para un usuario Asistente, se puede acceder a
través de la demo instalada en https://odoomeetings.tk. En primer lugar, el asistente tiene
que seleccionar el tipo de reunión. Además, puede ver la ubicación y la descripción del
mismo.
Fig. 8.1. Interfaz de seleccionar el tipo de reunión
A continuación, tiene que introducir su información personal y le llegará un correo de

confirmación. Por otro lado, se creará un nuevo evento en su Google Calendar.
Fig. 8.2. Interfaz de introducir datos personales
68
8.2. Usuario Anfitrión
Para acceder a las funcionalidades del usuario Anfitrión, hay que introducir las creden-
ciales de la tabla 7.1 en la siguiente dirección: https://odoomeetings.tk/web/login. Ade-
más, también se puede acceder desde “Registrar entrada”, situado en la parte derecha del
menú superior. A continuación, haciendo clic en los cuatro cuadrados de la parte superior
izquierda, accedemos al Calendario de Odoo.
Fig. 8.3. Interfaz del calendario de Odoo
Haciendo clic sobre Odoo Meetings, el usuario puede acceder a los tipos de reunión
creados.
Fig. 8.4. Interfaz de la lista de tipos de reunión
Y si hace clic sobre cualquier tipo de reunión, puede ver la información de cada uno.
Sin embargo, no puede crear, editar ni borrar tipos de reunión.
69
Fig. 8.5. Interfaz de los detalles de un tipo de reunión
Por otra parte, dentro del módulo Empleados, se puede cambiar la disponibilidad (ho-
ras laborables) dado que es el horario de trabajo que tiene:
Fig. 8.6. Interfaz del perfil de usuario
70
Fig. 8.7. Interfaz de la disponibilidad de un empleado
8.3. Usuario Admin
8.3.1. ¿Cómo gestionar los tipos de reunión?
El usuario con el rol de Admin puede ver, crear, editar y borrar un tipo de reunión.
Fig. 8.8. Interfaz del listado de tipos de reunión
Fig. 8.9. Interfaz de los detalles de un tipo de reunión
71
8.3.2. ¿Cómo gestionar los usuarios y los roles?
Los usuarios se gestionan dentro del módulo Empleados de Odoo, que se puede acce-
der desde el menú superior izquierdo.
Fig. 8.10. Interfaz del directorio de empleados
El primer paso será crear un nuevo empleado. La información más importante es de-
terminar las horas laborables (dentro de “Información del trabajo”) y el usuario OpenERP
(dentro de “Configuración RRHH”). En relación a las horas laborables, éstas representan
la disponibilidad del empleado, dado que es el horario de trabajo que tiene:
Fig. 8.11. Interfaz para determinar las horas laborables
Por otra parte, cuando se está creando el usuario OpenERP, es importante introducir
bien el correo electrónico dado que es el que empleará para iniciar sesión. El rol que tiene
por defecto es el de anfitrión. Una vez creado, hay que establecer la contraseña de acceso
a Odoo. Para ello es necesario ir a los ajustes de Odoo desde el menú superior izquierdo.
72
Fig. 8.12. Interfaz de los ajustes de Odoo
Dentro de las opciones generales, hay que hacer clic sobre “Administrar usuarios” y
seleccionar el nuevo usuario creado. Existen dos opciones para establecer la contraseña:
enviar un correo para que el usuario establezca él mismo su contraseña o cambiar la
contraseña directamente y darle las credenciales al usuario.
Fig. 8.13. Interfaz de enviar invitación o cambiar contraseña
Además, en esta misma ventana, dentro de “Permisos de acceso”, se le puede asignar

el rol de Admin. Si no tiene el rol de Admin asignado quiere decir que tiene el rol de
Anfitrión.
73
Fig. 8.14. Interfaz para gestionar los roles de usuario
74
BIBLIOGRAFÍA
[1] Organización Mundial de la Salud. “COVID-19: cronología de la actuación de la

OMS,” [En línea]. Disponible en: https://www.who.int/es/news/item/27-
04-2020-who-timeline---covid-19 (Acceso: 16-01-2021).
[2] Eurofound. “Working during COVID-19,” [En línea]. Disponible en: https://
www - eurofound - europa - eu . biblioteca5 . uc3m . es / data / covid - 19 /
working-teleworking (Acceso: 16-01-2021).
[3] El Banco de España. “El teletrabajo en España,” [En línea]. Disponible en: https:
//www.bde.es/bde/es/utiles/Canal_RSS/Publicaciones/el-teletrabajo-
en-espana.html (Acceso: 16-01-2021).
[4] N. Bloom, “To raise productivity, let more employees work from home,” Harvard
business review, vol. 92, n.o 1/2, pp. 28-29, 2014.
[5] Zoom. “CORRECTION – Zoom Reports Results for Third Quarter Fiscal Year
2021,” [En línea]. Disponible en: https : / / investors . zoom . us / news -
releases/news-release-details/correction-zoom-reports-results-
third-quarter-fiscal-year-2021 (Acceso: 16-01-2021).
[6] Odoo. “Quiénes somos,” [En línea]. Disponible en: https://www.odoo.com/
es_ES/page/about-us (Acceso: 16-01-2021).
[7] E. M. Shehab, M. W. Sharp, L. Supramaniam y T. A. Spedding, “Enterprise re-
source planning: An integrative review,” English, Business Process Management
Journal, vol. 10, n.o 4, pp. 359-386, 2004. [En línea]. Disponible en: https :
//search.proquest.com/scholarly-journals/enterprise-resource-
planning-integrative-review/docview/220295661/se-2?accountid=
14501.
[8] L. B. Schwarz, “The Economic Order-Quantity (EOQ) Model,” en D. Chhajed
y T. J. Lowe, eds., ép. Building Intuition: Insights From Basic Operations Ma-
nagement Models and Principles. Boston, MA: Springer US, 2008, pp. 135-154,
ID: Schwarz2008. doi: 10.1007/978-0-387-73699-0_8. [En línea]. Disponible
en: https://doi.org/10.1007/978-0-387-73699-0_8.
[9] F. Robert Jacobs y F. ‘Ted’ Weston, “Enterprise resource planning (ERP)—A brief
history,” Journal of Operations Management, vol. 25, n.o 2, pp. 357-363, 2007,
Special Issue Evolution of the Field of Operations Management SI/ Special Issue
Organisation Theory and Supply Chain Management. doi: https://doi.org/
10 . 1016 / j . jom . 2006 . 11 . 005. [En línea]. Disponible en: http : / / www .
sciencedirect.com/science/article/pii/S0272696306001355.
[10] W. Kenton. “Material Requirements Planning (MRP),” [En línea]. Disponible en:
https://www.investopedia.com/terms/m/mrp.asp (Acceso: 20-01-2021).
75
[11] J. M. Wilson, “The origin of material requirements planning in Frederick W. Tay-
lor’s planning office.,” International Journal of Production Research, vol. 54, n.o 5,
pp. 1535-1553, 2016. [En línea]. Disponible en: http://search.ebscohost.
com . biblioteca5 . uc3m . es / login . aspx ? direct = true & db = egs & AN =
113778243&lang=es&site=ehost-live.
[12] Oracle. “¿Qué es ERP?” [En línea]. Disponible en: https://www.oracle.com/
es/erp/what-is-erp/#link4 (Acceso: 20-01-2021).
[13] Open Source Initiative. “The Open Source Definition,” [En línea]. Disponible en:
https://opensource.org/osd (Acceso: 18-01-2021).
[14] A. Fuggetta, “Open source software––an evaluation,” Journal of Systems and Soft-
ware, vol. 66, n.o 1, pp. 77-90, 2003. doi: https://doi.org/10.1016/S0164-
1212(02)00065-1. [En línea]. Disponible en: http://www.sciencedirect.
com/science/article/pii/S0164121202000651.
[15] A. Ganesh, K. N. Shanil, C. Sunitha y A. M. Midhundas, “OpenERP/Odoo - An
Open Source Concept to ERP Solution,” en 2016 IEEE 6th International Confe-
rence on Advanced Computing (IACC), 2016, pp. 112-116. doi: 10.1109/IACC.
2016.30.
[16] Optimus Information. “Open-Source vs. Proprietary Software Pros and Cons,” [En
línea]. Disponible en: http://www.optimusinfo.com/downloads/white-
paper/opensource- vs- proprietary- software- pros- and- cons.pdf
(Acceso: 09-02-2021).
[17] Odoo. “Building a module,” [En línea]. Disponible en: https://www.odoo.com/
documentation/14.0/howtos/backend.html (Acceso: 19-01-2021).
[18] Odoo. “Compare Odoo Editions,” [En línea]. Disponible en: https://www.odoo.
com/page/editions (Acceso: 19-01-2021).
[19] Calendly. “Calendly security and privacy,” [En línea]. Disponible en: https://
calendly.com/pages/security (Acceso: 22-01-2021).
[20] Calendly. “Try all features free for 14 days,” [En línea]. Disponible en: https:
//calendly.com/pages/pricing (Acceso: 22-01-2021).
[21] Odoo. “Precios de Odoo,” [En línea]. Disponible en: https://www.odoo.com/
es_ES/pricing (Acceso: 22-01-2021).
[22] PostgreSQL. “PostgreSQL: The World’s Most Advanced Open Source Relational
Database,” [En línea]. Disponible en: https://www.postgresql.org/ (Acceso:
22-01-2021).
[23] Creative Commons. “Choose a Licence,” [En línea]. Disponible en: https : / /
creativecommons.org/choose/ (Acceso: 22-01-2021).
[24] Odoo. “Odoo Guidelines,” [En línea]. Disponible en: https://www.odoo.com/
documentation/14.0/reference/guidelines.html (Acceso: 23-01-2021).
76
[25] Infoautónomos. “La contabilidad del autónomo y la pyme,” [En línea]. Disponi-
ble en: https : / / www . infoautonomos . com / contabilidad / tablas - de -
amortizacion-para-los-bienes-de-una-empresa/ (Acceso: 24-01-2021).
[26] P. Kruchten, “Architectural Blueprints—The “4+1” View Model of Software Ar-
chitecture,” IEEE Software, vol. 12, n.o 6, pp. 42-50, nov. de 1995.
77
ANEXO A. TELETRABAJO EN ESPAÑA (2019)
Teletrabajo
Ningún día Ocasionalmente Más de la mitad de los
( %) ( %) días trabajados ( %)
Situación laboral
Asalariado indefinido 64,4 35,3 33,6
Experiencia: menos de 1 año 6,5 5,6 4,3
Experiencia: 1-3 años 14,4 17,7 9,1
Experiencia: 3-7 años 18,1 16,8 11,5
Experiencia: más de 7 años 60,9 59,9 75,1
Asalariado temporal 23,5 6,2 9,9
Autónomo 12,1 58,5 56,5
Ocupación
Militares 0,6 0 0,2
Directores y gerentes 3,2 12,6 10,6
Técn. y prof. científ. e intelectuales 15,1 40 51,9
Técnicos y profesionales de apoyo 10,20 17,4 15,9
Empl. contables, admin. 11,1 4,9 3,2
Trab.de los serv. de restauración,
24,2 9,8 7,3
personales, protec. y vendedores
Trab. cualif. agrícola y ganadero 2,2 4,4 2,4
Artesanos y trab. cualif. 11,5 8,4 6,3
Oper. de instalaciones y maquinaria 8 1,5 1
Ocup. elementales 13,9 0,9 1,3
Sector de actividad
Agric., ganadería, silv. y pesca 4,4 4,6 2,7
Ind. manufacturera 12,9 9 5,7
Construcción 6,6 8,5 6,6
Comercio, reparación vehículos 15,7 13,8 11,5
Hostelería 9,4 2,5 2,2
Información y comunicaciones 2,7 7,5 5,8
Activ. financieras y seguros 2,1 3,1 2,2
Activ. inmobiliarias 0,6 2 2,3
Activ. prof., científ. y técnicas 4 14,9 16,6
Activ. admin. y serv. aux. 5,6 3,1 2,7
Admón. Públ. y Seg. Social. 7,3 1,5 1,6
Educación 5,2 17,6 28,9
Activ. sanitarias y de serv. sociales 9,1 3,5 3,1
Activ. artísticas y recreativas 2,1 2,9 2,6
Fuente: Adaptado de [3].

TFG Sensen Ye

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TFG Sensen Ye

Cargado por

Copyright:

Formatos disponibles

Doble Grado Universitario en Ingeniería Informática y ADE

Trabajo Fin de Grado

Esta obra se encuentra sujeta a la licencia Creative Commons Reconocimiento - No

La aparición del COVID-19 ha cambiado por completo el comportamiento de millo-

3.1 Algoritmo de asignación de reuniones . . . . . . . . . . . . . . . . . . . 17

4.1 Clasificación de requisitos funcionales . . . . . . . . . . . . . . . . . . . 21

5.1 Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.1 Mapa de navegación del usuario Asistente . . . . . . . . . . . . . . . . . 59

8.1 Interfaz de seleccionar el tipo de reunión . . . . . . . . . . . . . . . . . . 68

2.1 Presupuesto de los materiales necesarios . . . . . . . . . . . . . . . . . . 12

3.1 Capacidades del “usuario Asistente” . . . . . . . . . . . . . . . . . . . . 18

4.1 Plantilla de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.1 Componente meeting_type_views . . . . . . . . . . . . . . . . . . . . . 50

1.1. Visión general

El 31 de diciembre de 2019, la Comisión Municipal de Salud de Wuhan (China) no-

La aparición del COVID-19 ha cambiado por completo el comportamiento de millones

1.4. Estructura del documento

2.1. Estado del arte

2.1.1. Definición de ERP

Un ERP (Enterprise Resource Planning) es un sistema de gestión empresarial que se

2.1.2. La historia de los ERP

Si se solicita una mayor cantidad de pedido, la frecuencia de pedido disminuye, y

Lista de materiales, también conocido como BOM (Bills of materials). Se incluye

Programa maestro de producción, también conocido como MPS (Master Production

Más tarde, en el año 1983, se creó la planificación de recursos de fabricación, denomi-

2.1.3. Clasificación de los ERP

Al principio estos sistemas eran instalados en máquinas locales, no obstante, la gran

Las organizaciones tienen un control absoluto sobre el sistema y sobre el código

No obstante, no todo son ventajas, uno de los principales inconvenientes es el soporte

2.1.4. ERP Odoo

• Vista de objetos. Permiten definir la interfaz gráfica.

Los módulos se agrupan en varias categorías, por ejemplo contabilidad, gestión de

2.1.5. Productos similares

2.2. Marco regulador

El objetivo del presente trabajo es desarrollar un módulo de programación de reunio-

2.3. Entorno socio-económico

Precio × Tiempo de uso

2.3.2. Impacto socio-económico

3.1. Alcance del software

En este proyecto se va a desarrollar un módulo open source para la programación

3.2. Capacidades generales

Fig. 3.1. Algoritmo de asignación de reuniones

A continuación, para cada empleado de la lista, se comprueba su disponibilidad y si

3.3. Restricciones generales

3.4. Características de los usuarios: roles y capacidades

Dentro del sistema existen tres tipos de usuarios.

Las personas que atienden a las reuniones (“Usuario Anfitrión”).

El administrador, que es el encargado de crear, editar y eliminar los tipos de reunio-

Cada rol requiere distintos servicios o funciones, denominados capacidades. Estas

3.5. Entorno operacional

Generador de Módulo de Odoo Módulo de Odoo

Crear videoconferencia Leyenda

Entidades externas Interacción

Fig. 3.2. Diagrama de contexto

4.1. Vocabulario del dominio

4.1.1. Vocabulario del modelo de información

Reunión: cita online o física entre un anfitrión y un asistente. Pertenece a un único

4.1.2. Vocabulario técnico

RF: requisito funcional. CUE: cuenta.

RNF: requisito no funcional.

REU: reuniones. ADM: usuario con el rol de Admin.

4.2. Justificación de la clasificación de requisitos y de las pruebas

Usuario Asistente Usuario Anfitrión Usuario Admin