Un DJ Virtual como aplicación web

Universidad de Valladolid ESCUELA DE INGENIER´ IA INFORM´ ATICA GRADO EN INGENIER´ IA INFORM ´ ATICA MENCI ´ ON EN INGENIERIA DE SOFTWARE Un DJ Virtual como aplicaci´on web Alumno/a: Carlos Lobo Mata Tutor/es/as: Yania Crespo Gonz´alez-Carvajal A mis padres, que siempre me han apoyado. I II AGRADECIMIENTOS Agradecimientos A mi familia, por apoyarme desde el principio, por dif´ıcil que se lo pusiera a veces. A mi tutora Yania, por todo el trabajo que realiza a diario para ayudar a sus alumnos a aprender. A mis amigos y compa˜neros de carrera, que me acompa˜naron durante el viaje, me ense˜naron y me impulsaron a aprender muchas cosas, sin las que ahora no estar´ıa donde estoy. A mi novia Cristina, que me motiva a dar lo mejor de mi d´ıa a d´ıa. Gracias a todos III AGRADECIMIENTOS IV RESUMEN Resumen El objetivo de este proyecto es desarrollar una Aplicaci´on Web de mezcla musical, que simula una interfaz de mesa de mezclas. Est´a pensado para personas que se est´an iniciando en el mundo de la mezcla musical. El proyecto se ha desarrollado utilizando el framework Angular, Typescript, HTML y CSS siguiendo una metodolog´ıa ´agil y aplicando los principios de SCRUM. El software desarrollado se ha llamado Web Virtual DJ y se ha publicado con Licencia Publica General de GNU, versi´on 3 (GPLv3). V RESUMEN VI ABSTRACT Abstract The purpose of this project is to develop a music mixing WebApp that mimics a physical mixing table. It is designed for amateurs in music mixing. The project has been developed using the Angular framework, Typescript, HTML and CSS, following agile methodology and applying the SCRUM principles. The developed software has been named Web Virtual DJ and has been published under the GNU General Public License, version 3 (GPLv3). VII ´ INDICE GENERAL 7.7. Descarga de m´usica desde plataformas . . . . . . . . . . . . . . . . . . . . . . 89 7.7.1. Limitaciones legales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 7.7.2. Limitaciones t´ecnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 7.7.3. Evaluaci´onfinal............................... 90 7.7.4. Cambios a la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 7.8. Implementaci´on del pitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 7.9. Implementaci´on de CUE, loops y retoques finales . . . . . . . . . . . . . . . . 91 7.10.Finaldeldesarrollo................................. 92 7.11.Licencia ....................................... 92 8. Testing 93 8.1. Testsprogram´aticos ................................ 93 8.1.1. Configuraciones importantes . . . . . . . . . . . . . . . . . . . . . . . 94 8.1.2. Resultados de los test program´aticos . . . . . . . . . . . . . . . . . . . 95 8.2. Pruebasconusuarios................................ 95 8.2.1. Resultados del testing con usuarios . . . . . . . . . . . . . . . . . . . . 96 9. Conclusi´on y l´ıneas de trabajo futuras 99 9.1. Conclusiones .................................... 99 9.2. Mejorasfuturas................................... 100 ANEXOS 101 A. Manual de instalaci´on del entorno para desarrolladores 101 A.1.Requisitosprevios ................................. 101 A.2.Instalaci´on ..................................... 101 A.3.Comandos´utiles .................................. 102 B. Manual de despliegue 103 XIV ´ INDICE GENERAL C. Contenido del CD-ROM 105 Bibliograf´ıa 107 Glosario 113 XV ´ INDICE GENERAL XVI ´ INDICE DE FIGURAS ´ Indice de figuras 1.1. Interfaz de usuario de Virtual DJ [3] . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Interfaz de usuario de You.dj [4] . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Interfaz de usuario de Youtube-dj [5] . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Resumen gr´afico de Scrum [11] . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Ramasprincipales[19]............................... 19 3.2. Ramas feature [19] ................................ 20 3.3. Ramas hotfix [19]................................. 20 3.4. Relaci´on entre los elementos b´asicos de Angular [30] . . . . . . . . . . . . . . 28 3.5. Binding de datos de los componentes [31] . . . . . . . . . . . . . . . . . . . . 29 3.6. Binding de datos entre componentes [31] . . . . . . . . . . . . . . . . . . . . . 30 6.1. Flujo MVC aplicado a un servicio web [12] . . . . . . . . . . . . . . . . . . . . 55 6.2. Diagrama de componentes: Componente b´asico . . . . . . . . . . . . . . . . . 57 6.3. Diagrama de componentes: Componentes padre e hijo . . . . . . . . . . . . . 57 6.4. Diagrama de componentes: Componente con servicio . . . . . . . . . . . . . . 57 6.5. Diagrama de componentes: Componente con directiva . . . . . . . . . . . . . 58 6.6. ComponenteApp.................................. 59 6.7. ComponenteAppAbout .............................. 59 6.8. ComponenteAppDeck............................... 59 XVII ´ INDICE DE FIGURAS 6.9. Componente AppEffectsCreator . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.10. Componente AppEffectsSelector . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.11.ComponenteAppHelp ............................... 60 6.12.ComponenteAppLayout.............................. 60 6.13. Componente AppSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.14.ComponenteAppTabs ............................... 61 6.15. Componente AppVolume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.16. Componente AppMusicList . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.17. Componente RouletteController . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.18. Componente SliderController . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.19. Servicios de funcionalidad principal . . . . . . . . . . . . . . . . . . . . . . . . 63 6.20.HelpService ..................................... 64 6.21.TranslationService ................................. 64 6.22.SizeService ..................................... 64 6.23. AppDeckComponent class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.24. AppMusicListComponent class . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.25. AppEffectsCreatorComponent class . . . . . . . . . . . . . . . . . . . . . . . . 66 6.26. AppVolumeComponent class . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.27. AppTabsComponent class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.28. SliderControllerComponent class . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.29. AppEffectsSelectorComponent class . . . . . . . . . . . . . . . . . . . . . . . 66 6.30. AppLayoutComponent class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.31. AppSettingsComponent class . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.32. AppAboutComponent class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.33. AppHelpComponent class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.34.AppComponentclass................................ 67 XVIII ´ INDICE DE FIGURAS 6.35. TranslationService class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.36.PlayerServiceclass ................................. 67 6.37. MusicLoaderService class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.38. RouletteControllerComponent class . . . . . . . . . . . . . . . . . . . . . . . . 68 6.39.SizeServiceclass .................................. 68 6.40.HelpServiceclass .................................. 68 6.41.EffectsServiceclass................................. 68 6.42.EQServiceclass................................... 68 6.43. Diagrama de despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 7.1. Entornosdegitlab ................................. 78 7.2. Entornoproducci´on ................................ 79 7.3. Boceto de interfaz gr´afica de usuario . . . . . . . . . . . . . . . . . . . . . . . 80 7.4. Detalle de boceto de interfaz gr´afica, deck . . . . . . . . . . . . . . . . . . . . 81 7.5. Detalle de boceto de interfaz gr´afica, controlador de volumen . . . . . . . . . 81 7.6. Slidercontroller................................... 81 7.7. Roulette controller a) al m´aximo . . . . . . . . . . . . . . . . . . . . . . . . . 81 7.8. Roulette controller b) en el medio . . . . . . . . . . . . . . . . . . . . . . . . . 81 7.9. Implementaci´on inicial del deck . . . . . . . . . . . . . . . . . . . . . . . . . . 82 7.10. Implementaci´on inicial del volumen . . . . . . . . . . . . . . . . . . . . . . . . 82 7.11. Implementaci´on inicial de la b´usqueda . . . . . . . . . . . . . . . . . . . . . . 82 7.12. Implementaci´on inicial de la lista de m´usica . . . . . . . . . . . . . . . . . . . 83 7.13. Implementaci´on inicial de la configuraci´on . . . . . . . . . . . . . . . . . . . . 83 7.14. Implementaci´on inicial de about . . . . . . . . . . . . . . . . . . . . . . . . . . 83 7.15.Listadem´usicavac´ıa................................ 85 7.16. Lista de m´usica con b´usqueda . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 7.17. Lista de m´usica mientras arrastras . . . . . . . . . . . . . . . . . . . . . . . . 85 XIX ´ INDICE DE FIGURAS 7.18. Men´us con tama˜no normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 7.19.Men´usmaximizados ................................ 88 7.20.Crearefectos .................................... 89 7.21.Eliminarefectos1 ................................. 89 7.22.Eliminarefectos2 ................................. 89 7.23.Interfazsinb´usqueda................................ 91 XX ´ INDICE DE CUADROS ´ Indice de cuadros 2.1. Planificaci´on inicial por fechas . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2. Userstories ..................................... 15 3.1. Esquemas de prioridad CSS [23] . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1. Riesgodeenfermedad ............................... 40 4.2. Riesgo de falta de formaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.3. Riesgo de requisitos ambiguos . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.4. Riesgo de requisitos cambiantes . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.5. Riesgo de retraso en la planificaci´on . . . . . . . . . . . . . . . . . . . . . . . 41 4.6. Riesgo de problemas de hardware . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.7. Riesgo de problemas con T&C de YouTube . . . . . . . . . . . . . . . . . . . 41 4.8. Riesgo de falta de tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.9. Estimaci´on de presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.10. Horas finales invertidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.11.Costesfinales .................................... 43 5.1. Tareasdelsprint1 ................................. 46 5.2. Tareasdelsprint2 ................................. 46 5.3. Tareasdelsprint3 ................................. 47 5.4. Tareasdelsprint4 ................................. 48 XXI ´ INDICE DE CUADROS 5.5. Tareasdelsprint5 ................................. 48 5.6. Tareasdelsprint6 ................................. 49 5.7. Tareasdelsprint7 ................................. 49 5.8. Tareasdelsprint8 ................................. 50 5.9. Tareasdelsprint9 ................................. 50 5.10.Tareasdelsprint10 ................................ 51 5.11.Tareasdelsprint11 ................................ 51 XXII CAP´ ITULO 1. INTRODUCCI ´ ON Y OBJETIVOS Cap´ıtulo 1 Introducci´on y objetivos 1.1. Introducci´on En los ´ultimos a˜nos ha aumentado la popularidad de la m´usica electr´onica. Con este aumento se ha visto la aparici´on de m´ultiples aplicaciones de DJ virtual. Este es el tipo de aplicaci´on que se pretende desarrollar en este trabajo. La plataforma elegida es la Web pues garantiza portabilidad y accesibilidad. Por tanto, se pretende desarrollar la aplicaci´on como una WebApp. 1.2. Motivaci´on La idea de este proyecto surgi´o mientras se intentaba buscar un reproductor m´as complejo que los presentes habitualmente en Spotify o Youtube. Tras una b´usqueda r´apida se vio que los que estaban disponibles requer´ıan una compra y descarga, ten´ıan funcionalidades muy peque˜nas o directamente no funcionaban. 1.3. Estudio de las alternativas actuales Se ha realizado una b´usqueda m´as exhaustiva para conocer no s´olo la existencia sino tambi´en los puntos fuertes y d´ebiles de las aplicaciones similares. En los siguientes apartados se presenta el resultado de forma resumida resaltando los pros y contras de cada una de las herramientas revisadas1. 1Se utilizan t´erminos t´ecnicos para los que se ha incluido una descripci´on en el Glosario (ver p´agina 113) 1 1.6. ESTRUCTURA DE LA MEMORIA 8 CAP´ ITULO 2. PROCESO DE DESARROLLO Y PLANIFICACI ´ ON Cap´ıtulo 2 Proceso de desarrollo y planificaci´on 2.1. Scrum 2.1.1. ¿Qu´e es Scrum? Scrum [6] es un marco de trabajo simple que promueve la colaboraci´on en los equipos para lograr desarrollar productos complejos. Es un proceso de gesti´on que reduce la complejidad en el desarrollo de productos para satisfacer las necesidades de los clientes. En s´ı Scrum no es una metodolog´ıa, sino un marco para el desarrollo ´agil y la gesti´on de proyectos. Scrum se caracteriza [62] por: Aportar una estrategia de desarrollo incremental, en lugar de la planificaci´on y ejecuci´on completa del producto. La calidad del resultado se basa principalmente en el conocimiento t´ecnico de las personas en equipos auto organizados, antes que en la calidad de los procesos empleados. Solapamiento de las diferentes fases de desarrollo. Seguir los pasos del desarrollo ´agil: Desde el concepto o visi´on general de la necesidad del cliente hasta la construcci´on del producto de forma incremental a trav´es de iteraciones. Estas iteraciones (En Scrum se llaman sprints) se repiten de forma continua hasta que el cliente da por cerrada la evoluci´on del producto. El tama˜no del sprint en Scrum es fijo a lo largo de todo el desarrollo. Los artefactos del marco Scrum son [11]: 9 2.1. SCRUM Pila del producto o Product Backlog: Lista de requisitos del usuario en forma de historias de usuario (user stories). Se crea a partir de la visi´on inicial pero puede ir evolucionando durante el desarrollo. Pila del sprint o Sprint Backlog: Lista de historias de usuario que debe realizar el equipo durante el sprint para generar el incremento previsto. Incremento: Parte del producto desarrollada en un sprint en condiciones de ser usada. 2.1.2. Eventos de Scrum Los eventos de Scrum se utilizan para reducir la necesidad de reuniones no definidas en Scrum, as´ı como establecer una cadencia que permita mejorar la comunicaci´on y colaboraci´on del equipo. Todos los eventos tienen una duraci´on y una periodicidad marcadas. Los eventos de Scrum son [8, 9]: Sprint o Iteraci´on: Intervalo de tiempo con duraci´on fija, de entre 1 y 4 semanas, donde se desarrolla el incremento de un producto, potencialmente entregable. La periodicidad est´a dada por la duraci´on del sprint y mientras dure el proyecto siempre hay un sprint activo. Reuni´on de planificaci´on de Sprint o Sprint Planning: Reuni´on que se realiza una vez por sprint. La duraci´on de esta reuni´on puede variar dependiendo del n´umero de personas involucradas, siendo de entre dos y cuatro horas en condiciones normales (aunque puede llegar en condiciones especiales a durar una jornada de trabajo completa). Trata de responder a dos preguntas “¿Qu´e va a ser entregado en el incremento resultante del pr´oximo Sprint?” y “¿C´omo se va a realizar el trabajo seleccionado?”. Es decir, elegir qu´e elementos forman parte del siguiente Sprint Backlog. El Scrum diario o Daily Scrum: Es una reuni´on de 15-30 minutos cuyo objetivo es que el equipo de desarrollo sincronice actividades, y cree un plan para las pr´oximas 24-48 horas. Se realiza cada d´ıa (o cada dos d´ıas en caso de no haber tanta disponibilidad). Revisi´on del Sprint o Sprint Review: Se lleva a cabo al final de cada sprint con el objetivo de inspeccionar el incremento y adaptar, si es necesario, el Product Backlog. Retrospectiva del sprint o Sprint Retrospective: Se lleva a cabo al final de cada sprint tras el Sprint Review y es la oportunidad para el Equipo Scrum de analizar qu´e ha salido bien y qu´e ha salido mal en el ´ultimo sprint y crear un plan de mejoras para ejecutar durante el siguiente sprint. 2.1.3. Participantes de Scrum Los participantes de Scrum o roles [10] son: 10 CAP´ ITULO 2. PROCESO DE DESARROLLO Y PLANIFICACI ´ ON Facilitador o Scrum master: Persona que lidera el equipo gui´andolo para que cumpla las reglas y procesos del marco de trabajo, as´ı como act´ua de facilitador durante las reuniones para lograr que sean productivas. Tambi´en ayuda al equipo a salir de situaciones de bloqueo y ense˜na al equipo a auto gestionarse [61]. Product owner: Representante de los accionistas y/o clientes que usan el software. Se focaliza en la parte de negocio. Traslada la visi´on del proyecto al equipo, formaliza las prestaciones en historias de usuario a incorporar en el Product Backlog y las reprioriza de forma regular. Equipo: Grupo de profesionales con los conocimientos t´ecnicos necesarios para el desarrollo del producto. Desarrollan las historias de usuario elegidas para cada Sprint. Interesados: Resto de implicados. S´olo pueden asesorar y observar. En la Figura 2.1 se muestra un resumen gr´afico de todo lo explicado anteriormente. 2.1.4. Requisitos de Scrum Para poder poner en pr´actica Scrum se deben cumplir ciertos requisitos [7]: Cultura de empresa: La cultura de la empresa proveedora del proyecto debe estar alineada con la filosof´ıa de una gesti´on ´agil de proyectos. Por ello debe fomentar el trabajo en equipo y la colaboraci´on, los equipos auto-gestionados, la creatividad del equipo y la transparencia y mejora continua. Compromiso del cliente: Scrum exige al cliente una alta implicaci´on y una dedicaci´on regular. Debe disponer siempre de una visi´on de alto nivel del producto y debe tener reflejadas sus expectativas en forma de lista de requisitos priorizada (actualizada cada sprint). Compromiso de la direcci´on: se har´an muy evidentes los obst´aculos, ya existentes y por venir, que impiden el correcto desarrollo de los proyectos y ser´a necesario tomar decisiones, realizar cambios organizativos, alinear personas y proporcionar recursos para hacer la transici´on. Compromiso del equipo: Scrum se basa en el compromiso conjunto y la colaboraci´on entre los miembros del equipo. La transparencia entre todos es fundamental para poder inspeccionar la situaci´on real del proyecto y as´ı poder hacer las mejores adaptaciones que permitan conseguir el objetivo com´un. Relaci´on entre proveedor y cliente: Debe estar basada en el principio ganar - ganar, en vez de estar basado en un contrato f´erreo de alcance, tiempo y coste. Para obtener los mejores resultados debe asumirse que habr´a cambios con respecto al documento original y puede que algunos puntos pierdan su sentido. Por tanto debe existir transparencia en la ejecuci´on del proyecto para facilitar esta relaci´on. 11 2.1. SCRUM Figura 2.1: Resumen gr´afico de Scrum [11] 12 CAP´ ITULO 2. PROCESO DE DESARROLLO Y PLANIFICACI ´ ON Facilidad para realizar cambios en el proyecto: Se debe poder incorporar requisitos de manera incremental en el proyecto sin un coste prohibitivo para el cliente. Tama˜no del equipo: El tama˜no ideal estar´a entre 5 y 9 personas. Es posible realizar Scrum con menos o m´as pero puede haber problemas derivados (con menos cualquier ausencia de una persona en el proyecto puede comprometer el desarrollo del sprint y con m´as la complejidad para comunicarse y colaborar aumenta). Localizaci´on geogr´afica: Es muy recomendable que todos los miembros del equipo compartan localizaci´on geogr´afica pues esto facilita la comunicaci´on. Dedicaci´on a tiempo completo: Es importante que los miembros del equipo se dediquen a tiempo completo para evitar da˜nar su productividad y facilitar la gesti´on de recursos humanos. Estabilidad del equipo: El equipo debe ser estable durante el proyecto, sus miembros deben cambiar lo m´ınimo posible, para poder aprovechar el esfuerzo que les ha costado construir sus relaciones interpersonales, engranarse y establecer su organizaci´on del trabajo. 2.2. Aplicaci´on de Scrum en este proyecto Para este proyecto se ha decidido aplicar Scrum. Es necesario realizar una adaptaci´on de Scrum al contexto del proyecto. La forma de aplicarlo se describe a continuaci´on. Dada la limitaci´on de personal en este proyecto, el alumno debe cumplir varios roles. Ser´a el product owner y el equipo de desarrollo (gestiona las historias de usuario y las implementa). La tutora se encargar´a de ser Scrum master y de ser un agente interesado (gu´ıa al alumno para cumplir la metodolog´ıa y asesora al alumno en otros aspectos). Se ha establecido la duraci´on del sprint en 2 semanas con “dailies” los viernes (por el tama˜no del equipo y por disponibilidad) y uno de cada dos viernes marcar´a el final de un sprint y el inicio del siguiente. Por tanto, ser´a este d´ıa en el que se realiza la revisi´on, retrospectiva del sprint finalizado y la planificaci´on del siguiente sprint. La tecnolog´ıa usada para la aplicaci´on de Scrum es GitLab y ser´a discutida en el pr´oximo cap´ıtulo. El product backlog, sprint backlog e incremento de cada sprint ser´an discutidos en los cap´ıtulos dedicados a la planificaci´on y seguimiento. 2.2.1. Planificaci´on El trabajo de fin de grado del Grado en Ingenier´ıa Inform´atica (menci´on en Ingenier´ıa del Software) tiene una valoraci´on en cr´editos total de 12 ECTS [1]. En vista de que cada cr´edito equivale a 25-30 horas de trabajo [2] este trabajo deber´ıa estar dimensionado en 300-360 horas. En este caso se tomar´a como referencia 25 horas pues es la cantidad que se usa en las asignaturas de la Escuela de Ingenier´ıa Inform´atica de Valladolid. 13 2.2. APLICACI ´ ON DE SCRUM EN ESTE PROYECTO Se planificar´a un proyecto de un total de 300 horas de dedicaci´on a este trabajo. Habiendo decidido usar metodolog´ıas ´agiles se divide la carga de trabajo en varias iteraciones o sprints. Tener iteraciones de aproximadamente 30 horas parece lo m´as adecuado. Por tanto, se tendr´an un total de 10 sprints. En vista de que dispongo de unas 15 horas por semana lo mejor ser´a que cada sprint dure 2 semanas. Esto resulta en una duraci´on de la planificaci´on de 20 semanas. Lo anterior se resume en la Tabla 2.1. Sprint Fecha de comienzo Fecha de fin Observaciones 1 06/10/2018 19/10/2018 2 20/10/2018 02/11/2018 3 03/11/2018 16/11/2018 4 17/11/2018 30/11/2018 5 01/12/2018 14/12/2018 14-21 fuera, a˜nadida semana extra 6 22/12/2018 04/01/2019 7 05/01/2019 18/01/2019 8 19/01/2019 01/02/2019 9 02/02/2019 15/02/2019 10 16/02/2019 01/03/2019 Tabla 2.1: Planificaci´on inicial por fechas Como se puede apreciar en la Tabla 2.1 la fecha estimada de finalizaci´on ser´ıa el 01/03/2019. Durante la semana del 14 al 21 de diciembre me ser´a imposible trabajar. Por tanto, el siguiente sprint empieza una semana despu´es. 2.2.2. Product Backlog o User stories Las historias de usuario que se han especificado son las que se muestran en la Tabla 2.2. 2.2.3. Tareas Las tareas que se han realizado en cada sprint se ven en el cap´ıtulo de seguimiento (Cap´ıtulo 5). 14 CAP´ ITULO 2. PROCESO DE DESARROLLO Y PLANIFICACI ´ ON N´umero T´ıtulo Descripci´on 001 Interfaz gr´afica de usuario Como usuario quiero ver una interfaz gr´afica de usuario de DJ virtual 002 Cargar m´usica en local Como usuario quiero poder cargar mi m´usica desde mi ordenador a mi navegador 003 Reproducir m´usica Como usuario quiero poder reproducir y pausar m´usica 004 Modificar el volumen de la m´usica Como usuario quiero poder modular el volumen de la m´usica que estoy reproduciendo. 005 Modificar volumen de distintas frecuencias Como usuario quiero poder modificar el volumen de distintas frecuencias (agudos, medios y graves) 006 M´as de un deck Como usuario quiero poder tener m´as de una canci´on cargada y lista para reproducir a la vez 007 Cargar m´usica desde servicios de internet Como usuario quiero poder cargar m´usica desde servicios de internet 008 Cambio de pitch Como usuario quiero poder cambiar el pitch de la m´usica que est´a sonando 009 Agregar efectos Como usuario quiero poder reproducir efectos mientras suena la m´usica 010 Loops Como usuario quiero poder hacer loops con la m´usica 011 CUE Como usuario quiero poder cargar CUEs 012 Mostrar onda Como usuario quiero poder ver la onda de la m´usica que estoy escuchando Tabla 2.2: User stories 15 2.2. APLICACI ´ ON DE SCRUM EN ESTE PROYECTO 16 CAP´ ITULO 3. TECNOLOG´ IAS UTILIZADAS Cap´ıtulo 3 Tecnolog´ıas utilizadas 3.1. GitLab GitLab [15] es una aplicaci´on cuyo objetivo es ser la ´unica aplicaci´on que debes usar durante el ciclo completo de desarrollo y despliegue. Para conseguir esto, GitLab integra herramientas de planificaci´on, creaci´on, integraci´on continua, empaquetado, despliegue, configuraci´on, monitorizaci´on y seguridad. 3.1.1. Planificaci´on Gitlab integra herramientas [16] de planificaci´on como un tablero Kanban y tablero de issues, control del tiempo usado, gestor de issues, gesti´on de hitos, burndown charts, fechas de entregas para las issues, etiquetas en las issues, tableros en funci´on de etiquetas, etc... Disponer de estas herramientas es m´as que suficiente para el desarrollo que se quiere realizar. El gestor de issues permite crear las historias de usuario y las tareas y marcarlas con etiquetas. Los tableros son muy ´utiles para el seguimiento de las user stories y tareas desde su creaci´on hasta su finalizaci´on. Finalmente la gesti´on de hitos es perfecta para simbolizar los sprints. Con todas estas herramientas puedo realizar toda la gesti´on del proyecto, desde su planificaci´on. 3.1.2. Control de versiones Gitlab permite [17] crear repositorios privados gratis sin limitaci´on de miembros. Ofrece gr´aficos de commits y herramientas de reporte, documentaci´on del proyecto basado en Wiki o alojamiento de p´aginas est´aticas (para crear tu propia documentaci´on est´atica), merge 17 3.3. CSS3 Se representa en el CSS por el id precedido por un punto: . title { color : #000; font - size : 20 px; } 3.3.2. Orden de importancia Como se pueden aplicar distintos estilos de distinta forma hay un esquema de prioridades. De mayor a menor prioridad este esquema quedar´ıa como se muestra en la tabla 3.1: Prioridad Tipo de origen de CSS Descripci´on 1 Importancia La anotaci´on !important sobreescribe la prioridad anterior 2 Inline Un estilo que se aplica directamente sobre el HTML, por medio del atributo style 3 Media Type (tipo de dispositivo) Un estilo que se aplica solo en caso de tener un tipo de dispositivo especifico (m´ovil,tablet, sobremesa, etc...) 4 Definido por el usuario La mayor´ıa de los navegadores tienen esta caracter´ıstica de accesibilidad: un estilo CSS definido por el usuario 5 Especificidad del selector Un selector contextual espec´ıfico (#heading p) sobreescribe una definici´on general (p) 6 Orden de las reglas La ´ultima regla especificada tiene una mayor prioridad 7 Herencia Si una propiedad no est´a especificada, es heredada del elemento padre 8 Definici´on de propiedad CSS en el documento HTML Una regla CSS com´un (selector *) sobreescribe el valor del navegador 9 Predeterminado del navegador La prioridad m´as baja: estos valores son determinados por las especificaciones iniciales de la W3C Tabla 3.1: Esquemas de prioridad CSS [23] 3.3.3. Resumen y aplicaci´on Siguiendo con la analog´ıa presentada en HTML, si ´este era el esqueleto, CSS ser´ıa la piel. Es la parte que se puede apreciar. Por tanto se usar´a en conjunto con HTML para dise˜nar 24 CAP´ ITULO 3. TECNOLOG´ IAS UTILIZADAS c´omo est´a estructurada y c´omo se ven las vistas que se dise˜nen. 3.4. Javascript JavaScript (JS) [24] es un lenguaje de programaci´on interpretado, dialecto del est´andar ECMAScript. Est´a orientado a objetos y basado en prototipos, es imperativo, d´ebilmente tipado y din´amico. Se utiliza principalmente para desarrollar aplicaciones de cliente (client-side); implementado como parte de un navegador web permite mejoras en la interfaz de usuario y p´aginas web din´amicas. Tambi´en existe una forma de JavaScript del lado del servidor. JavaScript tiene una sintaxis similar a C, aunque adopta nombres y convenciones del lenguaje de programaci´on Java. Sin embargo, Java y JavaScript tienen sem´anticas y prop´ositos diferentes. 3.4.1. Caracter´ısticas Las siguientes caracter´ısticas son comunes a todas las implementaciones que se ajustan al est´andar ECMAScript: Imperativo y estructurado: JavaScript es compatible con gran parte de la estructura de programaci´on de C. Una salvedad a destacar: en C, el ´ambito de las variables alcanza al bloque en el cual fueron definidas, sin embargo en las implementaciones originales de JavaScript cuando se declaraba una variable como var el ´ambito de las variables era el de la funci´on en la cual eran declaradas. Esto ha cambiado con la versi´on de ECMAScript 2015, ya que a˜nade compatibilidad con block scoping por medio de la palabra clave let. De tipado din´amico: Como en la mayor´ıa de lenguajes de scripting, el tipo esta asociado al valor, no a la variable. Objetual: JavaScript est´a formado casi en su totalidad por objetos. Los objetos en JavaScript son arrays asociativos, mejorados con la inclusi´on de prototipos Con evaluaci´on en tiempo de ejecuci´on: Aunque desaconsejado, se pueden evaluar expresiones de tipo cadena en tiempo de ejecuci´on. Esto es ineficiente e inseguro. Con funciones de primera clase: Es decir, las funciones se pueden usar como variables y pueden ser pasadas a otras funciones. Protot´ıpico: Se usan prototipos y no clases para el uso de herencia. Se puede simular el comportamiento de clases con ´estos. Otras: Funciones vari´adicas, funciones como m´etodos, arrays y objetos (arrays asociativos en otros idiomas) pueden ser creados con una sintaxis abreviada, expresiones regulares similares a Perl. 25 3.5. TYPESCRIPT 3.4.2. Resumen y aplicaci´on Para finalizar la analog´ıa, ya ten´ıamos un esqueleto y una piel, pero nos faltaban los m´usculos. Javascript es el musculo de la p´agina web. Es Javascript quien permite a la p´agina moverse, por as´ı decirlo. Permite al usuario interactuar con la p´agina y con otros servicios que no est´an presentes en el navegador. Por tanto usaremos Javascript para crear el modelo y los controladores necesarios para tener una p´agina funcional. Aun as´ı para facilitarnos las cosas no usaremos Javascript directamente. Usaremos un framework y un superset de Javascript. Estos permiten a˜nadir funcionalidad a Javascript a la par que facilitan las tareas de programaci´on y debugueo. 3.5. TypeScript El framework elegido es Angular, que permite el uso de JavaScript o TypeScript [25]. TypeScript es un superset sint´actico estricto de JavaScript que a˜nade tipado est´atico. Est´a dise˜nado para grandes aplicaciones y traspila a JavaScript. Un programa JavaScript es un programa TypeScript v´alido. TypeScript soporta los ficheros de definici´on de estructuras de datos y sus tipos. Las principales caracter´ısticas que a˜nade a JavaScript son: Anotaciones de tipo y comprobaci´on en tiempo de compilaci´on Inferencia de tipos Interfaces Tipos enumerados Gen´ericos Espacios de nombres Tuplas 3.5.1. Resumen y aplicaci´on Typescript facilita el trabajo al programador al a˜nadir un tipado est´atico, el cual permite detectar errores en tiempo de compilaci´on, haciendo mas escalable el desarrollo de aplicaciones que traten con diferentes tipos de datos y favoreciendo la mantenibilidad. Ya que el framework elegido soporta Typescript y que ´este aporta notorios beneficios, se usar´a en este proyecto. 26 CAP´ ITULO 3. TECNOLOG´ IAS UTILIZADAS 3.6. Angular Angular [26] es un framework ideado para la creaci´on de aplicaciones web con HTML, CSS y TypeScript. Angular mejora estas tecnolog´ıas y facilita su integraci´on. Los elementos b´asicos presentes en Angular son los m´odulos, componentes y servicios: M´odulos: Un m´odulo es una clase precedida por el decorador @NgModule. Los m´odulos permiten agrupar componentes, servicios y otros elementos de funcionalidades similares. Al crear un m´odulo, m´as tarde se puede importar este m´odulo en otro y usarlo indistintamente, lo que permite seguir los principios de bajo acoplamiento y alta cohe- si´on. Se puede elegir que los m´odulos se carguen con lazy-loading. Componentes: Un componente es una clase precedida por el decorador @Component. A esta clase se asocia un template HTML y una hoja de estilos. La funcionalidad de la clase TypeScript mejora el template para dotarlo de dinamismo mediante data-binding de eventos y data-binding de propiedades. Servicios (e inyecci´on de dependencias): Para la carga de datos y la l´ogica que se comparte entre distintos componentes, se crea una clase de tipo servicio. Se le precede del decorador @Injectable. Esto indica que puede ser inyectado en un componente como una dependencia, permitiendo que los componentes se mantengan ligeros al delegar tareas pesadas en los servicios. Otros elementos m´as avanzados son: Routing: Existe un tipo especial de m´odulos conocidos como m´odulos de routing. Son usados para cargar m´odulos en funci´on de la ruta a la que se accede desde el navegador y son los que permiten el lazy-loading. Directivas: aplican una transformaci´on sobre un elemento del template, por ejemplo mostr´andolo solo si se cumple una condici´on, o creando un elemento por cada elemento de un array. Tuber´ıas: realizan una transformaci´on sobre una variable TypeScript pero s´olo en el template HTML, por ejemplo si se aplica la tuber´ıa JSON a un objeto, ser´ıa lo mismo que aplicarle la funci´on JSON.stringify. La relaci´on entre los elementos b´asicos de Angular se puede consultar en la Figura 3.4. 3.6.1. M´odulos Como se ha explicado, los m´odulos son clases precedidas del decorador @NgModule. Este decorador acepta un objeto de meta-datos. Los meta-datos pueden ser: declarations: qu´e componentes, directivas y tuber´ıas pertenecen a este m´odulo. 27 3.6. ANGULAR Figura 3.4: Relaci´on entre los elementos b´asicos de Angular [30] exports: el conjunto de declaraciones que ser´an visibles y usables cuando se importe este m´odulo en otros m´odulos. imports: m´odulos de los cuales se necesita importar clases. providers: servicios que usa este m´odulo, o que son inyectados en este m´odulo. bootstrap: la vista principal de la aplicaci´on. Solo el m´odulo ra´ız debe tener esta propiedad Pese a que el gestor de m´odulos de Angular es diferente y no tiene relaci´on con el gestor de m´odulos de JavaScript, ambos se pueden usar de forma complementaria para cargar m´odulos Angular y m´odulos JavaScript de forma conjunta en la misma aplicaci´on. 3.6.2. Componentes Los componentes son clases que acompa˜nadas de el template HTML y una hoja de estilos propia (opcional) conforman la vista y el controlador asociado. A este conjunto en Angular se le llama vista. Las clases componente van siempre precedidas del decorador @Component. Este decorador acepta un objeto de meta-datos. Estos meta-datos pueden ser: selector: Un selector CSS que indica a Angular que debe insertar ese componente cuando encuentre esa etiqueta en un template HTML. Por ejemplo en un componente: @Component { ... selector: ’app -hero -list ’, ... } Y en un template se usar´ıa: 28 CAP´ ITULO 3. TECNOLOG´ IAS UTILIZADAS <app -hero -list > </app -hero -list > templateUrl otemplate: la ruta relativa del template HTML o el template inline (no recomendado). providers: en caso de necesitar acceder a alg´un servicio se a˜nade aqu´ı. styleUrls ostyle: de forma opcional se le puede pasar la ruta relativa a una hoja de estilos que ´unicamente se aplicar´a al template de este componente. O pasarle los estilos directamente (no recomendado). El template HTML es como un archivo HTML normal pero con algunos a˜nadidos. En este template se pueden usar directivas y tuber´ıas y se puede usar binding de datos. Figura 3.5: Binding de datos de los componentes [31] Hay cuatro tipos de binding (Figura 3.5 y Figura 3.6)y pueden ser unidireccionales o bidireccionales: Binding con llaves: Este es el tipo mas b´asico de binding. Su funci´on es mostrar una variable del componente en el template. Por ejemplo: En el componente: numero = 5; En el template: El numero guardado es: {{ numero }} El resultado: 29 3.6. ANGULAR El numero guardado es: 5 Por supuesto una modificaci´on de la variable en el componente actualizar´ıa el valor en el template, resultando en la muestra din´amica de datos. Binding con atributos: para tener un atributo din´amico en Angular se podr´ıa hacer mediante binding con llaves pero esto puede dar problemas de rendimiento. La forma correcta de hacerlo es con un binding de atributos. Por ejemplo: <input type =" text " [id ]=" id_dinamico "/> Esto aplicar´ıa la string de la variable id dinamico como atributo id al input. Binding de eventos: permite asociar eventos t´ıpicos de JavaScript a funciones en la clase. Por ejemplo: < button ( click )=" clicked ()">Pulsame </ button > Esto asociar´ıa el evento de hacer click sobre el bot´on con la funci´on clicked de nuestro componente. Binding con ngModel: Hasta ahora todos los bindings eran unidireccionales. ngModel en cambio es bidireccional. Asocia una variable a un campo din´amico del template. En caso de que el campo cambie en el template se actualiza el valor de la variable, pero tambi´en al contrario, si se actualiza la variable el campo var´ıa. Por ejemplo: <input type =" text " [( ngModel )]=" campo_de_texto "/ > Si ahora se escribiera algo en el campo de texto la variable en el componente se modificar´ıa, y si de manera program´atica se modificara la variable el campo de texto se actualizar´ıa con este valor. Figura 3.6: Binding de datos entre componentes [31] Esto aporta dinamismo a nuestra p´agina de forma f´acil. Tambi´en se puede usar el mismo principio para pasar datos entre componentes padres e hijos. 30 CAP´ ITULO 3. TECNOLOG´ IAS UTILIZADAS 3.6.3. Tuber´ıas Las tuber´ıas se usan en el template de Angular para aplicar transformaciones a las variables que se quieren mostrar. Por ejemplo, si se quiere mostrar un objeto en el template los primero a intentar ser´ıa: {{ myObject }} Pero al ir a ver que ha mostrado la p´agina web se ver´ıa: [object Object] Esto es porque se est´a mostrando una referencia al objeto. Se podr´ıa transformar este objeto en una string y mostrar el objeto transformado, pero Angular facilita las cosas con una tuber´ıa por defecto, la tuber´ıa ser´ıa json: {{ myObject | json }} Y ahora se mostrar´ıa correctamente: { nombre: ’Carlos ’, apellido: ’Lobo ’ } Pero ´esta s´olo es una de las muchas tuber´ıas disponibles. Otras tuber´ıas permiten por ejemplo transformaci´on de palabras de singular a plural, visualizaci´on de precios en monedas distintas o transformaci´on de texto a may´usculas. Incluso se pueden crear tuber´ıas propias. Todo esto las transforma en un elemento bastante potente dentro del template. 3.6.4. Directivas Las directivas son el ´ultimo elemento usado dentro del template. Su uso var´ıa dependiendo del tipo. Hay dos tipos, directivas estructurales y directivas de atributo. Estructurales: son usadas para a˜nadir, eliminar o cambiar elementos del DOM2. Por ejemplo: <img src =" pepito .jpg " * ngIf =" mostrar "> A˜nadir esta directiva a la imagen conseguir´a que solo se muestre la imagen si la variable mostrar eval´ua a true. Pero si se cambia el valor tambi´en se cambia el estado de visualizaci´on. Esto permite mostrar y ocultar elementos bajo demanda. Otras directivas cl´asicas de este tipo son *ngFor que permite mostrar un elemento tantas veces como elementos haya en un array. o *ngSwitch que muestra un elemento u otro dependiendo del valor de una variable. 2Interfaz de plataforma que proporciona un conjunto est´andar de objetos para representar documentos XML. Es la representaci´on del template que ven los navegadores tras ser cargado. Modificarlo implica cambiar c´omo se ve la p´agina en el navegador. 31 3.6. ANGULAR De atributo: Estas alteran la apariencia o comportamiento de un elemento existente. El ejemplo mas simple es la directiva ngModel explicada mas arriba. Otro ejemplo seria ngClass. Esta directiva permite aplicar clases de forma din´amica, por ejemplo: <p [ ngClass ]="{ ’ style ’: active }" >Texto </p> Este ejemplo mostrar´ıa un p´arrafo al que se le aplica la clase style si la variable active eval´ua a true. 3.6.5. Servicios Un servicio es un valor, funci´on o caracter´ıstica que necesita nuestra aplicaci´on. Habitualmente es una clase con un prop´osito muy espec´ıfico. Los servicios son usados para encapsular la l´ogica necesaria en los componentes, pues ´estos s´olo deben usarse para la parte visual de nuestra aplicaci´on. Los componentes delegan en los servicios tareas como la persistencia de datos, validaci´on de datos de usuario o logs de errores. Los servicios pueden hacer uso de la inyecci´on de dependencias para evitar sobrecargar la aplicaci´on. 3.6.6. Inyecci´on de dependencias La inyecci´on de dependencias es una caracter´ıstica poco visual pero muy importante en Angular. La inyecci´on de dependencias se encarga de controlar que no m´as de una instancia de una clase sea cargada mientras no sea necesario. Por ejemplo, si dos componentes acceden a los mismos servicios y no hubiera control, se podr´ıan crear dos instancias de un mismo servicio. Angular se encarga, mediante la inyecci´on de dependencias, de implementar el patr´on Singleton, es decir, siempre que un componente le pide acceso a un servicio, Angular le da la referencia de la instancia que ya se hab´ıa creado de este servicio. Para esto hace uso del inyector y de los proveedores: Los proveedores son los servicios que se proveen de datos. Para poder usarse en un componente deben estar especificados en su decorador o en el decorador de su m´odulo. @Component { ... providers : [ BackendService , Logger ], ... } 32 CAP´ ITULO 3. TECNOLOG´ IAS UTILIZADAS El inyector se encarga de inyectar los servicios. Para ello requiere que toda clase de tipo servicio sea precedida de un decorador @Injectable. As´ı ser´a identificada como inyectable y podr´a ser inyectada. @Injectable({ providedIn : ’root ’, }) 3.6.7. Compilaci´on antes de tiempo Ahead of time compiling [40] o compilaci´on antes de tiempo es uno de los dos tipos de compilaci´on que se puede realizar en Angular (siendo el otro tipo just in time compiling o compilaci´on justo a tiempo). La compilaci´on antes de tiempo permite preparar los recursos de nuestra aplicaci´on para no necesitar de un servidor para ser totalmente interactivos con el usuario. Al elegir construir una aplicaci´on con compilaci´on antes de tiempo se consiguen m´ultiples ventajas: Renderizado m´as r´apido: Ni el navegador ni el servidor deben compilar la aplicaci´on para poder usarla. Ya estar´a listo para usar tras descargarse del servidor. Menos peticiones as´ıncronas: El compilador junta HTML, CSS y JS en un solo archivo, as´ı que solo se requiere de esa petici´on para que funcione. Menor tama˜no de descarga: No se debe descargar el compilador para usar en el navegador. Detecci´on temprana de errores: Algunos errores del template se detectan durante la compilaci´on. 3.7. GitLab Runner GitLab Runner [59] es un proyecto Open Source de GitLab que permite ejecutar trabajos de integraci´on continua en remoto o en local. Esto permite probar los cambios sin tener que esperar a que GitLab te asigne un worker. Por esto se ha usado para probar cambios en el pipeline de CI/CD en local. 3.8. Paquetes npm En esta secci´on se describen algunos paquetes que pueden facilitar las tareas de programaci´on y testing en este proyecto. 33 4.1. PLAN DE RIESGOS Riesgo 1 Enfermedad en un miembro del equipo Tipo Personal Probabilidad Baja Impacto Muy Alto Descripci´on Un miembro del equipo cae enfermo Plan de mitigaci´on Se ha previsto holgura entre la fecha estimada de finalizaci´on y la fecha m´axima de entrega y se ha dado holgura al presupuesto Plan de contingencia Posponer las tareas afectadas al siguiente sprint y en caso de necesidad a˜nadir un sprint m´as Tabla 4.1: Riesgo de enfermedad Riesgo 2 Falta de formaci´on Tipo T´ecnico Probabilidad Baja Impacto Medio Descripci´on El equipo no est´a suficientemente formado Plan de mitigaci´on Se han reservado parte de las horas del proyecto a formaci´on del equipo Plan de contingencia Pedir ayuda a alguien con mayores conocimientos Tabla 4.2: Riesgo de falta de formaci´on Riesgo 3 Requisitos ambiguos Tipo Contractual Probabilidad Baja Impacto Medio Descripci´on Los requisitos del proyecto son ambiguos Plan de mitigaci´on Dar mucha importancia al proceso de elaboraci´on de las user stories Plan de contingencia Revisar las user stories despu´es de cada sprint y valorar si siguen siendo claras (especialmente si se han modificado o a˜nadido user stories nuevas) Tabla 4.3: Riesgo de requisitos ambiguos Riesgo 4 Requisitos cambiantes Tipo Contractual Probabilidad Baja Impacto Alto Descripci´on Alg´un requisito del proyecto cambia Plan de mitigaci´on Usar planificaci´on ´agil, que lidia bien con requisitos cambiantes Plan de contingencia Aceptar los cambios Tabla 4.4: Riesgo de requisitos cambiantes 40 CAP´ ITULO 4. PLAN DE RIESGOS Y PRESUPUESTOS Riesgo 5 Retraso en la planificaci´on Tipo De planificaci´on Probabilidad Baja Impacto Medio Descripci´on Debido a una mala planificaci´on se necesitan m´as horas de trabajo Plan de mitigaci´on Se ha previsto holgura entre la fecha estimada de finalizaci´on y la fecha m´axima de entrega y se ha dado holgura en el presupuesto Plan de contingencia A˜nadir un sprint m´as en caso de necesidad Tabla 4.5: Riesgo de retraso en la planificaci´on Riesgo 6 Problemas de hardware Tipo T´ecnicos Probabilidad Baja Impacto Alto Descripci´on Un imprevisto en el hardware usado puede resultar p´erdida del trabajo realizado, as´ı como retrasos de planificaci´on. Plan de mitigaci´on Frecuencia alta de actualizaci´on del repositorio de software para evitar la perdida de datos. Plan de contingencia Reparar el hardware implicado y en caso necesario a˜nadir un sprint m´as. Tabla 4.6: Riesgo de problemas de hardware Riesgo 7 Problemas con T&C de YouTube Tipo Legales Probabilidad Media Impacto Alto Descripci´on Puede que no sea posible usar YouTube como servicio para la obtenci´on de m´usica Plan de mitigaci´on Estudio de la viabilidad del uso de YouTube como servicio de obtenci´on de m´usica Plan de contingencia Buscar una plataforma alternativa o descartar la funcionalidad. Tabla 4.7: Riesgo de problemas con T&C de YouTube Riesgo 8 Falta de tiempo Tipo Personal Probabilidad Baja Impacto Muy Alto Descripci´on Un miembro del equipo no tiene tiempo para trabajar Plan de mitigaci´on Se ha previsto holgura entre la fecha estimada de finalizaci´on y la fecha m´axima de entrega. Plan de contingencia Posponer el final del sprint en el que se est´a trabajando Tabla 4.8: Riesgo de falta de tiempo 41 4.2. C ´ ALCULO DE PRESUPUESTO 4.2. C´alculo de presupuesto Tras consultar el Bolet´ın Oficial del Estado [27] se ha encontrado que el salario base total para un Analista programador; Dise˜nador p´aginas web es de 22.993,74. Esto significa que para 160 horas al mes trabajadas a lo largo de 12 meses el sueldo bruto por hora es de 11,976 euros. Una empresa paga por un trabajador un extra del 30 % a la seguridad social [28]. Si adem´as asumimos alg´un beneficio social de aproximadamente un 20 % extra, una empresa tendr´ıa un coste total de 18 euros la hora de un Analista. Esto significa que para un trabajo de 300 horas el coste aproximado ser´ıa de 5400 euros. Se a˜naden al presupuesto 300 euros para gastos de iconograf´ıa e imagen en previsi´on de que deban crearse im´agenes para la interfaz de usuario. En cuanto a la amortizaci´on de hardware, se trabaja con un HP EliteBook 840 G3 valorado en 1.129 euros. Con la tabla de amortizaciones en mente [29], el coste de usar este hardware ser´ıa de 1.129 * 25 % anual * 6/12 a˜nos de trabajo estimado, es decir 141,125 euros. Se presupuesta adem´as la licencia de GitLab bronze [32] que ayudar´ıa en algunos aspectos del DevOps y la revisi´on de c´odigo, con un coste de 4 d´olares al mes o 3,45 euros al mes (16/10/2018) durante 6 meses. Esto costar´ıa 20,7 euros. El precio final estimado ascender´ıa a 5861,825 euros. A˜nadiremos un 20 % al presupuesto para contar con un colch´on de presupuesto con el que afrontar posibles riesgos. El total resultante es de 7034,19 euros (Tabla 4.9). Asunto Coste 300 horas de trabajo 5400 e Iconograf´ıa 300 e Amortizaci´on 141,125 e GitLab bronze 20,7 e Suma total 5861,825 e Total normalizado 7034,19 e Tabla 4.9: Estimaci´on de presupuesto 4.2.1. Costes finales Tras terminar todos los sprints, se han invertido un total de 323 horas como se puede ver en la Tabla 4.10. Finalmente no se contrat´o ning´un servicio de iconograf´ıa ni se contrat´o la licencia GitLab bronze, dado que se utiliza la instancia desplegada en la Escuela con funcionalidad pro 42 CAP´ ITULO 4. PLAN DE RIESGOS Y PRESUPUESTOS Sprint Horas invertidas 1 33 2 26 3 22 4 31,5 5 25 6 35 7 30 8 34 9 40,5 10 27 11 19 Total 323 Tabla 4.10: Horas finales invertidas solicitada por ser instituci´on acad´emica. Por tanto, el presupuesto final quedar´ıa como se ve en la Tabla 4.11 Asunto Coste 323 horas de trabajo 5814 e Iconograf´ıa 0 e Amortizaci´on 141,125 e GitLab bronze 0 e Suma total 5955,125 e Tabla 4.11: Costes finales Por tanto se ha calculado correctamente el presupuesto, pues el coste final queda entre el total estimado y el total normalizado. 43 4.2. C ´ ALCULO DE PRESUPUESTO 44 CAP´ ITULO 5. SEGUIMIENTO DEL PROYECTO Cap´ıtulo 5 Seguimiento del proyecto Durante el seguimiento del proyecto se han ido eligiendo tareas asociadas a las user stories, pero tambi´en otras tareas necesarias para la creaci´on del producto final, que en este caso es el producto de software y toda la documentaci´on asociada a su creaci´on. 5.1. Seguimiento sprint a sprint Se realiza un seguimiento de los sprints, tareas asociadas a cada uno y tiempo empleado en horas hombre (HH). Se documentar´a utilizando unas tablas con el identificador y tipo de tarea. Como tipos de tareas se utilizar´a: chore, us, qa, bug. Las tareas chore son necesarias para el desarrollo del proyecto pero no est´an vinculadas a una user story, las tareas us (user story) se acompa˜nar´an del id de la user story asociada, los tipos de tarea qa (quality assurance) y bug se corresponden con tareas de prueba y mejora de la calidad del c´odigo as´ı como de correcci´on de errores, respectivamente. En las tablas de seguimiento de cada sprint se incluye las HH correspondientes al tiempo invertido en la tarea y el estado de la tarea al finalizar el sprint. 5.1.1. Sprint 1 Durante el primer sprint se ha documentado la introducci´on, las metodolog´ıas y parte de las tecnolog´ıas y el planning. Tambi´en se han especificado las historias de usuario iniciales y para poder preparar el entorno de desarrollo se ha investigado el CI y CD de GitLab, testing con Jest, limpieza de c´odigo con prettier y hooks precommit con husky: Tambi´en se estima un gasto de 2 horas para labores de planificaci´on en GitLab: creaci´on de issues, creaci´on de tareas, gesti´on del tablero ´agil, gesti´on de milestones. Esto significa un tiempo invertido para este sprint de aproximadamente 33 horas. 45 5.1. SEGUIMIENTO SPRINT A SPRINT Tarea Tipo Descripci´on HH Estado T - 001 Chore Historias de usuario 1h Completado T - 002 Chore Documentar planificaci´on, calendarizaci´on, riesgos y presupuesto 3h En progreso T - 003 Chore Documentar la introducci´on y objetivos 3h Completado T - 004 Chore Documentar las metodolog´ıas y patrones 8h Completado T - 005 Chore Documentar las tecnolog´ıas 8h En progreso T - 006 Chore Preparar el entorno de desarrollo 8h En progreso Tabla 5.1: Tareas del sprint 1 Para el sprint backlog del siguiente sprint se han pasado las 3 tareas incompletas del sprint 1 y se han a˜nadido tareas asociadas a la user story 1. 5.1.2. Sprint 2 Durante este sprint se ha preparado el entorno de desarrollo con las tecnolog´ıas previamente investigadas y se han documentado estas tecnolog´ıas. Tambi´en se ha empezado a desarrollar la aplicaci´on. Se ha comenzado por la interfaz de usuario, esta es nuestra primera historia de usuario. Se ha desglosado en 2 tareas. Primero, realizar bocetos de la interfaz de usuario y segundo realizar la interfaz como tal, con HTML y CSS. Tarea Tipo Descripci´on Tiempo invertido Estado T - 002 Chore Documentar planificaci´on, calendarizaci´on, riesgos y presupuesto 3h En progreso T - 005 Chore Documentar las tecnolog´ıas 1h En progreso T - 006 Chore Preparar el entorno de desarrollo 2h Completado T - 007 US001 Bocetos de la interfaz gr´afica de usuario 3h Completado T - 008 US001 Interfaz con HTML y CSS 12h En progreso T - 009 US001 Separaci´on de la interfaz de usuario en componentes. 3h En progreso Tabla 5.2: Tareas del sprint 2 Tambi´en se han invertido 2 horas en crear un glosario de t´erminos. En total se han invertido aproximadamente 26 horas en este sprint y se han completado 2 tareas. Las tareas 2 y 5 est´an bastante avanzadas pero no se pueden completar a´un pues puede haber modificaciones. ´ Estas, junto con las tareas 8 y 9, se pasan al siguiente sprint. No se a˜naden nuevas tareas pues las tareas de la interfaz de usuario son las m´as grandes. Se deber´ıan haber separado en varias tareas m´as peque˜nas. 46 CAP´ ITULO 5. SEGUIMIENTO DEL PROYECTO 5.1.3. Sprint 3 Durante este sprint se ha seguido desarrollando la interfaz de usuario. Tambi´en se ha documentado todo este desarrollo. Tarea Tipo Descripci´on Tiempo invertido Estado T - 002 Chore Documentar planificaci´on, calendarizaci´on, riesgos y presupuesto 1h Completado T - 005 Chore Documentar las tecnolog´ıas 3h En progreso T - 008 US001 Interfaz con HTML y CSS 11h Completado T - 009 US001 Separaci´on de la interfaz de usuario en componentes. 4h Completado T - 010 Chore Documentar la implementaci´on. 3h En progreso Tabla 5.3: Tareas del sprint 3 En total se han trabajado 22 horas. Se han terminado m´ultiples tareas. La documentaci´on de las tecnolog´ıas a´un no se puede finalizar pues probablemente se usar´a alg´un paquete de npm para la reproducci´on de audio. Se han pasado las tareas no terminadas al siguiente sprint. 5.1.4. Sprint 4 Durante este sprint se ha decidido empezar a trabajar en la l´ogica, primero en cargar la m´usica desde el ordenador y segundo en poder reproducir m´usica. Estas son la user stories 2 y 3. Se ha dividido en 3 tareas: una tarea de investigaci´on y b´usqueda de una biblioteca de reproducci´on de audio (se detalla en el cap´ıtulo de tecnolog´ıas) una tarea correspondiente a la carga de m´usica local desde el ordenador una tarea correspondiente a la integraci´on de la biblioteca elegida en nuestro proyecto Tambi´en se ha documentado este desarrollo. Durante el trascurso del sprint se han a˜nadido tres tareas m´as. Una consistente en crear un servicio que se encarga de la reproducci´on de m´usica, que facilita acceder a distintas funciones del reproductor desde distintos componentes. Otra consistente en la gesti´on de volumen b´asica, correspondiente a la user story 4, que al tener el servicio ha sido bastante r´apida. La ´ultima consistente en investigar c´omo aplicar efectos de audio a la m´usica que se est´a reproduciendo. En total se han dedicado 31.5 horas en las tareas explicadas, m´as 1 hora extra para tareas de gesti´on del proyecto (gesti´on de tareas, user stories, tablero Kanban, documentaci´on de esta secci´on). 47 5.1. SEGUIMIENTO SPRINT A SPRINT Tarea Tipo Descripci´on Tiempo invertido Estado T - 005 Chore Documentar las tecnolog´ıas 0.5h En progreso T - 010 Chore Documentar la implementaci´on. 2h En progreso T - 011 US003 Investigar bibliotecas de tratamiento de audio. 8h Completada T - 012 US002 Carga de m´usica local. 5h En progreso T - 013 US003 Conexi´on con la librer´ıa elegida. 3h En progreso T - 014 US003 Servicios de reproductor de m´usica. 4h En progreso T - 015 US004 Control de volumen. 1h En progreso T - 016 US009 Investigar bibliotecas de efectos de audio. 8h En progreso Tabla 5.4: Tareas del sprint 4 5.1.5. Sprint 5 Durante este sprint se ha decidido trabajar en los efectos de audio y el volumen avanzado (que en t´erminos de implementaci´on es un efecto). Para ello se han creado las dos tareas correspondientes. Tarea Descripci´on Tiempo invertido Estado T - 005 Chore Documentar las tecnolog´ıas 0h En progreso T - 010 Chore Documentar la implementaci´on. 0h En progreso T - 017 US005 Control de volumen avanzado. 8h En progreso T - 018 US009 Implementaci´on de efectos de audio por defecto. 16h Completado Tabla 5.5: Tareas del sprint 5 En total se han dedicado 24 horas en las tareas explicadas, m´as 1 hora extra para tareas de gesti´on del proyecto. Por desgracia durante este sprint nos ha afectado el riesgo de enfermedad 4.1, lo que ha resultado en una p´erdida de 5 horas con respecto a la planificaci´on. Se aplica el plan de contingencia, posponiendo algunas tareas (sobre todo de documentaci´on) para el siguiente sprint. 5.1.6. Sprint 6 Durante este sprint primero se han usado unas 4 horas para terminar tareas no terminadas pertenecientes al anterior sprint. Despu´es se ha decidido trabajar en la customizaci´on de los efectos de audio. Para ello se han creado las tareas correspondientes. Se ha dedicado 1 hora para la documentaci´on de tecnolog´ıas as´ı como 3 horas para la documentaci´on de la implementaci´on del sprint anterior. Con esto se consigue recuperar 48 CAP´ ITULO 5. SEGUIMIENTO DEL PROYECTO Tarea Tipo Descripci´on Tiempo invertido Estado T - 005 Chore Documentar las tecnolog´ıas 1h En progreso T - 010 Chore Documentar la implementaci´on. 5h En progreso T - 020 Bug Men´us maximizables 2h Completado T - 019 US009 Implementaci´on de customizaci´on de efectos de audio 25h Completado Tabla 5.6: Tareas del sprint 6 el ritmo de trabajo esperado. Tras eso, se han dedicado 29 horas a las tareas 10, 19 y 20 asignadas a este sprint as´ı como 2 horas para tareas de gesti´on del proyecto. Por lo que se han dedicado un total de 35 horas este sprint y se han cerrado 2 tareas. 5.1.7. Sprint 7 Durante este sprint se ha investigado la viabilidad de la descarga de m´usica desde Youtube o Soundcloud, desde el punto de vista legal y t´ecnico. Tarea Tipo Descripci´on Tiempo invertido Estado T - 005 Chore Documentar las tecnolog´ıas 0h En progreso T - 010 Chore Documentar la implementaci´on. 4h En progreso T - 21 US007 Investigaci´on sobre descarga directa de m´usica y pruebas de concepto 21h Completado T - 22 US008 Implementaci´on del pitch 2h Completado Tabla 5.7: Tareas del sprint 7 Durante este sprint se han dedicado 21 horas a la investigaci´on sobre descarga de m´usica desde plataformas externas. Tambi´en se han dedicado 2 horas a implementar el pitch (US 008) y finalmente 4 horas a documentaci´on. Adicionalmente, se utiliz´o una hora para tareas de gesti´on del proyecto. Se cerraron dos tareas este sprint y se trabaj´o un total de 30 horas. 5.1.8. Sprint 8 Durante este sprint se han terminado las funcionalidades necesarias (loops y CUEs) adem´as de hacer algunos cambios para mejorar la calidad en uso del software, como son, un sistema de ayuda, la localizaci´on del software, y otros cambios menores. Durante este sprint nos ha vuelto a afectar el riesgo de enfermedad, resultando en la perdida de casi una semana entera. Por tanto se ha decidido posponer el fin del sprint una semana. Esto resulta en aplazar el fin del sprint 8 desde el 1 de febrero al 8. Aun as´ı esto permiti´o dedicar un poco mas de tiempo al sprint al final, resultando en la realizaci´on de m´as tareas de las originalmente planeadas. En total se han usado 32 horas para la realizaci´on de 49 6.2. DESARROLLO BASADO EN COMPONENTES este paradigma posee algunas ventajas: Reutilizaci´on de software Simplifica las pruebas: parte de las pruebas se hacen con el componente por separado, facilitando las pruebas generales del producto. Simplifica el mantenimiento del sistema: Cuando existe d´ebil acoplamiento entre componentes el desarrollador puede a˜nadir y quitar componentes sin afectar a otras partes del sistema. Mayor calidad: Al ser cada componente encargado de una tarea, es mas f´acil crear un componente simple, bien documentado y de calidad. Por supuesto tambi´en cuenta con inconvenientes: Documentar: la documentaci´on requiere m´as trabajo pues debe tener una documentaci´on cuidada y f´acil de entender, para facilitar su uso. M´as carga de trabajo al principio: Cuanto m´as general (o configurable) se quiere hacer un componente m´as trabajo de desarrollo y pruebas requiere. Se requiere mayor carga de trabajo a la hora de crear el componente pero menos a la hora de usarlo. Hay que estudiar para qu´e casos merece la pena. Tambi´en se puede optar por usar componentes desarrollados por otros. Tiene sus pros: Ciclos de desarrollo m´as cortos: Se usan directamente piezas con una funcionalidad que podr´ıa llevar semanas o meses implementar. Componente opaco: Si est´a bien documentado no es necesario saber c´omo es su funcionamiento interno, solo es necesario conocer sus interfaces. Pero a cambio hay contras: Dificultad para extender esos componentes directamente. En general, suele ser beneficioso usar componentes al aplicar los principios [14] de bajo acoplamiento y alta cohesi´on (glosario: cohesi´on). 6.2.2. Componentes en Angular Angular est´a pensado con el desarrollo basado en componentes en mente. En la Figura 6.2 se puede ver c´omo un componente Angular est´a formado por una clase Typescript y un template HTML. 56 CAP´ ITULO 6. DISE ˜ NO Figura 6.2: Diagrama de componentes: Componente b´asico La interacci´on entre componentes padre e hijo se puede ver en la Figura 6.3. En este diagrama se ve que el componente hijo es parte del template del padre. Esto permite al componente padre comunicarse con un hijo de forma f´acil. Figura 6.3: Diagrama de componentes: Componentes padre e hijo En cuanto a los servicios, el inyector de servicios act´ua como interfaz para el componente y permite usar los m´etodos f´acilmente. Esto se aprecia en la Figura 6.4. Figura 6.4: Diagrama de componentes: Componente con servicio Tambi´en se han usado directivas de Angular. Estas directivas act´uan como un componente reutilizable dentro de los templates, que a˜nade funcionalidades al template. Esto se puede apreciar en la Figura 6.5. Los servicios y directivas de Angular tambi´en son componentes program´aticos, pero no componentes Angular. Es decir, son piezas reutilizables de software pero no son los componentes como los entiende Angular. 57 6.2. DESARROLLO BASADO EN COMPONENTES Figura 6.5: Diagrama de componentes: Componente con directiva 6.2.3. Componentes creados Los componentes creados se pueden dividir en componentes y servicios Angular. Esto se ve en los diagramas con el estereotipo. Los componentes Angular que se han creado son: App: Encargado de contener la aplicacion completa (Figura 6.6). AppLayout: Encargado de contener la interfaz de usuario (Figura 6.12). AppDeck: Encargado de contener las platinas (Figura 6.8). AppVolume: Encargado de contener los controles de volumen y ecualizadores (Figura 6.15). AppTabs: Encargado de contener el men´u de pesta˜nas (Figura 6.14). AppMusicList: Encargado de contener la lista de m´usica (Figura 6.16). AppEffectsSelector: Encargado de contener la interfaz de selecci´on de efectos (Figura 6.10). AppEffectsCreator: Encargado de contener la interfaz de creaci´on de efectos (Figura 6.9). AppSettings: Encargado de contener la interfaz de ajustes (Figura 6.13). AppHelp: Encargado de contener la interfaz de ayuda (Figura 6.11). AppAbout: Encargado de contener la interfaz de acerca de (Figura 6.7). SliderController: Encargado de contener el control de tipo range modificado (Figura 6.18). RouletteController: Encargado de contener el control de tipo ruleta (Figura 6.17). 58 CAP´ ITULO 6. DISE ˜ NO Figura 6.6: Componente App Figura 6.7: Componente AppAbout Figura 6.8: Componente AppDeck Figura 6.9: Componente AppEffectsCreator Los servicios Angular presentes son: PlayerService: Se encarga de gestionar la reproducci´on de m´usica, volumen, efectos, CUEs y otras funcionalidades. Es un recubrimiento alrededor de la biblioteca npm Wavesurfer. Representado en la Figura 6.19. 59 6.2. DESARROLLO BASADO EN COMPONENTES Figura 6.10: Componente AppEffectsSelector Figura 6.11: Componente AppHelp Figura 6.12: Componente AppLayout Figura 6.13: Componente AppSettings MusicLoaderService: Se encarga de gestionar la carga de m´usica, tanto del ordenador al programa como de la lista de m´usica a una platina. Representado en la Figura 6.19. 60 CAP´ ITULO 6. DISE ˜ NO Figura 6.14: Componente AppTabs Figura 6.15: Componente AppVolume Figura 6.16: Componente AppMusicList EffectsService: Se encarga de gestionar los efectos existentes y permitir crear nuevos efectos o eliminarlos. Tambi´en se encarga de guardar los efectos en el almacenamiento interno del navegador para conservarlos entre sesiones y aporta 6 efectos base si es la primera vez que se inicia la aplicaci´on. Representado en la Figura 6.19. 61 6.2. DESARROLLO BASADO EN COMPONENTES Figura 6.17: Componente RouletteController Figura 6.18: Componente SliderController EQService: Se encarga de crear los filtros necesarios para tener el efecto de ecualizador. Representado en la Figura 6.19. HelpService: Se encarga de notificar a los componentes asociados qu´e elementos de la interfaz de usuario deben destacar cuando se interact´ua con el componente de ayuda. Representado en la Figura 6.20. TranslationService: Se encarga de gestionar el idioma en uso. Es un recubrimiento alrededor de la biblioteca ngx-translate. Representado en la figura 6.21. SizeService: Se encarga de controlar el tama˜no de la interfaz. Pensado para si se crea una versi´on de escritorio, pues actualmente se ajusta al tama˜no disponible. Representado en la figura 6.22. En los diagramas se representan los servicios PlayerService, MusicLoaderService, EffectsService y EQService juntos, pues juntos se encargan de las funcionalidades principales de la aplicaci´on. 62 CAP´ ITULO 6. DISE ˜ NO Figura 6.19: Servicios de funcionalidad principal 63 6.2. DESARROLLO BASADO EN COMPONENTES Figura 6.20: HelpService Figura 6.21: TranslationService Figura 6.22: SizeService 64 CAP´ ITULO 6. DISE ˜ NO 6.3. Diagrama de clases Habiendo visto la estructura de la aplicaci´on en tiempo de ejecuci´on mediante componentes y la comunicaci´on entre los mismos, queda detallar las clases que realizan en tiempo de compilaci´on las interfaces y funcionalidad de los componentes representados. No se representa el m´odulo principal AppModule, porque es una clase cuya ´unica funci´on en este proyecto es agrupar todos los componentes, servicios y m´odulos y es una clase vac´ıa. Los clases presentes son: Figura 6.23: AppDeckComponent class Figura 6.24: AppMusicListComponent class AppComponent: la clase del componente principal. Se encarga de inicializar el servicio de traducciones y evitar que el evento drop se propague m´as arriba en la jerarqu´ıa del DOM. Esto es necesario para evitar salir de la p´agina al intentar cargar m´usica arrastrando. Detallada en la Figura 6.34. AppLayoutComponent: Se encarga de la gesti´on del tama˜no de ventana. Detallada en la Figura 6.30. 65 6.5. DESPLIEGUE Figura 6.43: Diagrama de despliegue 72 CAP´ ITULO 7. IMPLEMENTACI ´ ON Cap´ıtulo 7 Implementaci´on 7.1. CI/CD Antes de empezar el desarrollo se prepar´o un pipeline de integraci´on continua y despliegue continuo, para automatizar algunos procesos necesarios para la ingenier´ıa de software. Esto se realizo con el formato usado por GitLab. El fichero final de integraci´on continua es el siguiente: image : node : latest cache : paths : - node_modules/ test_unit : before_script : - apt -get update -yqqq - apt -get install -y xvfb - apt -get install iceweasel -yqq - apt -get install fonts - liberation libappindicator3 -1 ,→libasound2 libatk - bridge2 .0 -0 libatspi2 .0 -0 libgtk ,→-3-0 libnspr4 libnss3 libxss1 libxtst6 lsb - release ,→xdg - utils -y - wget https :// dl. google . com/ linux / direct / google -chrome - ,→stable_current_amd64.deb - dpkg -i google - chrome - stable_current_amd64 . deb ; apt -get - ,→fy install - Xvfb :99 -ac & - export DISPLAY =:99 - npm install -- silent 73 7.1. CI/CD - ./ node_modules /. bin/ webdriver -manager update --versions . ,→gecko = v0 .17.0 script: - npm run test :ci # test_e2e : # before_script : # ... # script: # - npm run e2e deploy_stage: stage : deploy environment : Stage only: - develop before_script : - npm install -- silent script: - rm ./ package - lock .json - ./ node_modules / @angular / cli /bin /ng build -- progress false ,→-- prod --base - href http :// virtualdj - stage . surge .sh - ./ node_modules /. bin/ surge -p dist /TFG --domain virtualdj - ,→stage . surge .sh deploy_prod: stage : deploy environment: Production only: - master before_script : - npm install -- silent script: - rm ./ package - lock .json - ./ node_modules / @angular / cli /bin /ng build -- progress false ,→-- prod --base - href http :// virtualdj . surge . sh - ./ node_modules /. bin/ surge -p dist /TFG --domain virtualdj . ,→surge . sh pages : stage : deploy script: - echo ‘Nothing to do ... ’ artifacts : paths : - public only: - master 74 CAP´ ITULO 7. IMPLEMENTACI ´ ON 7.1.1. Preparaci´on El primer par´ametro que vemos es image: image : node : latest ... Esto le indica al worker de GitLab qu´e imagen docker debe coger para desplegar el entorno de CI y CD. En este caso cogemos node:latest. Esto coge la ´ultima versi´on del contenedor oficial node [60]. Este suele ser un linux bastante limpio con lo necesario para correr node desde el primer momento. El siguiente par´ametro es cache: ... cache : paths : - node_modules/ ... Esto le indica al worker que tras la ejecuci´on debe guardar la carpeta en cach´e y al principio de la ejecuci´on debe cargar esa copia (si esta disponible). Despu´es de eso tenemos los trabajos de CI y CD. 7.1.2. Trabajos de testing Hay dos trabajos de testing pero uno de ellos esta desactivado por ahora. El trabajo disponible es test unit: ... test_unit : before_script : - ... script: - ... Se ha decidido separar cada trabajo en dos partes por claridad. La preparaci´on del script y el script en s´ı. El par´ametro before script indica que debe hacerse antes de ejecutar el script. En este apartado se suelen instalar los paquetes necesarios, tanto del sistema operativo como de npm. En nuestro caso lo primero que se hace es actualizar la lista de paquetes y dependencias y despu´es actualizar los paquetes: 75 7.1. CI/CD ... - apt -get update -yqqq - apt -get install -y xvfb ... Tras eso se instala iceweasel, que es un fork de Firefox que permite ejecutar los tests. ... - apt -get install iceweasel -yqq ... Tambi´en se instala Chrome (y todos los paquetes necesarios), para tener dos navegadores distintos a la hora de realizar tests: ... - apt -get install fonts - liberation libappindicator3 -1 ,→libasound2 libatk - bridge2 .0 -0 libatspi2 .0 -0 libgtk ,→-3-0 libnspr4 libnss3 libxss1 libxtst6 lsb - release ,→xdg - utils -y - wget https :// dl. google . com/ linux / direct / google - chrome - ,→stable_current_amd64.deb - dpkg -i google - chrome - stable_current_amd64 . deb ; apt -get - ,→fy install ... Una vez tenemos los dos navegadores instalados debemos crear una instancia de X virtual framebuffer (un servidor X11 que ejecuta todas las operaciones gr´aficas en memoria, sin mostrar nada por pantalla) y decirle a nuestro sistema que es nuestro display principal. Esto es necesario para poder ejecutar un navegador en un worker sin display. ... - Xvfb :99 -ac & - export DISPLAY =:99 ... Hecho esto solo queda instalar los paquetes npm y actualizar el paquete webdriver-manager para usar una versi´on compatible con el Chrome y Firefox que hemos instalado. ... - npm install -- silent - ./ node_modules /. bin/ webdriver - manager update -- versions. ,→gecko = v0 .17.0 ... Ahora ya estamos listos para ejecutar los tests unitarios. El comando test:ci ejecuta los tests sin el par´ametro watch y sin el par´ametro progress, para evitar sobrecargar los logs. 76 CAP´ ITULO 7. IMPLEMENTACI ´ ON ... script: - npm run test :ci El trabajo de los tests e2e ser´ıa similar en el apartado before script y solo se cambiar´ıa el comando final. ... script: - npm run e2e En estos trabajos no hemos visto el par´ametro stage. Este indica en qu´e etapa debe ejecutarse el comando, pero por defecto stage vale test por tanto en los trabajos de test no se necesita. 7.1.3. Trabajos de despliegue Tenemos dos trabajos de despliegue de la aplicaci´on y un trabajo de despliegue de la documentaci´on. Los dos trabajos de despliegue de la aplicaci´on son muy similares: deploy_stage: stage : deploy environment : Stage only: - develop before_script : - npm install -- silent script: - rm ./ package - lock .json - ./ node_modules / @angular / cli /bin /ng build -- progress false ,→-- prod --base - href http :// virtualdj - stage . surge .sh - ./ node_modules /. bin/ surge -p dist /TFG --domain virtualdj - ,→stage . surge . sh deploy_prod: stage : deploy environment: Production only: - master before_script : - npm install -- silent script: - rm ./ package - lock .json - ./ node_modules / @angular / cli /bin /ng build -- progress false ,→-- prod --base - href http :// virtualdj . surge . sh 77 7.1. CI/CD - ./ node_modules /. bin/ surge -p dist /TFG --domain virtualdj . ,→surge . sh Lo primero que vemos es el par´ametro stage. Como queremos que solo se despliegue si la etapa de tests ha sido un ´exito aqu´ı debemos elegir la etapa deploy, que va despu´es. ... stage : deploy ... Despu´es vemos el par´ametro environment. Este sirve para crear un entorno en GitLab (Figura 7.1) que m´as tarde se puede consultar (Figura 7.2): ... environment : Stage ... environment: Production ... Figura 7.1: Entornos de gitlab Tras el par´ametro environment tenemos el par´ametro only. Este nos especifica las ramas o tags con las que ejecutar este trabajo. En nuestro caso deploy stage solo se ejecuta para develop y deploy prod para master. ... deploy_stage: ... only: - develop deploy_prod: ... only: - master ... Una vez configurados estos trabajos, la ejecuci´on es muy simple. Antes del script se instalan los paquetes npm necesarios y tras esto se construye la aplicaci´on y mediante el binario ofrecido por surge se despliega cada una en el dominio elegido. 78 CAP´ ITULO 7. IMPLEMENTACI ´ ON Figura 7.2: Entorno producci´on ... before_script : - npm install -- silent script: - rm ./ package - lock .json - ./ node_modules / @angular / cli /bin /ng build -- progress false ,→-- prod --base - href http :// virtualdj - stage . surge .sh - ./ node_modules /. bin/ surge -p dist /TFG --domain virtualdj - ,→stage . surge . sh ... El tercer trabajo de la etapa de despliegue es un trabajo propio de GitLab que se encarga de desplegar la documentaci´on siempre que se hace un push a master. No hace nada pues solo crea el artefacto que despu´es GitLab despliega en tu repositorio. pages : stage : deploy script: - echo ‘Nothing to do ... ’ artifacts : paths : - public 79 7.2. BOCETOS only: - master 7.2. Bocetos El primer paso en el desarrollo de una WebApp es la realizaci´on de bocetos de la interfaz gr´afica de usuario (Figura 7.3). Para una aproximaci´on inicial se tienen 2 decks (Figura 7.4) en los que reproducir m´usica, un controlador de volumen (Figura 7.5), una b´usqueda de Youtube y una lista de m´usica En los decks estar´ıa el control del pitch, la onda de sonido, los Figura 7.3: Boceto de interfaz gr´afica de usuario botones de reproducci´on/pausa y de crear CUEs, los botones de loops, los botones de efectos y los botones de retomar CUEs. 7.3. Desarrollo de la interfaz de usuario Durante la creaci´on de la interfaz han surgido algunos problemas. Por ejemplo, es dif´ıcil dar estilos a componentes b´asicos de HTML, lo que resulta en la creaci´on de un componente Angular espec´ıfico para poder, mediante el uso de JavaScript, dar el estilo deseado. Esto ha resultado en la creaci´on de dos componentes, slider controller (Figura 7.6) y roulette controller ( Figura 7.7 y Figura 7.8). 80 CAP´ ITULO 7. IMPLEMENTACI ´ ON Figura 7.4: Detalle de boceto de interfaz gr´afica, deck Figura 7.5: Detalle de boce- to de interfaz gr´afica, controlador de volumen Figura 7.6: Slider controller Figura 7.7: Roulette controller a) al m´aximo Figura 7.8: Roulette controller b) en el medio 7.3.1. Implementaci´on inicial Durante la implementaci´on inicial se ha modificado una de las ideas de los bocetos originales. En el apartado de la lista de m´usica se han a˜nadido pesta˜nas y 2 secciones nuevas. Una ser´a para la configuraci´on de diversos par´ametros (lenguaje, aspecto, efectos elegidos para cada bot´on de efectos) y una pesta˜na de informaci´on, en la que se mostrar´a informaci´on sobre la aplicaci´on, as´ı como informaci´on sobre atribuci´on de contenidos. La implementaci´on inicial de la interfaz, a falta de la representaci´on de las ondas (que se har´a cuando se reproduzca m´usica): Deck o platina, Figura 7.9. Volumen, sin texto por encima de las ruletas, Figura 7.10. 81 7.6. CREACI ´ ON DE EFECTOS de configs es un array con las distintas configuraciones para cada efecto. Estas configuraciones pueden ser un n´umero en un rango o un selector de posibles valores. En caso de ser un n´umero dentro de un rango posee m´ınimo, m´aximo, n´umero por defecto y opcionalmente step (unidad m´ınima aceptable en el n´umero) que tiene 0.01 como valor por defecto. En caso de ser un selector tendr´ıamos un array con los posibles valores y el valor elegido por defecto. El objetivo de crear esta estructura de datos es delimitar c´omo debe ser la estructura que describe el efecto (para que sea igual a la estructura descrita en la secci´on anterior). 7.6.2. Mejoras a la interfaz Antes de empezar a crear un formulario de creaci´on/eliminaci´on de efectos se decidi´o a˜nadir una mejora a la interfaz: la posibilidad de ampliar los men´us. Esto no consigue una mejora instant´anea, pero se valor´o que para la creaci´on de efectos resultar´ıa ´util o incluso necesario. Las mejoras se pueden ver en la Figura 7.18 y la Figura 7.19. Figura 7.18: Men´us con tama˜no normal Figura 7.19: Men´us maximizados 88 CAP´ ITULO 7. IMPLEMENTACI ´ ON 7.6.3. Formulario de creaci´on Tras realizar esta modificaci´on se procedi´o al desarrollo del formulario de creaci´on de efectos. ´ Este deber´a pedir primero el tipo de efecto que se quiere crear. Una vez seleccionado, deber´a pedir un nombre y valores para la configuraci´on del efecto. Tambi´en se a˜nadi´o un formulario para eliminar efectos. La interfaz de estos formularios se puede ver en la Figura 7.20, la Figura 7.21 y la Figura 7.22. Figura 7.20: Crear efectos Figura 7.21: Eliminar efectos 1 Figura 7.22: Eliminar efectos 2 7.7. Descarga de m´usica desde plataformas Durante el sprint 7 se ha investigado la descarga de m´usica desde plataformas como Youtube, Soundcloud y otras alternativas. 7.7.1. Limitaciones legales Durante la investigaci´on se han le´ıdo t´erminos y condiciones de Youtube [47]. En ellos se puede ver que no est´a permitida la descarga de contenido a no ser que se posea el permiso directo de Youtube o de los propietarios legales del contenido descargado, o que el contenido 89 7.7. DESCARGA DE M ´ USICA DESDE PLATAFORMAS en cuesti´on est´e exento de copyright. Por tanto deber´ıa a˜nadirse en los t´erminos de uso de nuestra aplicaci´on esta limitaci´on. Esto a˜nade un gran problema a la descarga de m´usica, pues el contenido sin copyright (m´as f´acilmente accesible) es bastante limitado. Tambi´en se revisaron los t´erminos y condiciones de Soundcloud [48] encontrando directamente la prohibici´on de uso del contenido en webs externas:“No debe utilizar scraping o t´ecnicas similares para agregar, reconvertir, volver a publicar o hacer cualquier otro uso de ning´un contenido.” Esto hace que sea inviable directamente usar Soundcloud dado que actualmente no ofrecen claves para consultar a la API directamente y la ´unica forma de usarlo ser´ıa mediante scraping, y eso est´a prohibido. 7.7.2. Limitaciones t´ecnicas Habiendo descartado Soundcloud, se procedi´o a intentar conectar la aplicaci´on con Youtube. Lo primero que se intent´o fue una conexi´on directa descargando desde Youtube un v´ıdeo en formato mp4 y transformando a mp3. Esto fue frustrado pues Youtube no permite las peticiones desde otros sitios web mediante CORS [49]. Youtube bloquea la descarga de contenido desde cualquier fuente que no sea Youtube. Esto supone la necesidad de a˜nadir un servidor entre Youtube y nuestra aplicaci´on. Para comprobar la viabilidad de la creaci´on de un servidor se procedi´o a crear un servidor de prueba en Node.js, usando el mismo lenguaje que se ha usado para nuestra aplicaci´on de Frontend, Javascript. El problema que se encontr´o en ese momento fue la necesidad de descargar el v´ıdeo sin audio, la transformaci´on y m´as tarde la transferencia al cliente. Esto a˜nad´ıa una latencia bastante alta (varios minutos) desde que se empezaba la descarga en el servidor hasta que llegaba al cliente, y esto teniendo un solo cliente. En el caso de a˜nadir varios clientes m´as en paralelo el tiempo necesario aumentar´ıa. Esto, para la aplicaci´on que se est´a dise˜nando, es inaceptable. Tambi´en podr´ıa suponer un problema legal en caso de que alg´un usuario decidiera descargar contenido con copyright, pues al descargarlo previamente en nuestro servidor para despu´es transformarlo a mp3 estar´ıamos incumpliendo sus t´erminos y condiciones y descargando contenido ilegal. 7.7.3. Evaluaci´on final Tras la investigaci´on y prueba de concepto se ha decidido descartar la funcionalidad de descarga de m´usica desde un servidor, pues puede causar problemas legales (siempre en Soundcloud y en Youtube en caso de descargar contenido protegido por copyright), y tiene 90 CAP´ ITULO 7. IMPLEMENTACI ´ ON problemas t´ecnicos a la hora de implementarse, causando una mala experiencia de usuario a la hora de utilizarse (tardando varios minutos desde que se pide una canci´on hasta que consigues poder usarla en un caso b´asico). Por tanto, en estos momentos solo se puede usar la carga de m´usica desde local, que por otra parte funciona bastante r´apido (tardando pocos segundos en cargar la m´usica a nuestra interfaz tras seleccionarla), por tanto la p´erdida de esta funcionalidad no es tan problem´atica. 7.7.4. Cambios a la interfaz En vista de la eliminaci´on de la b´usqueda de m´usica se elimin´o la parte correspondiente de la interfaz, resultando la nueva interfaz vista en la Figura 7.23. Figura 7.23: Interfaz sin b´usqueda 7.8. Implementaci´on del pitch Para terminar el sprint 7 se implement´o el pitch. Dado que los componentes de interfaz ya estaban preparados solo se a˜nadieron un par de funciones que se ejecutaban al usar estos componentes. 7.9. Implementaci´on de CUE, loops y retoques finales Durante el sprint 8 se implement´o el CUE. El objetivo de los CUEs es crear un punto para retomar la canci´on. La implementaci´on final permite guardar un punto mediante el bot´on de 91 7.10. FINAL DEL DESARROLLO CUE, hasta un total de 4 puntos guardados y luego retomar la canci´on desde cualquiera de estos puntos mediante 4 botones, as´ı como resetear los CUE. Tambi´en se han realizado algunos cambios a la interfaz, como a˜nadir botones de reset, indicador del pitch actual, control de resoluci´on y indicaci´on de la incompatibilidad con un layout vertical. Tras eso, se implementaron los loops, que permiten reproducir peque˜nos fragmentos de la canci´on repetidas veces. Finalmente se ha a˜nadido al men´u una nueva pesta˜na que explica las diversas funcionalidades de la aplicaci´on, con la posibilidad de mostrar cu´al es cada una de las funcionalidades en la interfaz de usuario. Tambi´en se ha enriquecido con aspectos de localizaci´on para mejorar la usabilidad del software con muchos m´as usuarios de diferente procedencia. 7.10. Final del desarrollo Al finalizar el sprint 8 se hab´ıa terminado el desarrollo inicial de la aplicaci´on, teniendo un artefacto que cumpl´ıa todos los requisitos pedidos en las User Stories. Por tanto durante el siguiente sprint se pasar´ıa al testing. 7.11. Licencia Tras publicar la ´ultima versi´on de c´odigo en el repositorio se decidi´o publicar el software como software libre. Para ello se eligi´o la licencia GNU GPLv3 [63]. Esto se ha decidido porque no se quiere restringir al usuario que usa el software; se quiere poder ofrecer el software para que cualquiera pueda usarlo, modificarlo y compartirlo, as´ı como compartir sus propias modificaciones. 92 CAP´ ITULO 8. TESTING Cap´ıtulo 8 Testing Durante el sprint 9 se ha planificado realizar tests program´aticos as´ı como pruebas con usuarios. 8.1. Tests program´aticos Durante la preparaci´on del entorno de desarrollo en el sprint 1 se eligi´o Jest como herramienta para el testing program´atico. Esto pareci´o una buena decisi´on pues Jest era m´as r´apido que Karma, la otra alternativa. Al empezar a realizar los tests se descubri´o que Jest no era compatible con las APIs de Canvas (usada para renderizar la onda de sonido de m´usica) y WebAudio (usada para reproducir m´usica) de HTML 5. Por lo tanto se volvi´o a preparar el entorno con Karma. Una vez preparado se empezaron a realizar tests. Durante la realizaci´on de los primeros tests se solucionaron unos cuantos problemas de calidad de c´odigo. Angular trabaja con el DOM [56] (la API que permite desde Javascript interactuar con el HTML) de una forma determinada y espera que el desarrollador use las herramientas que Angular pone a su disposici´on para ello. Al no usarlas se est´an poniendo en practica antipatrones que conducen a errores. Estos errores no son notables al ejecutar la aplicaci´on, pues desde que carga hasta que se empieza a usar pueden pasar algunos segundos, que permiten a Angular recuperarse de estos errores sin que el usuario se d´e cuenta. En cambio a la hora de testear se intenta aprovechar el tiempo lo mas posible, empezando el testing milisegundos despu´es de tener cargada la p´agina. Esto resulta en errores que provocan fallos en los tests, pero que poco tienen que ver con el test en s´ı. 93 8.1. TESTS PROGRAM ´ ATICOS 8.1.1. Configuraciones importantes Dado que durante el proceso de preparaci´on del entorno de desarrollo se prepararon trabajos de CI, se modific´o la configuraci´on de Karma para testear en dos navegadores importantes (Firefox y Chrome). El fichero de configuraci´on de Karma, karma.conf.js, qued´o as´ı: module . exports = function ( config ) { config .set ({ basePath : ‘’, frameworks : [‘jasmine ’, ‘ @angular - devkit /build -angular ’] , plugins: [ require (‘karma - jasmine ’) , require (‘karma - firefox - launcher ’) , require (‘karma - chrome - launcher ’) , require (‘karma - jasmine - html - reporter ’) , require (‘karma -coverage -istanbul -reporter ’) , require (‘@angular - devkit /build - angular / plugins / karma ’) ], client: { clearContext : false // leave Jasmine Spec Runner output ,→visible in browser }, coverageIstanbulReporter: { dir : require (‘ path ’). join ( __dirname , ‘../ coverage ’) , reports : [‘html ’, ‘lcovonly ’] , fixWebpackSourcePaths: true }, reporters : [‘ progress ’, ‘kjhtml ’], port: 9876 , colors : true , logLevel : config . LOG_INFO , autoWatch : true , browsers : [‘ FirefoxHeadless ’, ‘ ChromeHeadlessNoSandbox ’] , customLaunchers : { FirefoxHeadless : { base: ‘Firefox ’, flags : [‘- headless ’] }, ChromeHeadlessNoSandbox: { base: ‘ChromeHeadless ’, flags : [‘--no -sandbox ’] } }, singleRun : false }); 94 CAP´ ITULO 8. TESTING }; Las configuraciones que se han a˜nadido son: require(‘karma-firefox-launcher’) y require(‘karma-chrome-launcher’): Esto carga configuraciones necesarias para poder usar los dos navegadores elegidos. customLaunchers: Esto permite crear instancias de navegadores con una configuraci´on personalizada. En este caso se us´o para poder abrir los navegadores en modo headless y sandbox. browsers: Esto permite elegir qu´e navegadores utilizar, a la hora de realizar la bater´ıa de tests. 8.1.2. Resultados de los test program´aticos El c´odigo asociado a tests unitarios se encuentra en la carpeta propia de cada componente. Los tests e2e, de haberlos, se encontrar´ıan en una carpeta llamada e2e a la altura del c´odigo fuente. En total se realizaron 20 tests unitarios y 0 tests e2e. Cabe destacar un test asociado a la reproducci´on de canciones. Gracias a este test se descubri´o el uso de antipatrones. La implementaci´on original de la reproducci´on estaba modificando el DOM directamente. Esto causaba errores de los cuales Angular pod´ıa recuperarse, resultando invisibles al usuario, pero el uso continuado de las funciones acababa resultando en fallos graves de memoria. Tras investigar, se sustituyeron las modificaciones directas del DOM por funciones especificas de Angular, resolviendo el problema. 8.2. Pruebas con usuarios Para realizar las pruebas con usuario primero hay que preparar la metodolog´ıa y un formulario de preguntas que realizar. La metodolog´ıa usada ser´ıa: Realizar preguntas sobre el perfil de usuario (conocimiento sobre este tipo de software). Las preguntas realizadas son: •¿Conoc´ıas este tipo de software? •¿Cu´antas veces has usado este tipo de software? Dejar entre 5 y 10 minutos al usuario con el software para probarlo. Esto permite evaluar c´omo de intuitivo es de usar el software. 95 8.2. PRUEBAS CON USUARIOS Pedir al usuario que realice distintas acciones con el software evaluando la facilidad con la que los realiza. Se eval´ua del 1 al 5 siendo 1 la no realizaci´on de la acci´on y 5 la realizaci´on inmediata. Las acciones que se pide al usuario: •Cargar una canci´on en la lista de m´usica. •Cargar otra canci´on (cuando cambia de lugar el bot´on). •Utilizar la b´usqueda de canciones. •Cargar una canci´on en una platina. •Reproducir la canci´on. •Cambiar el volumen de una platina. •Cambiar el volumen de balance entre platinas. •Modificar el volumen de los ecualizadores. •Resetear los ecualizadores. •Utilizar los CUEs. •Modificar el pitch. •Resetear el pitch. •Usar los bucles. •Usar un efecto. •Crear un nuevo efecto. •Modificar los efectos disponibles. •Modificar el idioma. Una vez ha probado el software realizar varias preguntas y se apunta su respuesta: •¿C´omo consideras la disposici´on de objetos? •¿Has visto la pesta˜na de ayuda? ¿Te ha resultado ´util? •Sugerencias de mejora •Opini´on del usuario •Otro (esta parte se reservaba para apuntar errores o bugs encontrados. 8.2.1. Resultados del testing con usuarios Los resultados m´as inmediatos del testing fueron la resoluci´on de bugs y la implementaci´on de mejoras. Se han descubierto y corregido m´ultiples bugs, como son: El plato se para despu´es de cargar la canci´on. Si el usuario crea un efecto, lo carga en los efectos disponibles, lo usa y mientras est´a en uso lo borra, el programa deja de responder correctamente. 96 CAP´ ITULO 8. TESTING Si el usuario intenta arrastrar im´agenes la lista de m´usica deja de funcionar correctamente. Si el usuario cambia la resoluci´on a una resoluci´on en la que aparece el mensaje de advertencia, al volver a una resoluci´on v´alida crear´ıa un nuevo componente visual. Pero el anterior seguir´ıa existiendo, resultando en un fallo de memoria. Tambi´en se recibieron algunas sugerencias interesantes, las cuales se implementaron: Separar la selecci´on de efectos de la pesta˜na de ajustes, para hacerlo m´as claro El bot´on de reset no estaba lo suficientemente claro A˜nadir un t´ıtulo y un favicon (icono presente al lado del nombre en las pesta˜nas de los navegadores) A˜nadir texto para indicar cu´ales son los loops Un bot´on de ampliaci´on m´as intuitivo Indicaci´on en la pesta˜na de ayuda que se puede pulsar Eliminaci´on de la restricci´on de n´umero de caracteres en los nombres de efectos Botones en la pesta˜na de ayuda m´as claros Carga de canciones arrastrando desde la lista Botones para silenciar y maximizar el volumen Por otra parte tras realizar las pruebas se procedi´o a estudiar los resultados. Se realizaron pruebas un total de 18 usuarios. En resumen: El 83,3 % (15) de los usuarios conoc´ıa este tipo de software En total contar´ıamos con 6 usuarios que hemos calificado como expertos (han usado este tipo de software al menos 10 veces) y con 7 usuarios totalmente novatos (nunca han usado este tipo de software). Todos los usuarios han completado al instante las tareas de cargar m´usica, b´usqueda, carga en la platina, reproducci´on, cambio de volumen de platinas y reset del pitch. Las tareas m´as complicadas, que al menos un usuario no fue capaz de completar son, modificar los ecualizadores y usar los loops. En las dem´as tareas no hubo mucha complicaci´on en general, con un m´aximo de 2 o 3 usuarios no complet´andolas de forma instant´anea. En general la disposici´on se considera correcta (esto es especialmente importante en los usuarios expertos, pues resulta similar al software que han utilizado). 97 104 AP´ ENDICE C. CONTENIDO DEL CD-ROM Ap´endice C Contenido del CD-ROM Los contenidos del CD-ROM: La carpeta tfg: Contiene el c´odigo fuente de la aplicaci´on desarrollada (como explica 6.4), as´ı como la documentaci´on del proyecto. La carpeta memoria: contiene la presente memoria en formato PDF, as´ı como varias im´agenes, que por su tama˜no pueden resultar dif´ıciles de leer. 105 106 BIBLIOGRAF´ IA Bibliograf´ıa [1] Web de la Escuela de Ingenier´ ıa Inform´ atica de Valladolid,Gu´ıa docente de TRABAJO DE FIN DE GRADO – MENCI ´ ON I.S., Consultado el 12/10/2018, Disponible en https://www.inf.uva.es/wp-content/uploads/2016/06/G46976.pdf [2] Wikipedia,European Credit Transfer and Acummulation System, Consultado el 12/10/2018, Disponible en https://en.wikipedia.org/wiki/European_Credit_ Transfer_and_Accumulation_System [3] Virtual DJ,Pagina oficial de Virtual DJ, Consultado el 12/10/2018, Disponible en https://es.virtualdj.com/ [4] you.dj,Aplicaci´on web you.dj, Consultado el 12/10/2018, Disponible en https://you. dj/es [5] Youtube-dj,Aplicaci´on web YoutubeDJ, Consultado el 12/10/2018, Disponible en https://youtube-dj.com/ [6] Joel Francia - Scrum.org,¿Qu´e es Scrum?, Consultado el 13/10/2018, Disponible en https://www.scrum.org/resources/blog/que-es-scrum [7] proyectosagiles.org,Requisitos para poder utilizar Scrum, Consultado el 13/10/2018, Disponible en https://proyectosagiles.org/requisitos-de-scrum/ [8] beagilemyfriend.com,¿Qu´e es un Sprint en Scrum?, Consultado el 13/10/2018, Disponible en https://www.beagilemyfriend.com/que-es-un-sprint/ [9] Marc Bara - obs-edu.com,Las 5 etapas en los “Sprints” de un desarrollo Scrum, Consultado el 13/10/2018, Disponible en https: //www.obs-edu.com/es/blog-investigacion/project-management/ las-5-etapas-en-los-sprints-de-un-desarrollo-scrum [10] softeng.es/,Proceso y Roles de Scrum, Consultado el 13/10/2018, Disponible en https://www.softeng.es/es-es/empresa/metodologias-de-trabajo/ metodologia-scrum/proceso-roles-de-scrum.html [11] Scrum Manager BoK,Artefactos, Consultado el 13/10/2018, Disponible en https: //www.scrummanager.net/bok/index.php?title=Artefactos 107 BIBLIOGRAF´ IA [12] Universidad de Alicante,Modelo vista controlador (MVC), Consultado el 13/10/2018, Disponible en https://si.ua.es/es/documentacion/asp-net-mvc-3/ 1-dia/modelo-vista-controlador-mvc.html [13] Microsoft developer network,Desarrollo de Software basado en Componentes, Consultado el 13/10/2018, Disponible en https://msdn.microsoft.com/es-es/ library/bb972268.aspx [14] Julio Pari,Alta cohesi´on y bajo Acoplamiento – Dise˜no de Software, Consultado el 13/10/2018, Disponible en http://blog.juliopari.com/ alta-cohesion-y-bajo-acoplamiento-diseno-de-software/ [15] GitLab,What is GitLab?, Consultado el 13/10/2018, Disponible en https://about. gitlab.com/what-is-gitlab/ [16] GitLab,Plan, Consultado el 13/10/2018, Disponible en https://about.gitlab.com/ stages-devops-lifecycle/plan/ [17] GitLab,Create, Consultado el 13/10/2018, Disponible en https://about.gitlab. com/stages-devops-lifecycle/create/ [18] GitLab,Verify, Consultado el 13/10/2018, Disponible en https://about.gitlab. com/stages-devops-lifecycle/verify/ [19] Vincent Driessen,A successful Git branching model, Consultado el 13/10/2018, Disponible en https://nvie.com/posts/a-successful-git-branching-model/ [20] Wikipedia,Daily build, Consultado el 13/10/2018, Disponible en https://en. wikipedia.org/wiki/Daily_build [21] Wikipedia,HTML5, Consultado el 13/10/2018, Disponible en https://es. wikipedia.org/wiki/HTML5 [22] Javier Flores Herrera - C´ odigo Facilito,¿Qu´e es HTML?, Consultado el 14/10/2018, Disponible en https://codigofacilito.com/articulos/que-es-html [23] Wikipedia,Hoja de estilos en cascada, Consultado el 14/10/2018, Disponible en https: //es.wikipedia.org/wiki/Hoja_de_estilos_en_cascada [24] MDN Web Docs,¿Qu´e es JavaScript?, Consultado el 14/10/2018, Disponible en https://developer.mozilla.org/es/docs/Learn/JavaScript/First_steps/Qu% C3%A9_es_JavaScript [25] Pagina oficial de TypeScript,TypeSCript, Consultado el 14/10/2018, Disponible en https://www.typescriptlang.org/ [26] Angular.io,JavaScript, Consultado el 14/10/2018, Disponible en https://angular. io/ [27] Bolet´ ın oficial del estado,XVII Convenio colectivo estatal de empresas de consultor´ıa, y estudios de mercados y de la opini´on p´ublica, Consultado el 15/10/2018, Disponible en https://www.boe.es/boe/dias/2018/03/06/pdfs/BOE-A-2018-3156.pdf 108 BIBLIOGRAF´ IA [28] Elvira Ramajo - Ramajo Asesores,¿Cuanto le cuesto a mi empresa?, Consultado el 15/10/2018, Disponible en https://www.ramajoasesores.com/2014/12/ cuanto-le-cuesto-a-mi-empresa/ [29] Agencia tributaria,Tabla de coeficientes de amortizaci´on lineal., Consultado el 15/10/2018, Disponible en https://www.agenciatributaria.es/AEAT.internet/ Inicio/_Segmentos_/Empresas_y_profesionales/Empresas/Impuesto_sobre_ Sociedades/Periodos_impositivos_a_partir_de_1_1_2015/Base_imponible/ Amortizacion/Tabla_de_coeficientes_de_amortizacion_lineal_.shtml [30] Angular Documentation,Architecture overview, Consultado el 16/10/2018, Disponible en https://angular.io/guide/architecture [31] Angular Documentation,Introduction to components, Consultado el 16/10/2018, Disponible en https://angular.io/guide/architecture-components [32] Sobre GitLab,GitLab pricing, Consultado el 16/10/2018, Disponible en https:// about.gitlab.com/pricing/ [33] Pagina oficial de Jest,Jest, Consultado el 19/10/2018, Disponible en https:// jestjs.io/ [34] Repositorio oficial de Prettier,Prettier, Opinionated Code Formatter, Consultado el 19/10/2018, Disponible en https://github.com/prettier/prettier [35] Repositorio oficial de husky,husky, Consultado el 19/10/2018, Disponible en https://github.com/typicode/husky [36] Pagina oficial de surge,surge, Consultado el 19/10/2018, Disponible en https: //surge.sh/ [37] Pagina oficial de compodoc,Compodoc, Consultado el 20/10/2018, Disponible en https://compodoc.app/guides/getting-started.html [38] Pagina oficial de GitLab,Static vs Dynamic Websites, Consultado el 20/10/2018, Disponible en https://about.gitlab.com/2016/06/03/ ssg-overview-gitlab-pages-part-1-dynamic-x-static/ [39] Project Management for Instructional Designers,Risk Management Process, Consultado el 20/10/2018, Disponible en https://pm4id.org/chapter/ 11-2-risk-management-process/ [40] Angular documentation,The Ahead-of-Time (AOT) compiler, Consultado el 20/10/2018, Disponible en https://angular.io/guide/aot-compiler [41] MDN web docs,Web Audio API, Consultado el 20/11/2018, Disponible en https: //developer.mozilla.org/es/docs/Web_Audio_API [42] Wavesurfer Official Page,Wavesurfer, Consultado el 21/11/2018, Disponible en https://wavesurfer-js.org/ [43] howler.js Official Page,Howler JS, Consultado el 21/11/2018, Disponible en https://howlerjs.com/ 109 BIBLIOGRAF´ IA [44] wavesurfer github repository,It doesn’t support Angular 2, Consultado el 21/11/2018, Disponible en https://github.com/katspaugh/wavesurfer.js/issues/ 1200 [45] Theodeus,tuna, Consultado el 08/12/2018, Disponible en https://github.com/ Theodeus/tuna [46] Fhaceb Ook,EL FILTRO BICUADRADO, Consultado el 26/12/2018, Disponible en https://es.scribd.com/document/74185703/EL-FILTRO-BICUADRADO [47] Youtube,T´erminos y Condiciones del Servicio, Consultado el 13/01/2019, Disponible en https://www.youtube.com/static?gl=GB&template=terms [48] Souncloud,T´erminos y Condiciones de Uso de SoundCloud, Consultado el 13/01/2019, Disponible en https://soundcloud.com/terms-of-use#Aceptaci%C3% B3n-de-los-T%C3%A9rminos-y-Condiciones-de-Uso [49] MDN web docs,Control de acceso HTTP (CORS), Consultado el 13/01/2019, Disponible en https://developer.mozilla.org/es/docs/Web/HTTP/Access_control_CORS [50] NPM archive,Music Tempo, Consultado el 20/01/2019, Disponible en https://www. npmjs.com/package/music-tempo [51] backtrack.fm,Beats Per Minute, Consultado el 21/01/2019, Disponible en https: //backtracks.fm/resources/podcast-dictionary/beats+per+minute [52] Simon Dixon,Automatic Extraction of Tempo and Beat from Expressive Performances, Consultado el 21/01/2019, Disponible en http://www.eecs.qmul.ac.uk/~simond/pub/ 2001/jnmr.pdf [53] NPM archive,ngx-web-worker, Consultado el 26/01/2019, Disponible en https:// www.npmjs.com/package/ngx-web-worker [54] MDN web docs,Using Web Workers, Consultado el 26/01/2019, Disponible en https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/ Using_web_workers [55] Pagina oficial de karma,Karma, Consultado el 17/02/2019, Disponible en https: //karma-runner.github.io/latest/index.html [56] MDN web docs,DOM, Consultado el 18/02/2019, Disponible en https://developer. mozilla.org/es/docs/Glossary/DOM [57] P´ agina oficial de PlantUML,Gu´ıa de Referencia del Lenguaje PlantUML, Consultado el 02/03/2019, Disponible en http://plantuml.com/es/guide [58] Repositorio oficial de ngx-translate,@ngx-translate/core, Consultado el 02/03/2019, Disponible en https://github.com/ngx-translate/core [59] Documentaci´ on oficial de GitLab,GitLab Runner, Consultado el 02/03/2019, Disponible en https://docs.gitlab.com/runner/ 110 BIBLIOGRAF´ IA [60] Docker Hub,node, Consultado el 03/03/2019, Disponible en https://hub.docker. com/_/node/ [61] proyectosagiles.org,Facilitador (Scrum Master), Consultado el 17/03/2019, Disponible en https://proyectosagiles.org/facilitador-scrum-master/ [62] CONECTART,Metodolog´ıas ´agiles, Consultado el 17/03/2019, Disponible en https: //blog.conectart.com/metodologias-agiles/ [63] P´ agina oficial de GNU,A Quick Guide to GPLv3, Consultado el 02/04/2019, Disponible en https://www.gnu.org/licenses/quick-guide-gplv3.html [64] P´ agina oficial de Visual Paradigm,Visual Paradigm, Consultado el 02/04/2019, Disponible en https://www.visual-paradigm.com/ 111 BIBLIOGRAF´ IA 112 Glosario Glosario acoplamiento En dise˜no de software el acoplamiento es la medida en que los cambios de un componente tiende a necesitar cambios de otro componente. 27, 56 beats per minute Beats per minute es un termino usado para medir el tempo de una canci´on. ”Tempo” es un termino musical para la velocidad o ritmo de la canci´on. Beats per minute es la unidad usada para medir el tempo. Un ”beat” es la unidad est´andar de medici´on de longitud de una pieza de musica.) [51]. 2, 35, 71 cadencia Manera regular de ocurrir algo en per´ıodos de tiempo que se repiten. 10 cohesi´on En dise˜no de software la cohesi´on es la medida en la que un componente se dedica a realizar solo la tarea para la cual fue creado, delegando las tareas complementarias a otros componentes. 27, 56 CUE Un CUE en un entorno de dj es un punto de ruptura en una canci´on, que te permite retomar la canci´on en ese punto. XIV, 15, 91, 92 data-binding En Angular el data-binding es c´omo se conoce a la comunicaci´on unidireccional (o bidireccional) entre template y clase, que permite reaccionar a eventos presentes en el template o modificar la informaci´on mostrada por el template. 27 deck Un deck o platina en un entorno de DJ es un reproductor de discos, originalmente vinilos. Hoy en d´ıa suele ser un reproductor o la representaci´on de uno de estos reproductores, sea de forma f´ısica o de forma virtual. 15 filtro bicuadrado Filtro compuesto por un filtro paso bajo, otro paso alto, y un paso banda (filtra las frecuencias que est´en por debajo de un umbral, deja pasar las de dentro de un rango y filtra las que est´an por encima de otro umbral) [46]. 86 lazy-loading Lazy-loading en Angular es un proceso de carga de m´odulos en el cual los m´odulos se descargan y posteriormente cargan en memoria los m´odulos s´olo cuando se requieren, no durante la carga inicial de la pagina. 27 loop Un loop en un entorno de dj es la reproducci´on de una parte de la canci´on en bucle. XIV, 15, 91, 92, 97 113