Tool support for documenting NFRs in Agile

Tool support for documenting NFRs in Agile Ariadna Viñets Cuervas Director: Xavier Franch Codirector: Marc Oriol Junio 2021 Resumen Después de la creación de la herramienta Q-Rapids, el grupo GESSI vio que para facilitar su uso sería mucho más cómodo crear una herramienta o plugin que se uniera con algún gestor de tableros Scrum, en este caso Jira, para poder crear automáticamente esas incidencias que se generaban en Q-Rapids y trasladarlas directamente a Jira. De esa necesidad, ha surgido la creación de este proyecto, que se basará en crear ese plugin para Jira. Resum Després de la creació de l’eina Q-Rapids, el grup GESSI va veure que per facilitar el seu ús seria molt més còmode crear una eina o plugin que es connectés a algun gestor de taulers de Scrum, en aquest cas Jira, per poder crear les incidències que es generen a través de Q-Rapids i traslladar-les directament a Jira. A causa d’aquesta necessitat, ha sorgit la creació d’aquest projecte, que es basarà completament a crear el plugin a Jira per tal de traslladar les incidències. Abstract After the creation of the tool Q-Rapids, the GESSI group observed that would be much easy to create a tool or plug-in that we can add to an administrator of Scrum Dashboards, in this case, Jira, with the purpose of creating automatically these issues that are generated in Q-Rapids and pass it directly to Jira. Due to this necessity, it becomes the creation of this project, which would be based on creating this plugin for Jira. 1 Agradecimientos Me gustaría agradecer a mis dos directores del proyecto, Xavier Franch y Marc Oriol, por su ayuda en todas las dudas que me han podido surgir durante todos estos meses, además de cada semana contar con su feedback para poder ir progresando en el proyecto. También me gustaría agradecer a todos los amigos y familia por el apoyo y ánimos durante estos años de carrera y en el proceso de elaboración del proyecto. 2 Índice de contenidos 1. Contextualización 9 1.1. Introducción.................................... 9 1.2. Términosyconceptos .............................. 9 1.3. Identificación del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.4. Stakeholders.................................... 13 2. Justificación 14 3. Alcance 16 3.1. Objetivos ..................................... 16 3.2. Requisitos Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3. Requisitos No Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4. Obstáculos .................................... 18 4. Metodología y rigor 19 4.1. AgileyScrum................................... 19 4.2. Github....................................... 21 4.3. Jira ........................................ 21 4.4. CuentaGoogle .................................. 22 5. Descripción de Tareas 23 5.1. Introducción.................................... 23 5.2. Tareas de gestión del proyecto y Gantt . . . . . . . . . . . . . . . . . . . . . 23 5.3. Tareasdedesarrollo ............................... 24 5.4. Recursosutilizados................................ 26 6. Estimaciones y Gantt 28 6.1. Estimaciones ................................... 29 3 7. Herramienta para Jira 32 7.1. Explicación de QualityRequirement . . . . . . . . . . . . . . . . . . . . . . . 33 7.2. FuncióncreateIssue................................ 35 7.2.1. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.2.2. Funcionamiento del método . . . . . . . . . . . . . . . . . . . . . . . 37 7.3. Función getMilestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.3.1. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.3.2. Funcionamiento del método . . . . . . . . . . . . . . . . . . . . . . . 43 7.4. FuncióngetPhases ................................ 45 7.4.1. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7.4.2. Funcionamiento del método . . . . . . . . . . . . . . . . . . . . . . . 46 7.5. Función putAcceptanceCriteria . . . . . . . . . . . . . . . . . . . . . . . . . 48 7.5.1. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . 48 7.5.2. Funcionamiento del método . . . . . . . . . . . . . . . . . . . . . . . 49 7.6. Testeo de la herramienta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 8. Configuración de Jira 57 8.1. APIJiraCloud.................................. 57 8.2. Configuración de Jira para el funcionamiento del plugin . . . . . . . . . . . 58 8.2.1. Creación tipo Milestone . . . . . . . . . . . . . . . . . . . . . . . . . 58 8.2.2. Añadir fecha de vencimiento . . . . . . . . . . . . . . . . . . . . . . 62 8.2.3. Añadir custom field como acceptance criteria . . . . . . . . . . . . . 66 8.3. Creación del token para la conexión con la API . . . . . . . . . . . . . . . . 69 9. Configuración de QRapids 71 9.1. ObtenciónQRapids................................ 71 9.2. Creación archivo WAR herramienta Jira . . . . . . . . . . . . . . . . . . . . 71 9.3. Conexión entre QRapids y la herramienta para Jira . . . . . . . . . . . . . . 72 10.Gestión de riesgos 77 11.Presupuesto 78 11.1. Estimación de los costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 11.1.1. Recursos Humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 11.1.2.Hardware ................................. 79 11.1.3.Software.................................. 80 11.1.4.Contingencia ............................... 80 11.1.5.Imprevistos................................ 80 11.1.6.Presupuestofinal............................. 81 11.2.Controldegestión ................................ 81 4 12.Sostenibilidad 83 12.1.Autoevaluación.................................. 83 12.2.Dimensióneconómica .............................. 84 12.3.Dimensiónambiental............................... 84 12.4.Dimensiónsocial ................................. 85 13.Conclusiones 86 5 Índice de figuras 1.1. Método para analizar los RQ ........................... 11 1.2. Dashboard de Q-Rapids .............................. 11 3.1. Proceso de creación del issue ........................... 16 4.1. Proceso marco de trabajo Scrum ......................... 20 4.2. Funcionamiento de Github ............................. 21 6.1. Diagrama de Gantt de planificación ........................ 30 6.2. Diagrama de Gantt de ejecución .......................... 31 7.1. UML QualityRequirement ............................. 34 7.2. Diagrama de secuencia CreateIssue ........................ 36 7.3. llamada POST de createIssue ........................... 38 7.4. Extracción de los datos del issue .......................... 38 7.5. Extracción de Assignees .............................. 40 7.6. Obtención número tablero ............................. 41 7.7. Obtención de Sprints ............................... 41 7.8. Diagrama de secuencia de getMilestones ...................... 43 7.9. Llamada GET de milestones ............................ 44 7.10. Datos retornados de getMilestones ........................ 45 7.11. Diagrama de secuencia de getPhases ....................... 46 7.12. Cabecera función getPhases ............................ 47 7.13. Obtención de la primera fase ........................... 47 7.14. obtención siguientes fases ............................. 48 7.15. Diagrama de secuencia putAcceptanceCriteria ................... 49 7.16. Creación de la lista de issues ........................... 50 7.17. Campo de autenticación Postman ......................... 52 7.18. Test para la creación del issue ........................... 53 7.19. Test para obtener los sprints ............................ 54 7.20. Valor del criterio de aceptación .......................... 55 7.21. Test para actualizar los criterios de aceptación .................. 56 6 8.1. Proceso de creación del issue ........................... 58 8.2. Tipos de issue ................................... 59 8.3. Agregar tipo issue ................................. 59 8.4. Tipos de issue con Milestone añadido ....................... 60 8.5. Esquemas de tipos de incidencia del tablero .................... 61 8.6. Adición tipo Milestone ............................... 62 8.7. Ventana de tablero de sprint ............................ 63 8.8. Ventana incidencia con configuración de campos ................. 64 8.9. Ventana ¿Dónde está mi campo? ......................... 64 8.10. Ventana ¿Dónde está mi campo? de fecha de vencimiento ............. 65 8.11. Fecha de vencimiento ocultada .......................... 66 8.12. Creación de campo personalizado ......................... 67 8.13. Edición de campo personalizado .......................... 67 8.14. Asociación a pantallas del campo ......................... 68 8.15. Buscador de texto libre .............................. 69 8.16. Pasos a seguir para la creación del token ..................... 70 9.1. Modificaciones docker-compose .......................... 73 9.2. Ventana ajustes QRapids ............................. 74 9.3. Visualización Milestones en QRapids ....................... 75 9.4. Visualización Phases en QRapids ......................... 75 9.5. Datos del issue en QRapids ............................ 76 9.6. Issue creado correctamente en Jira ........................ 76 7 Índice de tablas 3.1. Tabla con los objetivos, subojetivos y no objetivos del proyecto .......... 17 6.1. Tabla de estimaciones actualizada con la nueva tarea . . . . . . . . . . . . . 29 10.1. Tabla de riesgos .................................. 77 11.1. Tabla de roles del proyecto caso 2 ......................... 78 11.2. Tabla de costes humanos .............................. 79 11.3. Tabla de costes de hardware ............................ 80 11.4. Tabla de costes de contingencia . . . . . . . . . . . . . . . . . . . . . . . . . 80 11.5. Tabla de costes de imprevistos . . . . . . . . . . . . . . . . . . . . . . . . . 81 11.6.Tabladecostesfinal ............................... 81 8 tareas que queremos mecanizar. Por los motivos descritos, se ha decidido que se desarrolle esta herramienta, ya que en un futuro se podría tener un código más unificado de los dos plugins y si en un futuro se quisiese ampliar a otras plataformas, sería mucho más fácil de desarrollar. 15 Capítulo 3 Alcance En este apartado explicaremos cuáles serán los objetivos principales que se intentan alcanzar en este proyecto, sus requisitos funcionales, los no funcionales y finalmente los obstáculos que nos podemos encontrar en su desarrollo. 3.1. Objetivos El objetivo principal de este proyecto será la creación de esta herramienta, la cuál será un plugin que conectará los dos componentes ya existentes. Tal y como vemos en la figura 3.1, por un lado tendremos que conectar con Q-Rapids, el componente creado por el grupo GESSI, al cuál nos conectaremos vía API haciendo sus respectivos GET para adquirir los datos necesarios del requerimiento no funcional que queremos añadir como incidencia. Luego nos encontramos con la API RESTful de Jira, a la cuál nos conectaremos también vía API y podremos hacer los POST necesarios para poder añadir los issues de Q-Rapids correctamente al tablero de Jira. Figura 3.1: Proceso de creación del issue Fuente: elaboración propia 16 El otro objetivo, en este caso un sub-objetivo del principal, sería añadir más funcionalidades al crear los issues, en este caso en la meta data del proyecto, donde estos datos dependerían de los atributos que tenemos en un issue propio de Jira. En el caso que se finalizasen estos dos objetivos, nos encontraríamos con la posibilidad de añadir el QR, es decir el issue, como criterio de aceptación en vez de como incidencia, lo cuál estaría relacionado con otro issue en vez de ser uno propio sin conexión. Cabe decir que hay que dejar claro los objetivos que no forman parte de este proyecto, como puede ser la implementación de otro plugin que no sea para Jira, ya que nos especializamos en esa plataforma, o fijarnos en otras operaciones de Jira, ya que nuestra finalidad es focalizamos en la parte de issues. Para que se vea claro los objetivos, sub-objetivos y los objetivos que no abarca el proyecto, se representará a continuación en una tabla: Objetivos Posibles objetivos No incluido en el proyecto - Creación plugin Jira - QR como criterio - Plugins para otras plataformas - Añadir más meta-datos de aceptación - Focalizarse en otras al plugin operaciones de Jira Tabla 3.1: Tabla con los objetivos, subojetivos y no objetivos del proyecto 3.2. Requisitos Funcionales Una vez dichos los objetivos a cumplir en el proyecto, vamos a enumerar aquellos requisitos funcionales que se deben de cumplir en la creación del proyecto: Conexión con la API de Jira a través del plugin a crear Conexión con el dashboard de QRapids y la herramienta de Jira Creación correcta de los issues, en este caso teniendo en cuenta los párametros de entrada. Este punto estaría muy relacionado con el primer apartado, pero en este caso es más centrado al archivo que se le pasará en la llamada. Buena separación de los datos y los métodos en el proyecto. 3.3. Requisitos No Funcionales A continuación comentaremos los requisitos no funcionales que encontraremos en el proyecto: 17 Reusabilidad: Como se ha comentado en la justificación del proyecto, se quiere que la herramienta tenga una estructura común para la implementación de posibles proyectos en otras plataformas Rendimiento: El rendimiento de la herramienta se quiere que sea eficaz al crear los issues a través de las correspondientes APIs. Escalabilidad: Se quiere que la herramienta tenga esta propiedad ya que uno de los objetivos es que se pueda ampliar añadiendo más funcionalidades. Accesibilidad: Se quiere que sea accesible para todo el mundo y que sea intuitiva una vez se esté utilizando. 3.4. Obstáculos Durante este periodo de desarrollo del proyecto, nos podemos encontrar con una serie de obstáculos que puedan dificultar el proceso, además de alterar la planificación inicial. En este caso, teniendo en cuenta los errores desde el comienzo del proyecto puede ser que el impacto se minimice. –Inexperiencia en las tecnologías usadas: La inexperiencia en algunas de las tecnologías usadas, como es las llamadas a las API o el framework Spring que se utiliza, puede hacer que el desarrollo sea más lento de lo esperado, ya que hay una curva de aprendizaje inicial. –Errores de código: Dado que existe una inexperiencia en las tecnologías usadas, se podría dar el caso de encontrarnos con errores de código que sean más difíciles de encontrar que si hubiese una experiencia inicial. –Fecha de entrega fija: Al tratarse de una asignatura con una fecha de inicio y fin determinada, el trabajo se debe entregar en el plazo fijado entre estas fechas, esto puede afectarnos en el caso de encontrarnos con una pausa en el desarrollo o algún fallo que obligue a ello, ya que el producto final puede no ser tan exacto como el que estaba planteado. 18 Capítulo 4 Metodología y rigor La metodología de trabajo será un factor determinante en el proyecto, ya que comportará el desarrollo de la herramienta y de como se llevarán a cabo todas las posibles reuniones para saber los avances de la misma. 4.1. Agile y Scrum Para llevar un seguimiento del proyecto, se llevará a cabo una metodología Agile, más concretamente en el marco de trabajo de Scrum [7]. Esta metodología ha sido la escogida ya que se ha tratado durante la especialidad, además de ser como se ha dicho anteriormente, una de las más extendidas en el desarrollo de Software. Las metodologías Agile [2] son aquellas que nos permiten adaptar el proyecto a la forma de trabajo determinada, consiguiendo así una flexibilidad e inmediatez a la hora de modificar nuestro desarrollo en caso de que las circunstancias nos obliguen. El marco de trabajo Scrum son un conjunto de prácticas regulares que se llevan a cabo de forma grupal y principalmente se basa en: – Equipos pequeños de 3 a 9 personas – El desarrollo del producto se basa en bloques pequeños de periodos cortos, dónde se va creando el producto de manera incremental – El equipo se sincroniza de manera diaria y realiza los cambios necesarios en el proyecto. – Se le enseña al cliente el producto cada sprint o iteración para tomar las decisiones necesarias y cumplir todos aquellos requisitos que el cliente requiere. 19 – Se fijan unos tiempos máximos para lograr los objetivos necesarios en el proyecto. Una vez resumido el marco de trabajo, explicaremos el proceso que se lleva a cabo a la hora de desarrollar el producto software: Primeramente tenemos el Product Backlog, dónde encontramos todas las funcionalidades a desarrollar en el proyecto de manera ordenada según su prioridad. Estas funcionalidades son llamadas historias de usuario. como se ha comentado, el desarrollo se divide en Sprints. Antes de iniciar un Sprint, se hace un planning de qué se va a desarrollar, en este caso se eligen las historias de usuario a crear. Esta reunión se llama Sprint Planning Meeting. Todas las historias de usuario a desarrollar en este Sprint se añaden al Product Backlog. Una vez está todo organizado, ya se pueden desarrollar las funcionalidades. Durante todo este Sprint, los desarrolladores harán reuniones diarias para saber su progreso y si ha habido alguna dificultad. Cuando se finaliza el Sprint, todas las historias de usuario que se encontraban en el Sprint Backlog deberían estar completadas y el Scrum Master debería hacer una retrospectiva de como ha ido el Sprint, diciendo las cosas a mejorar. En el caso de tener alguna historia de usuario no completada, se pasaría al siguiente Sprint. También encontramos la figura del Product Owner, que es la persona de negocio que se encuentra interesada en el desarrollo del producto. Figura 4.1: Proceso marco de trabajo Scrum Fuente: Scrum para Startups - Richard Gracia [8] En este caso no se dará un marco de trabajo Scrum al cien por cien, ya que me encuentro sola en el proyecto y no nos encontramos con un cliente que vaya a revisar ese producto en cada Sprint. En este caso, nuestro marco de trabajo si que se basará en Sprints. No se hará cada día una daily review, sino que cada semana tendremos reuniones con el director y codirector del proyecto para saber como avanza el desarrollo. 20 4.2. Github Para el control de las versiones del código, la herramienta utilizada será Github [9]. Github es una página web que nos ayuda a obtener un control de versiones de nuestro proyecto, dónde usa Git para ello. La función principal de Git es clonar el código en diferentes dispositivos, dónde cada dispositivo podrá modificar ese código y se subirá al repositorio que tendremos en Github, además de obtener las actualizaciones del código cada uno en su propio ordenar. Esto, nos ayudará también en el caso de que si sólo tuviésemos el código en local y hubiese algún fallo en nuestro ordenador y se perdiese todo, no pudiésemos recuperarlo. En el caso de ser más desarrolladores, Github nos ayudaría a tener a todos los desarrolladores el código actualizado en cada momento, pero al ser una única desarrolladora, no es un factor determinante. Al no encontrarnos con problemas al hacer subidas de código, todo se modificará en una única rama, es decir la rama master. En una buena práctica de desarrollo, esto no se debería de llevar así a cabo, ya que puede suponer problemas en las subidas y crear errores si otro desarrollador quisiese subir el código y estuviese programando en el mismo fichero. Figura 4.2: Funcionamiento de Github Fuente: Repositorios Públicos en Github [10] 4.3. Jira Teniendo en cuenta que el desarrollo se llevará a cabo con una metodología Agile, las funcionalidades que se tengan que llevar a cabo, es decir las tareas del proyecto, llamadas historias de usuario, se anotarán en un tablero de Jira [11]. Anteriormente, ya se ha explicado que era Jira, ya tiene un peso muy importante en el proyecto. En este apartado, sólo nos fijaremos en los tableros que se encuentran dentro de la plataforma, en este caso un tablero Scrum, y dónde en él encontraremos 3 estados de tarea diferentes: por hacer, en curso y hecha. Este estado dependerá según si se encuentra empezada o no dicha tarea. Las tareas que no se encuentren en ese sprint en concreto, se quedarán en el backlog de tareas pendientes. 21 4.4. Cuenta Google Debido a la situación excepcional que estamos viviendo y que no podremos mantener reuniones de manera presencial, la comunicación se establecerá a través de las funcionalidades que nos proporciona la cuenta de estudiante de Google. Para las reuniones semanales, se usará Google Meet, además del correo para las dudas que puedan aparecer. 22 Capítulo 5 Descripción de Tareas 5.1. Introducción Antes de describir las tareas, pondremos en contexto el proyecto. Este proyecto se inició el 8 de febrero de 2021 y acabará el 21 de junio de 2021, teniendo en cuenta que su presentación será el 28 de junio. Este proyecto contará con un total de 543h, que dependerán de las tareas que explicaremos más adelante en este apartado y en siguiente. Una vez comentada la duración temporal y la cantidad de horas a dedicar, vamos a ver las tareas de las cuales se compone este proyecto. Estas se dividirán en dos apartados: –Gestión del proyecto: se incluyen todas las tareas de la parte de gestión del proyecto, la documentación del mismo y su seguimiento. –Desarrollo: tareas de desarrollo de la herramienta, además de los pasos anteriores a hacer antes de su desarrollo. 5.2. Tareas de gestión del proyecto y Gantt En este caso, una vez el proyecto se ha finalizado, respecto a las posibles desviaciones que han podido ocurrir durante el transcurso del proyecto, todo se ha llevado a campo en los márgenes de tiempo establecidos y a continuación se expondrán todas las tareas que se han realizado. –GP1 - Contextualización y alcance (25h): Redacción de la primera entrega de la gestión del proyecto, donde se contextualiza el proyecto, su alcance y las metodologías a usar. –GP2 - Planificación(9h): Redacción de la segunda entrega de gestión del proyecto, donde se planifica de manera ordenada todo el proyecto, creando un diagrama de 23 Gantt, una tabla con todas las estimaciones de las tareas y explicando los riesgos que nos podemos encontrar en el proyecto. Dependencias: GP1. –GP3 - Gestión económica y de sostenibilidad(10h): Redacción de la segunda entrega de gestión del proyecto, donde se explica la gestión económica y el informe de sostenibilidad. Dependencias: GP2. –GP4 - Integración del documento inicial(19h): Redacción de la última entrega de gestión del proyecto, donde se incluyen las tres entregas anteriores y corrección de todo aquello que el tutor ha pedido en el feedback. Dependencias: GP3. –GP5 - Documentación de seguimiento (30h): Cada semana se harán reuniones semanales para saber el progreso del proyecto y consultar las dudas que puedan surgir a medida que se va desarrollando la herramienta. Dependencias: GP4 –GP6 - Documentación Final (80h): Documentación escrita de todo el desarrollo de la herramienta. Dependencias: GP5. –GP7 - Presentación final del proyecto (30h): Preparación de la presentación del proyecto y su correspondiente presentación. Dependencias: GP6. 5.3. Tareas de desarrollo En este caso, aún teniendo en cuenta las posibles desviaciones según la planificación inicial, finalmente el proyecto se llevó todo a cabo, es más, debido a que se acabó todo el desarrollo que estaba planteado, se procedió a hacer la parte que no estaba dentro del rango del proyecto, es decir, aquellas tareas que contaban como posibles pero no sabíamos si se podrán llevar a cabo. En ese caso, la planificación del proyecto se ha visto afectada y en este caso, se ha añadió una nueva tarea, que se encuentra justo antes de la última tarea de creación de tests. Las estimaciones de desarrollo han sido recalculadas, ya que algunas de ellas no ha sido necesario dedicarles tanto tiempo, y entonces se han añadido esas horas a la tarea creada. Finalmente así quedarían las tareas de desarrollo: –DP1 - Uso de herramienta Q-Rapids(40h): Antes de empezar con el desarrollo del plugin, se debe entender la herramienta a la que va a ser conectada, en este caso Q-Rapids. Para ello se tendrá que leer la documentación de la herramienta anterior para Gitlab, la documentación propia del dashboard de Q-Rapids y hacer diferentes pruebas en la interfaz para ver exactamente su funcionamiento. –DP2 - Uso herramienta Jira(20h): Antes de empezar con el desarrollo del plugin, se debe leer la documentación relacionada con Jira, más específicamente Jira Cloud y su API, además de hacer pruebas a la API con la aplicación Postman. 24 En este diagrama, podemos comprobar que se han puesto las fechas exactas de las entregas, además de los intervalos en los que se han implementado las diferentes funcionalidades del proyecto. Figura 6.2: Diagrama de Gantt de ejecución Fuente: Elaboración propia 31 Capítulo 7 Herramienta para Jira Este apartado se centrará en la parte principal del proyecto, es decir, la creación de la herramienta o plugin. Se explicarán cada uno de los métodos, primeramente analizando sus diagramas de secuencia. Luego, se verá más a fondo el código creado, explicando que hace cada método y todos los elementos que se encuentran implicados en él. También, antes de entrar en detalle de cada método, se hará una explicación de qué es un QualityRequirement y todos sus campos. Cabe destacar que para que exista una correcta comunicación del plugin con QRapids y Jira, se deberán seguir todos los pasos que se comentarán posteriormente en los capítulos 8 y 9. El framework utilizado en el proyecto será Spring, que nos ayudará a hacer las llamadas de nuestro servicio RESTful. En este caso, lo que haremos será que en cada método, antes de crearlo, se pondrá una cabecera, por ejemplo: "@GetMapping(/api/issues")". En este ejemplo, para llamar a la función, se tendrá que hacer una llamada al servidor local seguido de /api/issues, siendo una llamada GET. La sentencia final sería la siguiente: http://localhost:8080/api/issues Para finalizar, nos encontraremos un archivo properties en la solución del proyecto que antes de poder inicializar la herramienta se deberá rellenar con los datos siguiente: –jira.mail: correo electrónico con el que se ha creado la cuenta de Jira y donde se encuentra el proyecto escogido. –jira.secret: Token creado para la autenticación de las llamadas a la API. –jira.url: Url del proyecto en Jira que nos servirá para las llamadas a la API –jira.accriteria: valor del customfield que pertenece al acceptance criteria del proyecto de Jira. 32 7.1. Explicación de QualityRequirement En este apartado haremos una breve introducción al concepto de QualityRequirement, en este caso explicando el UML que podemos encontrar en la figura 7.1. Tal y como vemos en la imagen, un Quality requirement formaría parte de un requisito, en este caso no funcional. En este atributo encontraríamos una descripción y un nombre asociado. A continuación podemos ver la clase User Story, que en nuestro caso sería lo más similar al issue en Jira, ya que contiene todos los datos que modificaremos en nuestra herramienta. A ello se encuentra asociado un proyecto, que siempre ha de ser válido. Además, encontramos las clases Sprint y Developer, esta última haciendo referencia a la clase que en el proyecto se llama Assignee. En estas dos clases nos encontramos que pueden formar no parte en un user story, ya que en su creación no son necesarias. Este user story se encuentra asociado a un requirement, ya que este puede pertenecer o no a un user story, en cambio, un user story siempre debe estar enlazado a un requirement. La siguiente clase que encontraríamos es Acceptance criteria, que se puede encontrar relacionado con las clases User story y QualityRequirement. Si nos fijamos primeramente en User story, tal y como se ha creado la herramienta y se verá más adelante, se podrá tener más de un user story asociado. En el caso del acceptance criteria, se basa en el término que tenemos en QRapids, ya que la funcionalidad extra que se ha añadido ha sido que un requirement puede ser un criterio de aceptación y no una historia de usuario como tal. 33 Figura 7.1: UML QualityRequirement Fuente: creación propia 34 7.2. Función createIssue Este método, tal y como indica su nombre, se basará en la creación del issue y pasarlo al tablero que hemos creado anteriormente en Jira. Primeramente se analizará su diagrama de secuencia, y a continuación, se analizará el código del mismo. 7.2.1. Diagrama de secuencia Primeramente, si nos fijamos en la figura 7.2, podemos ver que el primer diagrama hace referencia al método, es decir, createIssue. En este caso, el usuario interactuaría con la interfaz gráfica de QRapids, el dashboard, y este se conectaría con el plugin creado. Este plugin, haría las respectivas modificaciones de datos para poder pasárselo a la API REST de Jira, y esta se conectaría con el servidor de Jira para devolver una respuesta. Una vez se tiene dicha respuesta, el plugin nos devolverá únicamente el id y en la url que se encuentra el issue creado, que el usuario lo verá a través de una ventana en QRapids. Si nos fijamos, encontramos dos diagramas de secuencia extras, que son aquellos necesarios para la próxima implementación de campos del issue en QRapids. En este caso, nos encontramos con getAssignees, que su funcionalidad principal será hacer la llamada GET y que nos devuelva la lista de todos aquellos developers que pueden ser asignados a los issues del proyecto. Esta lista que nos devuelve Jira será adaptada a nuestra clase creada en el código. Finalmente encontramos getSprints, en este caso, al hacer la llamada nos devolverá una lista de todos los sprints creados en el proyecto, que nosotros lo adaptaremos a una lista de nuestra clase Sprint. Sin estos dos métodos, no se podrían añadir estos dos campos en la creación del issue. También cabe destacar que la implementación en QRapids no se sabe como será, ya que no se encuentra en el rango del proyecto y aún no se ha creado. 35 Figura 7.2: Diagrama de secuencia CreateIssue Fuente: creación propia 36 7.2.2. Funcionamiento del método A continuación entraremos en detalle en el funcionamiento del método createIssue. Primeramente, los parámetros de entrada que tendremos serán los que nos encontramos en el dashboard de QRapids, en este caso, en nuestro método le entrara un objeto de datos del tipo QualityRequirement, que contiene diferentes variables, las cuáles expondremos a continuación: –issue_summary: título del issue, y no puede ser nulo. –issue_description: descripción del issue, que puede estar vacía. –issue_type: tipo del issue. En Jira encontramos 4 tipos: Bug, Story, Task y Epic. En nuestro caso, también encontraremos el tipo Milestone, ya que lo hemos creado previamente. –project_id: id del proyecto dónde queremos añadir los issues. –decision_rationale: en nuestro caso es un campo que no se usa, ya que no lo encontramos en Jira. –due_date: Fecha de vencimiento del issue. –priority: Prioridad del issue, en Jira encontramos 5 tipos: Highest, High, Medium, Low y Lowest. –assignee: Persona a la que se le va a asignar el issue. –sprint: Sprint al que se le va a asignar el issue. Cada uno de estos valores tendrá su método get, para poder extraerlo de la aplicación QRapids, y también su método set, que será utilizado más adelante en la función de putAcceptanceCriteria para extraer los datos de Jira. Una vez analizados los datos de un QualityRequirement, es decir, lo que se convertirá en nuestro issue de Jira, podemos pasar a comentar el código de la función. En este caso, nos encontraremos con la configuración a la llamada a la API de Jira, que para conectarlo lo haremos a través de la librería com.sun.jersey.api.client. Esta librería nos facilitará las llamadas a dicha API. En la figura 7.2.2 se puede ver la llamada a POST: 37 ClientResponse response; String auth = new String(Base64.encode(jiraURL + ":" + token)); final String headerAuthorization = "Authorization"; final String headerAuthorizationValue = "Basic " + auth; final String headerType = "application/json"; Client client = Client.create(); WebResource webResource = client.resource(jiraURL + "/rest/api/2/issue"); response = webResource.header(headerAuthorization, headerAuthorizationValue).type(headerType).accept(headerType).post(ClientResponse.class, fields.toString()); Figura 7.3: llamada POST de createIssue Fuente: código propio Antes de hacer la llamada, que en el código sería la línea de response, se tendrá que crear el JSON que se le pasará con todos los campos extraídos de QRapids. Para ello, se seguirá la estructura que pide Jira con los campos. Una vez creada esta estructura y ya hecha la llamada, esta nos devolverá una respuesta. En el caso de que esta respuesta sea correcta, devolverá un 201. A partir de ahí, como se ha explicado en el diagrama de secuencia, se extraerá la información de la llamada y se extraerán dos datos, en este caso el id y la url del issue. Esta extracción se hará tal y como se indica en la figura 7.4: SuccessResponse newIssue; newIssue = new SuccessResponse(object.get("id").getAsString(), object.get("self").getAsString()); Figura 7.4: Extracción de los datos del issue Fuente: código propio Finalmente, en el caso de que no sea correcto, nos devolverá un código de respuesta de error. Cabe destacar, que a pesar de estar toda la implementación hecha, la propia conexión con QRapids actualmente incluye solamente algunos valores, que son los siguientes: –issue_summary –issue_description –project_id –decision_rationale 38 En el caso de los otros campos que se han añadido, los vamos a analizar, ya que la mayoría de ellos han necesitado funciones para que su integración con QRapids sea lo más práctica posible y solo se deba modificar la interfaz gráfica. issue_type En este caso el parámetro no requerirá nada extra, pero si que únicamente sus valores serán los que se han comentado anteriormente (Bug, Story, Milestone, Task, Epic), y si se entrase uno diferente, la llamada nos daría error y no se crearía el issue. due_date Este valor únicamente será añadir una fecha en el formato correcto, es decir: yyyy-mmdd. priority como se ha comentado en el issue_type, se deberá añadir una prioridad válida, que en este caso será: Lowest, Low, Medium, High, Highest. assignee Para este parámetro si se ha requerido un función extra, tal y como se ha indicado en el diagrama de secuencia. Consta de un método GET para poder encontrar todos aquellas personas que se pueden asignar al proyecto indicado. Tal y como se ha hecho con las otras funciones, se pasará por parámetro el project_id, y se hará la llamada con la librería com.sun.jersey.api.client. En este caso, se hará una llamada GET a Jira para encontrar los asignados a ese proyecto. Una vez nos retorne el valor 200 (es decir, la llamada ha sido correcta), leeremos los datos del JSON que ha sido retornado por la llamada y se transformarán a una lista del tipo Assignee tal y como vemos en la figura 7.5: 39 for (int i = 0; i < obj.size(); ++i) { JsonObject object = obj.get(i).getAsJsonObject(); Assignee newAssignee = new Assignee(); newAssignee.setId(object.get("accountId").getAsString()); newAssignee.setName(object.get("displayName").getAsString()); assignees.add(newAssignee); } return new ResponseEntity<>(assignees, HttpStatus.OK); Figura 7.5: Extracción de Assignees Fuente: código propio Este tipo ha sido creado por nosotros, y contiene los siguientes campos: –name: nombre de la persona a asignar. –id: id de la persona a asignar. En este caso, se ha creado así por si en un futuro se quisiese aplicar un desplegable para elegir a la persona en la interfaz de QRapids, ya que lo único que se necesitaría para asignarlo a una persona sería su id y el nombre sería únicamente informativo. Una vez que tenemos esta llamada, podremos saber los ids de las personas y los nombres de las mismas, pero como no tenemos ninguna interfaz aún para poder seleccionarlo, por ahora la única opción de comprobarlo es a través de la aplicación Postman, dónde se creará un apartado específico para todo el tema de pruebas de la aplicación. Cuando ya sabemos exactamente el id de las personas que se pueden asignar en el proyecto, ya se podrán crear POSTs de issues con ese id de assignee específico, que se añadirán en la cabecera del método createIssue (en este caso, se añadirá el valor en el atributo assignee del QualityRequirement). sprint Este parámetro será el id del sprint que queremos asignar al issue del proyecto determinado. Para ello, como hemos comprobado en el diagrama de secuencia, se ha creado una función pública con una llamada GET, donde se pasará por parámetro el valor del project_id. Esta función nos ayudará a saber cuáles son los sprints que encontramos en el proyecto indicado. Antes de hacer dicha llamada, se tendrá que crear una función privada para encontrar en el tablero que se encuentra el proyecto, ya que es un dato necesario para la llamada de obtención de sprints. 40 Primeramente, cuando se creó esta función, seguía la misma estructura que la función creada para a herramienta de Gitlab. En este caso, contaba con un número de semanas y de duración de sprints determinado. Se pensó que para que fuese más personalizable para el usuario que vaya a usarlo, se podrían pasar los parámetros de número de semanas y duración de sprints a la llamada de la función. En este caso, encontraremos cuatro parámetros: project-id, date_from, num_weeks y duration_sprint, tal y como podemos ver en la figura 7.12: public ResponseEntity<Object> getPhases(@RequestParam String project_id, @RequestParam(value = "date_from", required = false) String date_from, @RequestParam(value = "num_weeks", required = false) String num_weeks, @RequestParam(value = "duration_sprint", required = false) String duration_sprint) Figura 7.12: Cabecera función getPhases Fuente: código propio En este caso, la función cogerá todos aquellos milestones con fecha de vencimiento que se encuentren en el proyecto determinado y, si encontramos fecha, que acaben después de la fecha que se ha pasado. A continuación, en el caso de que la llamada sea correcta, se devolverán aquellas fases, dependiendo de las semanas y los sprints que se hayan pasado. Por defecto, nos encontraremos que habrá 10 semanas y cada fase tendrá la duración de 1 semana. Este por defecto, se ha mantenido de la herramienta de Gitlab. Para la creación de estas fases, primero se cogerá el primer milestone que tenemos y se tendrá en cuenta si se ha pasado por parámetro la duración de los sprints y el número de semanas que debe durar cada fase, tal y como vemos en la figura 7.13: if (duration_sprint != null){ duration = Integer.parseInt(duration_sprint); } Phase firstPhase = new Phase(); LocalDate date = LocalDate.parse(milestones.get(i).getDate()); firstPhase.setDateFrom(date.minusWeeks(duration).toString()); firstPhase.setDateTo(date.toString()); firstPhase.setName(""); firstPhase.setDescription(""); phases.add(firstPhase); if (num_weeks != null){ numWeeks = Integer.parseInt(num_weeks); } Figura 7.13: Obtención de la primera fase Fuente: código propio 47 Una vez tenemos la primera fase creada, se iterará dependiendo de la duración y el número de semanas que queremos que contenga cada una, y se añadirá a la lista de fases. En la figura 7.14 podemos ver su funcionamiento: for (int j = 1; j < numWeeks; ++j) { Phase newPhase = new Phase(); newPhase.setDateFrom(date.minusWeeks(j + duration).toString()); newPhase.setDateTo(date.minusWeeks(j).toString()); newPhase.setName(""); newPhase.setDescription(""); phases.add(newPhase); } Figura 7.14: obtención siguientes fases Fuente: código propio 7.5. Función putAcceptanceCriteria 7.5.1. Diagrama de secuencia En este caso, el diagrama de secuencia que nos encontraremos será muy similar a los anteriores, aunque en este caso se llevará a cabo un PUT, que es una modificación de un archivo ya existente. Para ello, el procedimiento que se seguirá sera el siguiente: Tal y como vemos en la figura 7.15, primeramente se hará una llamda para obtener todos aquellos issues ya existentes en el tablero de Jira, que estos se convertirán en el archivo que nosotros tenemos, en este caso QualityRequirement. Una vez obtenemos todos aquellos QualityRequirements, podemos ver que en el otro diagrama de secuencia nos encontramos que se pasará el qualityRequirement seleccionado por el usuario, juntamente con el acceptance_criteria y su project_id. Este QualityRequirement se deberá transformar al archivo correcto JSON de Jira, ya que debe seguir una estructura determinada, y en caso de no crearse correctamente no funcionaría. Una vez creado, se hará la llamada PUT a la API de Jira, y esta obtendrá los valores del servidor. Finalmente el servidor retornará un valor que nos dirá si se ha hecho correctamente esta modificación y será lo que el usuario pueda ver. 48 Figura 7.15: Diagrama de secuencia putAcceptanceCriteria Fuente: creación propia 7.5.2. Funcionamiento del método Una vez se añadieron todos los campos adicionales en la creación del issue y se terminó la implementación planteada, se decidió añadir esta nueva funcionalidad. En este caso, la idea principal ha sido que un NFR (non-functional requirement) creado a través de QRapids, pueda añadirse como un criterio de aceptación en un issue ya existente. Para ello, primeramente se tuvo que implementar dicho campo, ya que en Jira no se encuentra, tal y 49 como se encuentra explicado en el capítulo 8. Una vez creado el custom field, se hará una explicación del funcionamiento de este método. En este caso, encontraremos dos funciones, aunque la principal sera la de adición del acceptance criteria. Primeramente nos encontraremos con una función GET, que se encuentra implementada para encontrar todos los issues que se tienen en Jira. Se encuentra creada a través de la query JQL, tal y como se explicó anteriormente en la función getMilestones. En el caso de esta query, solamente nos deja visualizar los 50 últimos issues creados en el tablero de Jira. Esta función nos servirá si en un futuro se quisiese implementar la función en el dashboard de QRapids, ya que lo podríamos visualizar y seleccionar en que issue se quiere añadir el criterio de aceptación. Como se puede ver en la figura 7.16, podemos ver que esta función nos retorna una lista del tipo QualityRequirement, que tendrá los mismos atributos que la clase explicada en el método createIssue, ya que es la misma. List<Issue> issues = new ArrayList<>(); for (int i = 0; i < data.size(); ++i) { JsonObject object = data.get(i).getAsJsonObject(); / Issue newIssue = new Issue(); newIssue.setIssue_id(object.get("id").getAsString()); JsonObject aux = object.getAsJsonObject().get("fields").getAsJsonObject(); newIssue.setIssue_summary(aux.get("summary").isJsonNull() ? null : aux.get("summary").getAsString()); String acc_criteria = aux.get("customfield_10029").isJsonNull() ? null : aux.get("customfield_10029").getAsString(); if (acc_criteria != null) { List<String> acc_criteriaList = new ArrayList<String>(Arrays.asList(acc_criteria.split("\\n"))); acc_criteriaList.removeIf(s -> s.equals("")); newIssue.setAcceptance_criteria(acc_criteriaList); } issues.add(newIssue); } Figura 7.16: Creación de la lista de issues Fuente: código propio Una vez visto el GET issues de Jira, pasaremos a la función principal, en este caso la adición del acceptance criteria. Para ello, en el método le pasaremos un tipo QualityRequi50 rement, y el string del acceptance criteria. En este caso, el tipo QualityRequirement será el mismo que nos encontramos en la función de createIssue. Para ello, haremos una llamada PUT, ya que lo que haremos es modificar un issue ya creado en Jira. Esta llamada se hará como las funciones anteriores, con la librería com.sun.jersey.api.client. Antes de hacer dicha llamada, tendremos que crear el JSON para poder hacer el PUT con el nuevo acceptance criteria. En Jira, se siguen unas reglas para la creación del JSON, y en este caso cada acceptance criteria, además del string que sea, tendrá que seguir ese estilo que se encuentra marcado para que sea correcta la respuesta a la API. En este caso, aunque nos encontrásemos ya un acceptance criteria en el issue seleccionado, no habría ningún problema, ya que las dos funciones involucradas en este método están hechas de forma acumulativa y siempre se añadirán los nuevos juntamente con los antiguos. Finalmente, una vez que la modificación del issue sea correcta, la respuesta nos devolverá el valor 204, y en la respuesta del usuario podremos ver todos los valores de dicho QualityRequirement con el nuevo acceptance criteria. 7.6. Testeo de la herramienta Para poder comprobar el correcto funcionamiento de dicha herramienta, se han creado diferentes escenarios en Postman para ver si retornaban el valor deseado. Se ha creado un ejemplo de cada funcionalidad creada en el código, y más adelante se adjuntarán algunos ejemplos de aquellas funcionalidades que no se pueden ver en la interfaz de QRapids. Primeramente, antes de hacer la integración, se fue probando cada elemento en Postman, una herramienta de envío de llamadas HTTP REST. Estas pruebas se hicieron de forma progresiva a medida que se iba creando cada método. El orden fue: createIssue, getMilestones, getPhases, ampliación de los metadatos de createIssue y putAcceptanceCriteria. En todos ellos, antes de hacer dicha llamada se debe poner la autenticación como se puede ver en la figura 7.17, que en este caso, ha sido una autenticación del tipo basic auth, donde la contraseña ha sido creada anteriormente por Jira tal y como se puede ver en el capítulo 8 en la parte de creación de token. 51 Figura 7.17: Campo de autenticación Postman Fuente: captura propia Si empezamos por createIssue, para ello lo que se hizo fue probar la llamada con un JSON de datos añadido, que en este caso se hizo probando diferentes valores, además de tener en cuenta los valores nulos, ya que estos dificultaron a veces la ejecución del código si no se tenía en cuenta esa posibilidad. En el caso de los metadatos añadidos, también se comprobó que solamente se puedan añadir los datos más relevantes, en este caso los que son obligatorios para la propia creación del issue. En la figura 7.18 podemos ver un ejemplo de creación con diferentes campos añadidos y su correspondiente respuesta. 52 Figura 7.18: Test para la creación del issue Fuente: captura propia Para las funciones necesarias de createIssue, en este caso getSprints y getAssignee, el procedimiento de creación fue similar, y en este caso se tenía que volver a tener en cuenta los valores nulos de los campos a obtener de Jira. A continuación, en la figura 7.19, podemos ver un ejemplo de getSprints. 53 Figura 7.19: Test para obtener los sprints Fuente: captura propia En el caso de getMilestones, para comprobar el funcionamiento de comprobó poniendo los dos casos que nos podemos encontrar: sólamente con project_id o también añadiendo una due_date. Para ello, anteriormente se crearon distintos issues en Jira que tenian fecha de vencimiento (ya que sino no saldría ningún milestone) y que se ciñesen a la fecha de vencimiento añadida. Seguidamente, en el caso de getPhases, se siguió el mismo procedimiento de testeo que getMilestones, donde no dio problemas, ya que se llamaba a la función de Milestones y no tenía ninguna llamada a Jira interna. Finalmente, para el último caso, putAcceptanceCriteria, se han hecho pruebas para las dos funciones relacionadas. En el caso del getIssues, se ha seguido un procedimiento similar al que se ha llevado a cabo en el caso de getSprints y getAssignes. Para el otro caso, que es la función principal de modificar el acceptance criteria según el issue pasado por parámetro y el acceptance criteria a añadir, se ha comprobado. través 54 de aquellos issues que nos ha devuelto la función anterior, dónde también se han tenido en cuenta los casos donde algunos parámetros pueden ser nulos, ya que se pudo comprobar que era un factor que daba errores. Para poder comprobar su funcionamiento, deberemos rellenar diferentes campos en Postman. Primeramente, deberemos pasar por parámetro el valor del criterio de aceptación a añadir, tal y como vemos en la figura 7.20. Figura 7.20: Valor del criterio de aceptación Fuente: captura propia A continuación, se deberá pasar el JSON del QualityRequirement, que deberá idéntico a como se encuentra en el proyecto de Jira, ya que sino no se hará la correcta actualización. Una vez pasado dicho issue, nos devolverá la respuesta correcta tal y como se ve en la figura 7.21. 55 Figura 7.21: Test para actualizar los criterios de aceptación Fuente: captura propia 56 Figura 8.7: Ventana de tablero de sprint Fuente: captura propia Para habilitar este campo, primeramente deberemos darle al botón de crear, tal y como podemos ver en la figura 8.7, y a partir de ahí nos saldrá una ventana de creación del issue, donde le tendremos que dar a configurar campos. Una vez que le hemos dado a configurar campos, le deberemos dar a la opción "¿Dónde está mi campo?", tal y como vemos en la figura 8.8 donde deberemos de buscar la opción fecha de vencimiento en el recuadro que nos saldrá como el de la figura 8.9. 63 Figura 8.8: Ventana incidencia con configuración de campos Fuente: captura propia Figura 8.9: Ventana ¿Dónde está mi campo? Fuente: captura propia A continuación nos saldrá una ventana como la de la figura 8.10 que nos dirá que el campo no se encuentra presente en el formulario, y más abajo encontraremos un link que nos llevará a la página para habilitarlo. 64 Figura 8.10: Ventana ¿Dónde está mi campo? de fecha de vencimiento Fuente: captura propia Una vez en la página, navegaremos hasta el campo fecha de vencimiento y le daremos a mostrar, tal y como se puede ver en la figura 8.11. Una vez hecho esto, ya se podrá visualizar el campo cuando vayamos a crear un issue. 65 Figura 8.11: Fecha de vencimiento ocultada Fuente: captura propia 8.2.3. Añadir custom field como acceptance criteria En este caso, tal y como se hizo anteriormente para el campo de Milestones, se seguirá un procedimiento similar pero no será completamente igual. Primeramente, deberemos ir a la barra que encontramos arriba del todo en la página web y allí darle a la rueda de ajustes. Una vez seleccionada, deberemos darle a incidencias. Una vez nos encontremos en la página de incidencias, en la barra lateral izquierda, en la zona de campos, seleccionaremos la opción Campos personalizados. Una vez dentro, en la esquina superior derecha nos encontraremos un botón que pondrá Çrear campo personalizado 2 le daremos click. 66 Figura 8.12: Creación de campo personalizado Fuente: captura propia En este caso, el campo personalizado que crearemos será un campo de texto de varias líneas, dónde le pondremos de nombre acceptance criteria, o en su caso criterio de aceptación, ya que el nombre no nos afectará a la hora de crear el campo y añadirlo en la función, la única variable que nos afectará será el id que le asigne Jira a este campo, que lo veremos más adelante. En el caso de la descripción, es opcional, entonces dependerá de cada uno a la hora de crearlo. Figura 8.13: Edición de campo personalizado Fuente: captura propia 67 Una vez el campo se encuentre creado, lo podremos encontrar en el apartado de campos personalizados. En este caso, para asegurarnos que funcionará correctamente, en la misma pantalla le daremos click a los tres puntos que nos aparecen en el lado derecho del campo personalizado y daremos click a la opción asociar a pantallas. En esta pantalla seleccionaremos todas las pantallas que queremos asociar este campo tal y como se indica en la figura 8.14. Figura 8.14: Asociación a pantallas del campo Fuente: captura propia Como dato opcional y en la pantalla de campos personalizados, existe la opción de ver el campo acceptance criteria de una manera más visual en la interfaz de Jira. Para ello, en los tres puntos le daremos a .editar detalles", y una vez ahí, en buscar plantilla, seleccionaremos la opción de Buscador de texto libre, tal y como se ve en la figura 8.15. 68 Figura 8.15: Buscador de texto libre Fuente: captura propia Finalmente, para saber cuál será el nombre indicado del custom_field que se ha asignado al acceptance criteria, solamente nos hará falta crear un nuevo issue con la interfaz de Jira y añadir un issue escribiendo un acceptance criteria. Una vez esté creado, podremos hacer un GET del issue que acabamos de crear (URL) y a partir de ahi, buscar manualmente (crtl F) en el JSON el acceptance criteria y ver como se llama el custom field. Todos los custom field empiezan por custom_field y a continuación una secuencia de números. Cuando sepamos el valor de este custom field, se deberá añadir en el archivo properties del proyecto para poder llamarlo correctamente. Finalmente, una vez que ya hemos hecho estos pasos previos, podremos usar las funcionalidades que nos proporciona el la herramienta creada para Jira. 8.3. Creación del token para la conexión con la API El último paso que nos encontramos será la creación de un token que se usará como nuestra contraseña para poder hacer dichas llamadas a la API de Jira cloud y que no nos de error. 69 En este caso, se tendrá que ir a la siguiente página web: https://id.atlassian.com/manage/apitokens. Una vez dentro, le daremos al botón azul que pone crear token de API. Nos indicará que añadamos un nombre, dónde podemos ponerle el nombre que nos sea más relevante y darle a crear. A continuación nos saldrá un panel el token y deberemos copiarlo y guardarlo en un sitio seguro, ya que no podremos volver a verlo en caso de olvido. En la figura 8.16 podremos ver los pasos a seguir para darse la creación de este token: Figura 8.16: Pasos a seguir para la creación del token Fuente: captura propia 70 Capítulo 9 Configuración de QRapids En este apartado se comentará la implicación de QRapids en nuestro plugin, en este caso explicando como lo conectaremos y en qué funcionalidades nos centraremos para su correcto funcionamiento. 9.1. Obtención QRapids Para que haya un correcto funcionamiento de nuestras funcionalidades y poder pasar la información de los issues de QRapids a nuestro tablero Jira, se tendrán que hacer una serie de modificaciones en diferentes archivos. Primeramente, se deberá instalar el docker de QRapids en nuestro ordenador, juntamente con la aplicación de docker, que se encuentran en la página de Github de QRapids: https://github.com/q-rapids/qrapids-dashboard_demo-docker. Una vez hemos entrado en la web, deberemos darle a la opción de Releases y bajarnos el demo docker que contiene requirements (Demo.Docker.1.3.WITH.Quality.Requirements.zip ). Una vez ya se haya bajado el zip, se deberá descomprimir y dentro de la carpeta, ejecutaremos el programa para ver que funcione. Para ejecutarlo, en un terminal pondremos "docker-compose up". 9.2. Creación archivo WAR herramienta Jira A continuación, cuando hayamos comprobado que funciona, crearemos un archivo WAR de nuestra herramienta para poder añadirlo a QRapids. Para ello, en mi caso utilizaré IntelliJ IDEA, que es el editor dónde he creado toda la herramienta. 71 Una vez cargado nuestro proyecto en el editor, abriremos un terminal dentro de IntelliJ y escribiremos "./gradlew bootWar". A continuación, nos dará BUILD SUCCESSFUL y el archivo WAR se habrá creado, que se encontrara en: nombre_carpeta_proyecto - >builds ->lib. Una vez en la carpeta lib encontraremos el archivo con el siguiente formato: nombre_proyecto-version1.0-SNAPSHOT.WAR. 9.3. Conexión entre QRapids y la herramienta para Jira Cuando ya tengamos los dos proyectos correctos, se deberá de hacer algún cambio en la carpeta del docker de QRapids que nos hemos instalado anteriormente. Para ello, primeramente añadiremos el arhivo .war que acabamos de crear. Se añadirá a: nombre_carpeta_docker ->www ->api ->public. Cuando ya lo hayamos añadido, modificaremos el nombre del war para que nos funcione correctamente luego, y será el siguiente: QRapids-Jira-1.0.war Una vez añadido si volvemos a la carpeta inicial del docker de QRapids podremos ver un archivo llamado "docker-compose.yml", que será el que tendremos que modificar para que finalmente todo funcione correctamente. En este caso, se añadirán correctamente las llamadas a la url del localhost y poniendo las credenciales correspondientes de Jira, tal y como podemos observar en la figura 9.1 A continuación podemos ver las modificaciones que deberemos hacer en el archivo y los correspondientes valores: 72 11.1.1. Recursos Humanos Una vez explicado como se calcularán los costes, a continuación se expondrá la tabla con todas las tareas que abarcan el proyecto, especificando las horas y coste de cada una dependiendo del caso que hablemos. La tabla es más específica para el caso 2, ya que para el caso 1 lo único que se hará es multiplicar todas las horas por el precio establecido, que son 9€/h. Código GP PO PR T Duración Coste (€) CASO 2 GP - GESTIÓN DEL PROYECTO 203h GP1 25h 25 636 GP2 9h 9h 229 GP3 10h 10h 254,4 GP4 19h 19h 483,4 GP5 30h 30h 763,2 GP6 80h 80h 2035,3 GP7 30h 30h 763,2 DP - DESARROLLO DEL PROYECTO 340h DP1 40h 40h 843,2 DP2 20h 20h 390,8 DP3 15h 15h 365 DP4 5h 5h 102,8 DP5 50h 50h 1028,3 DP6 40h 40h 822,6 DP7 40h 40h 822,6 DP8 30h 30h 617 DP9 60h 60h 1234 DP10 40h 40h 976 TOTAL 543h 12366,9 CASO 1 TOTAL 543h 4887 Tabla 11.2: Tabla de costes humanos 11.1.2. Hardware A continuación, se adjuntarán todos aquellos dispositivos que se van a utilizar para el desarrollo del proyecto, ya que son indispensables para poder crear la herramienta. Para calcular su amortización, les pondremos una vida media de 4 años a los dispositivos. Hay que calcular que el trabajo nos dará 543h, y teniendo en cuenta que un año tiene 220 días 79 laborales, además de que la dedicación diaria al dispositivo será de 5 horas, se harán los respectivos cálculos. Este coste nos servirá para calcular el caso 1 y caso 2. La fórmula para calcular su amortización será la siguiente: Amortización = Coste del equipo / (vida útil ·días laborables/año ·dedicación diaria) ·dedicación TFG Dispositivos Coste (€) Amortización (€) Macbook pro 13"(portátil [15]) 2129 262,7 Tecknet Optical Mouse (ratón [16]) 18,7 2,3 Logitech K380 (teclado [17]) 13 1,60 HP 27q (monitor [18]) 17,5 2,2 TOTAL 268,8 Tabla 11.3: Tabla de costes de hardware 11.1.3. Software Finalmente calcularemos el coste que nos supondrá el software usado. En nuestro caso, todo el software usado será gratuito, ya que la mayoría son gratuitos de por si, aunque hay otros que con el beneficio de la cuenta estudiante nos salen gratuitos. Todo el software usado ya se mencionó en el apartado de recursos utilizados. 11.1.4. Contingencia El coste de contingencia forma parte del dinero que se añade en un proyecto en caso de encontrarse algún imprevisto y así poder solucionarlo. Este porcentaje añadido al proyecto debe ser realista, y tampoco debemos pasarnos a la hora de calcularlo. Normalmente, este porcentaje suele estar entre el 10% y 20%, en nuestro caso será un 20%. Caso Coste (€) Contingencia( %) Contingencia (€) Caso 1 4887 20 977,4 Caso 2 12366,91 20 2473,4 Tabla 11.4: Tabla de costes de contingencia 11.1.5. Imprevistos Tal y como se mencionó en la segunda entrega, en el apartado de riesgos, se debe tener en cuenta los costes que estos podrían acarrear en el caso que se diesen según su probabilidad. Para ello, en la siguiente tabla se calculará el coste que tendrá cada riesgo, teniendo en cuenta su probabilidad y la cantidad de horas. Como anteriormente, contemplaremos los 80 dos casos, el caso que me encuentro individual y el caso de equipo. En el caso de equipo, el riesgo de inexperiencia con las tecnologías no se tendrá en cuenta, ya que en el equipo habrá gente especializada en el tema. Además, el precio será el del programador, ya que los riesgos están relacionados con este rol. Riesgo Descripción Probabilidad (%) Tiempo (h) Precio (€/h) Coste (€) Caso 1 RG1 Inexperiencia Tecnologías usadas 30% 40 9 108 RG2 Errores de código 50% 30 9 135 RG3 Entrega fijada 15% 20 9 27 TOTAL 270 Caso 2 RG2 Errores de código 50% 30 15,82 308,5 RG3 Entrega fijada 15% 20 15,82 61,7 TOTAL 370,2 Tabla 11.5: Tabla de costes de imprevistos 11.1.6. Presupuesto final Finalmente se calculará el presupuesto final teniendo en cuenta todos los factores anteriores. Caso Coste Humano (€) Hardware (€) Contingencia (€) Imprevistos (€) Total (€) Caso 1 4887 269 977 270 6403 Caso 2 12367 269 2473 370 15479 Tabla 11.6: Tabla de costes final 11.2. Control de gestión En este apartado, se explicará como se llevaran a cabo las posibles desviaciones que nos podamos encontrar en el proyecto. Para ello, teniendo en cuenta que se usará el marco de trabajo Scrum, se anotará en cada sprint las tareas a realizar en el tablero de Jira, donde en cada una se anotarán las horas totales estimadas y las reales. En este caso, para todos los gastos que puede suponer, se tendrá únicamente en cuenta el caso 1, que es el caso dónde me encuentro sola en el proyecto y, además, el caso real. 81 Todos estos cálculos se llevarán a cabo a partir de diferentes fórmulas, dependiendo de los factores que hemos apuntado en el apartado anterior. En el caso de las desviaciones de las tareas, se calculará de dos formas, una teniendo en cuenta el coste total (4887€) y otra teniendo en cuenta las horas (543h). – Desviaciones en la realización de tareas (coste) = (coste estimado – coste real) * consumo horas real – Desviaciones en la realización de tareas (horas) = (consumo estimado – consumo real) * coste real Para las desviaciones de hardware, se usará la fórmula siguiente: – Desviaciones de un recurso hardware (coste) = (coste estimado – consumo real) * coste real Una vez finalizado el proyecto, se calcularán las desviaciones totales de las tareas y recursos, y en el caso de tener que gastar más de lo esperado, se usará el coste calculado de contingencia: – Desviaciones totales en la realización de tareas = (coste estimado total – coste real total) – Desviaciones totales de recursos = (coste estimado total – coste real total) 82 Capítulo 12 Sostenibilidad 12.1. Autoevaluación Después de contestar la encuesta, he podido reflexionar sobre el tema de sostenibilidad, además de darme cuenta de que en algunos de los aspectos me falta saber más conocimientos, ya que anteriormente no los había tenido tan en cuenta a la hora de realizar proyectos. Por ejemplo, en la dimensión ambiental, si que es un apartado que tengo conciencia de ello, ya que durante la carrera hemos tratado en diferentes asignaturas este tema, más específicamente en las competencias transversales. Nos hemos centrado sobretodo el impacto que puede ocasionar la tecnología en el planeta y la reutilización de los dispositivos, además de los residuos generados a causa de la obsolescencia programada. En la dimensión económica, he podido ver que tengo una idea sobre ello, teniendo en cuenta lo costoso que puede llegar a ser conseguir aquellos elementos para los dispositivos, además de los costes que se pueden ocasionar en su fabricación. Además, en mi vida diaria, suelo tener en cuenta este impacto, y intento alargar la vida útil de estos dispositivos, donde aquí también entraría la dimensión ambiental, como se ha comentado anteriormente. Finalmente, en el caso de la dimensión social, pienso que es la que menos me había planteado, ya que no había pensado en el impacto que puede llegar a tener en la sociedad estos proyectos o dispositivos, donde pueden afectar muy positivamente en la sociedad. Como resumen, se podría ver que tengo unos conocimientos suficientes para poder afrontar un proyecto y poder ver sus dimensiones, además de poder hacerlo más sostenible y económico. 83 12.2. Dimensión económica Respecto al PPP: Reflexión sobre el coste que has estimado para la realización del proyecto Pienso que es un coste realista y que tampoco se excede muchísimo, ya que, si miramos el coste real, ha sido un total de 6403,21€, y este proyecto será efectivo durante mucho años, entonces ese coste se amortizará. Respecto a la vida útil: ¿Como se resuelve actualmente el problema que quieres afrontar? (estado del arte) y en qué mejorará económicamente (costes) tu solución respecto las existentes? Creo que, gracias a este proyecto, en comparación de la solución que hay en el mercado, se podrá ayudar a las empresas a ser más eficientes en el tema económico, ya que nuestra solución contará con mas funcionalidades para ayudar a los usuarios y empresas. 12.3. Dimensión ambiental Respecto al PPP: Has estimado el impacto ambiental que tendrá la realización del proyecto? Después de hacer la encuesta, hice una pequeña estimación del impacto que podría suponer. Hay que tener en cuenta que mi proyecto no es un proyecto físico, lo cuál reduce considerablemente la dimensión ambiental. En este caso, lo que más consumirá es luz, ya que todos los dispositivos se encuentran conectados a ella. Respecto al PPP: ¿Te has planteado minimizar el impacto, por ejemplo, reutilizando recursos? En este caso, al ser un impacto mínimo, no hay recursos los cuales se puedan reutilizar, ya que el único impacto mayor es el portátil, que es mi ordenador personal y no es un producto adquirido especialmente para el proyecto. Respecto a la vida útil: ¿Como se resuelve actualmente el problema que quieres afrontar? (estado del arte) y en qué mejorará ambientalmente tu solución respecto las existentes? Como se ha comentado anteriormente, este proyecto contará con más funcionalidades que la herramienta existente. Teniendo en cuenta que este proyecto lo que quiere es de una manera más rápida crear requisitos no funcionales y gracias al Q-rapids dashboard sacar esos requisitos, se aumentará la eficiencia del programa, lo que hará que su rendimiento mejore y se gaste menos energía. 84 12.4. Dimensión social Respecto al PPP: ¿Qué crees que te aportará a nivel personal la realización de este proyecto Pienso que me aportará unos conocimientos que anteriormente no tenía, además que me puede acercar más al mundo laboral, teniendo en cuenta que puede ser más similar a un proyecto de trabajo real. Respecto a la vida útil: ¿Como se resuelve actualmente el problema que quieres afrontar? (estado del arte) y en qué mejorará socialmente (calidad de vida) tu solución respecto las existentes? Respecto a la solución que encontramos actualmente, esta al tener más funcionalidades ayudará a los usuarios de una manera más completa. Respecto a la vida útil: ¿Existe una necesidad real del proyecto? En este caso sólo existe una solución que pueda encajar con el proyecto, pero esa herramienta no pertenece al equipo con el que estoy trabajando, entonces era necesaria la creación de esta nueva herramienta, ya que será más amplia que la ya creada y el grupo GESSI podrá hacer las modificaciones necesarias, no como en la otra. 85 Capítulo 13 Conclusiones Una vez finalizado el proyecto, se ha podido ver como funcionan las llamadas a una API RESTful, además de poder cumplir todos aquellos objetivos que tenía para la creación del plugin o herramienta para su conexión con Jira. Estos objetivos que se encontraban en el capítulo 3 eran: Primeramente contábamos con la creación del plugin, en este caso de una manera más global, ya que en este caso solamente contaba con las funcionalidades que proporcionaba el plugin generado para Gitlab. Una vez se creó este plugin, se quisieron añadir más funcionalidades a la función de creación, ya que el issue podía tener más datos a añadir que no los que nos proporcionaba el plugin en ese momento. Para ello, como se puede ver en la sección 7.1, podemos comprobar que se hizo esta ampliación, explicando cada metadato añadido. Finalmente, el último objetivo con el que contábamos, que aún en ese momento estaba como opcional, fue el de añadir un requirement, en este caso aquel que sale de QRapids, como un acceptance criteria y no como un issue tal y como se ha creado. Para ello, como podemos ver en la sección 7.4, se crearon diferentes funciones para dicha implementación. Gracias a este plugin, ahora es posible poder añadir esos requirements creados en QRapids a un tablero específico de Jira, que era nuestra meta principal a la hora de crear el proyecto. Cabe destacar, que aunque se haya llegado a nuestro objetivo, el trabajo aún puede ser muy ampliable, ya que solamente se ha hecho la parte de creación de la herramienta. En este caso, ahora explicaremos las posibles ampliaciones que encontraríamos si se quisiesen llevar a cabo: 86 – El primer caso encontrado sería la posible ampliación de esta herramienta. Para ello, podríamos añadir más metadatos en la creación del issue, además de, si en futuro, Jira crease el concepto de Milestone, poder aplicarlo de manera correcta. – El segundo caso que encontraríamos sería la creación de la interfaz de usuario de las funcionalidades creadas, ya que actualmente en QRapids únicamente encontramos algunas funcionalidades que no serían ni la mitad de lo creado en esta herramienta. – Como último encontraríamos la ampliación del plugin que se creó para Gitlab, ya que ahora mismo no se encuentran iguales. En este caso, esta ampliación podría ir juntamente con la segunda, ya que si se tuviesen dos plugins idénticos, la interfaz de usuario ya no serviría teniendo en cuenta las pocas funcionalidades que se obtienen con ella. Para finalizar, creo que el proyecto ha quedado muy completo y su realización me ha gustado mucho, ya que he podido tocar más el tema de las llamadas a API REST y el uso de herramientas para poder comprobar el correcto funcionamiento de dichas llamadas. Con este proyecto, he podido aprofundizar más en el lenguaje de programación Java, juntamente con el framework usado, Spring. También he aprendido sobre Postman, una herramienta muy útil para gestionar todas las llamadas a API y ver sus respuestas. Gracias al proyecto, en un futuro me gustaría seguir aprendiendo sobre el tema de las API y el desarrollo de aplicaciones con ellas. 87 Bibliografía [1] Q-Rapids, Q-Rapids, Visita: 27-02-2021. dirección: https://www.q-rapids.eu. [2] V. R. Villán, Las metodologías ágiles más utilizadas y sus ventajas dentro de la empresa, Visita: 28-02-2021. dirección: https://www.iebschool.com/blog/que-sonmetodologias-agiles-agile-scrum/. [3] B. Aston, 10 De Los Mejores Scrum Boards Para Aumentar La Productividad De Tu Equipo, Visita: 27-02-2021. dirección: https://thedigitalprojectmanager.com/ es/mejores-herramientas-scrum. [4] Atlassian, Licencias de Jira Software, Visita: 28-02-2021. dirección: https://www. atlassian.com/es/licensing/jira-software. [5] ——, ¿Para qué sirve Jira?, Visita: 28-02-2021. dirección: https://www.atlassian. com/es/software/jira/guides/use-cases/what-is-jira-used-for. [6] Q-rapids, q-rapids/qrapids-backlog-jira, Visita: 28-02-2021. dirección: https://github. com/q-rapids/qrapids-backlog-jira. [7] Wikipedia, Scrum (desarrollo de software), Visita: 27-02-2021. dirección: https : //es.wikipedia.org/wiki/Scrum_(desarrollo_de_software). [8] Scrum para Startups - Richard Gracia, Visita: 28-02-2021. dirección: https : / / richardgracia.com/scrum-para-startups/. [9] Kinsta, ¿Qué es GitHub? Una Guía para Principiantes sobre GitHub, Visita: 2702-2021. dirección: https://kinsta.com/es/basedeconocimiento/que-esgithub/. [10] jecrespom, Repositorios Públicos en Github, Visita: 27-02-2021. dirección: https: //aprendiendoarduino.wordpress.com/2019/09/01/repositorios-publicosen-github/. [11] Atlassian, Jira | Software de seguimiento de proyectos e incidencias, Visita: 27-022021. dirección: https://www.atlassian.com/es/software/jira. [12] G. Project, GanttProject - Free Project Management Application, Visita: 6-03-2021. dirección: https://www.ganttproject.biz. 88