Desarrollo de una Aplicación Móvil para Estudiantes de la FIB

Desarrollo de una Aplicación Móvil para Estudiantes de la FIB

______________________________________________________

Grado en Ingeniería Informática (GEI)

Trabajo Final de Grado

Autor: Joan Marc Pastor Mackenzie Director de proyecto: Carles Farré Tost Departamento: ESSI Especialidad: Ingeniería del Software Convocatoria: 2019/2020 Q2

Resumen Los estudiantes de la Facultat d’Informàtica de Barcelona interactúan con la facultad mediante una intranet llamada El Racó. Esta interacción se realiza constantemente, incluyendo situaciones en las que únicamente se tiene acceso desde un dispositivo móvil. Actualmente, el único método para acceder a este recurso es mediante un navegador web. Este proyecto pretende acercar la plataforma a un formato de aplicación móvil nativa con el fin de aprovechar los recursos que esta ofrece, como notificaciones y una mejor experiencia de navegación, para proporcionar al estudiante una experiencia cómoda y completa. Como base del proyecto, se trabajará sobre un aplicativo Android préviamente creado por el autor de este proyecto que interactúa con la API de la facultad. Se pretende rediseñar la capa de datos, añadir funcionalidades adicionales, crear juegos de pruebas completos, traer la aplicación a iOS y hacer los preparativos necesarios para publicar la aplicación open source.

2

Resum Els estudiants de la Facultat d'Informàtica de Barcelona interactuen amb la facultat mitjançant una intranet anomenada El Racó. Aquesta interacció es realitza constantment, incloent situacions en què únicament es té accés des d'un dispositiu mòbil. Actualment, l'únic mètode per accedir a aquest recurs és mitjançant un navegador web. Aquest projecte pretén apropar la plataforma a un format d'aplicació mòbil nativa per tal d'aprofitar els recursos que aquesta ofereix, com notificacions i una millor experiència de navegació, per proporcionar a l'estudiant una experiència còmoda i completa. Com a base de el projecte, es treballarà sobre un aplicatiu Android prèviament creat per l'autor d’aquest projecte que interactua amb l'API de la facultat. Es pretén redissenyar la capa de dades, afegir funcionalitats addicionals, crear jocs de proves complets, fer un port de l'aplicació a iOS i fer els preparatius necessaris per publicar l’aplicació open source.

3

Abstract The students of the Facultat d'Informàtica de Barcelona interact with the faculty through an intranet called El Racó. This interaction takes place constantly, including situations in which you only have a mobile device in hand. Currently, the only method to access this resource is through a web browser. This project aims to bring the platform closer to a native mobile application format in order to take advantage of the resources offered by a native application, such as notifications and a better browsing experience, to provide the student with a comfortable and complete experience. As a basis for the project, we will work on an Android application, previously created by the author of this project, that interacts with the faculty API. It is intended to redesign the data layer, add additional functionalities, create complete test suites, make a port to iOS and make the necessary preparations to publish the application as open source.

4

Índice

1. Contexto 9 1.1. Introducción 9 1.2. Definición de Conceptos 9

1.2.1. El Racó 9 1.2.2. API FIB 2.0 9 1.2.3. Framework 10 1.2.4. React Native 10

1.3. Problema a Resolver 10 1.4. Actores Implicados 10

2. Justificación 11 2.1. Soluciones Existentes 13

2.1.1. Racó de la Fib 13 2.1.2. El Racó 14 2.1.3. El Racó - FIB 15

2.2. Base del Proyecto 16

3. Alcance 17 3.1. Objetivos Iniciales 17

3.1.1. Documentar 17 3.1.2. Rediseñar 17 3.1.3. Refactorizar 17 3.1.4. Añadir Funcionalidades 17 3.1.5. Port a iOS 18 3.1.6. Testing 18

3.2. Obstáculos y Riesgos 18

4. Metodología y Rigor 19 4.1. Metodología 19 4.2. Validación 20

5. Planificación Temporal Inicial 21 5.1. Duración del Proyecto 21 5.2. Descripción de Tareas 21

5.2.1. Gestión de Proyecto Inicial 21 5.2.2. Agile Management 22 5.2.3. Documentar 22 5.2.4. Rediseñar y Refactorizar 22 5.2.5. Testing 22 5.2.6. Expandir Funcionalidades 23 5.2.7. Port a iOS 23

5

5.2.8. Hito de Seguimiento 23 5.2.9. Hito Final 23

5.3. Peso y Dependencias de Tareas 24 5.4. Recursos 25 5.5. Diagrama de Gantt 26

6. Gestión de Riesgos y Obstáculos 27

7. Presupuesto Inicial 28 7.1. Gastos de Personal por Actividad 28 7.2. Gastos Genéricos 30

7.2.1. Gastos en Hardware 30 7.2.2 Gastos en Licencias 30 7.2.3 Gastos de Vivienda 31

7.3. Contingencias 31 7.4. Partida de Imprevistos 31 7.5. Presupuesto total 32 7.6. Control de Presupuesto 33

8. Sostenibilidad 33 8.1. Autoevaluación 33 8.2. Dimensión Económica 33 8.3. Dimensión Ambiental 34 8.4. Dimensión Social 34

9. Especificación del Sistema 35 9.1. Requisitos Funcionales 35

9.1.1. Diagrama de Casos de Uso 35 9.1.2. Casos de Uso brief style 36 9.1.2. Casos de Uso Detallados 41

9.2. Requisitos no Funcionales 60

10. Diseño del Sistema 63 10.1. Arquitectura Física 63 10.2. Arquitectura Lógica 64

10.2.1. Estructura y Flujo de Datos Flux 65 10.3. Diagrama de Componentes 66 10.4. Patrones de Diseño 67

10.4.1. Lazy Loading 67 10.4.2. Patrón Decorador 68 10.4.3. Patrón Observer 68

10.5. Modelo de Datos 69 10.6. Vistas del Sistema y Navegabilidad 70

10.6.1. Navegabilidad 70 10.6.2. Vistas del Sistema 71

6

11. Implementación del Sistema 76 11.1. Tecnologías y Lenguajes Utilizados 76 11.2. Herramientas de Desarrollo 77

12. Testing y Validación 78 12.1. Software Quality Assurance 78 12.2. Pruebas funcionales 79

12.2.1. Tests Unitarios 80 12.2.2. Tests de Integración 80 12.2.3. Snapshot Testing 81

12.3. Tests de Aceptación de Usuario 81 12.4. Programa Open Testing 82 12.5. Seguimiento de Crashes y ANRs en Producción 82

13. Instalación y Ejecución del Sistema 84

14. Identificación de Leyes y Regulaciones 85 14.1. Normativa del Trabajo Final de Grado 85 14.2. Licencias de Frameworks y Software Utilizados 85 14.3. Condiciones de Uso FIB API v 2.0 86 14.4. Políticas del Programa para Desarrolladores de Google 86 14.5. Política de Privacidad de la App 88

15. Planificación Final y Cambios 89 15.1. Descripción del problema 89 15.2. Soluciones Planteadas 90

15.2.1. Reorganizar el orden de ejecución de las tareas 90 15.2.2. Aplazar las tareas afectadas 90 15.2.3. Reemplazar las tareas afectadas 90 15.2.4. Aplazar las tareas afectadas y añadir nuevas 90

15.3. Solución Adoptada 91 15.4. Descripción de Tareas Finales 91 15.5. Planificación Temporal Final 93 15.6. Desviaciones en el Presupuesto 94 15.7. Metodología Final 95

16. Conclusiones 95 16.1. Competencias Técnicas 96 16.2. Conclusiones Personales 98 16.3. Trabajo Futuro 98

Anexo 1: Repositorio Github de la Aplicación Android 99

Anexo 2: Repositorio Github de la Aplicación iOS 99

Anexo 3: Descarga de la Aplicación 99

7

Anexo 4: Tabla de tests funcionales 99

Anexo 5. Política de Privacidad de la Aplicación 104

FIB UPC (El Racó) - Android App 104 Privacy Policy 104

Tablas y Figuras 107 Tablas 107 Figuras 107

Referencias 109

8

1. Contexto

1.1. Introducción La Facultad de Informática de Barcelona (FIB), como todas las instituciones modernas, dispone de una intranet para compartir información y servicios accesibles desde el portal web de la facultad. Esta intranet, llamada El Racó [1], es una herramienta esencial para estudiantes, profesores y personal de administración y servicios. Mantiene a las partes interesadas informadas y ofrece una gran variedad de servicios para mantener el buen funcionamiento de la facultad. Este proyecto tiene como objetivo traer los servicios para estudiantes ofrecidos por esta intranet a un formato móvil cuyos usuarios puedan acceder de forma rápida e intuitiva. Como base del proyecto, se trabajará sobre una aplicación Android, previamente creada por el autor del proyecto, ampliando sus funcionalidades, realizando un port a iOS y refactorizando el código para lanzarlo open source al abasto de cualquiera. Este trabajo de final de grado de modalidad A pertenece al grado de Ingeniería Informática impartido por la Facultad de Informática de Barcelona. Más concretamente, bajo la especialidad de Ingeniería del Software [2] documentando el análisis de todo el marco y de las modificaciones al diseño actual. El proyecto en cuestión surgió por iniciativa propia del estudiante por tal de expandir el conocimiento sobre el desarrollo de aplicaciones móviles y mejorar la aplicación previamente creada por el autor.

1.2. Definición de Conceptos A continuación, se define una lista de conceptos y recursos para llevar a cabo el proyecto.

1.2.1. El Racó El Racó es la intranet de la Facultad de Informática de Barcelona. Se analizará las funcionalidades que ofrece a los estudiantes por tal de implementarlas en el aplicativo móvil.

1.2.2. API FIB 2.0 La API FIB 2.0 [3] es una API REST [4] aportando una interfaz con una biblioteca de recursos web bajo una cierta abstracción, permitiendo al usuario acceder a los datos públicos y privados (a nivel usuario) de la FIB. Cada recurso está autodocumentado en la descripción obtenida de OPTIONS o vía html en los mismos recursos.

1.2.3. Framework

Un framework es una estructura conceptual y tecnológica de asistencia definida, normalmente, con artefactos o módulos concretos de software, que puede servir de base para la organización y desarrollo de software.

9

1.2.4. React Native

React Native es un framework open source creado por Facebook [5] para desarrollar aplicaciones móviles nativas multiplataforma. Utiliza Javascript como principal lenguaje de programación y renderiza utilizando código nativo. Se ha elegido este framework en cuestión debido al previo conocimiento sobre éste, por la amplia variedad de módulos publicados por la comunidad y por el hecho de ofrecer soporte multiplataforma, facilitando el port a iOS.

1.3. Problema a Resolver Actualmente, la FIB únicamente proporciona acceso a su intranet a través del portal web de la facultad. La única aplicación móvil oficial de la FIB [6] fue actualizada por última vez en noviembre de 2011 y a día de hoy el aplicativo ya no se encuentra listado en la Google Play. Alternativamente, se pueden encontrar aplicaciones de terceros en Android utilizando la API de la FIB pero todas tienen carencias significativas definidas en el apartado 2.1. Para la plataforma iOS, no existe ningún aplicativo publicado de estas características, dejando a un porcentaje significativo de estudiantes sin ninguna alternativa al portal web. La aplicación Android y iOS desarrollada en este proyecto está enfocada a cubrir las carencias existentes de los otros aplicativos Android, traer esta intranet a iOS y añadir funcionalidades adicionales por tal de incentivar a los estudiantes a usar la aplicación móvil como sustituto del portal web en sus dispositivos móviles. Un problema secundario que puede surgir es que la API de la FIB se actualice dejando obsoleta la versión anterior o añadiendo nuevas funcionalidades. Para esas circunstancias, se requiere de una aplicación que esté bien documentada y de software libre para que cualquier programador pueda actualizar la aplicación de forma eficiente sin tener que empezar un nuevo proyecto desde cero.

1.4. Actores Implicados

● Desarrollador: Tiene la tarea de desarrollar la aplicación móvil tal y que consiga satisfacer todos los objetivos y las funcionalidades esperadas de ella, todo teniendo en cuenta las diferentes fases de desarrollo y respetando las fechas límite.

● Director de Proyecto: En este proyecto, Carles Farré Tost efectúa como director del

proyecto encargándose de dirigir y guiar al desarrollador durante el desarrollo del proyecto.

● Unitat Transversal de Gestió de l'Àmbit TIC Campus Nord (UTGCNTIC): Más

concretamente, Jaume Moral Ros, Director del proyecto de la API FIB 2.0. Se le

10

comunicarán posibles mejoras y errores sobre la API por tal de tener comentarios adicionales una vez la API vaya a ser actualizada.

● Estudiantes de la FIB: Los estudiantes de grado y de máster de la Facultad de

Informática de Barcelona son los usuarios directos del aplicativo móvil. Se pretende que tengan una interacción más práctica, eficaz y completa con la intranet de la facultad desde sus dispositivos móviles.

● Profesores de la FIB: Los profesores de la Facultad de Informática de Barcelona

son usuarios finales indirectos afectados por la aplicación. Ya que el aplicativo permite enviar notificaciones a los estudiantes, el tiempo en que la información se pasa de profesor a estudiante es reducido drásticamente.

2. Justificación Según un estudio del Instituto Nacional de Estadística, el 93,7% de los catalanes entre 16 y 74 años poseen algún tipo de dispositivo móvil [7]. A día de hoy, el teléfono móvil se ha incorporado en nuestro día a día como una herramienta fundamental para mantenernos conectados. La gran mayoría de consultas de información se realizan a través de este dispositivo debido a su gran portabilidad. Con la intranet de la facultad, no es la excepción. Teniendo en cuenta lo citado anteriormente, la experiencia de usuario entre un portal web y una aplicación nativa es drásticamente distinta. A continuación, citamos unas cuantas ventajas de las aplicaciones móviles nativas [8]:

● Accesibilidad: Tener la plataforma a un toque de la pantalla de inicio. ● Acceso a recursos del sistema operativo: GPS, almacenamiento, etc. En nuestro

caso, aprovechamos las notificaciones para mantener al usuario informado. ● Acceso sin conexión: No hace falta tener conexión para acceder a información con

pocas actualizaciones. Un ejemplo sería consultar el horario del estudiante. ● Libertad en diseño: Las páginas web utilizan los recursos ofrecidos por el

navegador: links, botón de retroceso, URLs, etc. Una aplicación nativa otorga al programador la libertad para diseñar su propio flujo de navegación y diseño con gestos como “toque”, “deslizar", "arrastrar", "pellizcar", "sostener"...

● Tiempo invertido: Los usuarios gastan significativamente más tiempo en aplicaciones nativas que no navegando la web [9] tal y como se puede ver en la Figura 1.

11

Figura 1: Tiempo dedicado en dispositivos móviles. Extraido de clearbridgemobile.com.

Analizando las descargas de las aplicaciones existentes, se comparan los datos de las aplicaciones en la Tabla 1.

Nombre de aplicación

Fecha de lanzamiento

Descargas anunciadas

Descargas mínimas

Descargas máximas

Usuarios activos

El Racó - FIB 16/11/2018 100+ 331 331 231

El Racó 04/01/2020 1+ 1 5 ?

Racó de la Fib 17/01/2019 50+ 50 100 ?

TOTAL - - 382 436 ≥ 231

Tabla 1: Datos de aplicaciones existentes extraídos de Google Play Store y Google Play Console el 22/02/2020. De elaboración propia. Actualmente, para iOS no se encuentra ningún aplicativo de estas características y, según el Centro Criptológico Nacional, en 2018, el 13,2% de la población con dispositivos móviles utilizaba iOS como sistema operativo en su celular [10]. Según el portal de la facultad, actualmente, la FIB dispone de 2106 estudiantes cursando un grado o máster [11]. Si analizamos los porcentajes de descargas, observamos que un máximo del 20,7% de los estudiantes actuales han descargado alguna vez una aplicación móvil de El Racó. El mínimo no se puede estimar con precisión debido a que la aplicación con significativamente más descargas fue publicada el curso pasado y es probable de que se hayan descargado la aplicación estudiantes que ya no están cursando ningún grado o máster. Además, los mismos usuarios pueden haber descargado más de una aplicación. Cabe mencionar que el porcentaje mencionado es sobre el máximo número de descargas posibles, no sobre usuarios activos. Estos datos muestran que hay poco interés o desconocimiento sobre los aplicativos existentes y que hay mucho espacio para mejoras. Además, aproximadamente un 13% de los estudiantes usan iOS como sistema operativo y no tienen una alternativa al portal web de la facultad.

12

2.1. Soluciones Existentes Actualmente, se pueden encontrar aplicaciones que ofrecen interacción con la API de El Racó. Se han analizado las virtudes y defectos de cada una en profundidad con el fin de crear una aplicación capaz de sobreponer su presencia sobre las alternativas ya existentes.

2.1.1. Racó de la Fib Ficha técnica de Racó de la Fib [12] y capturas de pantalla del aplicativo en la Figura 2:

● Plataforma: Android ● App ID: com.inlab.racodemoapi ● Autor: Jedi UPC ● Fecha de lanzamiento: 17/01/2019 ● Última actualización: 17/01/2019 ● Descargas: 50+

Figura 2: Capturas de Pantalla extraídas de la aplicación Racó de la Fib. Funcionalidades:

● Visualización de avisos y descarga de archivos adjuntos ● Consulta de asignaturas y sus respectivas guías docentes ● Visualización de horario

Puntos fuertes:

● Programado con Java: La velocidad de carga y descarga de contenidos es inigualable a cualquier otra aplicación no nativa.

● Ficha de asignaturas detallada: Se presenta mucha información y de forma organizada en las fichas de las asignaturas.

● Navegación: Utiliza un Material Bottom Bar Navigator como método para navegar entre las funcionalidades de la aplicación de manera rápida e intuitiva.

Puntos negativos:

● Interfaz: Interfaz ligeramente anticuada para el estándar moderno.

13

● Escasas funcionalidades: Falta de funcionalidades esenciales como, por ejemplo, acceso a noticias de la facultad, próximos eventos, exámenes…

● Sin notificaciones: No dispone de notificaciones de ningún tipo. ● Diseño de avisos flojo: No hay forma de mantener un registro de los avisos ya

leídos ni de obtener una vista de todos los avisos juntos. ● Diseño de horario flojo: Se divide el horario en una ventana por cada día obligando

al usuario a desplazarse a la ventana del día en cuestión. No es atractivo visualmente ya que se muestra con una lista superior al tamaño de la pantalla.

● Bugs ○ Si un estudiante dispone de un día sin ninguna clase, se muestra una

ventana en blanco. ○ Algunos usuarios no pueden entrar en la aplicación. Una vez se descarga el

contenido de la API, la aplicación se bloquea. Probablemente debido a excepciones sin tratar.

2.1.2. El Racó Ficha técnica de El Racó [13] y capturas de pantalla del aplicativo en la Figura 3:

● Plataforma: Android ● Android App ID: personal.yeqk97.raco ● Autor: Qiong Kai Ye ● Fecha de lanzamiento: 04/01/2020 ● Última actualización: 22/01/2020 ● Descargas: 5+

Figura 3: Capturas de Pantalla extraídas de la aplicación El Racó. Funcionalidades:

● Visualización de horario, avisos, noticias de la fib, asignaturas matriculadas, ocupación de laboratorios y eventos.

● Gestor de notas Puntos Fuertes:

● Soporte multi idioma: Dispone de versiones en inglés, español y catalán.

14

● Interfaz moderna: La interfaz se adapta a los estándares modernos. La información se muestra de manera ordenada y estética.

● Navegación: Utiliza un Material Bottom Bar Navigator como método para navegar entre las funcionalidades básicas y un Material Drawer Navigator para acceder a funcionalidades más específicas.

Puntos negativos:

● Sin notificaciones: No dispone de notificaciones de ningún tipo. ● Bloqueos al abrir: La aplicación, en su versión más reciente, se bloquea una vez se

inicia sesión impidiendo el uso de la aplicación. Probado con 3 cuentas de estudiantes y dispositivos móviles diferentes obteniendo los mismos resultados.

2.1.3. El Racó - FIB Ficha técnica de El Racó - FIB [14] y capturas de pantalla del aplicativo en la Figura 4:

● Plataforma: Android ● Android App ID: com.fibupc ● Autor: Joan Marc Pastor ● Fecha de lanzamiento: 16/11/2018 ● Última actualización: 09/09/2019 ● Descargas: 331 ● Usuarios activos: 231

Figura 4: Capturas de Pantalla extraídas de la aplicación El Racó - FIB. Funcionalidades:

● Visualización de horario, avisos, noticias de la fib, asignaturas matriculadas, ocupación de laboratorios y eventos.

● Notificaciones para avisos. ● Permite reservar salas grupales de estudio en la biblioteca BRGF.

Puntos Fuertes:

● Interfaz moderna: La interfaz se adapta a los estándares modernos. La información se muestra de manera ordenada y estética.

15

