Contribuciones a un proyecto Open Source de ámbito internacional: Ampache

Curso: 2020-2021 Fecha: Bilbao, 30, Junio, 2021 Alumno/Alumna: González, Llaguno, Urtzi Director/Directora: Pereira, Varela, Juanan GRADO EN INGENIERÍA INFORMÁTICA DE GESTIÓN Y SISTEMAS DE INFORMACIÓN TRABAJO FIN DE GRADO CONTRIBUCIONES A UN PROYECTO OPEN SOURCE DE ÁMBITO INTERNACIONAL: AMPACHE Resumen Castellano Este trabajo consiste en la contribuci´on al desarrollo de Ampache, un software libre para la gesti´on de contenido multimedia. Teniendo como objetivo aportar valor a˜nadido a un software usado por miles de usuarios, se han desarrollado mejoras propuestas por usuarios de la comunidad — la visualizaci´on de la duraci´on total de una lista de reproducci´on y la opci´on de definir una imagen de fondo personalizada —, y tambi´en se ha contribuido a la remodelaci´on de la interfaz de usuario. Euskara Lan honetan Ampache multimedia-edukia kudeatzeko software librearen garapenean ekarpenak egin dira. Milaka erabiltzailek erabilitako softwareari balio erantsia ematea helburu izanik, komunitateko erabiltzaileek proposatutako hobekuntzak egin dira — erreprodukzio-zerrenda baten iraupen osoa bistaratzea eta horma irudi pertsonalizatua definitzeko aukera —, baita erabiltzailearen interfazea birmoldatzen lagundu da ere. English This work consists of the contribution to the development of Ampache, a free software project for multimedia content management. Aiming to add value to a software used by thousands of people, new features proposed by community members have been developed - displaying the total duration of playlists and the ability to specify a custom background image - as well as helping in the redesign of the user interface. i ii Prefacio La motivaci´on de este proyecto surge del inter´es de aplicar los conocimientos y competencias adquiridas en el grado a un proyecto del mundo real, fuera del marco acad´emico. Contribuyendo a un proyecto existente con una comunidad de usuarios, se consigue aportar un valor a˜nadido dif´ıcilmente alcanzable por otros trabajos que parten desde cero. Adem´as, existen retos transversales tales como la comunicaci´on con otros contribuidores experimentados y la comprensi´on del c´odigo ya existente, que hacen que este trabajo se asemeje mejor al escenario en el que los nuevos graduados de ingenier´ıa inform´atica nos encontraremos. El proyecto en cuesti´on es Ampache, un administrador de archivos y servidor de streaming multimedia libre, que funciona sobre un servidor web. Lanzado en 2001, sigue teniendo un desarrollo activo y una comunidad involucrada en la constante mejora del servicio. Est´a compuesto de m´as de 500.000 l´ıneas de c´odigo programadas en PHP bajo la licencia AGPLv3. iii iv ´ Indice general Resumen i Prefacio iii ´ Indice de figuras vii ´ Indice de tablas ix 1. Introducci´on 1 1.1. Contexto.............................. 2 1.2. Motivaciones y beneficios . . . . . . . . . . . . . . . . . . . . . 3 1.3. Ampache.............................. 4 1.4. Objetivos ............................. 9 2. Metodolog´ıa 11 2.1. Planificaci´on............................ 12 2.2. Cronograma............................ 27 2.3. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . 29 2.4. Evaluaci´on econ´omica . . . . . . . . . . . . . . . . . . . . . . . 31 2.5. An´alisis de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . 36 3. Ejecuci´on 41 3.1. Captura de requisitos . . . . . . . . . . . . . . . . . . . . . . . 42 3.2. Interfaz .............................. 48 3.3. An´alisis y dise˜no . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.4. Desarrollo ............................. 70 4. Resultados 81 4.1. Pruebas de calidad . . . . . . . . . . . . . . . . . . . . . . . . 82 4.2. Integraci´on de los aportes . . . . . . . . . . . . . . . . . . . . 91 v 5. Conclusi´on 95 5.1. Diferencia entre estimaci´on y tiempo real . . . . . . . . . . . . 96 5.2. Futuras l´ıneas de trabajo . . . . . . . . . . . . . . . . . . . . . 98 5.3. Licencia .............................. 98 5.4. Reflexi´on personal . . . . . . . . . . . . . . . . . . . . . . . . . 99 Acr´onimos 101 Glosario 103 Bibliograf´ıa 107 vi ´ Indice de figuras 1.3. Arquitectura de Ampache. . . . . . . . . . . . . . . . . . . . . 6 1.4. Estructura interna de Ampache. . . . . . . . . . . . . . . . . . 7 2.1. Visi´on general del diagrama EDT. . . . . . . . . . . . . . . . . 12 2.2. Paquetes de trabajo de la agrupaci´on ((Planificaci´on)). . . . . . 13 2.3. Paquetes de trabajo de la agrupaci´on ((Formaci´on)). ...... 15 2.4. Paquetes de trabajo de la agrupaci´on ((Captura de requisitos)). 17 2.5. Paquetes de trabajo de la agrupaci´on ((An´alisis y dise˜no)). . . . 19 2.6. Paquetes de trabajo de la agrupaci´on ((Implementaci´on)). . . . 21 2.7. Paquetes de trabajo de la agrupaci´on ((Pruebas))......... 23 2.8. Paquetes de trabajo de la agrupaci´on ((Documentaci´on)). . . . 25 2.9. Diagrama Gantt de la planificaci´on del proyecto. . . . . . . . . 28 3.1. Jerarqu´ıa de actores. . . . . . . . . . . . . . . . . . . . . . . . 42 3.2. Casos de uso generales. . . . . . . . . . . . . . . . . . . . . . . 43 3.3. P´agina principal de la herramienta issue............. 44 3.4. Etiquetas de la issue #2527.................... 45 3.5. Etiquetas de la issue #2582.................... 46 3.6. P´aginadeinicio. ......................... 48 3.7. P´agina de todos los artistas. . . . . . . . . . . . . . . . . . . . 49 3.8. P´agina de un artista. . . . . . . . . . . . . . . . . . . . . . . . 50 3.9. P´agina de un ´album. . . . . . . . . . . . . . . . . . . . . . . . 51 3.10. P´agina de una canci´on. . . . . . . . . . . . . . . . . . . . . . . 51 3.11. Diagrama ER de la issue 2527. ................. 53 3.12. Diagrama de clases de la issue 2527. .............. 54 3.13. Interfaz de la p´agina show playlists. ............. 55 3.14. Interfaz de la p´agina show playlist............... 56 3.15. Diagrama de secuencia de la issue 2527. ............ 57 3.16. Diagrama ER de la issue 2582. ................. 59 3.17. Diagrama de clases de la issue 2582. .............. 60 3.18. Interfaz de la p´agina login.php. ................ 61 vii Ampache Urtzi Gonz´alez Llaguno 1.3. Ampache Ampache es una aplicaci´on web destinada a la transmisi´on de audio y v´ıdeo que realiza la funci´on de administraci´on de archivos y metadatos. Figura 1.1: Logotipo de Ampache.5 Entre las caracter´ısticas destacables de Ampache est´an incluidas (Ampache [2020]): Almacenamiento de m´usica: catalogaci´on y administraci´on de colecciones de m´usica a trav´es de una interfaz web. Streaming audiovisual: transmisi´on de contenido a reproductores multimedia y reproducci´on directa mediante la p´agina web con el reproductor HTML5. Software libre: respeta la libertad del usuario y el c´odigo es libremente accesible bajo la licencia AGPLv36. Compatibilidad: posibilidad de conexi´on a aplicaciones de terceros mediante protocolos de transmisi´on de informaci´on. 5Publicado por el autor SUTJael bajo la licencia p´ublica GPLv2. 6La licencia AGPLv3 es una versi´on modificada de la licencia GPLv3, que contiene una ´unica clausula adicional: al ejecutar un programa modificado en un servidor, el servidor debe permitir la descarga del c´odigo fuente correspondiente a la versi´on modificada que se ejecuta (Foundation [2015]). 4 Urtzi Gonz´alez Llaguno Ampache 1.3.1. Situaci´on del proyecto Publicado en 2001 por Scott Kveton, miembro de la Oregon State University, el proyecto Ampache ha tenido m´ultiples mantenedores y m´as de 100 contribuidores a lo largo de sus dos d´ecadas de existencia (Figura 1.2). Desde 2019 el proyecto es mantenido por el usuario australiano ((lachlan-00)). Figura 1.2: Gr´afico de actividad en el desarrollo de Ampache.7 Teniendo en cuenta que la mayor´ıa de proyectos open source tienen una esperanza de vida inferior a los dos a˜nos (Liao et al. [2017]), la longevidad de Ampache se convierte en una caracter´ıstica muy destacable del proyecto8. A fecha de redacci´on de esta memoria, la ´ultima versi´on publicada es la 4.4.3 (5 de junio del 2021). La versi´on 5.0.0 — que incluir´a cambios notables en la API y una modernizaci´on de la interfaz de usuario — se encuentra en desarrollo actualmente. En paralelo al desarrollo de nuevas versiones, se est´a realizando un nuevo frontend basado en el framework React — al que tambi´en se contribuir´a con este trabajo — con el objetivo de obtener una interfaz de usuario que tenga un aspecto m´as actualizado. 7Las aportaciones anteriores a 2006 no se realizaron en el repositorio actual de GitHub, por lo que no hay registro de actividad para esa franja de a˜nos. 8El efecto Lindy, descrito por el matem´atico Benoit Mandelbrot y ampliado por Nassim Taleb, indica que una tecnolog´ıa — o cualquier cosa no perecedera — aumenta su esperanza de vida con cada d´ıa adicional de existencia. Un software que ha existido durante 20 a˜nos es probable que siga existiendo otros 20 a˜nos (Taleb [2012]). 5 Ampache Urtzi Gonz´alez Llaguno 1.3.2. Arquitectura Ampache sigue un un modelo de arquitectura cliente-servidor (Figura 1.3). Los usuarios (cliente) interaccionan con la aplicaci´on (servidor) mediante dos posibles v´ıas: la interfaz web HTML5 o los conectores API para clientes de terceros. Esta l´ogica se ejecuta sobre un servidor HTTP (Apache, NGINX, lighttpd, etc.) el cual se encarga de la comunicaci´on con el resto de elementos y la base de datos. Figura 1.3: Arquitectura de Ampache. La interfaz web, desde la que acceden los navegadores, utiliza PHP y JavaScript para la parte l´ogica y HTML5 junto a CSS3 para la estructuraci´on de contenido. Dispone de un reproductor de audio y v´ıdeo y permite la gesti´on de la configuraci´on de la aplicaci´on. La estructura interna de Ampache (Figura 1.4) est´a dividida en una jerarqu´ıa de directorios. La l´ogica de negocio se encuentra en la carpeta ((lib)), es aqu´ı donde est´an definidas las clases y m´etodos principales. 6 Urtzi Gonz´alez Llaguno Ampache Figura 1.4: Estructura interna de Ampache. El c´odigo base no est´a desarrollado sobre ning´un framework, aunque s´ı que se utilizan algunas funcionalidades especificas de algunos frameworks para tareas concretas. Se hace uso de m´ultiples librer´ıas externas que facilitan el desarrollo de funcionalidades. Por ejemplo, se hace uso de la librer´ıa FFmpeg9para la conversi´on de codecs; jQuery10 para la manipulaci´on de elementos HTML; y Bootstrap11 para la interfaz gr´afica. Otras librer´ıas externas utilizadas son: 9FFmpeg: a complete, cross-platform solution to record, convert and stream audio and video (www.ffmpeg.org) 10jQuery: the Write Less, Do More, JavaScript Library (www.jquery.com) 11Bootstrap: the most popular HTML, CSS, and JS library in the world (www. getbootstrap.com) 7 Ampache Urtzi Gonz´alez Llaguno Aurora.js12:framework para la decodificaci´on y reproducci´on de audio. Beets13: m´odulo para el manejo de archivos multimedia, cataloga colecciones y gestiona metadatos. Captcha: m´odulo de seguridad para proteger los servicios de ataques automatizados. Horde14:framework de uso general que ofrece funcionalidades para la gesti´on de preferencias, compresi´on, detecci´on de navegador, etc. OAuth15: est´andar de seguridad para la delegaci´on de acceso. Rhinoslider16: librer´ıa para la creaci´on de efectos especiales. UberViz17: generador de efectos visuales en base a audio. Por otra parte, los conectores permiten la comunicaci´on con otras aplicaciones. Aplicaciones como Subsonic18 o DSub19 son compatibles con Ampache y habilitan una experiencia nativa para dispositivos Android. Para ello se establece un canal basado en un protocolo de comunicaci´on (UPnP,WebDAV,DAAP, etc.) que transmite la informaci´on entre ambas aplicaciones. De esta manera, se abre la posibilidad de conectarse a Ampache desde un dispositivo m´ovil con una aplicaci´on nativa a su sistema operativo. 12Aurora.js: JavaScript audio decoding framework (www.github.com/audiocogs/ aurora.js) 13Beets: media library management system for obsessive music geeks (https://beets. io/) 14Horde: general-purpose web application framework in PHP (www.horde.org) 15OAuth: industry-standard protocol for authorization (www.oauth.net) 16Rhinoslider: the most flexible jQuery slider/slideshow (www.rhinoslider.com) 17UberViz: custom real-time audio-reactive music visualizers (www.uberviz.io) 18Subsonic: stream music and video from your home computer to your phone (www. subsonic.org/pages/apps.jsp) 19DSub: music streaming app for Subsonic servers (www.github.com/daneren2005/ Subsonic) 8 Urtzi Gonz´alez Llaguno Objetivos 1.4. Objetivos A lo largo de la formaci´on en el grado de Ingenier´ıa Inform´atica de Gesti´on y Sistemas de Informaci´on se han adquirido multitud de competencias. En este trabajo se busca poner en pr´actica las competencias y conocimientos adquiridos en el grado para ayudar a corregir errores y a˜nadir nuevas funcionalidades a un software profesional. 1.4.1. Aplicar las competencias obtenidas en el grado Se busca demostrar la capacidad de las tecnolog´ıas vistas en el grado para su implementaci´on en un proyecto real. Siendo capaz de definir requisitos a nivel de software que se ajusten a las especificaciones y est´andares de la industria. Esto implica un conocimiento de la arquitectura y las distintas fases de desarrollo de un proyecto software, entre las que se encuentran: la captura de requisitos establecidos por el cliente, el an´alisis y dise˜no siguiendo los requisitos establecidos, la implementaci´on l´ogica mediante lenguajes de programaci´on, y la realizaci´on de pruebas de calidad que verifiquen los resultados obtenidos. Todo ello debe quedar adecuadamente documentado para permitir la comprensi´on por terceros y facilitar un desarrollo colaborativo, esta documentaci´on debe tener un lenguaje cient´ıfico-t´ecnico que se adec´ue al contexto inform´atico. 1.4.2. Contribuir a un software libre Existe una gran diferencia entre comenzar un nuevo proyecto desde tabula rasa, a tener que comprender el trabajo que decenas de personas han realizado durante d´ecadas, como es el caso de Ampache. Es una propiedad frecuente de los proyectos de gran envergadura encontrar secciones que contengan tecnolog´ıa desfasada y con poca o ninguna documentaci´on. Lo recomendable en esas situaciones es realizar una refac9 Objetivos Urtzi Gonz´alez Llaguno torizaci´on del c´odigo con el objetivo de reducir la deuda t´ecnica (Arif and Rana [2020]). Tambi´en es necesario un conocimiento del marco legal en el que se desarrolla un proyecto open source. Para ello es necesario un estudio de la permisividad de distribuci´on, modificaci´on y uso comercial que ofrecen los distintos tipos de licencias existentes (AGPL, Apache, Creative Commons, MIT, etc.). 1.4.3. Capacidad de relaci´on interpersonal en una lengua no materna Realizar contribuciones a un software open source supone un reto adicional, ya que es necesaria una comunicaci´on — generalmente en ingl´es — con personas de distintas nacionalidades, culturas y g´eneros. Dada la problem´atica de esta tarea, es frecuente encontrar c´odigos de conducta en los proyectos open source indicando expl´ıcitamente unas normas que permitan un trato respetuoso con el resto de personas. 1.4.4. Aprendizaje aut´onomo de nuevas tecnolog´ıas Por muy aptos que resulten los conocimientos adquiridos en el grado, estos no son suficientes para trabajar en un campo tan din´amico como es la inform´atica. El ´ambito inform´atico es uno donde la innovaci´on en la creaci´on de nuevas metodolog´ıas y herramientas es constante. Es por ello que es necesaria una formaci´on continua que se adapte a la direcci´on en la que evoluciona el campo. Tomando como base los conocimientos obtenidos en el grado, mediante el desarrollo de este trabajo se busca expandir y profundizar en las capacidades t´ecnicas tanto de las tecnolog´ıas vistas en el grado como de tecnolog´ıas en las que ser´a necesaria una nueva formaci´on aut´onoma individual. 10 2. Metodolog´ıa Planificaci´on Urtzi Gonz´alez Llaguno 2.1. Planificaci´on Con el objetivo de facilitar la planificaci´on de este trabajo, los distintos m´odulos que lo componen han sido descompuestos mediante un diagrama EDT. El diagrama EDT resultante est´a compuesto de las siguientes agrupaciones (Figura 2.1): planificaci´on, formaci´on, captura de requisitos, an´alisis y dise˜no, desarrollo, pruebas y documentaci´on. Figura 2.1: Visi´on general del diagrama EDT. 1. Planificaci´on y seguimiento: esta agrupaci´on incluye las actividades de coordinaci´on para la realizaci´on del proyecto. 2. Formaci´on: en esta agrupaci´on est´an incluidas las herramientas y tecnolog´ıas que requieren de un aprendizaje aut´onomo adicional. 3. Captura de requisitos: agrupaci´on de la informaci´on requerida para poder afrontar los requerimientos de los stakeholders. 4. An´alisis y dise˜no: esta agrupaci´on hace referencia a la fase de modelado y definici´on de la estructura del software a ser desarrollado. 5. Implementaci´on: agrupaci´on que incluye la fase de programaci´on del c´odigo siguiendo el dise˜no previamente definido. 6. Pruebas: en esta agrupaci´on est´an contenidas las distintas pruebas de calidad y usabilidad relativas al c´odigo desarrollado. 7. Documentaci´on: agrupaci´on que contiene los elementos relacionados a la realizaci´on de la memoria del proyecto. 12 Urtzi Gonz´alez Llaguno Planificaci´on 2.1.1. Planificaci´on En esta agrupaci´on est´an incluidos los paquetes de trabajo (Figura 2.2 y Tablas 2.1,2.2,2.3,2.4) que ofrecen un soporte a la gesti´on de la ejecuci´on del proyecto. Figura 2.2: Paquetes de trabajo de la agrupaci´on ((Planificaci´on)). Diagrama EDT Agrupaci´on: Planificaci´on. Duraci´on estimada: 5 horas. Descripci´on: la realizaci´on de este diagrama EDT, donde se descomponen en paquetes de trabajo las tareas a realizar a lo largo de la elaboraci´on del proyecto. Salidas/Entregables: diagrama EDT. Recursos necesarios:software ((diagrams.net)). Tabla 2.1: Paquete de trabajo ((Diagrama EDT)). 13 Planificaci´on Urtzi Gonz´alez Llaguno An´alisis y dise˜no Issue 2582 Agrupaci´on: An´alisis y dise˜no. Duraci´on estimada: 15 horas. Descripci´on: una vez dispuesta la captura de requisitos, elaboraci´on y desarrollo de diagramas ER, diagramas de clase y diagramas de secuencia. Salidas/Entregables: diagramas generados. Recursos necesarios: caso de uso 2582 y software ((diagrams.net)). Tabla 2.13: Paquete de trabajo ((An´alisis y dise˜no Issue 2582)). An´alisis y dise˜no React Agrupaci´on: An´alisis y dise˜no. Duraci´on estimada: 24 horas. Descripci´on: definici´on de las clases, m´etodos y flujos de comunicaci´on relacionados a las funcionalidades del nuevo frontend. Salidas/Entregables: diagramas generados. Recursos necesarios: casos de uso relacionados al desarrollo React y software ((diagrams.net)). Tabla 2.14: Paquete de trabajo ((An´alisis y dise˜no React)). 20 Urtzi Gonz´alez Llaguno Planificaci´on 2.1.5. Implementaci´on En esta agrupaci´on est´an incluidos los paquetes de trabajo (Figura 2.6 y Tablas 2.15,2.16,2.17) relativos a la programaci´on l´ogica del c´odigo en base a los dise˜nos concebidos previamente. Figura 2.6: Paquetes de trabajo de la agrupaci´on ((Implementaci´on)). Implementaci´on Issue 2527 Agrupaci´on: Implementaci´on Duraci´on estimada: 12 horas Descripci´on: proceso de programaci´on en el lenguaje PHP siguiendo el dise˜no definido en la fase de an´alisis. Salidas/Entregables: c´odigo relativo a la issue 2527. Recursos necesarios: diagramas ER, diagramas de clase, diagramas asociativos y diagramas de secuencia relativos a la issue 2527. Tabla 2.15: Paquete de trabajo ((Implementaci´on Issue 2527)). 21 Planificaci´on Urtzi Gonz´alez Llaguno Implementaci´on Issue 2582 Agrupaci´on: Implementaci´on Duraci´on estimada: 8 horas Descripci´on: definici´on de la l´ogica de la issue 2582 mediante c´odigo. Salidas/Entregables: c´odigo relativo a la issue 2582. Recursos necesarios: diagramas ER, diagramas de clase, diagramas asociativos y diagramas de secuencia relativos a la issue 2582. Tabla 2.16: Paquete de trabajo ((Implementaci´on Issue 2582)). Implementaci´on React Agrupaci´on: Implementaci´on Duraci´on estimada: 15 horas. Descripci´on: desarrollo de c´odigo en el framework React siguiendo las especificaciones de dise˜no definidas. Salidas/Entregables: c´odigo relativo al desarrollo React. Recursos necesarios: diagramas definidos en el an´alisis y dise˜no de React. Tabla 2.17: Paquete de trabajo ((Implementaci´on React)). 22 Urtzi Gonz´alez Llaguno Planificaci´on 2.1.6. Pruebas En esta agrupaci´on est´an incluidos los paquetes de trabajo (Figura 2.7 y Tablas 2.18,2.19,2.20) relativos a la comprobaci´on de la calidad y usabilidad del c´odigo generado. Figura 2.7: Paquetes de trabajo de la agrupaci´on ((Pruebas)). Pruebas Issue 2527 Agrupaci´on: Pruebas. Duraci´on estimada: 10 horas. Descripci´on: verificaci´on de la calidad del c´odigo, de modo que se identifiquen y solucionen los errores encontrados antes de integrar la implementaci´on con el producto final. Salidas/Entregables: documentaci´on de las pruebas realizadas sobre la implementaci´on de la issue 2527. Recursos necesarios: c´odigo relativo a la issue 2527. Tabla 2.18: Paquete de trabajo ((Pruebas Issue 2527)). 23 Planificaci´on Urtzi Gonz´alez Llaguno Pruebas Issue 2582 Agrupaci´on: Pruebas. Duraci´on estimada: 5 horas. Descripci´on: comprobaci´on de que la implementaci´on realizada alcanza un nivel de calidad y usabilidad aceptable. Salidas/Entregables: documentaci´on de las pruebas realizadas sobre la implementaci´on de la issue 2582. Recursos necesarios: c´odigo relativo a la issue 2582. Tabla 2.19: Paquete de trabajo ((Pruebas Issue 2582)). Pruebas React Agrupaci´on: Pruebas. Duraci´on estimada: 15 horas. Descripci´on: testeo de la implementaci´on realizada con el objetivo de comprobar errores en el dise˜no o desarrollo. Salidas/Entregables: documentaci´on de las pruebas realizadas sobre la implementaci´on del desarrollo React. Recursos necesarios: c´odigo relativo al desarrollo React. Tabla 2.20: Paquete de trabajo ((Pruebas React)). 2.1.7. Documentaci´on En esta agrupaci´on est´an incluidos los paquetes de trabajo (Figura 2.8 y Tablas 2.21,2.22) relativos a la investigaci´on y redacci´on de los documentos relacionados a la ejecuci´on del proyecto. 24 Urtzi Gonz´alez Llaguno Planificaci´on Figura 2.8: Paquetes de trabajo de la agrupaci´on ((Documentaci´on)). Memoria Agrupaci´on: Documentaci´on. Duraci´on estimada: 160 horas. Descripci´on: investigaci´on, redacci´on y maquetaci´on del proceso completo de la elaboraci´on del proyecto. Salidas/Entregables: documento de memoria del TFG. Recursos necesarios: todas las figuras, textos, tablas, diagramas y c´odigo generados a lo largo del proyecto. Tabla 2.21: Paquete de trabajo ((Memoria)). Defensa Agrupaci´on: Documentaci´on. Duraci´on estimada: 8 horas. Descripci´on: creaci´on de las diapositivas para la presentaci´on de la defensa del trabajo. Salidas/Entregables: conjunto de diapositivas. Recursos necesarios: figuras, textos, tablas y diagramas m´as relevantes del proyecto. Tabla 2.22: Paquete de trabajo ((Defensa)). 25 Planificaci´on Urtzi Gonz´alez Llaguno 2.1.8. Resumen de la planificaci´on Realizando una suma de la duraci´on individual de cada paquete de trabajo, se obtiene una duraci´on total de 420 horas para la ejecuci´on del proyecto completo (Tabla 2.23). Tabla 2.23: Resumen de tiempos y precedencias del EDT. 26 Urtzi Gonz´alez Llaguno Cronograma 2.2. Cronograma El proyecto tiene como fecha inicio el d´ıa 1 de septiembre de 2020 y fecha de cierre el 23 de julio de 20211. Existen ciertas tareas — como la redacci´on de la memoria, las reuniones y el intercambio de emails — que se realizan a lo largo de todo el proyecto y otras — como la formaci´on en las herramientas — que solo se realizan a lo largo del desarrollo de las issues. Se han definido tres hitos, cada uno est´a asociado a la completitud del desarrollo e integraci´on de una issue. Hito 1 - Issue 2527 completada: habiendo comenzado en octubre, se espera tener finalizada la primera issue para el d´ıa 1 de diciembre de 2020. Hito 2 - Issue 2582 completada: el desarrollo de la segunda issue comienza inmediatamente despu´es de terminar con la primera. Se establece como fecha objetivo tener su integraci´on realizada para el primer d´ıa de febrero de 2021. Hito 3 - Funcionalidades React completadas: dado que el ´ultimo hito se realiza tras la completitud de los dos anteriores, existe la posibilidad de que su plazo de ejecuci´on var´ıe en mayor medida. No obstante, se ha establecido como meta finalizar su desarrollo para el 1 de abril de 2021. Mediante un diagrama Gantt (Figura 2.9) es posible representar visualmente las fechas mencionadas en esta secci´on y los paquetes de trabajo descritos en el EDT de la secci´on anterior. 1La fecha de cierre puede variar entre el 19 y 23 de julio dependiendo de la fecha de defensa asignada por la universidad. 27 Cronograma Urtzi Gonz´alez Llaguno Figura 2.9: Diagrama Gantt de la planificaci´on del proyecto. 28 Urtzi Gonz´alez Llaguno Herramientas utilizadas 2.3. Herramientas utilizadas Para facilitar las labores relacionadas a este trabajo, se ha hecho uso de herramientas y servicios que facilitan la elaboraci´on del mismo. Entre ellas, las m´as destacables y directamente relacionadas con el trabajo han sido: Apache: servidor web. En la configuraci´on utilizada, la aplicaci´on de Ampache se ejecuta sobre un servidor montado en un servicio Apache. diagrams.net:software de creaci´on de diagramas. Los diagramas de clases, diagramas asociativos y diagramas de secuencia han sido realizados con esta herramienta. GanttProject: aplicaci´on de planificaci´on de proyectow. Su uso ha permitido la realizaci´on del diagrama Gantt utilizado para planificar este proyecto. Git: sistema de control de versiones. Se ha utilizado junto a la plataforma GitHub2para gestionar las distintas versiones de c´odigo generadas. IntelliJ IDEA: entorno de desarrollo integrado. Gracias a las funcionalidades que ofrece para el an´alisis de c´odigo, su uso ha facilitado la comprensi´on y desarrollo. L A T EX: sistema de preparaci´on de documentos. La documentaci´on asociada al trabajo ha sido redactada en el servicio Overleaf3el cual utiliza el sistema LaTeX. MySQL Workbench:software para el dise˜no visual de bases de datos. Su uso ha permitido una mejor comprensi´on de la base de datos de Ampache. Los diagramas ER han sido generados mediante esta herramienta. Telegram: servicio de mensajer´ıa instant´anea4. Es el canal de comunicaci´on general de los miembros de la comunidad. 2GitHub: where the world builds software (www.github.com) 3Overleaf: online LaTeX Editor (www.overleaf.com) 4Telegram: a new era of messaging (www.telegram.org) 29 An´alisis de riesgos Urtzi Gonz´alez Llaguno 2.5. An´alisis de riesgos Tal y como establece la familia de est´andares para la gesti´on del riesgo ISO 31000, se busca una integraci´on de normativas en los procesos (Figura 2.10), con el objetivo de identificar y gestionar los riesgos existentes en la ejecuci´on de un proyecto. Figura 2.10: Proceso de gesti´on de riesgos.8 Para ello, se identifican los principales riesgos existentes y se define para cada uno: Prevenci´on: pautas para reducir la posibilidad de que el riesgo se materialice. Plan de contingencia: en caso de producirse, pasos a tomar para minimizar el impacto causado. Probabilidad: estimaci´on de la probabilidad de que suceda el riesgo. Impacto: consecuencias de su materializaci´on. Riesgo: multiplicaci´on de la probabilidad por el impacto para obtener una cifra de evaluaci´on del riesgo. 8Publicado por la International Organization for Standardization (ISO [2018]). 36 Urtzi Gonz´alez Llaguno An´alisis de riesgos Planificaci´on incorrecta Una definici´on demasiado ambiciosa del alcance, una formaci´on lenta en las nuevas herramientas o una estimaci´on general imprecisa del tiempo necesario para la ejecuci´on, son motivos que generan un riesgo en la realizaci´on del proyecto. Prevenci´on Realizar un cronograma de los tiempos marcados. Permitir holgura entre tareas para paliar posibles inconvenientes. Definir con el tutor del trabajo un alcance adecuado. Plan de contingencia Redefinir el alcance del trabajo. Aumentar el n´umero de horas dedicadas a su realizaci´on. Probabilidad Planificaci´on ligeramente incorrecta - probabilidad estimada 50 %. Planificaci´on excesivamente incorrecta - probabilidad estimada 2 %. Impacto Planificaci´on ligeramente incorrecta: 5 d´ıas ×3 horas/d´ıa = 15 horas. Impacto medio. Planificaci´on excesivamente incorrecta: 30 d´ıas ×3 horas/d´ıa = 90 horas. Impacto alto. Riesgo Planificaci´on ligeramente incorrecta: 50 % ×15 horas = 7,5. Riesgo medio. Planificaci´on excesivamente incorrecta: 2 % ×90 horas = 1,8. Riesgo bajo. 37 An´alisis de riesgos Urtzi Gonz´alez Llaguno Cancelaci´on o abandono del proyecto principal Al estar trabajando sobre un proyecto real y dado que no existe ning´un contrato formal, existe la posibilidad de que el desarrollador principal abandone el proyecto sin previo aviso, bien sea por motivo de fuerza mayor (fallecimiento, enfermedad, etc.) o por voluntad propia. Prevenci´on Comunicarse con el desarrollador principal para conocer su compromiso con el mantenimiento del proyecto. Plan de contingencia Buscar otro proyecto al que poder contribuir. Animar a otros desarrolladores con experiencia a tomar la posici´on de desarrollador principal. Probabilidad Baja temporal del desarrollador principal 5 %. Ausencia permanente del desarrollador principal 1 %. Impacto Baja temporal del desarrollador principal: 10 d´ıas ×3 horas/d´ıa = 30 horas. Impacto medio. Ausencia permanente del desarrollador principal: 90 d´ıas ×3 horas/d´ıa = 270 horas. Impacto muy alto. Riesgo Baja temporal del desarrollador principal: 5 % ×30 horas = 1,5. Riesgo bajo. Ausencia permanente del desarrollador principal: 1 % ×270 horas = 2,7. Riesgo bajo. 38 Urtzi Gonz´alez Llaguno An´alisis de riesgos Incapacidad temporal Baja por enfermedad o accidente que imposibilita temporalmente la capacidad para trabajar. Prevenci´on Derivadas del trabajo •Evitar movimientos cr´onicos repetitivos. •Establecer un espacio de trabajo ergon´omico. •Establecer pausas destinadas al descanso. No derivadas del trabajo •Seguir las pautas de salud general recomendadas (descanso, dieta, distanciamiento social, higiene, etc.) por los expertos en salud. Plan de contingencia Solicitar una valoraci´on de la lesi´on en un centro m´edico homologado. Seguir las pautas recibidas en la valoraci´on solicitada. Probabilidad Lesi´on leve (una semana de baja) - probabilidad estimada 20 %. Lesi´on grave (un mes de baja) - probabilidad estimada 2 %. Impacto Lesi´on leve: 7 d´ıas ×3 horas/d´ıa = 21 horas. Impacto medio. Lesi´on grave: 30 d´ıas ×3 horas/d´ıa = 90 horas. Impacto alto. Riesgo Lesi´on leve: 20 % ×21 horas = 4,2. Riesgo bajo. Lesi´on grave: 2 % ×90 horas = 1,8. Riesgo bajo. 39 An´alisis de riesgos Urtzi Gonz´alez Llaguno P´erdida del trabajo realizado Existen multitud de motivos (virus o bugs en el software; fallo, p´erdida o robo del hardware; error humano) por los que se puede dar un deterioro o p´erdida completa del trabajo realizado, tanto a nivel de documentaci´on como de c´odigo. Prevenci´on Realizar copias de seguridad peri´odicas. Mantener redundancia de los ficheros en distintos lugares. Utilizar versiones estables y actualizadas de software. Utilizar adecuadamente el equipo inform´atico. Plan de contingencia Volver a realizar el trabajo perdido. En caso de ser necesario, aplazar las fechas estimadas de ejecuci´on. Probabilidad P´erdida leve (una semana de trabajo) - probabilidad estimada 10 %. P´erdida grave (tres meses de trabajo) - probabilidad estimada 1 %. Impacto P´erdida leve: 7 d´ıas ×3 horas/d´ıa = 21 horas. Impacto medio. P´erdida grave: 90 d´ıas ×3 horas/d´ıa = 180 horas. Impacto muy alto. Riesgo P´erdida leve: 10 % ×21 horas = 2,1. Riesgo bajo. P´erdida grave: 1 % ×180 horas = 1,8. Riesgo bajo. 40 3. Ejecuci´on Captura de requisitos Urtzi Gonz´alez Llaguno 3.1. Captura de requisitos En esta secci´on se describen los actores que interact´uan con el sistema y los casos de uso asociados. Tambi´en se presentan las issues escogidas junto a una descripci´on de sus requisitos y objetivos a alcanzar. 3.1.1. Jerarqu´ıa de actores Existen tres tipos de actores que utilizan el sistema (Figura 3.1): Usuario An´onimo: este actor hace referencia a los participantes que acceden a la aplicaci´on de Ampache sin haberse identificado con una cuenta registrada en el sistema. Usuario: una vez un ((Usuario An´onimo)) se identifica con unas credenciales v´alidas en la p´agina de login este pasa a ser un ((Usuario)). Administrador: existe una tercera categor´ıa destinada a las cuentas de servicio para la administraci´on y mantenimiento, para acceder al sistema como ((Administrador)) es necesario utilizar las credenciales de la cuenta de servicio creada en la instalaci´on de la aplicaci´on. Figura 3.1: Jerarqu´ıa de actores. 42 Urtzi Gonz´alez Llaguno Captura de requisitos 3.1.2. Casos de uso Los actores definidos pueden realizar las siguientes acciones (Figura 3.2) en la aplicaci´on: Figura 3.2: Casos de uso generales. 43 Captura de requisitos Urtzi Gonz´alez Llaguno 3.1.3. Selecci´on de issues Siendo un proyecto p´ublico, es la propia comunidad de usuarios quien propone las nuevas caracter´ısticas e informa de los fallos o bugs existentes de manera colaborativa. Esta gesti´on de requisitos y sus respectivas soluciones se gestiona mediante la herramienta de issues de GitHub1(Figura 3.3). Figura 3.3: P´agina principal de la herramienta issue. El sistema de rastreo de issues permite centralizar en un ´unico lugar todas las incidencias y aporta granularidad puesto que cada incidencia es tratada de manera individual. Una issue contiene los siguientes elementos: T´ıtulo y descripci´on indicando cual es el tema a tratar. Una persona apoderada que ser´a la responsable de su resoluci´on. Una secci´on de comentarios que facilite la comunicaci´on entre desarrolladores y usuarios. Opcionalmente, es posible a˜nadir etiquetas (p.e. ((Interfaz)),((Urgente)), ((Mejora))) que faciliten la categorizaci´on. 1GitHub Guides: mastering issues (https://guides.github.com/features/issues) (Guides [2020]) 44 Urtzi Gonz´alez Llaguno Captura de requisitos #2527 [Feature Request] Total time Esta incidencia se abri´o en septiembre de 2020 por el usuario ((4phun)) de Ohio, Estados Unidos (4phun [2020]). Posee las etiquetas: interfaz, base de datos y mejora (Figura 3.4). La descripci´on inicial menciona lo siguiente: ((Hi, I think it would be a great addition to the web UI to show the total time for playlists, albums, and wherever else it may apply.)) Figura 3.4: Etiquetas de la issue #2527. Se trata de una incidencia para solicitar una nueva caracter´ıstica en la interfaz de usuario. En concreto, se solicita que las colecciones de canciones como los ´albumes y listas de reproducci´on muestren su duraci´on total. #2582 [Feature Request] Changing login screen background En este caso, el usuario ((agopo)) de Alemania (agopo [2020]) indica que le gustar´ıa poder definir un background para la p´agina de inicio de sesi´on sin necesidad de alterar las hojas de estilo de la aplicaci´on: ((I’d like to be able to change the login screen background without having to tamper with the main theme.)) Tambi´en especifica el flujo de usabilidad deseado, indicando que desear´ıa que al acceder como administrador del sistema a los ajustes de preferencias, existiese una opci´on para determinar una URL que dirija a una imagen y que esta imagen se aplique como fondo. Considerando los requisitos, el desarrollador principal incluye esta issue dentro del proyecto ((Ampache Improvement and Modernization)) y le asigna las etiquetas: UI y enhancement (Figura 3.5). 45 An´alisis y dise˜no Urtzi Gonz´alez Llaguno 3.3. An´alisis y dise˜no Esta secci´on trata los aspectos de an´alisis y dise˜no correspondientes a cada funcionalidad implementada. Al tratarse de un proyecto de gran magnitud que posee cientos de clases y tablas resulta imposible representar mediante un ´unico diagrama todas las clases del sistema, por lo que se ha decidido mostrar con cada funcionalidad las clases y tablas pertinentes a la misma. A continuaci´on, se muestran los diagramas relacionales, diagramas de clase y diagramas de secuencia de cada issue. 3.3.1. #2527 [Feature Request] Total time Una visi´on de alto nivel de esta issue consiste en: obtener la duraci´on total de una lista de reproducci´on mediante la suma de la duraci´on sus canciones y mostrar dicha informaci´on mediante la interfaz de usuario. Para ello, se ha analizado la arquitectura del programa. Identificando los lugares donde se almacenan de datos, y la comunicaci´on entre clases que permita acceder a ellos y mostrarlos. 52 Urtzi Gonz´alez Llaguno An´alisis y dise˜no Diagrama ER (#2527) En primer lugar, ha sido necesario identificar las tablas de la bases de datos que contienen la informaci´on sobre la duraci´on de las canciones (Figura 3.11). La tabla song contiene la duraci´on de una canci´on y est´a relacionada con la tabla playlist mediante la relaci´on playlist data. Adem´as toda canci´on pertenece a un artista y est´a contenida en un catalogo. Figura 3.11: Diagrama ER de la issue 2527. Diagrama de clases (#2527) A continuaci´on, se ha analizado como obtener esta informaci´on mediante las clases adecuadas. En el diagrama de clases realizado (Figura 3.12), se muestra la jerarqu´ıa de las clases que implementan las listas de reproducci´on. La clase Playlist hereda de la clase abstracta playlist object, la cual a su vez, hereda de la clase abstracta database object. Tambi´en se observa que la clase abstracta playlist object implementa la interfaz library item, la cual hereda los atributos de playable item. 53 An´alisis y dise˜no Urtzi Gonz´alez Llaguno Las clases Browse ySearch son utilizadas para realizar las consultas sobre la base de datos y obtener la duraci´on total. Figura 3.12: Diagrama de clases de la issue 2527. 54 Urtzi Gonz´alez Llaguno An´alisis y dise˜no Diagramas asociativos (#2527) Tras obtener la informaci´on, es necesario mostrarla mediante la interfaz de usuario. Para facilitar esta labor, se han elaborado diagramas que asocian los elementos de la interfaz de usuario con las clases del sistema. En este caso, dos p´aginas de la interfaz muestran la informaci´on relativa a las listas de reproducci´on: (1) el script show playlists (Figura 3.13) se encarga de mostrar una lista de las listas de reproducci´on existentes y (2) el script show playlist (Figura 3.14) muestra los elementos o canciones contenidas en una lista de reproducci´on concreta. Figura 3.13: Interfaz de la p´agina show playlists. 55 An´alisis y dise˜no Urtzi Gonz´alez Llaguno Figura 3.14: Interfaz de la p´agina show playlist. Diagrama de secuencia (#2527) Es posible conseguir una visi´on m´as en detalle mediante el empleo de un diagrama de secuencia donde se describa la secuencia de acciones (Figura 3.15). El script show playlists muestra al usuario las listas de reproducci´on existentes (Figura 3.13) y el usuario selecciona una de las listas. Tras hacerlo, se instancia a la clase Playlist, la cual solicita a la base de datos la informaci´on de la lista de reproducci´on. Tras la instanciaci´on del objeto Playlist seleccionado, la informaci´on es mostrada por el script show playlist.inc.php (Figura 3.14). En esta p´agina se muestra tanto la informaci´on relativa a una lista de reproducci´on especifica, como las canciones que contiene. En show playlist.inc.php se delega la obtenci´on de informaci´on a la clase Browse, la cual conociendo el atributo id de la Playlist, realiza una consulta al SGBD y obtiene la duraci´on total (en segundos). Finalmente, la clase Browse llama al script show playlist medias.inc.php el cual muestra al usuario la duraci´on total de la lista de reproducci´on. 56 Urtzi Gonz´alez Llaguno An´alisis y dise˜no Figura 3.15: Diagrama de secuencia de la issue 2527. 57 An´alisis y dise˜no Urtzi Gonz´alez Llaguno 3.3.2. #2582 [Feature Request] Changing login screen background Tras realizar un an´alisis de esta issue, se ha identificado que para su implementaci´on es necesario a˜nadir una nueva opci´on de configuraci´on a los ajustes de Ampache. Examinando las opciones de configuraci´on ya existentes para otros ajustes, se ha realizado un dise˜no que se asemeje al funcionamiento de las mismas. Diagrama ER (#2582) Primero se ha identificado cu´ales son las tablas de la bases de datos que almacenan los ajustes de las preferencias de usuario. Esta informaci´on es almacenada en las tablas: user,user preference ypreference. La tabla user, que almacena los usuarios del sistema, est´a relacionada con m´ultiples valores de la tabla user preference la cual sirve de nexo con la tabla preference que es donde se almacenan los atributos de cada ajuste (Figura 3.16). Por lo que es necesario realizar dos inserciones: la primera en la tabla preference con los atributos necesarios para poder almacenar el fondo de pantalla que defina el usuario y la segunda en la tabla user preference para enlazar el ajuste con el usuario que lo haya definido. 58 Urtzi Gonz´alez Llaguno An´alisis y dise˜no Figura 3.16: Diagrama ER de la issue 2582. Diagrama de clases (#2582) Esta issue involucra la modificaci´on de tres clases: Update,Preference yUI (Figura 3.17). Update es la clase encargada de las actualizaciones del esquema de la bases de datos, por lo que es en ella donde se introducen las modificaciones mencionadas en la subsecci´on anterior. La clase Preference, que hereda de la clase abstracta database object, es donde se gestionan las preferencias de Ampache. Es en esta clase donde se habilitar´a la l´ogica que permita al usuario modificar la nueva preferencia introducida desde el panel de control de Ampache. Al ser una funcionalidad que muestra un elemento visual (el fondo de pantalla), tambi´en es necesaria una modificaci´on de la clase UI de modo que se muestre gr´aficamente la imagen definida por el usuario. 59 An´alisis y dise˜no Urtzi Gonz´alez Llaguno Figura 3.17: Diagrama de clases de la issue 2582. 60 Urtzi Gonz´alez Llaguno An´alisis y dise˜no Diagrama asociativos (#2582) Con el objetivo de obtener una representaci´on visual que facilite la comprensi´on de los elementos a modificar, se han generado unos diagramas (Figuras 3.18 y3.19) que asocian los elementos de la interfaz a las clases correspondientes. Por una parte, se ha identificado que la l´ogica de la p´agina de inicio de sesi´on se encuentra en el archivo login.php. Sin embargo, para mostrar un fondo de pantalla, no es necesaria la modificaci´on de la l´ogica de inicio de sesi´on, sino la introducci´on de un nuevo estilo en la clase UI.class.php. Por otra parte, es necesaria la introducci´on de una nueva preferencia y que esta sea accesible desde la p´agina de ajustes preferences.php. Para ello se insertar´a una nueva variable custom login backgound que permita la modificaci´on de esta nueva preferencia desde la p´agina de preferencias. Figura 3.18: Interfaz de la p´agina login.php. 61 An´alisis y dise˜no Urtzi Gonz´alez Llaguno 3.3.4. Cliente React - Favoritos Al acceder a una lista de canciones (pistas de un ´album, canciones de una lista de reproducci´on, etc.), un usuario dispone de un bot´on con forma de coraz´on para marcar una canci´on como favorita (Figura 3.25). Figura 3.25: Estado actual de la funcionalidad favoritos. En el presente, la funcionalidad de este bot´on no est´a implementada, por lo que, si se pulsa, no se produce ninguna acci´on. El objetivo consiste en conectar el frontend React con el backend de modo que quede registrada esta acci´on. Diagramas de secuencia (Favoritos) Cuando un usuario accede a una lista de canciones (´albumes, playlists, etc.), cada canci´on se muestra en una fila mediante el elemento SongRow. Para a˜nadir o eliminar una canci´on de favoritos, un usuario puede pulsar el bot´on con forma de coraz´on. Esta acci´on lanza una llamada a la API para invertir el valor existente de la etiqueta favoritos y devuelve en un JSON el valor actualizado (Figura 3.26). 68 Urtzi Gonz´alez Llaguno An´alisis y dise˜no Al usuario se le informa del resultado de esta acci´on, tanto si el proceso es exitoso como si sucede alg´un error, mediante un pop-up con estilo toast. Figura 3.26: Diagrama de secuencia de la funcionalidad favoritos. 69 Desarrollo Urtzi Gonz´alez Llaguno 3.4. Desarrollo Esta secci´on detalla el proceso individual seguido en la implementaci´on de cada issue. Se trata de un proceso iterativo que parte de una soluci´on inicial, incluye cambios en base a la retroalimentaci´on de la comunidad y concluye con un resultado final. Se incluye tambi´en una explicaci´on de los problemas encontrados y las soluciones propuestas en este proceso de desarrollo. 3.4.1. #2527 [Feature Request] Total time Primera aproximaci´on Para evitar el desarrollo de c´odigo redundante, se ha realizado una b´usqueda de funciones ya definidas que faciliten la implementaci´on de esta funcionalidad. En este caso, se ha encontrado que existe una funci´on get total duration() (C´odigo 3.1) la cual realiza una suma de tiempos a nivel de BD. Partiendo de ella, se ha incluido una nueva columna en la p´agina show - playlists.inc.php. Esta columna, muestra los segundos calculados por get total duration() en un formato HORAS:MINUTOS:SEGUNDOS para una mejor comprensi´on (Figura 3.27). 70 Urtzi Gonz´alez Llaguno Desarrollo 1/** 2* get_total_duration 3* Get the total duration of all songs. 4* @return string | null 5*/ 6 7public function get_total_duration () 8{ 9$songs = $this -> get_songs (); 10 $idlist = ’(’ . implode (’,’,$songs) . ’)’; 11 if ($idlist == ’() ’) { 12 return null; 13 } 14 $sql = " SELECT SUM(‘time ‘) FROM ‘song ‘ WHERE ‘id ‘ IN $idlist"; 15 $db_results = Dba :: read( $sql); 16 17 $results = Dba :: fetch_row ( $db_results); 18 19 return $results [’0’]; 20 } C´odigo 3.1: Funci´on get total duration(). Figura 3.27: Cambios en la p´agina show playlists.inc.php para mostrar la duraci´on total. 71 Desarrollo Urtzi Gonz´alez Llaguno Cambios en base a retroalimentaci´on Tras realizar esta primera aproximaci´on, el usuario que inicialmente abri´o la issue propone incluir5esta misma informaci´on tambi´en en la p´agina show - playlist.inc.php. Siguiendo su propuesta, se realiza un nuevo commit en el que se incluye el tiempo total junto al elemento Item Count de la interfaz (Figura 3.28). Figura 3.28: Cambios en la p´agina show playlist.inc.php para mostrar la duraci´on total. 5@4phun (creador de la issue)((Hi, this is cool! Can we get it on the playlist screen too? Where the songs are displayed.)) 72 Urtzi Gonz´alez Llaguno Desarrollo Problemas y soluciones con la implementaci´on Con los nuevos cambios se descubre un problema: la p´agina show playlist.inc.php solamente funciona con las listas de reproducci´on de tipo Playlist, mientras que la p´agina no carga para las de tipo Smart Playlist. Las Smart Playlist son listas de reproducci´on generadas en base a filtros (p. ej. en base a rangos en las fechas de publicaci´on). Debido a este motivo, son objetos de tipo Search en lugar de tipo Playlist. Esto hace que la llamada a la funci´on get total duration() genere un error6dado que no encuentra el objeto Playlist esperado. Este problema se ha solucionado realizando una comprobaci´on del tipo de objeto recibido. Comprobando mediante un operador ternario cual es el tipo de objeto recibido para poder llamar a la funci´on get total duration() con los par´ametros adecuados (C´odigo 3.2). 1$playlist_duration = $playlist === NULL ? $search -> get_total_duration ( $object_ids) : $playlist -> get_total_duration ();?> C´odigo 3.2: Comprobaci´on de clase mediante operador ternario. Tras su resoluci´on, se ha procedido a la realizaci´on de pruebas descritas en la secci´on ((4.1 Pruebas de calidad)). 6PHP Fatal error: Uncaught Error: Call to a member function on null 73 Desarrollo Urtzi Gonz´alez Llaguno 3.4.2. #2582 [Feature Request] Changing login screen background Primera aproximaci´on En primer lugar se han analizado las preferencias existentes en busca de una con un funcionamiento similar a tener como referencia. Tras esta b´usqueda se ha encontrado la preferencia ((Custom URL - Login page logo)), la cual permite modificar el logotipo de Ampache por uno definido por el usuario. Siguiendo la misma l´ogica se ha a˜nadido en la funci´on show custom - style() (C´odigo 3.3) un estilo para mostrar gr´aficamente el fondo de pantalla si este est´a definido. 1public static function show_custom_style () 2{ 3 if ( AmpConfig :: get (’custom_login_background’)) { 4 echo "<style > body { background - image : url (’" . AmpConfig :: get( ’custom_login_background’)." ’) ! important ; }</ style >"; 5} 6 7} C´odigo 3.3: Adici´on realizada a la funci´on show custom style(). La inserci´on de la nueva preferencia en la base de datos se ha definido mediante la funci´on update 400020() (C´odigo 3.4). Esta funci´on muestra el c´odigo de una migraci´on de la base de datos donde se a˜nade la entrada custom login background en la tabla preference de la base de datos. 74 Urtzi Gonz´alez Llaguno Desarrollo 1/** 2* update_400020 3* 4* Customizable login background image 5*/ 6 7public static function update_400020 () 8{ 9$retval = true ; 10 11 $sql = " INSERT INTO ‘preference ‘ (‘name ‘, ‘value ‘, ‘ description ‘, ‘level ‘, ‘type ‘, ‘catagory ‘, ‘ subcatagory ‘) ". 12 " VALUES (’ custom_login_background ’, ’’, ’ Custom URL - Login page background ’, 75, ’string ’, ’interface ’, ’ custom’)"; 13 $retval &= Dba :: write ( $sql); 14 $row_id = Dba :: insert_id (); 15 $sql = " INSERT INTO ‘ user_preference ‘ VALUES ( -1 ,? , ’’)"; 16 $retval &= Dba :: write ($sql , array ($row_id )); 17 18 return $retval; 19 } C´odigo 3.4: Funci´on update 400020(). El n´umero 400020 sigue la nomenclatura7utilizada para mantener el control de las migraciones de la base de datos. Las migraciones se realizan de manera secuencial y el n´umero 400020 de esta inserci´on representa la versi´on 4.0 actualizaci´on 20. Tambi´en se ha a˜nadido el string ((Custom URL - Login page background)) a los archivos de traducci´on messages.pot ytranslatable database - strings.txt para permitir su traducci´on a los m´as de 20 idiomas en los que est´a disponible Ampache. 7((This class mainly handles schema updates for the database. Versions are a monotonically increasing integer: First column(s) are the major version, followed by a single column for the minor version and four columns for the build number. 3.6 build 1 is 360000; 10.9 build 17 is 1090017.)) 75 Desarrollo Urtzi Gonz´alez Llaguno Tras realizar los cambios mencionados, se ha conseguido a˜nadir exitosamente la nueva preferencia ((Custom URL - Login page background)) en la p´agina de ajustes (Figura 3.29) y que se muestre la imagen en la p´agina de inicio de sesi´on (Figura 3.30). Figura 3.29: Cambios en la p´agina show preferences.inc.php para mostrar la nueva preferencia. Figura 3.30: P´agina de inicio de sesi´on tras definir un fondo. 76 Urtzi Gonz´alez Llaguno Desarrollo 3.4.3. Cliente React - P´agina ´albumes En las issues anteriores se han a˜nadido funcionalidades a una p´agina ya existente. En cambio, en esta ocasi´on se est´a desarrollando el m´odulo principal de una p´agina. Primero de todo, se ha a˜nadido una regla de enrutamiento en router.tsx de tal modo que cuando un usuario acceda a la ruta /albums deje de obtener un error 404 y, en su lugar, se muestre la p´agina de ´albumes. La informaci´on relativa a los ´albumes se obtiene mediante una llamada a la API. Para realizar esta llamada, se ha definido la funci´on getAlbums en la capa l´ogica del cliente (C´odigo 3.5). 1const getAlbums = ( authKey : AuthKey , includeSongs = false ) => { 2let includeString = ’’; 3 if (includeSongs) { 4includeString += ’& include []= songs ’; 5} 6const getUrl = ‘${ process . env. ServerURL }/ server /json . server .php ? action = albums & auth =${authKey}${ includeString }& version =400001 ‘; 7 return axios. get( getUrl ). then (( response ) => { 8const JSONData = response . data; 9 if (! JSONData ) { 10 throw new Error (’Server Error ’); 11 } 12 if ( JSONData . error ) { 13 throw new AmpacheError ( JSONData . error ); 14 } 15 return JSONData . album as Album []; 16 }); 17 }; C´odigo 3.5: Funci´on getAlbums. En la linea 6 est´a definida la llamada a la API. En concreto, se est´a haciendo uso de la acci´on albums (Tabla 3.1) y suministrando la variable authKey que contiene la sesi´on del usuario. 77 Pruebas de calidad Urtzi Gonz´alez Llaguno Figura 4.1: Log (reducido) de las pruebas automatizadas sobre el pull request 2527. Es requisito necesario — pero no suficiente — superar todas las pruebas automatizadas para que un pull request pueda ser aceptado. Todos los pull requests propuestos en este trabajo han superado las pruebas de integraci´on. 4.1.2. Pruebas manuales #2527 [Feature Request] Total time En primer lugar, se han realizado pruebas con distintos n´umeros de elementos (1, 5 y 100) para comprobar que tanto la suma total en segundos, como su representaci´on en el formato HORAS:MINUTOS:SEGUNDOS sea correcta. Realizando estas pruebas, se ha encontrado que en la soluci´on inicial el n´umero de horas hac´ıa un overflow al llegar al valor 24 debido a representar los valores mediante la funci´on gmdate(), la cual est´a dise˜nada para representar las horas de un d´ıa. 84 Urtzi Gonz´alez Llaguno Pruebas de calidad Para solucionar este problema, se ha dividido la suma total de segundos entre 3600 obteniendo as´ı el n´umero de horas y anexando a ello los minutos y segundos obtenidos mediante gmdate(). Tras comprobar que el tiempo se muestra correctamente, se ha verificado si el tiempo de carga de la p´agina playlists.php se mantiene en un margen aceptable. Para ello, se ha comparado el tiempo de carga previo con el tiempo de carga tras introducir los nuevos cambios (Tabla 4.1). Elementos Tiempo Previo Tiempo Posterior 2 0.3539s 0.3582s 115 3.9702s 4.0244s 315 5.8598s 5.9271s Tabla 4.1: Comparaci´on en los tiempos de carga del pull request 2527. Se encuentra una diferencia de alrededor de un 1 % en los tiempos de carga. Al no tratarse de una diferencia notable, se aceptan los resultados obtenidos. #2582 [Feature Request] Changing login screen background Usabilidad En primer lugar, se ha realizado el proceso de actualizaci´on de versi´on desde el punto de vista de usuario para comprobar que la inserci´on del nuevo atributo en la tabla de la base de datos sea correcta. Al tratarse de una funcionalidad con un elemento visual, se ha realizado una comprobaci´on de su presentaci´on en distintas resoluciones. Para ello se han tomado dos dispositivos como referencia: un monitor con una resoluci´on 1080p4(Figura 4.2) y un dispositivo m´ovil con una resoluci´on nativa5(Figura 4.3). 41920 p´ıxeles de ancho y 1080 p´ıxeles de alto. 5400 p´ıxeles de ancho y 720 p´ıxeles de alto. 85 Pruebas de calidad Urtzi Gonz´alez Llaguno Figura 4.2: Comprobaci´on de la representaci´on visual de la issue 2582 en una resoluci´on de 1080p. Figura 4.3: Comprobaci´on de la representaci´on visual de la issue 2582 en una resoluci´on m´ovil de 720p. 86 Urtzi Gonz´alez Llaguno Pruebas de calidad Se puede apreciar que la imagen elegida — en este caso un rect´angulo de 100 p´ıxeles — se replica ad infinitum hasta cubrir toda la resoluci´on disponible. Este es el comportamiento esperado de la funci´on de PHP background-image utilizada para mostrar el fondo de pantalla. Seguridad Por otra parte, se ha comprobado el aspecto de seguridad de esta nueva caracter´ıstica. Al tratarse de un campo con entrada de texto libre — que adem´as introduce un valor en la base de datos — existe la posibilidad de ataques tipo inyecci´on SQL oCross Site Scripting (XSS). Un ejemplo de ataque tipo inyecci´on SQL, podr´ıa consistir en introducir en el campo de entrada la sentencia: imagen.png’); DROP TABLE preferences;-- con el objetivo de eliminar la tabla preferences de la base de datos. Sin embargo, tras intentar realizar este ataque, no se ha conseguido penetrar la seguridad del sistema. Esto es debido a que la funci´on update() de Ampache — que actualiza las preferencias — filtra adecuadamente la entrada esperada6, salvaguardando as´ı la seguridad del sistema de inyecciones maliciosas. En cuanto a los ataques XSS, estos consisten en lograr la ejecuci´on de un script malicioso en la parte del cliente que accede al sistema. Se ha probado a introducir el siguiente script inofensivo para comprobar si este vector de ataque es posible: <script>alert("hacked")</script> Nuevamente se ha verificado que este tipo de ataque no es posible en el sistema. En este caso es la funci´on get post() de la clase gen´erica core.class.php la que realiza la sanitizaci´on de la entrada eliminando los caracteres especiales (<,>,/, etc.) que pueda contener. 6Para ello utiliza la funci´on gen´erica de PHP filter var() con el filtro FILTER - SANITIZE STRING que codifica o elimina caracteres especiales (www.php.net/manual/en/ function.filter-var.php) 87 Pruebas de calidad Urtzi Gonz´alez Llaguno Cliente React - P´agina ´albumes Con el objetivo de comprobar tiempos de carga y posibles errores, se ha analizado el funcionamiento de la p´agina con distintas cantidades de ´albumes. En caso de no tener ning´un ´album en el catalogo, la p´agina de ´albumes se muestra vac´ıa correctamente. Tanto con 1 como con 50 ´albumes el tiempo de carga es adecuado y la p´agina se muestra como es esperado (Figura 3.31). Sin embargo, a partir de 100 ´albumes el tiempo de carga se convierte excesivo, el cliente tarda demasiado en obtener y mostrar la informaci´on. Para solventar esta problem´atica, el desarrollador principal ha implementado un paginamiento a modo de scroll infinito de modo que la informaci´on se obtenga progresivamente en agrupaciones de 50 ´albumes. En caso de suceder un error obteniendo las informaci´on de los ´albumes, se le informa al usuario mediante una notificaci´on con el mensaje ((Something went wrong getting the albums)). Cliente React - Favoritos Se han comprobado dos aspectos fundamentales de esta integraci´on: (1) que la interfaz sea actualizada correctamente tras pulsar el bot´on, es decir, que el icono con forma de coraz´on se rellena y vac´ıe respectivamente y (2) que la informaci´on quede almacenada en la tabla correspondiente de la base de datos. Para facilitar esta tarea e informar al usuario de que su acci´on ha sido registrada, se han a˜nadido dos notificaciones emergentes con los mensajes ((Song added to favorites)) y((Song removed from favorites)). Partiendo de una lista de canciones (Figura 4.4), cuando el usuario pulsa el bot´on de favoritos, el icono se rellena (Figura 4.5) y vac´ıa (Figura 4.6) correctamente. 88 Urtzi Gonz´alez Llaguno Pruebas de calidad Figura 4.4: Lista de canciones de un ´album. Figura 4.5: Canci´on marcada como favorita. Figura 4.6: Canci´on desmarcada como favorita. 89 Pruebas de calidad Urtzi Gonz´alez Llaguno En cuanto a la base de datos, a priori la canci´on no est´a marcada como favorita, por lo que al realizar una query se obtiene un conjunto vac´ıo (Figura 4.7). Figura 4.7: Query antes de marcar la canci´on como favorita. Tras marcarla como favorita, al volver a realizar la query se obtiene la entrada correspondiente (Figura 4.8). Figura 4.8: Query despu´es de marcar la canci´on como favorita. 90 Urtzi Gonz´alez Llaguno Integraci´on de los aportes 4.2. Integraci´on de los aportes La integraci´on de los aportes realizados al repositorio del proyecto es un proceso elemental en una contribuci´on a un proyecto open source (Figura 4.9). Figura 4.9: Proceso de integraci´on de aportes.7 El proceso est´a compuesto de los siguientes elementos: 1. Creaci´on un fork: el primer paso consiste en clonar el repositorio del proyecto a un nuevo repositorio del que se ser´a propietario y se tendr´a permisos de edici´on. 2. Creaci´on una rama: en este paso se crea una nueva rama de desarrollo y ser´a en esta nueva rama donde se incluyan los cambios pertinentes al c´odigo existente. 3. Desarrollo c´odigo: tras realizar adiciones y cambios al c´odigo existente, estas modificaciones se introducen en commits, los cuales se sincronizan con la rama del repositorio que contiene el c´odigo. 4. Solicitud de pull request: una vez terminado el desarrollo, se solicita la integraci´on con el repositorio original mediante un pull request. 5. Aprobaci´on o denegaci´on de la solicitud: los cambios propuestos son revisados por la persona que mantiene del proyecto y ser´a esta persona quien decida si los cambios son aptos o no. 7Publicado por el autor Julien Danjou. (https://julien.danjou.info/content/ images/size/w2000/2018/06/github-branching.png) 91 Integraci´on de los aportes Urtzi Gonz´alez Llaguno 4.2.1. #2527 [Feature Request] Total time El primer pull request fue solicitado en noviembre de 2020. Est´a compuesto de 7 commits que afectan a 10 archivos del repositorio. En la solicitud se indicaron los cambios y pruebas realizadas (Figura 4.10). Figura 4.10: Comentario inicial del pull request de la issue 2527. El desarrollador principal del proyecto realiz´o una pregunta8respecto a la usabilidad, la cual fue respondida. Tras realizar unos cambios menores al pull request propuesto, se acept´o su integraci´on con la rama development del proyecto Ampache (Figura 4.11). Figura 4.11: Commit en el repositorio de Ampache del pull request 2527. 8@lachlan: ((For large lists are these hour minutes seconds still?)) 92 Urtzi Gonz´alez Llaguno Integraci´on de los aportes 4.2.2. #2582 [Feature Request] Changing login screen background El pull request realizado est´a compuesto de 6 commits que modifican un total de 5 archivos. Surgi´o un problema con las pruebas automatizadas realizadas por Travis CI (Figura 4.12) dado que el c´odigo propuesto inicialmente no cumpl´ıa la normativa de estilo. Figura 4.12: Fallo del commit 40c0bb2 en el test autom´atico de Travis CI. Despu´es de realizar los cambios necesarios para adecuar el c´odigo al estilo establecido — se estaban utilizando 8 espacios para la indentaci´on de una porci´on de c´odigo que deb´ıa contener 4 espacios — los cambios se aceptaron (Figura 4.13) e integraron en la rama development del repositorio. Figura 4.13: ´ Exito en el test autom´atico de Travis CI tras realizar los cambios de estilo al c´odigo. Tras integrar los cambios, el usuario que inicialmente abri´o la issue indic´o estar satisfecho con los cambios realizados9. 9@agopo (usuario creador de la issue): ((Hey, I honestly didn’t expect this to be implemented so quickly (if at all). Thanks a lot for your work, I’m looking forward to it!)) 93 Acr´onimos API Application Programming Interface. 5,46,66–68,77,80,98 BOE Bolet´ın Oficial del Estado. 31 CSS Cascading Style Sheets. 46 EDT Estructura de descomposici´on del trabajo. 12,13,27 ER Entidad Relaci´on. 19,21,22,29 FOSS Free and open-source software. 3 FSF Free Software Foundation. 1 HTML Hypertext Markup Language. 46 ISO International Organization for Standardization. 36 101 Acr´onimos Urtzi Gonz´alez Llaguno JSON JavaScript Object Notation. 66–68,78 LSI Lenguajes y Sistemas Inform´aticos. 2 MIT Massachusetts Institute of Technology. 1 SGBD Sistema de gesti´on de bases de datos. 56 SQL Structured Query Language. 104 TFG Trabajo de Fin de Grado. 25,47 UML Unified Modeling Language. 19,30 URL Uniform Resource Locator. 45,104 XSS Cross Site Scripting. 87 102 Glosario software libre ((Software que respeta la libertad de los usuarios y la comunidad. A grandes rasgos, significa que los usuarios tienen la libertad de ejecutar, copiar, distribuir, estudiar, modificar y mejorar el software))(Foundation [2019]). 3,32 backend Capa l´ogica de acceso a los datos en un software, generalmente se refiere al servidor de la aplicaci´on. 46,68 background Imagen utilizada a modo de fondo de pantalla en una interfaz gr´afica. 45 bug Agujero, brecha o falta de seguridad de un programa de computaci´on. 40,44,82,98 codec Programa que codifica contenido y permite comprimir informaci´on. 7 commit Dentro del contexto de un sistema de control de versiones, se trata de la operaci´on que env´ıa los cambios realizados al repositorio.72,91–94 compilar Proceso que convierte el c´odigo fuente en binario para su posterior ejecuci´on por una computadora. 82,83 103 Glosario Urtzi Gonz´alez Llaguno c´odigo fuente Versi´on del software tal y como fue escrita originalmente por un humano en texto plano. Es la base desde la que se compilan los binarios ejecutables que utilizan los ordenadores (Project [2006]). 1,103,105 DAAP Acr´onimo de ((Digital Audio Access Protocol)). Es un protocolo propietario de Apple para compartir archivos multimedia a trav´es de una red local. 8 framework Entorno de trabajo que provee funciones gen´ericas modificables con el objetivo de facilitar el desarrollo del software.5,7,8,22,46 frontend Capa de presentaci´on de una aplicaci´on software.5,20,46,68 hardware Componentes f´ısicos de un sistema inform´atico, como la unidad central de procesamiento (CPU) y los dispositvos perif´ericos. 40 inyecci´on SQL Vulnerabilidad que consiste en introducir sentencias SQL en campos de texto o URLs para actuar maliciosamente sobre una base de datos. 87 issue As´ı se denomina en GitHub a una resoluci´on de un error o una propuesta de mejora. 14,18,19,21–24,27,42,44,45,47,52,58,59,70, 72,77,93,98 kernel Programa que constituye el n´ucleo central de un sistema operativo. Tiene control total sobre todo lo que ocurre en el sistema (Project [2005]). 1 log Archivo que contiene un registro de eventos. 83 104 Urtzi Gonz´alez Llaguno Glosario login M´etodo de autenticaci´on en un sistema inform´atico mediante credenciales asociadas a una cuenta. 42 metadatos Informaci´on que describe el contenido, calidad, condiciones, historia, disponibilidad y otras caracter´ısticas de los datos (secretar´ıa de Gobierno Digital Peruana [2020]). 4,8,50,51 open source Se llama as´ı a los programas inform´aticos en los que el c´odigo fuente est´a disponible para su acceso p´ublico. 5,10,91 overflow Sucede cuando de una operaci´on aritm´etica se obtiene un valor fuera del rango de valores representables. 84 P2P Acr´onimo de ((Peer-to-peer)). Es una arquitectura de red que distribuye el procesamiento entre los nodos que la forman. 106 playlist Lista de canciones y piezas musicales. Traducci´on: lista de reproducci´on. 68 pop-up Ventana emergente que se superpone al resto de elementos de la interfaz. 69 pull request Proceso de integraci´on que permite informar a otros usuarios sobre los cambios realizados en una rama de un repositorio.83,84,91–94 p´ıxel Unidad b´asica de representaci´on en una imagen digital. 85,87 query Consulta realizada sobre una base de datos. 62,90 105 Glosario Urtzi Gonz´alez Llaguno README Documento que presenta una informaci´on general sobre un proyecto, sirve a modo de carta de presentaci´on. 47 repositorio Lugar donde se almacenan archivos los archivos de c´odigo. 15,16,82, 91–93,103,105 script Lista de comandos para la automatizaci´on de tareas que se ejecutan en tiempo de ejecuci´on. 55,56,62,64,87 software ((Conjunto de programas, instrucciones y reglas inform´aticas para ejecutar ciertas tareas en una computadora))(RAE [2020]). 1,2,9,10, 12–14,19,20,29,32,40,82,103,104 stakeholder Individuo, grupo u organizaci´on que se ve afectado por el resultado de un proyecto. 12 string Secuencia de caracteres. 75 UPnP Acr´onimo de ((Universal Plug and Play)). Es un conjunto de protocolos propietarios P2P dise˜nados para permitir la conectividad entre dispositivos de distintos proveedores. 8 WebDAV Acr´onimo de ((Web Distributed Authoring and Versioning)). Es un conjunto de extensiones del protocolo HTTP que permite a los usuarios editar y administrar archivos de forma colaborativa en servidores web (Whitehead [2010]). 8 106 Bibliograf´ıa 4phun. #2527 [feature request] total time. www.github.com/ampache/ ampache/issues/2527, 2020. agopo. #2582 [feature request] changing login screen background. www. github.com/ampache/ampache/issues/2582, 2020. Oihane Albizuri. Contribuciones a un proyecto open source de ´ambito internacional: Ganttproject. Universidad del Pa´ıs Vasco, 2019. Ampache. Music streaming service. www.ampache.org, 2020. A. Arif and Z. A. Rana. Refactoring of code to remove technical debt and reduce maintenance effort. 2020 14th International Conference on Open Source Systems and Technologies (ICOSST), 2020. BOE. Resoluci´on de 7 de octubre de 2019, de la Direcci´on General de Trabajo, por la que se registra y publica el XIX Convenio colectivo del sector de empresas de ingenier´ıa y oficinas de estudios t´ecnicos. Ministerio de Trabajo, Migraciones y Seguridad Social, 2019. Eduardo Chillida. Elogio del horizonte. Conversaciones con Eduardo Chillida. Destino, 2003. Free Software Foundation. Why the affero gpl. www.gnu.org/licenses/ why-affero-gpl.en.html, 2015. Free Software Foundation. ¿qu´e es el software libre? www.gnu.org/ philosophy/free-sw.es.html, 2019. GitHub Guides. Mastering issues. https://guides.github.com/features/ issues, 2020. ISO. Gesti´on del riesgo — Directrices. International Organization for Standardization, 2018. 107 Bibliograf´ıa Urtzi Gonz´alez Llaguno Anaitz Jaio. Contribuciones a un proyecto open source de ´ambito internacional: Ganttproject. Universidad del Pa´ıs Vasco, 2019. Zhifang Liao, Benhong Zhao, Shengzong Liu, Haozhi Jin, Dayu He, Liu Yang, Jinsong Wu, and Yan Zhang. A prediction model of the project life-span in open source software ecosystem, 2017. Hans Werner Meuer. Looking back over 15 years of supercomputing experience. The TOP500 Project, 2008. Juanan Pereira. Leveraging final degree projects for open source software contributions. Electronics, 10(10), 2021. ISSN 2079-9292. URL www. mdpi.com/2079-9292/10/10/1181. The Linux Information Project. Kernel definition. www.linfo.org/kernel. html, 2005. The Linux Information Project. Source code definition. www.linfo.org/ source_code.html, 2006. RAE. Diccionario de la lengua espa˜nola. RAE, 2020. La secretar´ıa de Gobierno Digital Peruana. ¿qu´e son los metadatos? www.geoidep.gob.pe/conoce-las-ides/metadatos/ que-son-los-metadatos, 2020. Nassim Taleb. Antifragile: Things That Gain From Disorder. Random House, 2012. Eric von Hippel and Georg von Krogh. Open source software and the “private-collective” innovation model: Issues for organization science. Massachusetts Institute of Technology, 2009. Jim Whitehead. Webdav resources. www.webdav.org, 2010. YAML. The official yaml web site. www.yaml.org, 2020. 108