● Navegación: Utiliza un Material Bottom Bar Navigator como método para navegar entre las funcionalidades básicas, un Material Drawer Navigator para acceder a funcionalidades más específicas y Modal Views para mostrar más información sobre los elementos.

● Notificaciones: Incorpora un Background Service Worker activado cada 20 minutos para buscar nuevos avisos y notificarlos al usuario.

Puntos negativos:

● Mal manejo de sesión: De forma poco habitual, el token de sesión se pierde obligando al usuario a cerrar sesión e iniciar una de nueva.

● Bloqueos: Pueden surgir bloqueos ocasionales por causas desconocidas.

2.2. Base del Proyecto Para este proyecto, se han planteado 3 posibles puntos de partida: Descartado: Desarrollar una aplicación desde cero

Crear una aplicación de estas características requiere de mucha dedicación y, si se hubiese empezado de cero, se hubiesen esperado limitaciones de tiempo significativas que podrían haber afectado al producto final. Esta opción únicamente podría haber sido viable si no existiesen otros puntos de partida o si éstos tuvieran defectos y limitaciones relevantes. Descartado: Aplicación El Racó (por Qiong Kai Ye)

El código fuente de esta aplicación se puede encontrar en Github [15] bajo una licencia MIT [16] de software libre, por lo que es posible trabajar sobre este proyecto. Esta opción se ha descartado debido a carencias de funcionalidades, preferencias de diseño y desconocimiento sobre el framework utilizado, Flutter. Punto de partida: Aplicación El Racó - FIB (por Joan Marc Pastor)

El código fuente de esta aplicación no está publicado ni bajo ninguna licencia. Se puede usar como punto de partida debido a que el desarrollador de la aplicación es el autor de este proyecto final de grado. Los principales factores por los que se ha elegido este punto de partida son los siguientes:

● Se conoce el lenguaje y framework utilizado. ● Se tiene un entendimiento sobre el código de la aplicación base y es fácil ampliar

sus funcionalidades. ● React Native permite hacer aplicaciones multiplataforma por lo que se puede

reutilizar código para realizar el port a iOS. ● Es la aplicación con mayor número de funcionalidades en el mercado. ● El diseño de la aplicación cuadra con los estándares modernos por lo que se

requiere de poco cambio. ● Ya posee una base de usuarios significativamente grande en relación con las

alternativas existentes. Posee 331 descargas con 231 usuarios activos que equivale a un 69,79% de retención de usuarios.

16

3. Alcance

3.1. Objetivos Iniciales El objetivo principal de este proyecto es crear una aplicación móvil multiplataforma para reemplazar el uso que se hace del portal web en dispositivos móviles. El fin es proporcionar al estudiante una experiencia más completa y práctica. Para lograr este objetivo, se definen en detalle los subobjetivos en los que se trabajará sobre la aplicación base.

3.1.1. Documentar Proporcionar documentación detallada del código fuente de la aplicación. Se pretende publicar la aplicación en Github bajo una licencia MIT [16] por tal de permitir a otros individuos actualizar, mejorar o corregir errores en un futuro y poder alargar al máximo la esperanza de vida de la aplicación. Por tal de facilitar la tarea a futuros colaboradores, hace falta que el código fuente esté documentado al detalle.

3.1.2. Rediseñar Rediseñar la interfaz de usuario de la aplicación. Una aplicación ha de ser intuitiva de usar y estéticamente agradable para mantener una base de usuarios. El objetivo es maximizar el potencial de la aplicación rediseñando la apariencia y la navegabilidad de ésta.

3.1.3. Refactorizar Refactorizar el código fuente añadiendo modularidad. Por tal de facilitar la tarea de programación a nuevos desarrolladores, es esencial tener código de calidad. React Native utiliza componentes para segmentar el código permitiendo la creación de clases especializadas. La correcta separación de componentes depende de la habilidad del programador y, en la aplicación base, se aprovecha muy pobremente este recurso. El objetivo es refactorizar el código fuente para facilitar su comprensión y modificación.

3.1.4. Añadir Funcionalidades Añadir funcionalidades para los usuarios de la aplicación. Éstas son las siguientes:

● Seguimiento de plazas libres durante la matrícula ● Buscador de aulas con cierto número de horas libres seguidas ● Gestor de notas ● Soporte multi idioma

17

3.1.5. Port a iOS Realizar un port a iOS de la aplicación. Actualmente no se encuentra ninguna aplicación móvil de estas características en la App Store de iOS. Se traerá este aplicativo a esta plataforma por tal de proporcionar este servicio a esa base de usuarios.

3.1.6. Testing Crear tests unitarios y de integración. Por tal de asegurar el buen funcionamiento de la aplicación durante el desarrollo y vida útil de ésta, se quiere crear tests unitarios, de integración y validación sobre los componentes de la aplicación. React Native utiliza Jest para esta tarea.

3.2. Obstáculos y Riesgos A continuación, se valoran los obstáculos y riesgos que pueden surgir durante el desarrollo del proyecto.

● Tarea de carga superior a la prevista: Debido a la poca experiencia calculando el peso de tareas, es probable que se estime de forma incorrecta la carga de trabajo de alguna tarea.

● Desconocimiento de las tecnologías: Inexistencia de librerías para implementar elementos nativos. Especialmente para realizar el port a iOS ya que la base del proyecto utiliza librerías diseñadas únicamente para Android. Puede suponer un riesgo de tiempo debido al periodo adicional requerido para aprender la tecnología en cuestión.

● Carencia de librerías: Riesgo potencial al realizar el port a iOS. Es posible que las librerías utilizadas no tengan compatibilidad con iOS y no haya librerías equivalentes para esta plataforma.

● Miembros del proyecto enferman: Junto a la aparición del nuevo brote de coronavirus, Covid-19, enfermar supone un riesgo potencial que puede causar retrasos debido a la incapacidad de trabajar del miembro enfermado.

● Hardware deja de funcionar: Daños de material pueden suponer retrasos en el periodo de desarrollo.

● Los laboratorios de la FIB dejan de proporcionar servicio a los estudiantes: Debido al brote de Covid-19 que está sufriendo España en estos momentos, es probable que los centros educativos, incluyendo los laboratorios de la FIB, cierren puertas durante el sprint dedicado al desarrollo de la aplicación iOS.

● La API FIB v2 deja de dar soporte a aplicaciones de terceros: Es un riesgo muy poco probable pero, Sin una API de la que extraer información, la gran mayoría de funcionalidades de la aplicación dejarían de funcionar. Si no se consigue permiso, la aplicación se ha de abandonar o enfocar de otra manera.

18

● Se deja de dar soporte a la FIB API 2.0: Sin una API de la que obtener la información, no hay espacio para las aplicaciones de terceros de El Racó. Habría que mirar la posibilidad de obtener un permiso especial para realizar scraping del portal web para obtener la información.

Los planes de mitigación definidos para estos riesgos están definidos en detalle en el apartado 6.

4. Metodología y Rigor

4.1. Metodología Para la metodología del proyecto se recurrirá a SCRUM [18], una metodología ágil, junto a Kanban Boards [19] para realizar el seguimiento. SCRUM es un marco de trabajo en el que se aplica una estrategia de desarrollo incremental organizado en iteraciones, o sprints, en el que se pueden solapar diferentes fases de desarrollo. En este proyecto, se ha previsto implementar 4 sprints de tres semanas de duración. Al inicio de cada sprint, se realiza el sprint planning meeting, una reunión con todo el equipo del proyecto para acordar las tareas que van a ser realizadas durante el sprint. Al final de cada sprint, se realiza el agile review meeting donde se presentan los trabajos completados y el agile retrospective meeting en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Para gestionar las tareas, se utiliza KANBAN. Esta metodología consiste en fragmentar las tareas y representarlas en tarjetas. Estas tarjetas se asignan en una lista determinada según el estado en el desarrollo de la tarea en cuestión. Los estados del tablero (listas) utilizados son los siguientes:

● Por Hacer ● En desarrollo ● Validación ● Finalizado

De manera secuencial, el desarrollador escoge una tarjeta sobre la que trabajar y no se abandona hasta que la tarea pase al siguiente estado. Se han elegido estas metodologías debido a la libertad que proporciona al desarrollador. A su misma vez, permite tener una visión global del estado del proyecto cuando el equipo cuenta con pocos desarrolladores.

19

El seguimiento se realizará con Trello, un software de administración de proyectos basado en tarjetas, listas y tableros. Para mantener un registro de las versiones del código fuente, se utilizará GIT [20], un software de control de versiones que, a su vez, se sincronizará con Github, una plataforma para alojar repositorios remotos, proporcionando una copia en la nube y dejándolo al abasto de cualquiera. Para mantener un registro de las horas dedicadas al proyecto, se crea un project record track, un documento Google Sheets almacenado en Google Drive en el que se rellena diariamente las horas invertidas durante el día y a qué tareas van asociadas.

4.2. Validación Por tal de validar las funcionalidades de la aplicación, se realizarán tests unitarios y de integración sobre el código y tests manuales con diversas cuentas de estudiante de la facultad. De esta forma, se podrá corroborar el buen funcionamiento de la aplicación. Otro indicador de control útil durante el desarrollo del proyecto es el feedback proporcionado por estudiantes de la facultad con la aplicación instalada. Se les preguntará directamente para obtener opiniones diversas del público objetivo de la aplicación. En referencia al seguimiento de tareas, la metodología utilizada ayuda a gestionar la validación. En cada reunión de agile review, se presentan las tareas completadas con el director del proyecto presente y se evalúa si se ha desviado de la planificación general esperada. En caso afirmativo, se compensa dedicando más horas en el próximo sprint. Por tal de validar el requisito de horas dedicadas a este proyecto final de grado, el project record track, definido en el apartado 4.1, proporciona un seguimiento de las horas dedicadas al proyecto. Por tal de validar este requisito, la suma total ha de ser equivalente a 540 horas. Para concluir, toda decisión que se desvía de la planificación inicial, tendrá que disponer de la aprobación del director del proyecto.

20

5. Planificación Temporal Inicial

5.1. Duración del Proyecto Para el tercer y último hito, se pretende escoger el periodo de lectura de junio. Éste tiene una duración de 5 días empezando el 29 de junio de 2020. Es requisito entregar la memoria del proyecto con una semana de antelación. Es por eso que, el 21 de junio, representa la fecha de finalización del proyecto. El proyecto empieza el día 17 de febrero de 2020 con una totalidad de 18 semanas de las cuales se han repartido de la siguiente manera:

● Semanas 1 - 4: Gestión de proyecto ● Semanas 5 - 7: Sprint 1 ● Semanas 8 - 10: Sprint 2 ● Semanas 11 - 13: Sprint 3 ● Semanas 14 - 16: Sprint 4 ● Semana 17: Finalización y consolidación ● Semana 18: Semana libre para solventar posibles retrasos en el desarrollo

Se dedicará una totalidad de 540 horas al proyecto que implica una carga media de 4,3 horas diarias, teniendo en cuenta que también se trabajará los fines de semana.

5.2. Descripción de Tareas Cada tarea de desarrollo se compone de tres partes:

● Documentación de requisitos: Se documentan las restricciones que han de contener las funcionalidades implementadas.

● Diseño: Se actualiza el diseño a la arquitectura para añadir las funcionalidades. ● Implementación: Se implementa la funcionalidad. ● Tests unitarios y de integración: Se crean tests para validar los requisitos

definidos.

5.2.1. Gestión de Proyecto Inicial Tareas que forman la gestión inicial para definir y encaminar el proyecto.

● Estudio de aplicaciones existentes: Se realiza un estudio de las aplicaciones existentes que hacen uso de la API FIB v2.0 por tal de elegir un punto de partida y comprender las funcionalidades y carencias de cada aplicativo.

● Estudio de herramientas para la realización del proyecto: Estudio de las herramientas necesarias para llevar a cabo el proyecto.

● Definición de contexto y abasto: Se define el contexto y el abasto del proyecto. ● Planificación temporal: Se definen las tareas a realizar y una planificación temporal

acorde con éstas. ● Estudio de presupuesto y sostenibilidad: Se estudia detalladamente el

presupuesto y la sostenibilidad del proyecto.

21

● Formar documento de gestión final: Se compone un documento inicial recopilando la gestión del proyecto.

5.2.2. Agile Management Tareas relacionadas con el seguimiento del proyecto.

● Agile sprint planning meetings: Realizado el primer día de cada sprint. Se organiza una reunión online entre los participantes en el proyecto para acordar las tareas a realizar durante el sprint actual.

● Agile review meetings: Realizado el último día de cada sprint. Se organiza una reunión online entre los participantes del proyecto con el objetivo de buscar feedback creando transparencia sobre el crecimiento del producto.

● Agile retrospective meetings: Realizado al final de cada sprint. Durante la retrospectiva, el equipo reflexiona sobre lo que sucedió en la iteración e identifica acciones para mejorar en el futuro.

5.2.3. Documentar ● Documentar código existente: Se documenta detalladamente el código ya

existente de la aplicación de tal forma que futuros desarrolladores tengan documentación necesaria para continuar el desarrollo de ésta con facilidad.

● Documentar código implementado: Se documenta progresivamente el código implementado en este proyecto.

5.2.4. Rediseñar y Refactorizar ● Refactorizar código existente: Actualmente, el código base de la aplicación deja

mucho que desear en referencia a su estructura. Se necesita refactorizar el código en componentes React por tal de facilitar la tarea de programación a futuros desarrolladores.

● Rediseñar interfaz de usuario: Se rediseña la interfaz de usuario conforme a los estándares modernos por tal de hacer más placentera la experiencia de usuario.

● Añadir modelo de datos Redux: Por tal de mantener consistencia en los datos y una gestión de éstos más organizada, se implementará una capa de datos con Redux.

5.2.5. Testing ● Implementar tests unitarios sobre código existente: Implementación de tests

unitarios para validar el correcto funcionamiento de segmentos de código. ● Implementar tests de integración sobre código existente: Implementación de

tests de integración para validar el correcto funcionamiento entre diferentes módulos.

22

5.2.6. Expandir Funcionalidades ● Implementar seguimiento de plazas libres durante la matrícula: Implementar un

servicio para facilitar el proceso de matrícula manteniendo un registro actualizado de la ocupación de asignaturas marcadas por el usuario.

● Implementar buscador de aulas libres: Implementar un servicio en el que el usuario indica las horas que se pretenden usar y el sistema proporcionará una lista de aulas disponibles durante ese periodo de tiempo.

● Implementar gestor de notas: Implementar un gestor de notas para guardar notas de asignaturas y obtener estadísticas acerca del rendimiento del curso.

5.2.7. Port a iOS ● Obtener una base ejecutable: Obtener una aplicación iOS ejecutable como base

para la implementación progresiva de funcionalidades. ● Implementar login: Implementar un login funcional de manera que el usuario pueda

registrarse en la aplicación con su cuenta de estudiante. ● Implementar vistas: Implementar en la aplicación iOS las vistas que componen la

aplicación Android. ● Implementar notificaciones: Implementar un background service worker por tal de

notificar al usuario cuando se publiquen nuevos avisos. ● Publicar aplicación: Publicar la aplicación en la App Store de iOS.

5.2.8. Hito de Seguimiento ● Redacción del documento de seguimiento: Se redacta el documento de

seguimiento.

5.2.9. Hito Final ● Redacción de la memoria del proyecto: Se redacta la memoria del proyecto. ● Preparación de la defensa: Se prepara la presentación para la defensa del

proyecto.

23

5.3. Peso y Dependencias de Tareas En la Tabla 2, se considera el peso de cada tarea el horas y las dependencias entre éstas.

Tabla 2: Peso y dependencias de tareas. De elaboración propia.

24

5.4. Recursos Por tal de llevar a cabo el proyecto, son esenciales los recursos listados en la Tabla 3 para las respectivas tareas asociadas. Estos están divididos en categorías según su naturaleza.

Tabla 3: Recursos y tareas asociadas. De elaboración propia.

25

5.5. Diagrama de Gantt El siguiente diagrama de Gantt, en la Figura 5, proporciona una visión general sobre el desarrollo del proyecto aplicando SCRUM, una metodología ágil. Se ha tenido en consideración las dependencias y el peso de las tareas a la hora de dividir los Sprints para obtener una carga de trabajo equilibrada a lo largo de las semanas.

Figura 5: Diagrama de Gantt inicial. De elaboración propia con Microsoft Office Excel.

26

6. Gestión de Riesgos y Obstáculos Tal y como se han definido en el apartado 3.2. existen riesgos que pueden afectar a la planificación del proyecto o a la correcta realización de éste. En la Tabla 4, se definen planes de mitigación a los riesgos definidos.

ID Riesgo Probabilidad

Impacto Plan de mitigación Horas previstas por plan

de mitigación

R1 Tarea de carga superior a la prevista

Alta Medio Se balancean las tareas de futuros sprints aumentando las horas de dedicación diarias para compensar las pérdidas.

20

R2 Desconocimiento de las tecnologías

Media Bajo Se dedica tiempo adicional a aprender sobre la tecnología.

4

R3 Carencia de librerías

Muy baja Medio En caso de no disponer de ninguna librería para realizar un objetivo concreto, se abandona la tarea relacionada a ese objetivo.

-

R4 Miembros del proyecto enferman

Baja Medio En caso de ser una enfermedad leve, se puede seguir el desarrollo desde el hogar. Si la enfermedad impacta las capacidades del miembro, se balancean las tareas pendientes en las futuras iteraciones, aumentando las horas de dedicación diarias para compensar las perdidas.

0 - 20

R5 Hardware deja de funcionar

Baja Bajo Se reemplazará por un portátil o un móvil Android alternativo ya en adquisición según el dispositivo que deja de funcionar. Todo el contenido del proyecto se sincroniza en la nube por tal de no perder ficheros.

2

R6 Los laboratorios de la FIB dejan de proporcionar servicio a los estudiantes

Muy alta (debido a Covid-19)

Bajo Se procederá a instalar Hackintosh en una máquina virtual para poder trabajar remotamente desde casa.

4

27

R7 La API FIB v2 deja de dar soporte a aplicaciones de terceros

Muy baja Muy alto Sin una API de la que extraer información, la gran mayoría de funcionalidades de la aplicación dejarían de funcionar. Si no se consigue permiso, la aplicación se ha de abandonar.

-

R8 Se deja de dar soporte a la API FIB v2

Muy baja Muy alto Sin una API de la que extraer información, la gran mayoría de funcionalidades de la aplicación dejarían de funcionar. Una alternativa es pedir permiso a la facultad para realizar web scraping del portal web. Si se concede permiso, implica un cambio drástico en las tareas del proyecto para implementar las modificaciones. En caso contrario, la aplicación se abandona.

140

Tabla 4: Gestión de riesgos y obstáculos. De elaboración propia. Como medida adicional de precaución, se ha decidido dejar una semana de margen sobre la fecha límite de la entrega de la memória. En el caso de la existencia de retrasos significativos causados por acumulaciones de obstáculos, se utilizará esta semana adicional para trabajar sobre las tareas restantes. Si no es posible asignar la tarea en cuestión a esta semana debido a dependencias entre tareas, se desplazan los sprints los días necesarios para finalizar la tarea retrasada.

7. Presupuesto Inicial Para el desarrollo de este proyecto, se ha estimado un presupuesto para cubrir todos los gastos de éste y controlar que los gastos no se desvíen de lo razonable.

7.1. Gastos de Personal por Actividad Se ha utilizado el portal de indeed.es para obtener una estimación del salario promedio en Barcelona para los integrantes del proyecto. Se ha extraído la media del salario bruto anual para jornadas completas y se ha reservado un 30% adicional para cubrir los gastos de seguridad social. Estos valores se pueden observar en la Tabla 5.

28

Perfil Salario bruto anual (€)

Salario bruto + Seguridad social anual (€)

Salario bruto + Seguridad social por hora (€/h)

Gestor de Proyecto 40.891,00 [21] 53.158,30 27,34

Programador Junior 18.959,00 [22] 24.646,70 12,68

Tester 26.223,00 [23] 34.089,90 17,53

Tabla 5: Retribución media por perfil en Barcelona. De elaboración propia. A continuación, en la Tabla 6 se visualiza el desglose de los gastos de recursos humanos en relación al rol y las tareas a realizar.

Tabla 6: Gastos en recursos humanos. De elaboración propia.

29

7.2. Gastos Genéricos

7.2.1. Gastos en Hardware En la Tabla 7, se han recopilado los gastos de hardware considerando el periodo de desarrollo del proyecto (126 días) y el periodo de amortización de cada elemento. La amortización se calcula según la siguiente fórmula:

amortización_a_pagar = precio * 126 / (vida_útil_años * 365)

Dispositivo Precio (€) Vida util (años) Amortización a pagar por 126 días de proyecto (€)

Dell XPS 15 1.750 4 151,03

OnePlus 7 Pro 750 2 129,45

TOTAL 280,48

Tabla 7: Gastos en Hardware. De elaboración propia.

7.2.2 Gastos en Licencias Por tal de reducir los gastos del proyecto, se ha asegurado el uso exclusivo de software gratuito. Por otro lado, hace falta adquirir licencias para cada plataforma de distribución digital. Estos gastos se definen en la Tabla 8.

Licencias Coste (€)

Android Developer 25,00

Apple Developer 90,00

TOTAL 115,00

Tabla 8: Costes de licencias. De elaboración propia.

30

7.2.3 Gastos de Vivienda A continuación, se analizan los gastos relacionados a la vivienda. Estos son definidos en la Tabla 9.

Elemento Precio mensual (€) Precio 126 días (€)

Local 1.600,00 6.720,00

Electricidad 40,00 168,00

Agua 25,00 105,00

Internet (600 Mb) 26,90 112,98

TOTAL 7.105,98

Tabla 9: Gastos adicionales. De elaboración propia.

7.3. Contingencias Para la realización de este proyecto, se reserva un 15% de los gastos para cubrir contingencias en el transcurso del proyecto. Éstos pueden ser causados por retrasos en tareas, daños materiales, licencias no previstas, etc. Se ha reservado un un total de 1398,35€ y puede verse desglosado en la Tabla 10.

Tipo de Gasto Coste (€) Porcentaje de margen

Reservado para cubrir contingencias (€)

Recursos Humanos 12.571,13 15% 1.885,67

Hardware 286,06 15% 42,91

Licencias 115,00 15% 17,25

Otros 1691,90 15% 253,79

TOTAL 2.199,62

Tabla 10: Contingencias. De elaboración propia.

7.4. Partida de Imprevistos En la Tabla 11 se presentan los gastos relacionados con los planes de mitigación de los riesgos mitigables, definidos en el apartado 6. Se ha estimado la probabilidad del riesgo y el coste económico que supone para el proyecto. Por tal de estimar el coste, se sigue la siguiente fórmula: coste_riesgo = probabilidad * horas_plan_mit * salario_implicado

31

El salario de los miembros está descompuesto en el apartado 7.1. Si un plan de mitigación supone la implicación de más de un miembro del equipo, se estima el coste a partir de la media de los salarios de los miembros implicados.

ID Riesgo Probabilidad Horas de plan de mitigación

Roles implicados

Coste (€)

R1 Tarea de carga superior a la prevista

75% 20 Cualquiera 287,70

R2 Desconocimiento de las tecnologías

60% 4 Programador Junior

30,43

R4 Miembros del proyecto enferman

15% 20 Cualquiera 57,54

R5 Hardware deja de funcionar

15% 2 Programador Junior + Tester

4,53

R6 Los laboratorios de la FIB dejan de proporcionar servicio a los estudiantes


45,33

R8 Se deja de dar soporte a la API FIB v2


88,76

TOTAL 514,29

Tabla 11: Partida de imprevistos. De elaboración propia.

7.5. Presupuesto total En la Tabla 12 se expresan los gastos totales del proyecto. Calculado a partir de los costes globales de cada categoría.

Tipo de Gasto Coste (€)

Recursos Humanos 12.571,13

Hardware 286,06

Licencias 115,00

Vivienda 1.691,90

Contingencias 2.199,62

Imprevistos 514,29

TOTAL 17.378

Tabla 12: Presupuesto final. De elaboración propia.

32

7.6. Control de Presupuesto Se ha definido un modelo para controlar los costes del proyecto en función de lo que se ha presupuestado, apartado 7, y el diagrama de tareas Gantt, apartado 5.5. Al final de cada sprint, se compararán y evaluarán las desviaciones, si las hay, entre el presupuesto y los costes reales en que ha incurrido el proyecto. Para cada desviación detectada, se anotará en un documento junto a los motivos e implicados en la desviación. Se calculan los costes totales por sprint mediante la siguiente fórmula: coste_total_sprint = costes_directos_Gantt + costes_indirectos +

contingencia + imprevistos

El objetivo de este proceso es poder analizar y comprender la gravedad de las desviaciones durante el desarrollo del proyecto.

8. Sostenibilidad

8.1. Autoevaluación Una vez completada la encuesta de sostenibilidad proporcionada [24], soy consciente de la poca importancia que dedicaba al análisis de sostenibilidad en proyectos anteriores. Es posiblemente el factor más importante a tener en consideración cuando se plantea un proyecto ya que, en el informe de sostenibilidad, no solo se analiza la viabilidad económica sino el impacto que causará en múltiples ámbitos el desarrollo del proyecto. A pesar de que la especialidad de ingeniería del software me ha ofrecido un marco de conocimiento más completo sobre la sostenibilidad a comparación con otras especialidades, me falta comprender en profundidad muchos de los aspectos importantes sobre ésta y entender que hay mucho más que el beneficio económico. Dicho esto, qué mejor oportunidad para empezar a pulir estas habilidades que en este mismo proyecto final de grado. Pretendo dar relevancia a un análisis de sostenibilidad completo.

8.2. Dimensión Económica A nivel económico, se ha estimado, en el apartado 7, el coste de recursos humanos y materiales considerando las posibles contingencias que puedan surgir. El presupuesto de este proyecto no es superior a proyectos similares ya que, durante gran parte de su desarrollo, se trabaja con un único programador junior y un tester. Adicionalmente, trabajar a partir de una aplicación existente, con un framework multiplataforma y con software gratuito reduce drásticamente el coste del proyecto.

33

En cuanto a la viabilidad económica, a pesar de que este proyecto no aportará ningún beneficio económico, los servicios aportados a los estudiantes de la FIB hacen este proyecto meritorio de una inversión.

8.3. Dimensión Ambiental El impacto ambiental que producirá el desarrollo de este proyecto es únicamente energético. Estimando que se trabajará sobre un ordenador portátil y en una habitación con luz artificial, obtenemos el siguiente consumo mostrado en la Tabla 13.

Elemento Consumo por hora (kWh) Consumo 540 horas (kWh)

Ordenador portátil 0,110 59,4

Entorno de trabajo 0,045 24,3

TOTAL 83,7

Tabla 13: Consumo energético. De elaboración propia. Trabajando con un ordenador portátil en vez de un ordenador de sobremesa, se están ahorrando un total de 59 kWh, equivalente a 20,24 Kgs de CO2 [25]. Según las cifras obtenidas, el consumo energético del desarrollo del proyecto es muy bajo y no supone un efecto negativo grave sobre el medio ambiente. En cuanto al impacto que causará a los usuarios de la aplicación, se incrementará ligeramente el consumo de energía de los dispositivos móviles, entre un 0,5 y un 1%, debido al background service worker que se activa cada 20 minutos para buscar nuevas notificaciones. Éste es un coste relativamente pequeño por lo útil que resulta esta funcionalidad.

8.4. Dimensión Social Este proyecto, de cara al aspecto personal, me proporcionará una oportunidad para mejorar mi conocimiento sobre el desarrollo de aplicaciones móviles y sobre tecnologías web utilizadas, como React. Además, representa también una oportunidad para aplicar el conocimiento adquirido durante el curso de ingeniería informática y, específicamente, sobre la especialidad de ingeniería del software. Para lo que supondrá a los estudiantes de la FIB, este proyecto pretende ofrecerles una herramienta para facilitar su estancia en la facultad. A pesar de que ya existen algunas alternativas mencionadas en el apartado 2.1., éstas tienen defectos y no son nada populares entre los estudiantes, como ya se ha demostrado en el apartado 2.2. Mantendremos a los usuarios informados de nuevos avisos, reduciendo el estrés ocasionado por la obligación de consultar frecuentemente el portal web, y ofreceremos una forma fácil e intuitiva de acceder a información relevante de la facultad.

34

9. Especificación del Sistema

9.1. Requisitos Funcionales Los requisitos funcionales definen los efectos funcionales que el sistema ha de tener en su entorno. Para los requisitos funcionales, se muestran en los casos de uso y su comportamiento.

9.1.1. Diagrama de Casos de Uso El comportamiento e interacción entre casos de uso ha sido documentada utilizando un diagrama de comportamiento UML (Figura 6 y 7).

Figura 6: Diagrama de casos de uso (1 de 2). De elaboración propia.

35

Figura 7: Diagrama de casos de uso (2 de 2). De elaboración propia. Como se puede observar en los diagramas previos (Figura 6 y 7), nuestra aplicación solo dispone de un stakeholder directo, el estudiante de la FIB, definido en el Apartado 1.4.

9.1.2. Casos de Uso brief style A continuación, se especifican todas las funcionalidades del sistema mediante sus casos de uso siguiendo el patrón brief style.

● UC01 - Iniciar sesión: El estudiante inicia sesión en la aplicación con las credenciales de estudiante de la FIB. La sesión permanecerá abierta hasta que el usuario cierre sesión o elimine el aplicativo.

● UC02 - Cerrar sesión: El estudiante puede cerrar sesión borrando todos los datos guardados localmente del usuario.

● UC03 - Consultar horario: El estudiante puede consultar visualmente su horario de clases.

● UC04 - Modificar información del horario: El estudiante puede modificar su horario añadiendo o eliminando clases.

36

● UC05 - Consultar avisos: El estudiante puede consultar los avisos de las asignaturas a las que está inscrito.

● UC06 - Ver aviso: El estudiante puede ver el contenido del aviso así como el

metadata asociado a éste.

● UC07 - Descargar documentos adjuntos del aviso: El estudiante puede descargar los documentos adjuntos al aviso activo.

● UC08 - Filtrar avisos por asignatura: El estudiante puede filtrar los avisos mostrados según la asignatura a la que pertenecen.

● UC09 - Actualizar avisos: El estudiante puede actualizar la lista de avisos.

● UC10 - Consultar noticias de la FIB: El estudiante puede consultar las noticias más recientes de la FIB.

● UC11 - Consultar noticias de la UPC: El estudiante puede consultar las noticias más recientes de la UPC.

● UC12 - Actualizar noticias: El estudiante puede actualizar la lista de noticias con la información más reciente.

● UC13 - Ver detalles noticia: El estudiante puede ver una vista completa de la página

original de la noticia.

● UC14 - Consultar asignaturas cursadas: El estudiante puede consultar las asignaturas que está cursando actualmente junto a una breve descripción.

● UC15 - Consultar plan de estudios de asignatura: El estudiante puede consultar el plan de estudios de una asignatura. Incluyendo los profesores, método de evaluación y metodología docente.

● UC16 - Consultar eventos: El estudiante puede consultar, de forma cronológica, los

eventos relacionados con su estancia en la facultad.

● UC17 - Ver próximas festividades de la FIB: El estudiante puede consultar las fechas de los próximos días festivos de la facultad.

● UC18 - Ver próximos exámenes: El estudiante puede consultar las fechas de los próximos exámenes de las asignaturas a las que esté adscrito.

● UC19 - Gestionar notas de asignaturas: El estudiante puede gestionar las notas de sus asignaturas.

37

● UC20 - Ver rendimiento de asignatura: El estudiante puede ver su rendimiento de

una asignatura. Se le muestra la nota media, la nota final y el progreso.

● UC21 - Ver rendimiento global: El estudiante puede ver su rendimiento global. Se le muestra la nota media, la nota final y el progreso de la media de todas las asignaturas cursadas.

● UC22 - Ver notas de asignaturas: El estudiante puede consultar las notas que haya añadido de una determinada asignatura e información relevante de ésta.

● UC23 - Añadir una nota a una asignatura: El estudiante puede añadir una nota de una asignatura al gestor de notas indicando el título del acto evaluativo, la nota y el peso.

● UC24 - Eliminar una nota de una asignatura: El estudiante puede eliminar una nota guardada en el gestor de notas.

● UC25 - Modificar una nota de una asignatura: El estudiante puede modificar una nota guardada en el gestor de notas.

● UC26 - Consultar disponibilidad de los laboratorios: El estudiante puede consultar la disponibilidad de los laboratorios de la FIB.

● UC27 - Ver ocupación de ordenadores: El estudiante puede ver la ocupación

individual de cada ordenador de los laboratorios de la FIB.

● UC28 - Actualizar la ocupación de ordenadores: El estudiante puede actualizar la ocupación de los ordenadores de la FIB con información actualizada.

● UC29 - Consultar ocupación de salas de la biblioteca BRGF: El estudiante puede consultar la ocupación de las salas grupales de la biblioteca BRGF del día actual.

● UC30 - Reservar una sala de la biblioteca BRGF: El estudiante puede reservar una sala de estudio de la biblioteca BRGF indicando una fecha y hora de inicio, una duración y el aula a ocupar.

● UC31 - Buscar aulas libres de la FIB: El estudiante puede buscar aulas normales y laboratorios de la FIB sin ocupar durante un periodo de tiempo determinado por el usuario e indicando el día de la semana y hora de inicio.

● UC32 - Gestionar plazas matrícula: El estudiante puede hacer uso de un gestor de plazas para facilitar el acto de matricularse.

● UC33 - Añadir asignatura al gestor de plazas: El estudiante puede añadir al gestor de plazas una asignatura para mantener vigilada.

38

● UC34 - Eliminar asignatura del gestor de plazas: El estudiante puede eliminar una

asignatura previamente añadida del gestor de plazas.

● UC35 - Ver ocupación por grupos de las asignaturas del gestor de plazas: El estudiante puede consultar la ocupación de los grupos de las asignaturas a las que esté suscrito en el gestor de plazas.

● UC36 - Consultar planes de movilidad: El estudiante puede consultar los planes de

movilidad de la FIB.

● UC37 - Ver universidades con planes de movilidad con la FIB: El estudiante puede consultar todas las universidades que tengan un plan de movilidad con la FIB.

● UC38 - Filtrar universidades por plan: El estudiante puede filtrar las universidades por tipo de plan de movilidad.

● UC39 - Filtrar universidades por país: El estudiante puede filtrar las universidades por país.

● UC40 - Obtener enlaces a páginas relacionadas con la movilidad: El estudiante puede acceder a enlaces a páginas de la FIB con más información acerca de los planes de movilidad y cómo aplicar a uno.

● UC41 - Consultar próximas lecturas de TFG y TFM: El estudiante puede consultar las próximas lecturas de TFG y TFM que se van a presentar en la FIB.

● UC42 - Obtener información de la lectura: El estudiante puede obtener información

de una lectura de TFG o TFM como la fecha y hora de la presentación, título del proyecto, ponente, director, lugar, grado, modalidad, etc.

● UC43 - Filtrar lecturas por grado: El estudiante puede filtrar las lecturas mostradas por grado.

● UC44 - Consultar enlaces de interés: El estudiante puede consultar enlaces externos de interés como a guías de la facultad, asociaciones y software accesible por ser estudiante de la FIB.

● UC45 - Valorar la app: El estudiante puede dejar una valoración de la aplicación en la Google Play Store.

● UC46 - Reportar bug o sugerencia: El estudiante puede enviar un correo directo al desarrollador de la app para reportar un bug o una sugerencia de la app.

● UC47 - Abrir el repositorio de la app: El estudiante puede abrir el repositorio de código abierto de la aplicación en un navegador.

39

● UC48 - Obtener notificaciones de nuevos avisos: El estudiante recibe notificaciones

acerca de nuevos avisos de asignaturas inscritas.

● UC49 - Desactivar notificaciones: El estudiante puede desactivar las notificaciones de la aplicación.

● UC50 - Activar notificaciones: El estudiante puede activar las notificaciones de la aplicación.

● UC51 - Modificar la apariencia de la aplicación: El estudiante puede modificar la apariencia visual de la aplicación.

● UC52 - Modificar la apariencia del horario: El estudiante puede modificar el tamaño de las casillas del horario y en qué formato se muestran las clases.

● UC53 - Modificar el tamaño de la fuente de los avisos: El estudiante puede modificar el tamaño de la fuente en la vista detallada de los avisos.

● UC54 - Cambiar idioma de la app: El estudiante puede cambiar el idioma de la aplicación entre catalán, español e inglés.

40

9.1.2. Casos de Uso Detallados Siguiendo el patrón Volere, a continuación se definen en detalle los casos de uso del sistema.

Caso de uso UC01 - Iniciar sesión

Actor principal Estudiante de la FIB

Precondición El estudiante no está autenticado en el sistema y posee una cuenta de estudiante de la FIB.

Trigger El usuario quiere autenticarse en el sistema.

Escenario principal de éxito

1. El usuario presiona el botón de iniciar sesión 2. Se le redirige a la FIB API v.2.0 para que se identifique 3. Introduce usuario y contraseña 4. Presiona el botón de "Autorizar" cediendo los permisos de "read scope" a la app 5. Se redirige al usuario a la aplicación 6. Se autentifica y se le muestra la página de inicio

Extensiones

3a. La combinación de usuario y contraseña es incorrecta. 3a.1. Se le informa al usuario y se vuelve al paso 3. 4a. Presiona el botón "Cancelar". 4a.1. Se redirige el usuario a la aplicación. 4a.2. Se le informa de que fue denegada la petición de permisos y se vuelve al paso 1.

Caso de uso UC02 - Cerrar sesión


Precondición El estudiante está autenticado en el sistema.

Trigger El usuario quiere cerrar su sesión en el sistema.


1. El usuario abre el drawer lateral de la aplicación. 2. El usuario pulsa el botón de cerrar sesión. 3. El sistema cierra la sesión localmente y elimina el token de la sesión en la API. 4. Se redirige al usuario a la vista de inicio de sesión.

Extensiones

3a. La aplicación no tiene conexión a internet. 3a.1. El sistema cierra sesión localmente pero no se elimina el token de sesión en la API. 3a.2. Se redirige al usuario a la vista de inicio de sesión.

41

Caso de uso UC03 - Consultar horario



Trigger El usuario quiere consultar su horario.


1. El usuario navega hasta la vista de horario mediante el bottom tab navigator principal. 2. El sistema muestra el horario del estudiante

Caso de uso UC04 - Modificar información del horario



Trigger El usuario quiere modificar el horario localmente.


1. El usuario navega hasta la ventana de configuración mediante el drawer de la app. 2. El usuario pulsa el botón “añadir clase” para añadir una clase al horario. 3. El estudiante introduce los datos de la clase y pulsa el botón “guardar”. 4. El sistema guarda las modificaciones.

Extensiones

3a. El estudiante pulsa el botón “cancelar”. 3a.1. El sistema cierra la ventana emergente y ninguna información es almacenada.

Caso de uso UC05 - Consultar avisos



Trigger El usuario quiere consultar los avisos de las asignaturas adscritas.


1. El usuario navega hasta la ventana de avisos mediante bottom tab navigator principal. 2. El sistema muestra al usuario un listado de los avisos de las asignaturas adscritas junto a su metadata.

Extensiones

2a. El sistema no tiene conexión a internet 2a.1. El sistema hará saber al usuario de la carencia de conexión y no se le mostrará ningun aviso.

42

Caso de uso UC06 - Ver aviso


Precondición El estudiante está autenticado en el sistema, está en la vista de “Avisos” y tiene como mínimo un aviso.

Trigger El estudiante quiere ver los detalles de un aviso.


1. El estudiante pulsa en el aviso de interés. 2. El sistema muestra una ventana emergente con los detalles del aviso seleccionado.

Caso de uso UC07 - Descargar documentos adjuntos del aviso


Precondición El estudiante está autenticado en el sistema y ha abierto los detalles de un aviso.

Trigger El usuario quiere descargar un documento adjunto a un aviso.


1. El usuario presiona el documento adjunto que quiere descargar. 2. El sistema empieza la descarga del documento y notifica al usuario de la acción. 3. El sistema informa de la finalización de la descarga. 4. Si el documento es formato PDF, el sistema abrirá una vista con el PDF.

Extensiones

2a. El sistema se encuentra sin conexión a internet. 2a.1. El sistema informa al usuario de la falta de conexión.

Caso de uso UC08 - Filtrar avisos por asignatura


Precondición El estudiante está autenticado en el sistema y está cursando asignaturas.

Trigger El estudiante quiere obtener los avisos de una única asignatura.


1. El usuario presiona la pestaña de la asignatura en cuestión en la barra superior de la vista. 2. El sistema mostrará al usuario únicamente los avisos que pertenezcan a esa asignatura.

43

Caso de uso UC09 - Actualizar avisos


Precondición El estudiante está autenticado en el sistema y está en la vista de “Avisos”.

Trigger El estudiante quiere actualizar los avisos mostrados.


1. El estudiante desliza verticalmente hacia abajo con el dedo para iniciar la actualización. 2. El sistema actualiza los avisos con la última información obtenida de la API de la FIB.

Caso de uso UC10 - Consultar noticias de la FIB



Trigger El estudiante quiere consultar las noticias de la FIB.


1. El usuario navega hasta la ventana de noticias mediante el bottom tab navigator principal. 2. El sistema muestra al usuario un listado de las noticias de la FIB.

Extensiones


Caso de uso UC11 - Consultar noticias de la UPC



Trigger El estudiante quiere consultar las noticias de la UPC.


1. El usuario navega hasta la ventana de noticias mediante el bottom tab navigator principal. 2. El sistema muestra al usuario un listado de las noticias de la UPC.

Extensiones


44

Caso de uso UC12 - Actualizar noticias


Precondición El estudiante está autenticado en el sistema y en la vista de noticias.

Trigger El usuario quiere actualizar las noticias.


1. El estudiante desliza verticalmente hacia abajo con el dedo para iniciar la actualización. 2. El sistema actualiza las noticias de la FIB y la UPC con la información más reciente. 3. El sistema muestra las modificaciones al usuario

Caso de uso UC13 - Ver detalles noticia


Precondición El estudiante está autenticado en el sistema, en la vista de noticias y tiene como mínimo una noticia listada.

Trigger El usuario quiere obtener más información acerca de una noticia.


1. El estudiante pulsa en la noticia de la que quiere obtener más información. 2. El sistema abre un webview de la página de la notícia original.

Extensiones

2a. El sistema no tiene acceso a internet. 2a.1. El sistema notifica al usuario de la ausencia de conexión.

Caso de uso UC14 - Consultar asignaturas cursadas



Trigger El estudiante quiere consultar las asignaturas cursadas.


1. El usuario navega a la vista de asignaturas desde el bottom tab navigator principal de la app. 2. El sistema muestra las asignaturas cursadas por el estudiante junto al metadata esencial de cada asignatura.

Extensiones

2a. El sistema no tiene conexión a internet. 2a.1. El sistema informa al usuario de la falta de conexión.

45

Caso de uso UC15 - Consultar plan de estudios de asignatura


Precondición El estudiante está autenticado en el sistema y en la vista de asignaturas con como mínimo una asignatura listada.

Trigger El estudiante quiere consultar el plan de estudios de una asignatura.


1. El usuario pulsa en la asignatura de la que quiere consultar su plan de estudios 2. El sistema abre una vista emergente con un listado de los profesores de la asignatura, la metodología docente y el método de evaluación.

Caso de uso UC16 - Consultar eventos



Trigger El estudiante quiere consultar los próximos eventos.


1. El usuario navega hasta la vista de eventos desde el drawer lateral de la aplicación. 2. El sistema muestra un listado de los eventos del estudiante y de la facultad.


2a. El sistema no tiene conexión a internet. 2a.1. El sistema notifica al usuario de la falta de conexión.

Caso de uso UC17 - Ver próximas festividades de la FIB



Trigger El estudiante quiere consultar las próximas festividades.


1. El usuario navega hasta la vista de eventos desde el drawer lateral de la aplicación. 2. El sistema muestra un listado de los eventos incluyendo las festividades de la FIB.

Extensiones


46

Caso de uso UC18 - Ver próximos exámenes



Trigger El estudiante quiere consultar los próximos exámenes de las asignaturas cursadas.


1. El usuario navega hasta la vista de eventos desde el drawer lateral de la aplicación. 2. El sistema muestra un listado de los eventos incluyendo los exámenes de las asignaturas cursadas.

Extensiones


Caso de uso UC19 - Gestionar notas de asignaturas



Trigger El usuario quiere gestionar sus notas.


1. 1. El usuario navega hasta la vista del gestor de notas desde el drawer lateral de la aplicación. 2. El sistema muestra el rendimiento global del usuario (nota media de cuatrimestre, nota final de cuatrimestre y progreso del cuatrimestre) junto a un listado de las asignaturas con su rendimiento individual.

Extensiones

2a. El usuario no está cursando ninguna asignatura 2a.1. El sistema notifica al usuario la necesidad de cursar como mínimo una asignatura para usar este recurso.

47

Caso de uso UC20 - Ver rendimiento de asignatura


Precondición El estudiante está autenticado en el sistema y está en la vista del gestor de notas.

Trigger El estudiante quiere ver su rendimiento de una asignatura.


1. El usuario presiona en una asignatura listada 2. El sistema expande la sección de la asignatura mostrando las evaluaciones creadas por el usuario (nombre, nota, peso) y su rendimiento de la asignatura (nota media, nota final, progreso).

Caso de uso UC21 - Ver rendimiento global



Trigger El estudiante quiere ver su rendimiento global.


1. 1. El usuario navega hasta la vista del gestor de notas desde el drawer lateral de la aplicación. 2. El sistema muestra el rendimiento global del usuario (nota media de cuatrimestre, nota final de cuatrimestre y progreso del cuatrimestre)

Extensiones

2a. El usuario no está cursando ninguna asignatura 2a.1. El sistema notifica al usuario la necesidad de cursar como mínimo una asignatura para usar este recurso.

Caso de uso UC22 - Ver notas de asignaturas



Trigger El estudiante quiere ver sus notas de una asignatura específica.


1. El usuario presiona en una asignatura listada 2. El sistema expande la sección de la asignatura mostrando las evaluaciones creadas por el usuario (nombre, nota, peso).

48

Caso de uso UC23 - Añadir una nota a una asignatura



Trigger El usuario quiere añadir una nota a una asignatura.


1. El usuario presiona en una asignatura listada 2. El sistema expande la sección de la asignatura mostrando las evaluaciones y un botón para añadir notas. 3. El usuario presiona el botón “añadir nota” 4. El sistema muestra al usuario una vista emergente con los campos a rellenar 5. El usuario introduce el nombre de la evaluación, el peso y la nota obtenida. 6. El estudiante presiona en el botón “Guardar” para añadir la nota 7. El sistema guarda la evaluación, actualiza la vista de la asignatura y cierra la vista emergente.

Extensiones

6a. El estudiante presiona el botón “Cancelar”. 6a.1. El sistema cierra la ventana emergente sin guardar ninguna información. 7a. El usuario no ha introducido un nombre, peso o nota válida. 7a.1. El sistema notifica al usuario de la invalidez de los campos y se vuelve al paso 5. 7b. La suma del peso de todas las evaluaciones de la asignatura supera el 100%. 7b.1. El sistema notifica al usuario del error y se vuelve al paso 5.

Caso de uso UC24 - Eliminar una nota de una asignatura



Trigger El estudiante quiere eliminar una nota.


1. El usuario presiona el icono de la basura junto a la nota que desea eliminar. 2. El sistema abre una ventana emergente pidiendo confirmación de la acción. 3. El usuario confirma su acción presionando en “Sí”. 4. El sistema cierra la ventana emergente, elimina la nota del sistema y actualiza la vista.

Extensiones

3a. EL usuario presiona “No”. 3a.1. La ventana emergente se cierra y no se realiza ninguna modificación en el sistema.

49

Caso de uso UC25 - Modificar una nota de una asignatura


Precondición El estudiante está autenticado en el sistema, está en la vista del gestor de notas y existe como mínimo una nota creada.

Trigger El estudiante desea modificar una nota previamente creada.


1. El usuario presiona en el botón de editar junto a la nota que desea editar. 2. El sistema muestra al usuario una ventana emergente con los datos de la evaluación. 3. El usuario modifica los campos de “nombre”, “nota” o “peso”. 4. El usuario pulsa el botón “Guardar”. 5. El sistema guarda la modificación y cierra la ventana emergente.

Extensiones

4a. El usuario pulsa el botón “Cancelar”. 4a.1. El sistema cierra la ventana emergente y no se realiza ninguna modificación en el sistema.

Caso de uso UC26 - Consultar disponibilidad de los laboratorios



Trigger El estudiante desea consultar la disponibilidad de los laboratorios.


1. El usuario navega hasta la vista de “Disponibilidad Labs” desde el drawer lateral de la app. 2. El sistema muestra al usuario la disponibilidad de los laboratorios.

Extensiones


50

Caso de uso UC27 - Ver ocupación de ordenadores



Trigger El usuario quiere consultar la ocupación de los ordenadores de la FIB


1. El usuario navega hasta la vista de “Disponibilidad Labs” desde el drawer lateral de la app. 2. El sistema muestra al usuario la ocupación de los ordenadores de la FIB.

Extensiones


Caso de uso UC28 - Actualizar la ocupación de ordenadores


Precondición El estudiante está autenticado en el sistema y en la vista de “Disponibilidad Labs”.

Trigger El estudiante quiere actualizar la información mostrada.


1. El usuario presiona el botón de “Actualizar”. 2. El sistema actualiza la información mostrada con la información más reciente.

Extensiones


Caso de uso UC29 - Consultar ocupación de salas de la biblioteca BRGF



Trigger El estudiante quiere consultar la ocupación de las salas de la biblioteca BRGF.


1. El usuario navega hasta la vista “Salas Bibl. BRGF” desde el drawer lateral de la app. 2. El sistema muestra un webview con la ocupación de las salas de la biblioteca.

51

Caso de uso UC30 - Reservar una sala de la biblioteca BRGF


Precondición El estudiante está autenticado en el sistema y se encuentra en la vista “Salas Bibl. BRGF”.

Trigger El estudiante quiere reservar una sala de la biblioteca BRGF.


1. El usuario presiona en el botón de “reservar sala”. 2. El sistema muestra al usuario un webview de la página de la biblioteca para reservar aulas.

Extensiones


Caso de uso UC31 - Buscar aulas libres de la FIB



Trigger El estudiante quiere buscar aulas libres de la FIB.


1. El estudiante navega hasta la vista “Buscar aulas libres” desde el drawer lateral de la app. 2. El estudiante introduce un día de la semana, una hora de inicio, una duración mínima y el tipo de aula deseada. 3. El sistema muestra al usuario las aulas libres que se adaptan a los campos de búsqueda y hasta que hora permanecerán libres.

Extensiones


52

Caso de uso UC32 - Gestionar plazas matrícula



Trigger El estudiante quiere consultar y gestionar las plazas de asignaturas.


1. El usuario navega hasta la vista “Plazas matrícula” desde el drawer lateral de la app. 2. El sistema ofrece al estudiante una plataforma para gestionar las plazas de las asignaturas.

Caso de uso UC33 - Añadir asignatura al gestor de plazas


Precondición El estudiante está autenticado en el sistema y se encuentra en la vista “Plazas matrícula”.

Trigger El usuario quiere añadir una asignatura al gestor de plazas.


1. El usuario presiona en el botón “Añadir Asignatura”. 2. El sistema muestra una vista emergente con un listado con todas las asignaturas ofrecidas por la facultad. 3. El estudiante presiona la asignatura que desea añadir. 4. El sistema añade la asignatura al gestor de plazas.

Caso de uso UC34 - Eliminar asignatura del gestor de plazas



Trigger El usuario desea eliminar una asignatura del gestor de plazas.


1. El usuario presiona el botón de eliminar junto a la asignatura que desea eliminar. 2. El sistema muestra una ventana emergente pidiendo confirmación sobre la acción. 3. El usuario presiona “Sí” para eliminar la asignatura del gestor. 4. El sistema elimina la asignatura del gestor de plazas.

Extensiones

3a. El usuario presiona “No” en la confirmación de la acción. 3a.1. El sistema cierra la ventana emergente y no realiza ninguna modificación.

53

Caso de uso UC35 - Ver ocupación por grupos de las asignaturas del gestor de plazas



Trigger El usuario desea ver la ocupación de las plazas de las asignaturas en el gestor.


1. El sistema muestra al usuario la ocupación de las plazas de cada asignatura en el gestor por grupos.

Caso de uso UC36 - Consultar planes de movilidad



Trigger El estudiante desea consultar los planes de movilidad de la FIB.


1. El usuario navega hasta la vista “Planes de movilidad” desde el drawer lateral de la app. 2. El sistema muestra los planes de movilidad ofrecidos por la FIB.

Extensiones


Caso de uso UC37 - Ver universidades con planes de movilidad con la FIB


Precondición El estudiante está autenticado en el sistema y está en la vista “Planes de movilidad”.

Trigger El usuario desea ver las universidades que ofrecen un plan de movilidad con la FIB.


1. El usuario navega hasta la vista “Planes de movilidad” desde el drawer lateral de la app. 2. El sistema muestra las universidades con planes de movilidad con la FIB junto a una ficha de información, un enlace a su página web, un enlace a Google Maps con las coordenadas de la facultad y un enlace a un PDF con información sobre la facultad y su plan de movilidad.

54

Caso de uso UC38 - Filtrar universidades por plan



Trigger El usuario quiere filtrar las universidades por plan de movilidad.


1. El usuario abre el panel desplegable “Planes” y selecciona el plan de movilidad a filtrar. 2. El sistema elimina de la lista todas las universidades que no contengan el plan de movilidad seleccionado con la FIB.

Caso de uso UC39 - Filtrar universidades por país



Trigger El usuario quiere filtrar las universidades por país.


1. El usuario abre el panel desplegable “País” y selecciona el país a filtrar. 2. El sistema elimina de la lista todas las universidades que no se encuentren en el país seleccionado.

Caso de uso UC40 - Obtener enlaces a páginas relacionadas con la movilidad



Trigger El usuario quiere obtener enlaces a páginas relacionadas con la movilidad.


1. El usuario presiona el botón de información. 2. El sistema despliega una ventana emergente con enlaces de interés. 3. El usuario presiona un enlace de interés. 4. El sistema redirige al usuario a la página especificada.

55

Caso de uso UC41 - Consultar próximas lecturas de TFG y TFM



Trigger El usuario quiere consultar las próximas lecturas de TFG o TFM.


1. El usuario navega hasta la vista “Lecturas TFG y TFM” mediante el drawer lateral de la app. 2. El sistema muestra una lista con las próximas lecturas de TFG y TFM de la FIB.

Extensiones


Caso de uso UC42 - Obtener información de la lectura


Precondición El estudiante está autenticado en el sistema y se encuentra en la vista “Lecturas TFG y TFM”.

Trigger El usuario quiere consultar los detalles de una próxima lectura.


1. El sistema muestra, para cada lectura en la lista, el nombre del proyecto, autor, director, fecha y hora de defensa, lugar, modalidad y plan.

Extensiones


Caso de uso UC43 - Filtrar lecturas por grado


Precondición El estudiante está autenticado en el sistema y se encuentra en la vista “Lecturas TFG y TFM”.

Trigger El estudiante quiere filtrar las próximas lecturas por grado.


1. El usuario selecciona el grado por el que quiere filtrar desde el desplegable “Grado”. 2. El sistema filtra la lista de próximas lecturas y solo enseña las que coincidan con el grado

seleccionado.

56

Caso de uso UC44 - Consultar enlaces de interés



Trigger El estudiante quiere consultar enlaces de interés de la facultad.


1. El usuario navega hasta la vista “Enlaces de interés” a través del drawer lateral de la app. 2. El sistema muestra una lista con enlaces de interés organizados en secciones: “la facultad”, “guías”, “programas y servicios para el estudiante”. 3. El usuario presiona en un enlace. 4. El sistema redirige al usuario al recurso web solicitado.

Caso de uso UC45 - Valorar la app



Trigger El estudiante quiere valorar la aplicación.


1. El usuario navega hasta la vista “Feedback & Bugs” a través del drawer lateral de la app. 2. El sistema muestra una vista con 3 botones: “Valora la app”, “Envíame un correo” y “Colabora”. 3. El usuario presiona en el botón “Valora la app”. 4. El sistema redirige al usuario a la página de la aplicación de la Google Play Store para que el usuario pueda dejar una valoración.

Caso de uso UC46 - Reportar bug o sugerencia



Trigger El estudiante quiere reportar un bug.


1. El usuario navega hasta la vista “Feedback & Bugs” a través del drawer lateral de la app. 2. El sistema muestra una vista con 3 botones: “Valora la app”, “Envíame un correo” y “Colabora”. 3. El usuario presiona en el botón “Envíame un correo”. 4. El sistema redirige al usuario a la aplicación de correo por defecto en el dispositivo con una plantilla de correo lista para ser enviada al desarrollador de la app.

57

Caso de uso UC47 - Abrir el repositorio de la app



Trigger El estudiante quiere acceder al repositorio de la app.


1. El usuario navega hasta la vista “Feedback & Bugs” a través del drawer lateral de la app. 2. El sistema muestra una vista con 3 botones: “Valora la app”, “Envíame un correo” y “Colabora”. 3. El usuario presiona en el botón “Colabora”. 4. El sistema redirige al usuario a la página web del repositorio en Github.

Caso de uso UC48 - Obtener notificaciones de nuevos avisos



Trigger Cada 20 minutos, el sistema analiza si se han publicado nuevos avisos. En caso afirmativo, se activa el caso de uso.


1. El sistema obtiene los nuevos avisos. 2. El sistema envía al dispositivo una notificación para cada aviso nuevo.

Extensiones

1a. El usuario ha marcado que no quiere recibir notificaciones. 1a.1. La aplicación no realiza ninguna acción.

Caso de uso UC49 - Desactivar notificaciones



Trigger El estudiante quiere desactivar las notificaciones de la aplicación.


1. El usuario navega a la vista “Configuración” a través del drawer lateral de la app. 2. El usuario presiona el botón “Desactivadas” de la pestaña de “Notificaciones avisos”. 3. El sistema desactiva todas las notificaciones de la aplicación.

58

Caso de uso UC50 - Activar notificaciones



Trigger El estudiante quiere activar las notificaciones de la aplicación.


1. El usuario navega a la vista “Configuración” a través del drawer lateral de la app. 2. El usuario presiona el botón “Activadas” de la pestaña de “Notificaciones avisos”. 3. El sistema activa todas las notificaciones de la aplicación.

Caso de uso UC51 - Modificar la apariencia de la aplicación



Trigger El usuario quiere modificar la apariencia visual de la aplicación.


1. El usuario navega a la vista “Configuración” a través del drawer lateral de la app. 2. El sistema proporciona funcionalidades para modificar la apariencia del horario y de los avisos de la app.

Caso de uso UC52 - Modificar la apariencia del horario


Precondición El estudiante está autenticado en el sistema y está en la vista de “Configuración”.

Trigger El usuario quiere modificar la apariencia de los horarios.


1. El usuario puede presionar los botones “Minimalista” o “Completo” para cambiar el formato en el que se muestran las clases en el horario o arrastrar el slider para modificar el tamaño de fuente. 2. El sistema almacenará los cambios del usuario automáticamente y actualizará la vista del horario.

59

Caso de uso UC53 - Modificar el tamaño de la fuente de los avisos



Trigger El estudiante quiere modificar el tamaño de la fuente de los avisos.


1. El usuario desplaza el slider de “Tamaño de avisos” para ajustar el tamaño de la fuente. 2. El sistema guarda automáticamente las preferencias del usuario y refleja los cambios en la pestaña de avisos.

Caso de uso UC54 - Cambiar idioma de la app



Trigger El usuario quiere cambiar el idioma de la aplicación.


1. El usuario, en la sección de idioma, puede seleccionar el idioma al que desea cambiar a través de un panel desplegable. 2. El sistema guarda automáticamente las preferencias del usuario y refleja el cambio de idioma en toda la aplicación.

9.2. Requisitos no Funcionales Los requisitos no funcionales establecen propiedades de calidad que el sistema ha de cumplir. Los requisitos no funcionales de la aplicación a desarrollar listados a continuación siguen la plantilla de especificación de requisitos Volere [39] con el patrón brief style. [Volere id 10.] Look and feel requirements

● 10a. Appearance Requirements: La aplicación ha de encajar con los estándares modernos de diseño para ofrecer una experiencia visual agradable.

● 10b. Style Requirements: El estilo de la aplicación ha de ser consistente entre vistas.

[Volere id 11.] Usability and Humanity Requirements ● 11a. Ease of Use Requirements: La aplicación ha de ser intuitiva de utilizar para una

persona de entre 17 y 25 años. La aplicación ha de ayudar al usuario a no cometer acciones no deseadas. Los usuarios han de querer usar la aplicación. La aplicación ha de poder ser utilizada por usuarios sin ningún tipo de entrenamiento previo.

60

● 11b. Personalization and Internationalization Requirements: El usuario ha de poder seleccionar el lenguaje de la aplicación. La aplicación ha de permitir personalizar su experiencia y mantener los cambios.

● 11c. Learning Requirements: Los usuarios han de poder utilizar la aplicación de forma intuitiva sin necesidad de ninguna guía o entrenamiento.

● 11d. Understandability and Politeness Requirements: Los iconos dentro de la aplicación han de ser fácilmente identificables por los usuarios. Las funcionalidades de la aplicación han de ser fácilmente predecibles a partir de la descripción. Cuando la información está siendo cargada, se ha de notificar visualmente al usuario de la acción.

● 11e. Accessibility Requirements: La aplicación ha de poder ser utilizada por todos los estudiantes de la FIB.

[Volere id 12.] Performance Requirements ● 12a. Speed and Latency Requirements: La navegación entre vistas de la aplicación

ha de sentirse inmediata. La aplicación ha de iniciarse en menos de 1,5 segundos. Toda información no ha de tardar más de 2 segundos en mostrarse desde que el usuario la pide.

● 12b. Safety-Critical Requirements: La aplicación no ha de causar ningún daño al dispositivo, usuario o interfaces online a las que conecta.

● 12c. Precision or Accuracy Requirements: La precisión en las fecha y hora ha de ser hasta el minuto. La precisión en la gestión de notas del estudiante ha de ser hasta 2 decimales.

● 12d. Reliability and Availability Requirements: La aplicación ha de estar disponible 24 horas al día, 356 días al año.

● 12e. Robustness or Fault-Tolerance Requirements: La aplicación ha de poder ofrecer las funcionalidades básicas, como consultar el horario y gestionar las notas, cuando se pierde conexión a internet o a los servidores.

● 12f. Capacity Requirements: La aplicación ha de poder ser usada de forma simultánea por todos los estudiantes de la facultad.

● 12g. Scalability or Extensibility Requirements: La aplicación ha de poder ser descargada por todos los estudiantes de la FIB.

● 12h. Longevity Requirements: Esta aplicación ha de poder operar en el máximo presupuesto de mantenibilidad por un mínimo de 5 años.

[Volere id 13.] Operational and Environmental Requirements ● 13a. Expected Physical Environment: La aplicación ha de poder ser utilizada desde

un dispositivo móvil bajo todas las condiciones de entorno posibles. ● 13b. Requirements for Interfacing with Adjacent Systems: La aplicación ha de poder

funcionar en dispositivos Android con una versión igual o superior a Android 5. La aplicación ha de poder interactuar con interfaces online mediante HTTP Requests.

● 13c. Productization Requirements: La aplicación ha de distribuirse mediante tiendas de aplicaciones móviles como Google Play Store.

● 13d. Release Requirements: La aplicación ha de poderse actualizar de forma automática. Las actualizaciones no han de causar el fallo de funcionalidades previas.

61

[Volere id 14.] Maintainability and Support Requirements ● 14a. Maintenance Requirements: Una nueva actualización a la aplicación a de poder

ser instalada en el dispositivo de un usuario con conexión a internet en un periodo de 24 horas desde su publicación.

● 14b. Supportability Requirements: Los usuarios de la aplicación han de poder ponerse en contacto con los desarrolladores para pedir soporte sobre la aplicación. La respuesta a las peticiones de soporte no ha de demorarse más de 24 horas.

● 14c. Adaptability Requirements: Esta aplicación está diseñada para poder ser ejecutada en una versión de Android 5 o superior. La aplicación va a permanecer de descarga gratuita indefinidamente.

[Volere id 15.] Security Requirements ● 15a. Access Requirements: Solo usuarios con una cuenta de la FIB pueden acceder

al contenido de la aplicación. ● 15b. Integrity Requirements: La aplicación impide al usuario introducir datos con un

formato incorrecto. La aplicación ha de tener medidas para solucionar la posible eliminación manual del token de la aplicación.

● 15c. Privacy Requirements: La aplicación ha de informar sobre las políticas de privacidad de la aplicación antes de recolectar información de los usuarios. La aplicación no ha de revelar ninguna información privada de los usuarios. La aplicación ha de proteger la información privada de los usuarios según las leyes de privacidad y de la política de privacidad de la aplicación.

[Volere id 16.] Cultural Requirements

● 16a. Cultural Requirements: La aplicación no ha de ser ofensiva a ningún grupo religioso o cultural.

[Volere id 17.] Legal Requirements ● 17a. Compliance Requirements: La aplicación ha de mantenerse legal según las

legislaciones implicadas y cumplir todas las políticas de los recursos de terceros utilizados. Más detalle en el Apartado 14.

62

10. Diseño del Sistema

10.1. Arquitectura Física La arquitectura física de nuestro sistema se forma de una aplicación Android distribuida y servicios web con los que interacciona. Los componentes de la arquitectura pueden verse definidos y representados (Figura 8) a continuación.

Figura 8: Interacción física del sistema. De elaboración propia. Aplicación Android “El Racó - FIB”: Aplicación Android distribuida mediante Google Play Store que ofrece una interfaz de usuario móvil a la API de la FIB y interactúa con los servidores definidos a continuación mediante HTTP Requests. Android 5 es la versión mínima de Android con la que se puede ejecutar la aplicación. Esta aplicación es la que se desarrolla en este Trabajo Final de Grado. FIB API v.2.0: API de la Facultad de Informática de Barcelona donde se pueden encontrar tanto recursos públicos de la facultad (noticias, eventos, asignaturas...) como recursos privados del estudiante (horario, avisos, asignaturas cursadas...) mediante una autenticación Oauth 2.0 [40]. La aplicación móvil de este proyecto extrae la gran mayoría de su información a partir de este recurso.

63

Servidor Bibliotècnia UPC: La biblioteca digital de la UPC. Nuestra aplicación Android interactua con este servidor para extraer la ocupación de las salas de la biblioteca BRGF y poder realizar reservas para la misma. Esta información es extraída y mostrada a partir de un webview para poder mostrar el contenido tal y como lo proporciona el servidor en formato HTML. Servidor UPC: Servidor del portal de la Universitat Politècnica de Catalunya. Nuestra aplicación interactúa con el servidor para extraer las noticias de la universidad, mediante un canal RSS. Cuando un usuario quiere obtener más información acerca de una noticia de la UPC, se le muestra el contenido de la noticia en un webview siguiendo el enlace proporcionado. Servidor FIB: Servidor del portal de la Facultat d’Informàtica de Catalunya. La aplicación actúa de manera similar a la interacción con el servidor de la UPC. Cuando un usuario de la aplicación desea obtener más información acerca de una notícia de la facultad, extraída desde la FIB API v.2.0, se realiza una petición HTTP GET al servidor para obtener más detalles acerca de ésta. Así mismo, la aplicación Android ofrece enlaces de interés al portal como entradas sobre movilidad o guías de la facultad.

10.2. Arquitectura Lógica Debido a que trabajamos sobre React en la aplicación Android del proyecto, se ha priorizado utilizar una arquitectura Flux [41] para complementar el sistema. React, un framework popular para crear interfaces frontend, está basado en componentes en cascada. Los componentes finales de la cascada hacen la misma función que las vistas de una arquitectura MVC, creando la interfaz gráfica, y, adicionalmente, se encargan de mantener actualizados los componentes renderizados con los datos provistos. Respecto a la parte de “controlador” de la arquitectura modelo-vista-controlador (MVC), una arquitectura Flux hace uso de Controller-Views. Traducido a React, equivale a componentes con el único fin de gestionar el estado de la aplicación. Estos componentes de tipo “controlador” son ejecutados en cascada según el flujo de ejecución y, al final del árbol en cascada, se encuentran los componentes tipo “vista”. Más detalle sobre los componentes del aplicativo en el Apartado 10.3. En cuanto al modelo de datos de la aplicación, es donde podemos observar una significativa diferencia con el patrón MVC. Flux es la arquitectura responsable de crear la capa de datos de aplicaciones Javascript. La principal función de este patrón es crear unidireccionalidad en el flujo de datos de la aplicación y permitir una fácil escalabilidad del sistema.

64

10.2.1. Estructura y Flujo de Datos Flux Una capa de datos Flux se compone principalmente de 3 elementos: actions, dispatchers, y stores. En la Figura 9 se puede apreciar el flujo de datos y su unidireccionalidad.

Figura 9: Flujo de Flux. Extraído del portal web de FluxJS. Store: La store es donde se contiene el estado y la lógica de la aplicación. Ésta, a diferencia del modelo de un MVC tradicional, maneja el estado de múltiples objetos para un dominio particular dentro de la aplicación. Al actualizar una store, ésta alimenta las modificaciones a todos los componentes React que hayan solicitado ese recurso previamente. Dispatcher: El dispatcher es el eje central que gestiona todo el flujo de datos en una aplicación Flux. Es esencialmente un registro de callbacks a las stores, un mecanismo simple para distribuir las acciones. Cada store se registra en los dispatchers y proporciona un callback. Cuando una acción es proporcionada al dispatcher, todas las stores de la aplicación reciben la acción a través de los callbacks en el registro y actualizan sus datos en las stores si éstas contienen el mismo tipo de dato. Actions: Una acción es un método que, al ser llamado, ejecuta una acción en el sistema que pretende modificar el estado de la aplicación. Con los datos obtenidos de la acción, posteriormente son alimentados al dispatcher que los distribuye a todas las stores para que actualicen su información en caso de corresponderse el tipo de dato. En este proyecto, se ha elegido el uso de una arquitectura Flux sobre una MVC principalmente por la propiedad unidireccional de los datos y la ventaja de disponer de un registro encargado de actualizar automáticamente las vistas del sistema cuando el estado de la aplicación es modificado.

65

Pongamos un ejemplo de su practicalidad. Lo que supondría una vista tradicional en un sistema MVC, esta está formada por dos componentes React de tipo ‘vista’ en el nuestro, “CompView1” y “CompView2”. Ambos componentes utilizan un recurso común llamado “Dato1”. Ahora, el usuario interactúa con “CompView1” y desea modificar “Dato1”. En una arquitectura MVC tradicional, el controlador es el encargado de pedir la modificación del dato y de actualizar los dos componentes manualmente para reflejar los cambios. Ahora bien, si se quiere escalar la vista y añadir un nuevo componente “CompView3” que también requiera de “Dato1”, será necesario modificar el método de la actualizacización de “Dato1” en la capa de controlador para también reflejar los cambios en “CompView3” al ser actualizado. Estos problemas de escalabilidad son fácilmente solucionables con una arquitectura Flux. Con Flux, cada componente se subscribe a las stores con los datos que requiera y, una vez los datos de la store sean modificados, los reducers enviarán automáticamente los datos modificados a todos los componentes inscritos en el registro de la store. Por tal de implementar fácilmente esta arquitectura en la aplicación del proyecto, se hará uso del framework Redux que incorpora métodos para implementar los registros y las stores del sistema.

10.3. Diagrama de Componentes La aplicación de este proyecto se construirá mediante el uso de React. Este framework de desarrollo de aplicaciones no usa un sistema tradicional basado en objetos (OOP) sino una fragmentación de responsabilidades basada en componentes React [42]. Estos componentes son inicializados en cascada durante la ejecución del aplicativo. En este proyecto, se ha querido diferenciar dos tipos de componentes. Por un lado, existen componentes de tipo controlador, que se encargan de gestionar la lógica de la aplicación así como funcionar de enrutadores para el segundo tipo de componentes, los componentes de tipo vista. Estos últimos componentes, definidos en detalle en el Apartado 10.6, forman la interfaz gráfica del aplicativo. Los componentes React de tipo controlador, así como su función en el sistema, son resumidos en la Figura 10 de a continuación.

66

Figura 10: Diagrama simplificado de componentes React. De elaboración propia.

10.4. Patrones de Diseño Los patrones de diseño de software son soluciones reusables a problemas recurrentes en el ámbito de diseño de software. Durante la fase de diseño y desarrollo de este proyecto se han trabajado con patrones para crear soluciones elegantes a problemas comunes.

10.4.1. Lazy Loading Lazy loading es una táctica de diseño de software donde se retrasa la inicialización de un objeto hasta que el recurso es necesitado. Usualmente, este patrón se implementa para ganar eficiencia retrasando la inicialización de elementos pesados. En este proyecto, su uso es algo más peculiar. React Navigation, el framework utilizado para gestionar la navegación de la aplicación de forma nativa, se integra en la cascada de componentes de React como un componente pero tiene un comportamiento distinto al de un componente común. Ningún argumento (React props) puede ser proporcionado al componente y en vez de ser ejecutado y evaluado en tiempo real por un Javascript engine, el framework compila a código nativo al inicializarse sin permitir la posterior modificación de los datos. El problema surge al tener en cuenta los distintos paquetes de idiomas que nuestra aplicación ofrece. Los componentes de navegación, como títulos de ventanas o de la barra de pestañas, han de cargarse en función del lenguaje seleccionado. Por tal de proporcionar argumentos al componente de React Navigation durante su inicialización, este se inicializa mediante el patrón lazy loading, se hace uso de variables globales para guardar el paquete de idiomas y, posteriormente, poderlos leer desde el componente de React Navigation una vez se inicialice.

67

Este patrón se implementa mediante el método “React.lazy” del framework de React. “React.lazy()” permite renderizar dinámicamente una dependencia externa como un componente React.

10.4.2. Patrón Decorador El patrón decorador es un patrón de diseño que permite añadir comportamiento adicional a un objeto o método dinámicamente. Este patrón se ha implementado en este proyecto para solventar dos problemas distintos. Primeramente, se utiliza el patrón decorador para facilitar las tareas de testing. Los métodos de los componentes React testados son envueltos con un patrón decorador para extender sus funcionalidades con comportamiento útil para los tests. Cada método es extendido para obtener la siguiente información adicional.

● Número de veces invocado ● Argumentos proporcionados al método ● Resultado del método

De esta manera, podemos obtener un mejor entendimiento de cómo el componente React interactúa con el método para realizar tests más extensos y reducir los comportamientos no deseados. En segundo lugar, se utiliza para falsificar HTTP Requests envolviendo la librería encargada de realizar las llamadas, “axios”, con el fín de debuggear la aplicación y para realizar tests. Este uso del patrón es fundamental para quitar toda variabilidad externa en los juegos de pruebas y para probar la aplicación con ocurrencias concretas al realizar un HTTP Request.

10.4.3. Patrón Observer El patrón observer es un patrón de diseño para observar el estado de un objeto en el sistema. Existe un objeto, llamado sujeto, el cual guarda un registro de objetos dependientes, llamados observadores. Cuando el registro sujeto cambia su estado, este notifica la modificación a todos los objetos adscritos en la lista de registro. Todo objeto observador puede suscribirse y desuscribirse del registro en tiempo de ejecución. Este patrón es usado en nuestro proyecto para completar la arquitectura Flux, definida en el Apartado 10.2. Las stores del sistema hacen la función de sujeto y todos los componentes del sistema que requieran de información sobre un dato existente en una store son adscritas al registro obteniendo actualizaciones sobre la modificación del dato.

68

10.5. Modelo de Datos Un modelo de datos UML es un modelo abstracto que define y organiza los elementos de información de un sistema y la relación entre ellos mediante el estándar de modelado general UML. Nuestra aplicación gestiona una gran cantidad de información variable acerca del estudiante, la facultad y el estado lógico de la aplicación. El modelo de datos UML de nuestra aplicación está representado en las Figuras 11 y 12 a continuación.

Figura 11: Modelo de datos UML de la aplicación (parte 1 de 2). De elaboración propia.

69

Figura 12: Modelo de datos UML de la aplicación (parte 2 de 2). De elaboración propia. Debido a que nuestro sistema hace uso de una arquitectura Flux para gestionar el estado de nuestra aplicación, las clases de datos del sistema, definidos anteriormente en las Figuras 11 y 12, son guardados según su modalidad, en formato JSON, dentro de las stores de la aplicación, tal y como se define en el Apartado 10.2.1.

10.6. Vistas del Sistema y Navegabilidad

10.6.1. Navegabilidad Para la navegabilidad de la aplicación de este proyecto, se utilizan recursos de navegación móvil nativos. Una vez el usuario se autentica en la aplicación, se le presenta toda la información mediante un bottom tab navigator y un drawer. El bottom tab navigator se muestra en la vista principal del sistema donde permite al usuario el fácil acceso a las vistas esenciales de la aplicación. Estas son consultar el horario (UC03), consultar los avisos (UC05), Consultar las noticias de la FIB y de la UPC (UC10 y UC11) y consultar las asignaturas cursadas (UC14). Se puede alternar de vista mediante los botones de acceso rápido del bottom tab navigator o deslizando el dedo horizontalmente a través de las vistas. Este componente se puede visualizar en la Figura 13.

Figura 13: Bottom tab navigator de la aplicación del proyecto. De elaboración propia. Adicionalmente, para acceder a las funcionalidades restantes de la aplicación, se usa un drawer. El drawer puede ser accedido desde cualquier parte de la aplicación, una vez el usuario ya haya sido autenticado, mediante un icono en la barra superior o deslizando horizontalmente desde la izquierda de la pantalla del dispositivo. Este componente de navegación puede ser observado en la Figura 14.

70

Figura 14: Drawer de la aplicación del proyecto. De elaboración propia.

10.6.2. Vistas del Sistema A continuación, desde la Figura 15 hasta la Figura 23, se muestran todas las vistas del sistema que forman la interfaz de usuario.

Figura 15: Vistas de inicio de sesión y horario del estudiante en formato extendido y minimalista. De elaboración propia.

71

Figura 16: Vistas de lista de avisos del estudiante, detalles de aviso y próximos eventos. De elaboración propia.

Figura 17: Vistas de noticias de la UPC y FIB, detalles de notícia y ocupación de laboratorios de la FIB. De elaboración propia.

72

Figura 18: Vistas de asignaturas cursando, guía docente de una asignatura y ocupación de salas de la biblioteca BRGF. De elaboración propia.

Figura 19: Vistas del buscador de aulas libres, gestor de matrícula y vista emergente para añadir asignaturas al gestor. De elaboración propia.

73

Figura 20: Vistas de programas de movilidad, vista emergente con enlaces externos de movilidad y vista de próximas lecturas. De elaboración propia.

Figura 21: Vistas del gestor de notas compacto, extendido y vista emergente para añadir evaluación. De elaboración propia.

74

Figura 22: Vistas de enlaces de interés, feedback & bugs y configuración de la aplicación. De elaboración propia.

Figura 23: Vistas auxiliares para modificar el horario del estudiante. De elaboración propia.

75

11. Implementación del Sistema Para implementar el sistema, se ha estudiado los lenguajes y frameworks que más encajan con la especificación del sistema y los requisitos de diseño y las herramientas de desarrollo que permitirán llevar a cabo las tareas de desarrollo.

11.1. Tecnologías y Lenguajes Utilizados Lenguajes

● Javascript: Javascript es un lenguaje de alto nivel, interpretado y multiparadigma. Se define como orientado a objetos, basado en prototipos y dinámico. El principal motivo por el que se ha hecho uso de este lenguaje es para poder trabajar con los frameworks definidos más adelante ya que éstos sólo ofrecen soporte en NodeJS, cuyo lenguaje utilizado es Javascript.

● JSON: JSON es un formato de texto para intercambios de datos. En nuestro proyecto, se utiliza este formato para intercambiar datos con la FIB API v.2.0 y manejar los objetos de Javascript.

● XML: XML es un lenguaje de marcado que define un conjunto de normas para codificar documentos. Se ha hecho uso de este lenguaje para extraer información de canales RSS, crear snapshots de la interfaz gráfica y para definir documentos de atributos requeridos en todas las aplicaciones Android.

Frameworks

● React Native: React native es un framework para construir aplicaciones nativas utilizando React. Se ha hecho uso de este framework ya que permite desarrollar aplicaciones multiplataforma (Android y iOS) de forma nativa reutilizando código y por el hecho de que ya se tenía un conocimiento previo de React. De esta forma, se puede ganar mucho tiempo en las fases de desarrollo.

● React: React es un framework para construir interfaces de usuario en Javascript. Su función es la de crear componentes tipo “vista” definidos en el Apartado 10.2.

● Redux: Redux es una librería para manejar el estado de la aplicación. Se utiliza en este proyecto para completar la arquitectura Flux ya que se integra bien con React.

● React Navigation: React Navigation es una librería para manejar el routing y navegación de una aplicación React Native. Se utiliza este recurso para evitar la necesidad de interactuar con código nativo (Java en Android o C# en iOS) para utilizar elementos nativos de navegación.

● Jest: Jest es un framework de testing para Javascript. Su principal característica es su simplicidad y la compatibilidad que ofrece con otros frameworks. Se ha elegido este framework de testing ante cualquier otra opción ya que este es el que dispone de más funcionalidades y es el framework recomendado en la documentación de React y React Native.

76

Runtime environment ● NodeJS: NodeJS es un entorno de ejecución de Javascript fuera del navegador. Se

utiliza en este proyecto para construir la aplicación Android e iOS con los frameworks descritos anteriormente.

11.2. Herramientas de Desarrollo Software:

● Visual Studio Code: VS Code es un editor de texto open source. Se utiliza este programa sobre otros editores debido a la facilidad que ofrece para gestionar GIT, por tener un intérprete de comandos integrado y por la gran variedad de plugins de terceros que ofrece.

● Android Studio: Android Studio es un IDE para desarrollar aplicaciones Android. Es necesario en este proyecto para compilar la aplicación de Android.

● Android Emulator: Android Emulator es un emulador de Android utilizado para ejecutar versiones debug y release de la aplicación.

● Android Debug Bridge (ADB): ADB es una command-line tool para comunicarse con dispositivos Android virtuales o físicos. Se usa para actualizar la aplicación en vivo con cada modificación en el código de la aplicación React Native.

● Xcode: Xcode es el IDE de Apple para desarrollar aplicaciones iOS y OSX. En este proyecto se utiliza para compilar la aplicación iOS y ser ejecutada en su emulador integrado.

● NPM: NPM es un gestor de paquetes utilizado por NodeJS. Mediante él, es posible la descarga y gestión de dependencias del proyecto.

● Fiddler: Fiddler es una herramienta de depuración proxy que se utiliza para registrar, inspeccionar y alterar el tráfico HTTP. En este proyecto se usa para interceptar las comunicaciones de la aplicación en modo depuración para depurar el código a tiempo real.

● Gradle: Gradle es un software de automatización de tareas utilizado por defecto en React Native para compilar y ejecutar el aplicativo.

● GIT: Git es un sistema de gestión de versiones diseñado para gestionar proyectos de todo tamaño con eficiencia y rapidez. En el proyecto se usa para mantener un registro de versiones de la aplicación y poder gestionar el repositorio remoto del proyecto en Github.

Hardware:

● Ordenador portátil (Windows 10): Utilizado como ordenador principal para llevar a cabo todas las tareas del proyecto a excepción de la tarea T7, definida en el Apartado 5.2.

● Macbook Pro: Ordenador Apple con iOS para desarrollar la aplicación iOS (tarea T7, definida en el Apartado 5.2.) debido a que Xcode únicamente es compatible con plataformas OSX.

● Dispositivo móvil con Android 10: Con el fin de testar la aplicación en un dispositivo Android físico para observar su comportamiento antes de publicar una actualización, se ha hecho uso de un dispositivo móvil con Android 10 como su sistema operativo.

77

12. Testing y Validación

12.1. Software Quality Assurance Software quality assurance (SQA) es la definición de un conjunto de prácticas para garantizar la calidad en los procesos de un proyecto. En este proyecto, tal y como se define en la metodología (Apartado 4), se hace uso de una metodología ágil SCRUM segmentando el desarrollo del proyecto en tareas. Para garantizar la calidad de la tarea implementada, se ha definido un ciclo de vida mediante procesos de SQA a continuación. El flujo de procesos puede verse representado en la Figura 24.

Figura 25: Ciclo de vida de una tarea SCRUM. De elaboración propia. Requisitos: Fase en la que se definen todos los requisitos funcionales y no funcionales de la tarea y cumplimientos para poderse considerar finalizada. Diseño: Modificación del diseño del sistema para incorporar la nueva funcionalidad. Construcción: Fase de desarrollo donde se implementa la tarea. Test: Creación de tests funcionales y de aceptación para verificar el cumplimiento de los requisitos definidos. Publicar: Fase en la que se publica la actualización de la aplicación una vez superado todos los tests funcionales. Ésta está formada por dos subfases. Primeramente, se publica en el programa de open testing, definido en el Apartado 12.4. Seguidamente, se analiza el rendimiento de la aplicación y, finalmente, si se considera que cumple todos los requisitos, la actualización se publica de manera global. Durante la fase de testing, se aplica un nuevo ciclo de procesos para crear los tests funcionales de la tarea. Este proceso se define en la Figura 25.

Figura 25: Ciclo de testing. ©2003-2006 Scott W. Ambler.

78

12.2. Pruebas funcionales Una parte importante del testing y validación de casos de uso a nivel funcional se realiza mediante pruebas funcionales del software. Estas pruebas funcionales no solo ayudan a verificar el comportamiento correcto de nuevos casos de uso implementados sino también a prevenir la corrupción de funcionalidades previamente implementadas. Para la validación de los casos de uso, se hacen uso de test suites. Un test suite es una agrupación de casos de pruebas cuyos objetivos pertenecen a casos de uso dependientes o con similitudes. Cada test suite está formado por tests unitarios, tests de integración y snapshots de los componentes testados para proporcionar información objetiva e independiente sobre la calidad de los componentes testados. Durante la construcción de los tests unitarios, de integración y snapshots del sistema, se ha considerado la variabilidad de los recursos externos al método u objetos testados. Por tal de anular toda variabilidad externa a los tests se han hecho uso de los siguientes recursos.

● HTTP Requests: Todas las llamadas mediante HTTP Requests han sido simuladas (mocked / stubbed) y su respuesta reemplazada por objetos de información con la misma interfaz, controlados y constantes. Para conseguir este comportamiento se ha hecho uso de decorator patterns para crear un adaptador a la librería responsable de las llamadas. Más información en el Apartado 10.4.2.

● Dependencias u objetos externos: Para simular un comportamiento deseado y constante sobre dependencias externas a los elementos testados, éstos son reemplazados por stubs con la misma interfaz y falsificando su valor de retorno por objetos predefinidos (mocks). Además, a los stubs se les puede incorporar comportamiento adicional para obtener información sobre sus llamadas y con qué argumentos han sido llamados.

● Contexto del objeto: Al testar un método de objeto, muchas veces estos interactúan con el contexto del objeto, consultando o modificando su estado. Para crear un entorno limpio para la ejecución del método, éste se extrae del objeto y se le asigna un contexto nuevo con el estado inicial deseado.

En el Anexo 4 se muestran todos los casos de pruebas implementados en el sistema.

79

12.2.1. Tests Unitarios Los tests unitarios son pruebas de software con la finalidad de testar el correcto funcionamiento de una unidad de código aislado. En este proyecto, se han considerado tests unitarios a nivel de método y de componente React. Un método es preparado para ser testado aislandolo de su contexto y simulando un nuevo contexto con datos controlados y constantes. Al ejecutar un test unitario, el método en cuestión es ejecutado y se compara su respuesta con los valores esperados. Adicionalmente, se puede consultar las modificaciones realizadas al contexto del objeto simulado y las llamadas realizadas a dependencias externas. Sobre la aplicación, se han testado los métodos de los componentes React del sistema, métodos relacionados con la gestión del token de la FIB API v.2.0, métodos de gestión de permanencia de datos y acciones de la arquitectura Flux, definida en el Apartado 10.2.1.

12.2.2. Tests de Integración Los tests de integración son tests en donde se verifica el comportamiento entre distintos módulos del sistema. Las pruebas de integración se llevan a cabo para evaluar el cumplimiento de un sistema o componente con requisitos funcionales específicos. En nuestro aplicativo, se integran tests de integración a nivel componentes de tipo vista y controlador y su interacción con los elementos de una arquitectura Flux (flux actions, reducers y stores. Definido en el Apartado 10.2.1). Adicionalmente, también se realizan tests de integración sobre la gestión del token de la FIB API v.2.0. El objetivo de estos tests es verificar las vistas del sistema junto a los casos de uso asociados. En relación a la navegabilidad entre diferentes vistas de la aplicación, no se han podido realizar tests de este estilo debido a un impedimento estructural. La navegabilidad de la aplicación es gestionada mediante el framework React Navigation. Este framework hace de puente entre el código de la aplicación, escrito en Javascript, y elementos nativos de navegación (Java en Android y C# en iOS). Al ejecutar este módulo en Jest, un framework de testing para Javascript, el módulo no puede acceder a las dependencias necesarias provocando un error en el sistema.

80

12.2.3. Snapshot Testing El snapshot testing es una herramienta muy útil para garantizar que la interfaz de usuario no no es alterada inesperadamente. Una aplicación React Native, al renderizar la cascada de componentes React, se crea un esquema XML con todos los componentes visuales (botones, imágenes, texto...), su posición y sus atributos que se muestran en la vista actual. Ahora bien, dos esquemas XML idénticos siempre generarán la misma interfaz gráfica. Partiendo de esta premisa, se pueden comparar estos esquemas con versiones previas al sistema para detectar cambios en la interfaz gráfica. Utilizando EnzymeJS, una utilidad de testing para componentes React, se ha introducido este tipo de testing en las test suites del sistema. Su función es la siguiente, una vez encapsulado el componente React a testar y asignado el contexto del objeto (estado y propiedades), mediante esta utilidad se puede generar el esquema XML de su cascada de renderizado. La primera vez que se ejecuta la prueba se genera un fichero con el esquema y si en posteriores ejecuciones se encuentra una diferencia con el fichero generado, el juego de pruebas falla y indica la diferencia entre los esquemas. Si el esquema se ha modificado intencionalmente, se puede proveer un flag al comando de ejecución de los tests para que actualice todas las snapshots del test suite.

12.3. Tests de Aceptación de Usuario A parte de los tests funcionales de un sistema, es esencial disponer de tests de aceptación de usuario. Estos tests consisten en un proceso para verificar que la solución del sistema funciona de manera óptima para el usuario directo del aplicativo. Por tal de llevar a cabo tests de aceptación de manera sencilla y eficaz, se han realizado una serie de preguntas de manera informal a un total de 12 estudiantes de la FIB con la aplicación del proyecto instalada y habiendo usado ésta un periodo de tiempo razonable. Las preguntas proponen al usuario que analicen los siguientes temas.

● Requisitos no funcionales: Preguntas en relación a la eficiencia, curva de aprendizaje, diseño y estilo de la aplicación, accesibilidad, disponibilidad de servicios, porcentaje de batería drenada, etc.

● Requisitos funcionales: Preguntas en relación a los casos de uso. Expectativas de los casos de uso a comparación con su experiencia y comportamientos no esperados.

● Experiencia de uso: Feedback en relación a la experiencia de uso con la aplicación. ● Sugerencias para mejorar: Sugerencias del usuario para mejorar la aplicación en

cualquier ámbito. ● Bugs encontrados: Reportar bugs y crashes encontrados en la aplicación.

81

Por otro lado, la aplicación cuenta con un caso de uso para contactar con el desarrollador desde la app sobre su experiencia de uso, sugerencias y bugs encontrados (UC46). Por último, la aplicación cuenta con un espacio en la Google Play Store para poder dejar valoraciones y comentarios sobre la aplicación. A día 09/10/2020, la aplicación cuenta con un total de 13 valoraciones y con una media de 4.6 sobre 5. A pesar de las buenas valoraciones, hay un bajo número de valoraciones para haber superado las 500 descargas y promocionar esta acción en la aplicación. Como conclusión, a partir de estas pruebas de aceptación de usuario se ha obtenido un mayor entendimiento de las necesidades del estudiante y se ha verificado el buen cumplimiento de los requisitos funcionales y no funcionales así como la posibilidad de corregir errores visuales para dispositivos concretos que no quedaban reportados en el registro de crashes.

12.4. Programa Open Testing Como desarrollador de una aplicación, nuestro objetivo es ofrecer la mejor experiencia de usuario a los stakeholders directos de la aplicación. Al actualizar la aplicación a versiones más recientes, se incorpora más incertidumbre a relación de errores y crashes que pueden ocurrir. Por tal de reducir este riesgo en nuestros usuarios finales, se ha hecho uso del servicio de Open Testing ofrecido por Google Play Console, la consola de aplicaciones de la Google Play. Desde el listado de la aplicación en Google Play o a través del enlace ofrecido en el repositorio de Github, cualquier usuario puede registrarse en el programa Open Testing de la aplicación del proyecto para ayudar a testar futuras actualizaciones antes de ser publicadas. Una vez el usuario se ha inscrito, al lanzar una actualización de la aplicación, estos usuarios serán los primeros en obtener la actualización. De esta forma, se pueden analizar los registros de crashes y ANRs de esta muestra de la población (mediante los recursos mostrados en el Apartado 12.5) con el objetivo de prevenir posibles errores antes del lanzamiento global de la actualización.

12.5. Seguimiento de Crashes y ANRs en Producción La Google Play Console ofrece una serie de herramientas para poder rastrear crashes y ANRs (Application Not Responding) en tiempo real sobre los usuarios activos de la aplicación. Estas herramientas son el último recurso utilizado para rastrear errores ya que estos ya están afectando a los usuarios finales de la aplicación. No obstante, es un recurso valioso para depurar ya que es imposible testar el buen funcionamiento de la aplicación en todos los diferentes dispositivos móviles, versiones de sistemas operativos o diferente información obtenida desde la FIB API v.2.0.

82

La información recolectada desde esta plataforma se muestra en las Figuras 26, 27 y 28 conteniendo los siguientes parámetros sobre cada crash.

● Ocurrencias ● Usuarios impactados ● Última ocurrencia ● Versiones Android afectadas ● Versiones de la aplicación afectadas ● Dispositivos afectados ● Registro del error

Figura 26: Listado de crashes y ARNs de la aplicación del proyecto. Extraído de la Play Console.

Figura 27: Gráficas de parámetros de un crash. Extraído de Google Play Console.

Figura 28: Registro de un crash seleccionado. Extraído de Google Play Console.

83

13. Instalación y Ejecución del Sistema Para facilitar la instalación a los usuarios, utilizamos la Google Play Store para distribuir el aplicativo en sistemas Android. Con las herramientas que nos ofrece Google, el usuario puede instalar fácilmente la aplicación y recibir actualizaciones automáticas en segundo plano. Requisitos para instalar y ejecutar la aplicación:

● Dispositivo móvil con Android 5 o superior ● Tener instalado Google Play Services (Instalado por defecto en la mayoría de

distribuciones Android) ● Disponer de conexión a internet

Pasos para instalar y ejecutar la aplicación (mostrados gráficamente en la Figura 29):

1. Abrir Google Play Store en el dispositivo móvil 2. Buscar “FIB el racó” 3. Ubicar la aplicación y acceder a ella 4. Presionar el botón “Instalar” para empezar la descarga 5. Una vez instalado, presionar el botón “abrir”

Figura 29: Pasos para instalar la aplicación. De elaboración propia a partir de capturas de pantalla de la Google Play Store.

84

14. Identificación de Leyes y Regulaciones Un factor importante al llevar a cabo un Trabajo Final de Grado es conocer las regulaciones que influyen el desarrollo y el producto final del proyecto. Nuestro proyecto gira entorno a la construcción de un aplicativo móvil, con lo cual, no solo hay que revisar la normativa del trabajo final de grado, sino que también, las licencias del software utilizado, las políticas de desarrolladores de la Google Play Store y las políticas de uso de las APIs utilizadas.

14.1. Normativa del Trabajo Final de Grado La Facultad de Informática de Barcelona define el marco del Trabajo Final de Grado con un documento recopilatorio con la normativa de éste [27]. Este documento se puede encontrar en el portal web de la facultad. El documento define el TFG, la carga de trabajo, las modalidades, las figuras implicadas, los hitos de evaluación, el método de evaluación, el tribunal, los contenidos de la memoria y la propiedad intelectual del proyecto. Por tal de realizar un Trabajo Final de Grado en condiciones, el proyecto ha de seguir rigurosamente las indicaciones definidas.

14.2. Licencias de Frameworks y Software Utilizados Por tal de reducir el gasto en licencias de software y garantizar el uso libre del producto, se han hecho uso únicamente de recursos con licencias de software libre permisivas [28]. A continuación, se listan los recursos utilizados en el código fuente de la aplicación y sus respectivas licencias:

● react: MIT license ● react-native: MIT license ● react-native-*: MIT license ● @react-native-community/*: MIT license ● redux: MIT license ● react-navigation: MIT license ● rn-fetch-blob: MIT license ● axios: MIT license ● querystring: ninguna license ● lodash: MIT license ● jest: MIT license ● enzyme: MIT license

La licencia MIT [29] domina sobre cualquier otra licencia de software libre. Esto se debe a su gran permisividad, dejando al desarrollador hacer un uso comercial, modificar, distribuir o hacer del recurso un uso privado con las condiciones de mantener la licencia en sus distribuciones y sin ofrecer ninguna garantía de ningún tipo.

85

14.3. Condiciones de Uso FIB API v 2.0 La API de la FIB contiene unas condiciones de uso que han de ser cumplidas por tal de registrar una aplicación utilizando esta API [30]. Éstas son las siguientes.

● No se puede usar el logo de la FIB ni el logo del Racó. En el desarrollo de este proyecto se ha evitado el uso del logo de ninguna institución. A su vez, se ha creado un logo alternativo para la aplicación que resemble el portal de la facultad. Éste se puede ver a continuación en la Figura 30.

Figura 30: Logo de la aplicación, de elaboración propia.

● La aplicación debe incluir un enlace a la API. La aplicación nombra el uso de la FIB API v.2.0 en 3 instancias diferentes. Se puede encontrar en la descripción de la aplicación de la Google Play Store y en las vistas de “inicio de sesión” y “Feedback & Bugs” de la aplicación. Enlaces incluidos.

● En ningún caso se introducirá el nombre de usuario y la contraseña del Racó

en una aplicación de terceros. Siempre se dirige a la página oficial del Racó. Tal y como está implementada la aplicación, en ningún momento se ceden las credenciales del estudiante a ésta. Para iniciar sesión en el aplicativo, se redirige al portal de la API de la facultad que posteriormente devuelve un token de sesión a la aplicación.

14.4. Políticas del Programa para Desarrolladores de Google Por tal de mejorar la seguridad, fiabilidad e innovación en la Google Play Store, Google ha lanzado una extensa lista de políticas para desarrolladores de cumplimiento obligatorio para lanzar la aplicación al mercado [31]. Cuando se publica por primera vez o se actualiza una aplicación a la Play Store, una revisión manual de la aplicación tomará efecto. Si en ésta se detecta algún incumplimiento en sus políticas, la publicación se congela hasta que el desarrollador haga las modificaciones necesarias. Los apartados más importantes de entre sus políticas del programa para desarrolladores aparecen listados a continuación. Los numerosos puntos relacionados con el comercio no son mencionados ya que la aplicación de este proyecto, El Racó - FIB, se ofrece de forma gratuita y sin anuncios asociados.

86

● Contenido restringido. En este apartado se definen normas en relación a

protección infantil, contenido inadecuado, actividades ilegales, contenido generado por usuarios, sustancias no aprobadas, etc. De inicio, no hace falta adaptar nuestra aplicación a estas medidas ya que nuestra aplicación no está orientada a niños, no muestra ningún contenido inadecuado ni actividad ilegal, no permite la generación de contenido público por parte del usuario y no ofrece ningún servicio de venta de productos.

● Suplantación de identidad. No está permitido imitar otras aplicaciones o falsamente asociarse con otra compañía. Por tal de cumplir este apartado, se ha asegurado de dejar clara la no oficialidad de esta aplicación en la descripción de la Play Store y en la vista de inicio de sesión de la aplicación. Además, se ha creado un logo para la aplicación suficientemente único en relación al de la FIB.

● Propiedad intelectual. La aplicación y su contenido han de ser originales, tener las autorizaciones correspondientes y ofrecer lo que prometen. En nuestra aplicación, toda la información se extrae de la FIB API v.2.0. Siguiendo las políticas de uso de la API, definidas en el Apartado 14.3, obtenemos la autorización necesaria para hacer uso de este recurso. Además, siempre que el usuario disponga de una cuenta de estudiante de la FIB, tendrá acceso a todos los servicios anunciados en la descripción de la Play Store.

● Privacidad, elementos engañosos y uso inadecuado de dispositivos. Debe ser transparente en la forma en que maneja los datos del usuario. Eso significa revelar el acceso, la recopilación, el uso y el intercambio de datos de su aplicación, y limitar el uso de los datos a los fines revelados. Además, los permisos requeridos por la aplicación han de ser coherentes con su funcionalidad. Para que nuestra aplicación sea transparente con el usuario, el manejo de los datos vienen especificados en la política de privacidad de la aplicación, definida en el apartado 14.5. Y, en relación a los permisos requeridos, la aplicación solo hace uso de aquellos que son fundamentales para su funcionamiento. Tanto la política de privacidad de la app como los permisos utilizados, son visibles desde la ficha técnica de la aplicación en la Play Store.

● Ficha de Play Store y promoción. No están permitidas tácticas desleales para atraer a los usuarios. Esto incluye promociones engañosas, metadata adicional en la descripción de la aplicación o manipular las valoraciones u opiniones de la Play Store. Mientras no se realicen las acciones mencionadas, la aplicación estará en regla con este apartado.

● Spam y funcionalidad mínima. La experiencia que ofrece la aplicación ha de cumplir las expectativas de los usuarios. La aplicación de este proyecto cumple con las funcionalidades promocionadas en la descripción y el metadata de la Play Store.

● Software malicioso. La aplicación no ha de contener código que podría poner en riesgo la seguridad de un usuario, de sus datos o de sus dispositivos. Gracias al sistema de autenticación por tokens de la FIB API v.2.0, la aplicación solo guarda localmente el token de sesión del usuario. En ningún momento se comparte este token con otro dominio que no sea el de la API de la facultad y todas las transacciones se hacen sobre un canal encriptado HTTPS con el fin de proteger al usuario.

87

14.5. Política de Privacidad de la App A condición de publicar cualquier aplicación en la Google Play Store y la App Store, se requiere proporcionar un enlace web en el que se definan las condiciones de uso junto a la política de privacidad de la aplicación. Para la aplicación de este proyecto, El Racó - FIB, se ha utilizado una plantilla ofrecida por privacypolicytemplate.net la cual recoge los apartados necesarios para la base del documento. A continuación, se lista los apartados de la política de privacidad aplicada a la aplicación junto a un pequeño resumen.

● Recolección de Información y uso. Por tal de ofrecer nuestros servicios, es posible que se requiera de información que pueda identificarle. Esta información se almacena localmente y no es recolectada por nosotros.

● Datos recopilados. En caso de error en la aplicación, se recopilan datos e información (a través de productos de terceros) en su teléfono llamados Log Data. Este Log Data puede incluir información como el nombre del dispositivo, la versión del sistema operativo, la configuración de la aplicación, la hora y fecha del uso del servicio y otras estadísticas.

● Cookies. Este Servicio no utiliza cookies [32] explícitamente. Sin embargo, la aplicación puede utilizar código o librerías de terceros que pueden utilizar cookies para recopilar información y mejorar sus servicios. Tiene la opción de aceptar o rechazar estas cookies y saber cuándo se envía una cookie a su dispositivo. Si decide rechazar nuestras cookies, es posible que no pueda utilizar algunas partes de este servicio.

● Proveedores de servicio. Podemos recurrir a empresas e individuos de terceros por las siguientes razones: para facilitar nuestro servicio; para proporcionar el servicio en nuestro nombre o para ayudarnos a analizar cómo se utiliza nuestro servicio.

● Seguridad. Valoramos su confianza al proporcionarnos su información personal, por lo que nos esforzamos por utilizar medios comercialmente aceptables para protegerla. Pero recuerde que ningún método de transmisión por Internet o método de almacenamiento electrónico es 100% seguro y confiable y no podemos garantizar su absoluta seguridad.

● Enlaces a otros dominios. Esta aplicación puede contener enlaces a páginas de terceros. Estas páginas no están dirigidas por nosotros, por consiguiente, recomendamos revisar las políticas de privacidad de las páginas mencionadas.

● Privacidad de los niños. Los servicios proporcionados por la aplicación no están enfocados a menores de 13 años y no se recolecta información de este grupo con previo conocimiento.

● Modificaciones en la política de privacidad. Se reserva el derecho a cambios en las políticas de privacidad de la aplicación y serán vigentes al instante de ser actualizada la página.

Se puede consultar la política de privacidad de la aplicación con más detalle en el Anexo 5.

88

15. Planificación Final y Cambios Debido a obstáculos en el desarrollo del proyecto con planes de mitigación con comportamiento no predecido, la planificación temporal ha sido modificada drásticamente de lo planificado inicialmente. A pesar de ello, se ha llegado a una solución manteniendo el número de horas invertidas en el proyecto y cumpliendo los objetivos planteados inicialmente.

15.1. Descripción del problema La tarea definida en el Apartado 5.2.7., “Port a iOS”, requiere llevar la aplicación a la plataforma iOS. Para desarrollar un proyecto iOS en React Native, nuestro framework de desarrollo, hace falta tener instaladas las dependencias de Xcode IDE para poder compilar la aplicación y ejecutarla en un emulador [33]. A efectos prácticos, hace falta tener un ordenador Apple con OSX para desarrollar una aplicación iOS ya que Xcode solo es compatible con este sistema operativo [34]. En la planificación inicial, se planteó utilizar los laboratorios de la Facultad de Informática de Barcelona ya que disponen de ordenadores Apple [35]. El problema empezó cuando España entró en estado de alarma el 14 de Marzo del 2020 debido a la pandemia de COVID-19 [36]. La facultad anuló las clases presenciales y se cerraron los laboratorios durante todo el semestre [37]. Dada la situación, se ejecutó el plan de mitigación de riesgos R6 definido en el Apartado 6. Este plan predecía un posible cierre de los laboratorios de la facultad y proponía como solución instalar Hackintosh, una versión de OSX modificada para poder ser ejecutada en hardware no autorizado [38]. Hackintosh fue instalado en una máquina virtual pero ésta no reconocía la tarjeta gráfica de Nvidia a pesar de instalar los drivers correspondientes. Este problema hacía imposible realizar acciones como utilizar el emulador o utilizar fluidamente aplicaciones gráficas como el editor de texto Visual Studio Code.

89

15.2. Soluciones Planteadas Con el objetivo de solventar el problema, se han planteado las siguientes soluciones.

15.2.1. Reorganizar el orden de ejecución de las tareas Ya que al anunciar el cierre de los laboratorios de la facultad, explicado en el apartado 15.1, no se anunció una fecha exacta para reabrir las instalaciones, una posibilidad podría haber sido reorganizar el orden de ejecución de las tareas del proyecto con la esperanza de una temprana apertura de los laboratorios. De esta manera, no se crearían retrasos ni significativas modificaciones en la planificación. Esta solución fue rápidamente descartada debido a la incertidumbre sobre la fecha final al estado de alarma. Otro inconveniente apareció al analizar las dependencias entre tareas, definidas en el apartado 5.3. La tarea bloqueada estaba situada muy al final del árbol de dependencias por lo que, reordenando las tareas sin dependencias entre ellas, solo se podría ganar un tiempo muy limitado.

15.2.2. Aplazar las tareas afectadas Otra solución al problema planteado podría haber sido aplazar parte del desarrollo del proyecto. El proyecto se pausaría y se retomaría una vez los laboratorios se abran a los estudiantes. Esta solución obliga retrasar el turno de lectura a octubre de 2020. De nuevo, se plantean problemas similares a la solución 15.2.1. Había incertidumbre sobre la fecha de apertura de los laboratorios y, debido a las vacaciones de la facultad, las instalaciones permanecen cerradas durante el mes de agosto.

15.2.3. Reemplazar las tareas afectadas Una solución más drástica podría haber sido abandonar las tareas implicadas y sustituirlas con nuevas tareas. En esta solución, se abandonaría el objetivo del proyecto definido en el apartado 3.1.5, “port a iOS”, y se podrían reforzar otros objetivos o crear uno de nuevo. Esta solución es demasiado drástica y afectaría tanto a la planificación del proyecto como a los objetivos del mismo.

15.2.4. Aplazar las tareas afectadas y añadir nuevas Se aplazará el turno de lectura a octubre de 2020. Como alternativa al uso de los laboratorios de la FIB, se puede buscar una persona externa al proyecto que pueda prestar un ordenador Apple durante un periodo de tiempo corto. Ya que el peso inicial de las tareas afectadas es muy elevado, éstas se pueden reducir y se pueden crear de nuevas para compensar las horas del proyecto.

90

15.3. Solución Adoptada Por tal de solventar el problema mencionado en el apartado 15.1, se ha aplicado la solución definida en el apartado 15.2.4. Se ha podido encontrar a un familiar de un relativo cercano dispuesto a prestar su ordenador portátil Apple durante un periodo de 16 días a finales de verano. Dada esta oportunidad, se ha decidido seguir con todos los objetivos del proyecto planteados. Para ello, se ha reducido drásticamente el peso de las tareas afectadas para encajarlas en las semanas con acceso a un Macbook. Además, se eliminará la tarea T7.5, “publicar aplicación”, definida en el apartado 5.2.5. Se ha tomado esta decisión ya que se considera que la aplicación iOS podría carecer de funcionalidades o no podría estar testada lo suficiente. Además, la creación de una cuenta de desarrollador de Apple no es un proceso directo. Se requiere de tiempo para que sea validada. Dato que se desconocía al iniciar el proyecto. Para compensar el peso de las tareas modificadas y eliminadas, se han creado 4 nuevas subtareas a la tarea T6, “Expandir funcionalidades”. Éstas se pueden ver en detalle en el apartado 15.4.

15.4. Descripción de Tareas Finales A continuación, las tareas añadidas en la planificación final. T6 Expandir funcionalidades

● T6.5 Consultar programas de movilidad: Los usuarios podrán consultar todos los planes de movilidad que la facultad ofrece, listando las universidades inscritas a cada plan de movilidad. Además, tendrán acceso a toda la información necesaria acerca de la movilidad.

● T6.6 Consultar próximas lecturas: Los usuarios de la aplicación podrán consultar de forma sencilla las próximas lecturas de TFG o TFM de la facultad junto a los datos técnicos de éstas.

● T6.7 Consultar noticias de la UPC: La aplicación permitirá a los usuarios consultar las noticias de la UPC.

● T6.8 Modificar horario: A menudo, los estudiantes de la FIB realizan cambios en su horario no oficializados. Se añadirá a la aplicación la posibilidad de modificar el horario libremente.

T10 Solventar bugs

● T10.1 Arreglar bugs de la aplicación: Se arreglarán los bugs de la aplicación descubiertos a partir de todos los métodos de testing implementados.

91

Con las modificaciones mencionadas en el apartado 15.3, las tareas finales del proyecto, junto a sus pesos y dependencias, se pueden observar en la Tabla 14. Se ha modificado el peso dedicado a cada tarea para que las horas totales dedicadas al proyecto no se alteren.

92

Tabla 14. Tareas finales del proyecto. De elaboración propia.

15.5. Planificación Temporal Final Debido al repentino obstáculo, definido en el Apartado 15.1, y al fallo en la prevención de dicho obstáculo, se tuvo que pausar el desarrollo del proyecto hasta adoptar una posible solución. Se decidió aplazar la fecha límite del proyecto al siguiente turno de lectura, octubre 2020/2021 para dar tiempo a incorporar las medidas definidas en el Apartado 15.3. La planificación temporal final queda representada en la Figura 31 de a continuación.

Figura 31: Diagrama de Gantt final. De elaboración propia.

93

Como se puede observar en la Figura 31, se conserva la estructura de 4 sprints con 3 tres semanas de duración de la planificación inicial. Esto implica que la carga de trabajo por día no ha sido alterada. La estimación de carga de trabajo media es de 4,3 horas diarias incluyendo fines de semana.

15.6. Desviaciones en el Presupuesto Debido a que todas las tareas creadas, eliminadas y modificadas tienen asignadas los mismos recursos humanos y el total de horas no ha sido modificado, el presupuesto en recursos humanos no ha sido alterado a comparación con la planificación inicial, definida en el apartado 7.1. El desglose de los gastos de recursos humanos puede verse en detalle en la Tabla 15 a continuación.

Tabla 15. Gastos finales en recursos humanos. De elaboración propia.

94

En relación a los gastos en licencias, debido a la eliminación de la tarea T7.5, “publicar la aplicación”, el gasto de la licencia de Apple Developer, definida en el apartado 7.2.2, ya no es necesario. Si contamos con el 15% adicional en contingencias, la desviación se calcula a partir de la siguiente fórmula.

Desviación = 90 * 1.15 = 103,50 € A fines prácticos, el coste total del proyecto se reducirá en 103,50 € que podrán ser invertidos en futuros proyectos.

15.7. Metodología Final La metodología del proyecto no ha sido modificada durante el desarrollo del mismo. Un marco de trabajo ágil encaja muy bien con la naturaleza del proyecto y es gracias a ésta que se ha podido solucionar el obstáculo, definido en el apartado 15.1, de la manera en la que se ha hecho. Se han conservado los 4 sprints de desarrollo con 3 semanas cada una modificando únicamente las fechas de inicio y las tareas asociadas a las últimas dos. Tres semanas de sprint resulta una duración apropiada a la escala del proyecto ya que, de esta manera, el sprint acumula suficientes tareas finalizadas para hacer de los review y retrospective meetings un acto relevante.

16. Conclusiones Las conclusiones de este proyecto pueden definirse positivamente. Todos los objetivos marcados al inicio del proyecto y definidos en el Apartado 3.1 han sido cumplidos satisfactoriamente. Durante el proyecto, se ha abierto el acceso al repositorio del aplicativo, se ha documentado el código de la aplicación para facilitar futuras modificaciones (Anexo 1 para acceder al repositorio), se ha rediseñado por completo la gestión de la información y el estado del sistema (definido en el Apartado 10.2) así como la interfaz visual de la aplicación (visible en el Apartado 10.6), se han añadido funcionalidades adicionales (definidas en los apartados 5.2.6 y 15.4 y verificadas mediante testing y validación en el Apartado 12) y se ha refactorizado la aplicación para facilitar la tarea de crear tests funcionales en profundidad (definidos en el Apartado 12.2). Adicionalmente, se ha cumplido el objetivo “Port a iOS” a pesar de haberse visto afectado gravemente por obstáculos en la fase de desarrollo (repositorio de la aplicación iOS en el Anexo 2). Más detalle sobre los obstáculos en el Apartado 15.

95

16.1. Competencias Técnicas Durante el desarrollo de este Trabajo Final de Grado, se ha prestado especial énfasis en trabajar las siguientes competencias técnicas de la especialidad de ingeniería en software.

CES1.2: Dar solución a problemas de integración en función de las estrategias, de los estándares y de las tecnologías disponibles. [Bastante] En este proyecto, se han solucionado problemas de integración a relación de estrategias, estándares y tecnologías disponibles. Primeramente, se ha diseñado un sistema capaz de gestionar las identidades de los usuarios mediante el estándar Oauth 2.0 [40] para interactuar con la FIB API v.2.0. Además, de esta API se han extraído y formateado la información que forma el modelo de datos de la aplicación. En segundo lugar, para obtener las noticias de la UPC desde nuestro aplicativo, se ha hecho uso del canal RSS de la FIB y se han transformado las noticias a formato JSON, un estándar de data formatting. Además, se ha hecho uso de patrones de diseño para solventar problemas de integración. Entre ellos, destacamos la solución propuesta para pasar información al componente de navegación creado por React Navigation. Más detalles en el Apartado 10.4, “Patrones de Diseño”.

CES1.3: Identificar, evaluar y gestionar los riesgos potenciales asociados a la construcción de software que pudiesen presentarse. [Bastante] Durante la fase inicial de este proyecto, se han definido los riesgos que pueden surgir durante el desarrollo del proyecto, definidos en el Apartado 3.2, “Obstáculos y Riesgos”. A su vez, se ha estimado la probabilidad de suceso y se han diseñado planes de mitigación para reducir el impacto causado. Definidos en el Apartado 6, “Gestión de Riesgos y Obstáculos”. Durante el desarrollo del proyecto, se ha presenciado un obstáculo cuyo plan de mitigación no pudo ejecutarse de la forma esperada. A pesar de ello, se ha llegado a una solución manteniendo el número total de horas dedicadas. Más información en el apartado 15, “Planificación Final y Cambios”.

CES1.4: Desarrollar, mantener y evaluar servicios y aplicaciones distribuidas con soporte de red. [Bastante] La aplicación desarrollada en este proyecto, “El Racó - FIB”, cae en la categoría de aplicación distribuida ya que los usuarios finales, los estudiantes de la FIB, han de obtener una copia del aplicativo para interactuar con este servicio. Esta gestión se releva a la Google Play Store. Más información sobre la estructura física de la aplicación en el Apartado 10.1, “Arquitectura Física”.

96

En relación a la mantenibilidad, la Play Store ofrece herramientas para actualizar la app de manera invisible a los stakeholders directos. Con esto en perspectiva, se plantea el desarrollo y publicación de actualizaciones como un proceso iterativo. El objetivo de este proyecto es ofrecer herramientas para poder ofrecer soporte al aplicativo a largo plazo. El código fuente del sistema ha sido publicado bajo una licencia MIT [29] y se ha documentado el código para facilitar la tarea de desarrollo. Cualquier estudiante de la FIB puede expandir las funcionalidades de la aplicación así como solventar posibles errores de código o compatibilidad que puedan surgir. Enlace del repositorio del proyecto en el Anexo 1. El aplicativo se evalúa mediante un proceso de testing y validación completo. Más información en el apartado 12, “Testing y Validación”. Además, la Google Play Console, el gestor de aplicaciones de la Play Store, ofrece herramientas potentes para analizar la estabilidad de la aplicación, más detalles en el Apartado 12.5, “Seguimiento de Crashes y ANRs en Producción” así como el rendimiento en cifras a relación de descargas y usuarios activos del sistema.

CES1.7: Controlar la calidad y diseñar pruebas en la producción de software. [En profundidad] Una parte importante del desarrollo de sistemas de software es garantizar su calidad y verificar los requisitos del sistema especificados. En este proyecto, por tal de alcanzar este fin en profundidad, se ha definido una metodología de Software Quality Assurance especificada en el Apartado 12.1, “Software Quality Assurance”. En esta metodología se define el proceso de especificación, diseño, desarrollo y testing de las tareas y el proceso para publicar actualizaciones del aplicativo utilizando programas open testing. Para controlar la calidad, se han desarrollado pruebas funcionales con un total de 90 tests unitarios, 36 pruebas de integración y 93 snapshots capturadas. Más detalle en el Apartado 12.2, “Pruebas Funcionales”. Adicionalmente, se han implementado tests de aceptación de usuario para verificar que el sistema funciona de manera óptima para el usuario directo del aplicativo, los estudiantes de la FIB. Más información en el Apartado 12.3, “Tests de Aceptación de Usuario”. Como consecuencia de este proceso de testing, se han podido solventar muchos bugs del sistema y mejorar la usabilidad de la aplicación así como la implementación de sugerencias de los usuarios finales.

CES2.1: Definir y gestionar los requisitos de un sistema software. [En profundidad] La Ingeniería de Requisitos es el proceso de obtener y gestionar los requisitos sobre las funcionalidades y la calidad de nuestro sistema. Este proceso es esencial para definir un sistema software y se le ha dado gran importancia en el desarrollo de este proyecto. La definición de requisitos funcionales y no funcionales se puede ver en profundidad en los Apartados 9.1, “Requisitos Funcionales”, y 9.2, “Requisitos no Funcionales”.

97

En relación a la gestión y validación de requisitos, se puede ver definida en el Apartado 4, “Metodología y Rigor”, y más en detalle sobre la validación de requisitos en el Apartado 12, “Testing y Validación”.

16.2. Conclusiones Personales El desarrollo de este proyecto ha aportado mucho en lo personal. Verdaderamente me ha gustado mucho llevar a luz esta aplicación exitosamente. No solo por el hecho de haber creado un recurso útil para los estudiantes de la FIB sino también por los retos que ha supuesto desarrollar la aplicación. Además, se ha tenido la oportunidad de aprender sobre procesos y tecnologías altamente demandadas en el mercado actual. Destaco el testing y validación de sistemas mediante pruebas funcionales, el uso de frameworks muy populares como React y React Native, el descubrimiento sobre arquitecturas Flux y poder aplicar conocimientos teóricos adquiridos durante el grado en un proyecto real, como la especificación y diseño de un sistema o la interacción con una API REST. Juntar todos los conocimientos adquiridos durante la carrera y el desarrollo del proyecto para formar esta aplicación me ha hecho ver que tengo las capacidades necesarias para participar en proyectos TIC y espero ser de utilidad en los proyectos que estén por venir.

16.3. Trabajo Futuro Actualmente, el desarrollo de la aplicación del proyecto se considera terminado. No obstante, no se descarta la posibilidad de expandir sus funcionalidades en un futuro cercano. Al ser una aplicación con su código fuente público, cualquier persona puede colaborar en proyectos futuros sobre la aplicación. Nuevos casos de uso pueden surgir a partir de la inclusión de nueva información en la FIB API v.2.0, de la creatividad del desarrollador o por necesidad de los usuarios finales. En cuanto a mantenimiento, hará falta hacer iteraciones de desarrollo para mantener la aplicación actualizada con las tecnologías. Un ejemplo puede ser la próxima versión de Android, Android 11, en donde se va a dejar de dar soporte el sistema de almacenamiento que utiliza la app para descargar ficheros. Adicionalmente, se espera crear futuras iteraciones para solventar bugs que vayan surgiendo con el tiempo. Es por eso que planeo dar soporte a la aplicación personalmente por un mínimo de 3 años.

98

Anexo 1: Repositorio Github de la Aplicación Android Repositorio open source del aplicativo Android del proyecto: https://github.com/joan3pastor/el-raco-fib

Anexo 2: Repositorio Github de la Aplicación iOS Repositorio open source del aplicativo iOS del proyecto: https://github.com/joan3pastor/el-raco-fib-ios

Anexo 3: Descarga de la Aplicación Mediante el siguiente enlace, se puede descargar el aplicativo Android desarrollado en este proyecto desde la Google Play Store. https://play.google.com/store/apps/details?id=com.fibupc

Anexo 4: Tabla de tests funcionales

A continuación, se definen todos los tests unitarios implementados en el proyecto. HORARIO (componente)

- Testing getData method

+ fetches 'aules' and 'classes' correctly.

- Testing parseAules method

+ parses 'aules' correctly.

- Testing filterAules method

+ filters 'aules' correctly.

- Testing getIndexHora method

+ generates index for a given hour string.

- Testing getDia method

+ returns the index of the day for the given string.

AVISOS (componente)

- Testing renderTabs method

+ renders tabs with no subjects

+ renders tabs with one subject

+ renders tabs with five subjects

- Testing getAvisos method

+ filters and orders avisos from an empty list of avisos

+ filters avisos from a list of 1 'avis' of subject 'ASDP' when 'Tots'

tab is selected

99

https://github.com/joan3pastor/el-raco-fib

https://github.com/joan3pastor/el-raco-fib-ios

https://play.google.com/store/apps/details?id=com.fibupc

+ filters avisos from a list of 1 'avis' of subject 'ASDP' when 'ASDP'

tab is selected

+ filters avisos from a list of 1 'avis' of subject 'ASDP' when 'ROB'

tab is selected

- Testing formatDay method

+ formats '2020-04-12T21:08:09' into 'DD/MM/AAAA hh:mm'

+ formats '2020-06-29T11:48:50' into 'DD/MM/AAAA hh:mm'

- Testing decodeSC method

+ for each encoded string character, it generates de decoded character

- Testing loadingComp method

+ renders loading component correctly

- Testing updateAvisos method

+ fetches new avisos and updates the state of redux store

+ displays alert message when GET request not returned code 200[OK]

- Testing renderAvis method

+ renders correctly an 'avis' without attachments

+ renders correctly an 'avis' with attachments

- Testing adjuntos method

+ renders correctly the attachment section when there is no attachments

+ renders correctly the attachment section when there is one attachment

+ renders correctly the attachment section when there is more than one

attachment

- Testing modal method

+ renders correctly the extended view (modal) of an 'avis' without

attachments

+ renders correctly the extended view (modal) of an 'avis' with one

attachment

+ renders correctly the extended view (modal) of an 'avis' with more

than one attachment

ASIGNATURAS (componente)

- Testing renderProfs method

+ returns a render list of professors sorted and classified by

'is_responsable'

+ returns a render list of professors with the size defined in settings

- Testing createCards method

+ returns a rendered list of cards (size=1) with its modal view with

'/guia' still not fetched


'/guia' still not fetched


'/guia' fetched

- Testing fetchData method

+ does nothing when called more than one time

+ fetches the '/guia' of each taken subject' for first time and does

nothing when request fails

+ fetches the '/guia' of each taken subject' for first time and updates

component state

NOTICIAS (componente)


+ returns an empty list when providing an empty list of 'noticies'

+ extracts and maps the relevant data from a list of unparsed 'noticies'

(list size = 1)

100

+ extracts and maps the relevant data from a list of unparsed 'noticies'

(list size = 11)

- Testing renderNoticia method

+ renders the preview of the notice

- Testing refreshData method

+ fetches new notices and updates the state of redux store

+ fetches new notices with bad response and notifies user

EVENTOS (componente)


+ formats '2020-04-12T21:08:09' into '12T21:08:09/04/2020'

+ formats '2020-06-29T11:48:50' into '29T11:48:50/06/2020'

- Testing filterExamens method

+ returns 0 'examens' when there are no subjects

+ returns 'examens' from the active subjects

- Testing filterEvents method

+ returns 0 'events' when <reduxstore>.events is empty

+ returns 'events' parsed from <reduxstore>.events

- Testing filterByDay method

+ returns 0 'events' because the 'event' provided is too old

+ returns 0 'events' because the date from the 'event' provided is in

more than 3 months from now

- Testing getEvents method

+ gathers all events from filterExamens and filterEvents and filters

them by day

NOTAS (componente)

- Testing calculateAVG method

+ returns average of a subject with no entries

+ returns average of a subject with entries

- Testing calculateFinal method

+ returns final score of a subject with no entries

+ returns final score of a subject with entries

- Testing calculateProgress method

+ returns the progress of a subject with no entries

+ returns the progress of a subject with entries

- Testing verifyAndSaveForm method

+ returns error when entry name not inserted

+ returns error when entry weight not inserted

+ returns error when entry weight out of range (0 - 1)

+ returns error when the subject total weight surpases 100%

+ returns error when entry score out of range (0 - 10)

+ saves new entry when data is valid

AULAS (componente)


+ fetches 'aules' and 'classes' correctly

- Testing parseAules method

+ parses 'aules' correctly

- Testing filterAules method

+ filters 'aules' correctly

- Testing getIndexHora method

+ generates index for a given hour string

- Testing getDia method

101

+ returns the index of the day for given string

MOVILIDAD (componente)


+ fetches mobility offers correctly

- Testing getPaisos method

+ returns sorted list of countries found in mobility offers

- Testing getProgrames method

+ returns sorted list of programs found in mobility offers

- Testing filterOfertes method

+ returns a list of offers that match country='Francia' and

program='ERASMUS+'

+ returns a list of all offers when matched with country='Todos' and

program='Todos'

LECTURAS TFG TFM (componente)


+ fetches next 'lectures' correctly

- Testing getPlans method

+ extracts all 'plans' found in 'lectures' data

- Testing filterLectures method

+ filters `lectures` by selected `pla`

+ Does nothing when `pla` == `Tots`. (lectures = lecturesFiltered)


+ formats avis.date (2020-04-12T21:08:09) into 'DD/MM/AAAA hh:mm

+ formats avis.date (2020-06-29T11:48:50) into 'DD/MM/AAAA hh:mm

ACTUALIZAR TOKEN

- Testing updateToken global method

+ returns current token if redux token is still valid

+ returns current token if token saved in asyncStorage is still valid

+ returns new token if current token from redux store and asyncStorage

have expired and updates the token of those stores

+ returns 0 when token has expired but request returns an error

NOTIFICACIONES AVISOS

- Testing comparator method from NotificationsAvisos class

+ returns True when two 'avisos' are the same

+ returns False when two 'avisos' aren't the same

- Testing checkSettings method from NotificationsAvisos class

+ returns 1 if 'notificationsAvisos' are enabled on saved settings

+ returns -1 if 'notificationsAvisos' are disabled on saved settings

- Testing sendNotification method from NotificationsAvisos class

+ calls localNotification from this.PushNotification object with the

correct parameters

- Testing execute method from NotificationsAvisos class

+ gets 'avisos' from local device storage and parses 'avisos' from FIB's

API. When there is a new one, sends a new notification about it

+ gets 'avisos' from local device storage and parses 'avisos' from FIB's

API. When there are more than one new 'avis', sends a new notification

for each of them

102

Sobre tests de integración, se ha desarrollado como mínimo un test de este tipo por cada vista del sistema. Estos tests de integración validan el correcto funcionamiento de los casos de uso integrando las vistas del sistema, sus respectivos controladores y la interacción con las stores del sistema. Adicionalmente, a cada cambio de estado en la vista, se captura una snapshot del esquema XML de la vista renderizada. A continuación, se listan todas las vistas del sistema testadas en los tests de integración. - Asignaturas (vista para asignaturas cursadas, ficha técnica y guía docente) - Aulas (vista para buscar aulas y laboratorios de la FIB vacíos) - Avisos (vista para obtener avisos del estudiante, filtrarlos y actualizarlos) - Drawer (componente de navegación) - Eventos (vista para consultar festividades y próximos exámenes) - Enlaces Externos (vista para obtener enlaces de interés para el estudiante) - Feedback (vista para proporcionar feedback, bugs y valorar la aplicación) - Horario (vista para consultar el horario del estudiante) - Labs (vista para visualizar la ocupación de los laboratorios) - Lecturas TFG TFM (vista para consultar próximas lecturas) - Movilidad (vista para obtener información sobre movilidad y planes con universidades) - Notas (vista para gestionar notas del estudiante) - Noticias (vista para consultar noticias de la FIB y la UPC) - Salas Bibl. (vista para consultar la ocupación o reservar una aula de la bibl. BRGF)

103

Anexo 5. Política de Privacidad de la Aplicación

FIB UPC (El Racó) - Android App Privacy Policy

Joan Marc Pastor built the FIB UPC (El Racó) app over FIB's oAuth api (https://api.fib.upc.edu/) as a Free app. This SERVICE is provided at no cost and is intended for use as is.

This page is used to inform visitors regarding my policies with the collection, use, and disclosure of Personal Information if anyone decided to use my Service.

If you choose to use my Service, then you agree to the collection and use of information in relation to this policy. The Personal Information that I collect is used for providing and improving the Service. I will not use or share your information with anyone except as described in this Privacy Policy.

The terms used in this Privacy Policy have the same meanings as in our Terms and Conditions, which is accessible at FIB UPC (El Racó) unless otherwise defined in this Privacy Policy.

Information Collection and Use

For a better experience, while using our Service, I may require you to provide us with certain personally identifiable information. The information that I request will be retained on your device and is not collected by me in any way.

The app does use third party services that may collect information used to identify you.

Link to privacy policy of third party service providers used by the app

● Google Play Services

Log Data

I want to inform you that whenever you use my Service, in a case of an error in the app I collect data and information (through third party products) on your phone called Log Data. This Log Data may include information such as your device Internet Protocol (“IP”) address, device name, operating system version, the configuration of the app when utilizing my Service, the time and date of your use of the Service, and other statistics.

104

https://www.google.com/policies/privacy/

Cookies

Cookies are files with a small amount of data that are commonly used as anonymous unique identifiers. These are sent to your browser from the websites that you visit and are stored on your device's internal memory.

This Service does not use these “cookies” explicitly. However, the app may use third party code and libraries that use “cookies” to collect information and improve their services. You have the option to either accept or refuse these cookies and know when a cookie is being sent to your device. If you choose to refuse our cookies, you may not be able to use some portions of this Service.

Service Providers

I may employ third-party companies and individuals due to the following reasons:

● To facilitate our Service; ● To provide the Service on our behalf; ● To perform Service-related services; or ● To assist us in analyzing how our Service is used.

I want to inform users of this Service that these third parties have access to your Personal Information. The reason is to perform the tasks assigned to them on our behalf. However, they are obligated not to disclose or use the information for any other purpose.

Security

I value your trust in providing us your Personal Information, thus we are striving to use commercially acceptable means of protecting it. But remember that no method of transmission over the internet, or method of electronic storage is 100% secure and reliable, and I cannot guarantee its absolute security.

Links to Other Sites

This Service may contain links to other sites. If you click on a third-party link, you will be directed to that site. Note that these external sites are not operated by me. Therefore, I strongly advise you to review the Privacy Policy of these websites. I have no control over and assume no responsibility for the content, privacy policies, or practices of any third-party sites or services.

Children’s Privacy

These Services do not address anyone under the age of 13. I do not knowingly collect personally identifiable information from children under 13. In the case I discover that a child under 13 has provided me with personal information, I immediately delete this from our servers. If you are a parent or guardian and you are aware that your child has provided us with personal information, please contact me so that I will be able to do necessary actions.

105

Changes to This Privacy Policy

I may update our Privacy Policy from time to time. Thus, you are advised to review this page periodically for any changes. I will notify you of any changes by posting the new Privacy Policy on this page. These changes are effective immediately after they are posted on this page.

Contact Us

If you have any questions or suggestions about my Privacy Policy, do not hesitate to contact me.

This privacy policy content was generated at privacypolicytemplate.net and modified/generated by App Privacy Policy Generator

106

https://privacypolicytemplate.net/

https://app-privacy-policy-generator.firebaseapp.com/

https://app-privacy-policy-generator.firebaseapp.com/

Tablas y Figuras

Tablas Tabla 1: Datos de aplicaciones existentes 12 Tabla 2: Peso y dependencias de tareas 24 Tabla 3: Recursos y tareas asociadas 25 Tabla 4: Gestión de riesgos y obstáculos 27 Tabla 5: Retribución media por perfil en Barcelona 29 Tabla 6: Gastos en recursos humanos 39 Tabla 7: Gastos en Hardware 30 Tabla 8: Costes de licencias 30 Tabla 9: Gastos adicionales 31 Tabla 10: Contingencias 31 Tabla 11: Partida de imprevistos 32 Tabla 12: Presupuesto final 32 Tabla 13: Consumo Energético 34 Tabla 14: Tareas finales del proyecto 92 Tabla 15: Gastos finales en recursos humanos 94

Figuras Figura 1: Tiempo dedicado en dispositivos móviles 12 Figura 2: Capturas de Pantalla extraídas de la aplicación Racó de la Fib 13 Figura 3: Capturas de Pantalla extraídas de la aplicación El Racó 14 Figura 4: Capturas de Pantalla extraídas de la aplicación El Racó - FIB 15 Figura 5: Diagrama de Gantt inicial 26 Figura 6: Diagrama de casos de uso (1 de 2) 35 Figura 7: Diagrama de casos de uso (2 de 2) 36 Figura 8: Interacción física del sistema 63 Figura 9: Flujo de Flux 65 Figura 10: Diagrama simplificado de componentes React 67 Figura 11: Modelo de datos UML de la aplicación (parte 1 de 2) 69 Figura 12: Modelo de datos UML de la aplicación (parte 2 de 2) 70 Figura 13: Bottom tab navigator de la aplicación del proyecto 70 Figura 14: Drawer de la aplicación del proyecto 71 Figura 15: Vistas de inicio de sesión y horario del estudiante en formato extendido y minimalista 71 Figura 16: Vistas de lista de avisos del estudiante, detalles de aviso y próximos eventos 72 Figura 17: Vistas de noticias de la UPC y FIB, detalles de notícia y ocupación de laboratorios de la FIB 72

107

Figura 18: Vistas de asignaturas cursando, guía docente de una asignatura y ocupación de salas de la biblioteca BRGF 73 Figura 19: Vistas del buscador de aulas libres, gestor de matrícula y vista emergente para añadir asignaturas al gestor 73 Figura 20: Vistas de programas de movilidad, vista emergente con enlaces externos de movilidad y vista de próximas lecturas 74 Figura 21: Vistas del gestor de notas compacto, extendido y vista emergente para añadir evaluación 74 Figura 22: Vistas de enlaces de interés, feedback & bugs y configuración de la aplicación 75 Figura 23: Vistas auxiliares para modificar el horario del estudiante 75 Figura 24: Ciclo de vida de una tarea SCRUM 78 Figura 25: Ciclo de testing 78 Figura 26: Listado de crashes y ARNs de la aplicación del proyecto 83 Figura 27: Gráficas de parámetros de un crash 83 Figura 28: Registro de un crash seleccionado 83 Figura 29: Pasos para instalar la aplicación 84 Figura 30: Logo de la aplicación 86 Figura 31: Diagrama de Gantt final 93

108

Referencias [1] El Racó | Facultad de Informática de Barcelona. (n.d.). Retrieved February 25, 2020, from https://www.fib.upc.edu/es/la-fib/servicios-tic/el-raco [2] Ingeniería del Software | Facultad de Informática de Barcelona. (n.d.). Retrieved February 25, 2020, from https://www.fib.upc.edu/es/estudios/grados/grado-en-ingenieria-informatica/plan-de-estudios/especialidades/ingenieria-del-software [3] Desarrollando la API de la FIB 2.0 | inLab FIB. (n.d.). Retrieved February 25, 2020, from https://inlab.fib.upc.edu/es/blog/desenvolupant-la-api-de-la-fib-20 [4] Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST). (n.d.). Retrieved February 25, 2020, from https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm [5] React Native · A framework for building native apps using React. (n.d.). Retrieved February 25, 2020, from https://reactnative.dev/ [6] Racó mobile | inLab FIB. (n.d.). Retrieved February 25, 2020, from https://inlab.fib.upc.edu/es/raco-mobile [7] Tipo de dispositivos móviles utilizados para acceder a Internet en los últimos 3 meses fuera de la vivienda habitual o centro de trabajo por Comunidades y Ciudades Autónomas. (n.d.). Retrieved February 23, 2020, from https://www.ine.es/jaxi/Datos.htm?path=/t25/p450/base_2011/a2018/l0/&file=08005.px [8] Mobile App Vs. Mobile Website: Which Is The Better Option? (n.d.). Retrieved February 23, 2020, from https://clearbridgemobile.com/mobile-app-vs-mobile-website-which-is-the-better-option/ [9] Mobile App Vs. Mobile Website: Which Is The Better Option? (n.d.). Retrieved February 23, 2020, from https://clearbridgemobile.com/mobile-app-vs-mobile-website-which-is-the-better-option/ [10] Siles, R., & Salas, M. (2019). Informe Anual 2018 Dispositivos y comunicaciones móviles. Centro Criptológico Nacional. [11] La facultad en cifras | Facultad de Informática de Barcelona. (n.d.). Retrieved February 22, 2020, from https://www.fib.upc.edu/es/la-fib/la-facultad/la-facultad-en-cifras [12] Racó de la Fib – Apps on Google Play. (n.d.). Retrieved February 25, 2020, from https://play.google.com/store/apps/details?id=com.inlab.racodemoapi

109

[13] El Racó – Apps on Google Play. (n.d.). Retrieved February 25, 2020, from https://play.google.com/store/apps/details?id=personal.yeqk97.raco&gl=ES [14] El Racó - FIB – Apps on Google Play. (n.d.). Retrieved February 25, 2020, from https://play.google.com/store/apps/details?id=com.fibupc [15] Github - yeqk97/raco. (n.d.). Retrieved February 25, 2020, from https://github.com/yeqk97/raco [16] The MIT License | Open Source Initiative. (n.d.). Retrieved February 25, 2020, from https://opensource.org/licenses/MIT [17] Terms of Use - FIB API v2. (n.d.). Retrieved February 25, 2020, from https://api.fib.upc.edu/v2/docs/condicions [18] Wayback Machine. (n.d.). Retrieved March 16, 2020, from https://web.archive.org/web/20080516073429/http://members.cox.net/risingl1/Articles/IEEEScrum.pdf [19] THE PRINCIPLES OF THE KANBAN METHOD | DJA. (n.d.). Retrieved February 25, 2020, from https://web.archive.org/web/20140114161522/http://www.djaa.com/principles-kanban-method [20] Git. (n.d.). Retrieved February 25, 2020, from https://git-scm.com/ [21] Salarios para empleos de Director/a de proyecto en Barcelona, Barcelona provincia | Indeed.es. (n.d.). Retrieved March 16, 2020, from https://www.indeed.es/salaries/director-de-proyecto-Salaries,-Barcelona-CT [22] Salarios para empleos de Programador/a junior en Barcelona, Barcelona provincia | Indeed.es. (n.d.). Retrieved March 9, 2020, from https://www.indeed.es/salaries/programador-junior-Salaries,-Barcelona-CT [23] Salarios para empleos de Tester/a en Barcelona, Barcelona provincia | Indeed.es. (n.d.). Retrieved March 16, 2020, from https://www.indeed.es/salaries/tester-Salaries,-Barcelona-CT [24] Cuestionario de Estudiantes de Ingeniería Informática. (n.d.). Retrieved March 9, 2020, from https://docs.google.com/forms/d/e/1FAIpQLSelZixKIUFbCn1oVkd2JM3yxCc208E85RgKZclKd8eUu3GvBg/viewform [25] Ecorresponsabilidad. (n.d.). Retrieved March 8, 2020, from http://www.ecorresponsabilidad.es/fichas/portatil.htm

110

[26] García, J. M. B. (2018). Cómo funciona la librería Redux - Blog de arsys.es. https://www.arsys.es/blog/programacion/redux-datos-aplicaciones/ [27] Facultat d’Informàtica de Barcelona. (2020). Normativa Del Treball Final De Grau Del Grau En Enginyeria Informàtica De La Facultat D’Informàtica De Barcelona. https://www.fib.upc.edu/sites/fib/files/documents/estudis/normativa-tfg-mencio-addicional-gei-br.pdf [28] Rodríguez, C. (n.d.). Licencias software libre permisivas; todo lo que necesitabas saber | Agilia Center. Retrieved September 28, 2020, from https://www.agiliacenter.com/software-libre-permisivas/ [29] The MIT License | Open Source Initiative. (n.d.). Retrieved September 28, 2020, from https://opensource.org/licenses/MIT [30] Terms of Use - FIB API v2. (n.d.). Retrieved September 28, 2020, from https://api.fib.upc.edu/v2/docs/condicions [31] Centro de Políticas de Desarrolladores. (n.d.). Retrieved September 28, 2020, from https://play.google.com/intl/es/about/developer-content-policy/ [32] All About Computer Cookies - Session Cookies, Persistent Cookies,How to Enable/Disable/Manage Cookies. (n.d.). Retrieved September 28, 2020, from https://www.allaboutcookies.org/ [33] Setting up the development environment · React Native. (n.d.). Retrieved September 28, 2020, from https://reactnative.dev/docs/environment-setup [34] Xcode - Wikipedia. (n.d.). Retrieved September 28, 2020, from https://en.wikipedia.org/wiki/Xcode [35] Software installed on computers | FIB - Barcelona School of Informatics. (n.d.). Retrieved September 28, 2020, from https://www.fib.upc.edu/en/fib/it-services/software-installed-computers [36] Cuarentena en España de 2020 - Wikipedia, la enciclopedia libre. (n.d.). Retrieved September 28, 2020, from https://es.wikipedia.org/wiki/Cuarentena_en_España_de_2020#Historia_y_desarrollo [37] FIB - UPC en Instagram: “@la_upc ha suspès l’activitat docent presencial a partir de demà 13 de març i fins el 3 d’abril, ambdós inclosos. + info: web FIB.” (n.d.). Retrieved September 28, 2020, from https://www.instagram.com/p/B9pKRbdIciX/ [38] Hackintosh Instructions, Hackintosh How To Guides: Hackintosh.com. (n.d.). Retrieved September 28, 2020, from https://hackintosh.com/

111

[39] Robertson, J., & Robertson, S. (2000). Volere. In Requirements Specification Templates. https://www.cs.uic.edu/~i440/VolereMaterials/templateArchive16/c Volere template16.pdf [40] OAuth 2.0 — OAuth. (n.d.). Retrieved October 23, 2020, from https://oauth.net/2/ [41] Flux | Flux. (n.d.). Retrieved October 23, 2020, from https://facebook.github.io/flux/ [42] React.Component – React. (n.d.). Retrieved October 23, 2020, from https://reactjs.org/docs/react-component.html

112

Desarrollo de una Aplicación Móvil para Estudiantes de la FIB

Documents

Transcript of Desarrollo de una Aplicación Móvil para Estudiantes de la FIB