Gestión de proyectos con Redmine

Gesti´on de proyectos con Redmine Project management with Redmine TRABAJO FIN DE GRADO GRADO EN INGENIER´ IA INFORM ´ ATICA CURSO 2022–2023 Lucas Iv´an S´anchez Correa Directores Luis Javier Garc´ıa Villalba Ana Lucila Sandoval Orozco Departamento de Ingenier´ıa del Software e Inteligencia Artificial Facultad de Inform´atica Universidad Complutense de Madrid Madrid, Mayo de 2023 Agradecimientos En primer lugar me gustar´ıa agradecer el trabajo de mis directores, Luis Javier y Ana Lucila por todo el apoyo dado durante la realizaci´on de este trabajo. Asimismo, me gustar´ıa agradecer a Pablo y a Luis Miguel por sus comentarios y ayudas durante el desarrollo del gestor de proyectos. Por ´ultimo, gracias a Agust´ın, Daniel y Gonzalo por demostrarme que la confianza en los dem´as les hace m´as fuertes. iii ´ Indice General ´ Indice de Figuras IX ´ Indice de Tablas XI Lista de Acr´ onimos XIII Abstract XV Resumen XVII 1. Introducci´ on 1 1.1. Motivaci´on .................................... 1 1.2. Contexto ..................................... 2 1.3. Plan de Trabajo ................................. 3 1.4. Estructura del Trabajo .............................. 5 2. Marco te´ orico 7 2.1. ¿Qu´e es una metodolog´ıa? ............................ 7 2.2. Importancia de organizarse con metodolog´ıas ................. 7 2.3. Metodolog´ıas existentes ............................. 9 2.3.1. Metodolog´ıas Cl´asicas .......................... 9 2.3.1.1. Cascada ............................. 9 2.3.1.2. Modelo V ............................ 10 2.3.1.3. Modelo en Espiral ....................... 12 2.3.1.4. M´etodo de la Ruta Cr´ıtica .................. 13 v vi ´ INDICE GENERAL 2.3.2. Metodolog´ıas ´ Agiles ........................... 15 2.3.2.1. Kanban ............................. 15 2.3.2.2. Programaci´on extrema .................... 17 2.3.2.3. Desarrollo basado en funcionalidades ............ 19 2.3.2.4. Scrum .............................. 20 2.4. Metodolog´ıa aplicada a este proyecto ...................... 21 3. Estado del Arte 23 3.1. Herramientas de trabajo utilizadas actualmente ................ 23 3.2. Gestores de proyectos existentes ......................... 23 3.2.1. Jira .................................... 24 3.2.2. Asana ................................... 24 3.2.3. Basecamp ................................. 25 3.2.4. Redmine .................................. 26 3.3. Comparativa de gestores de proyectos ..................... 27 4. Implementaci´ on de proyectos con Redmine 29 4.1. Investigaci´on y An´alisis ............................. 29 4.1.1. Especificaci´on de requisitos ....................... 29 4.1.2. Flujo de trabajo ............................. 29 4.2. Implementaci´on de Ruby on Rails ........................ 29 4.2.1. Patr´on Modelo-Vista-Controlador ................... 30 4.2.2. Patr´on Active Record .......................... 32 4.3. Implementaci´on de Redmine ........................... 33 4.3.1. Extensiones ................................ 34 4.4. Implementaci´on del flujo de trabajo ....................... 35 4.5. Pruebas y Resultados .............................. 37 4.5.1. Introducci´on ............................... 37 4.5.2. Pruebas de concepto ........................... 37 4.6. Pruebas de funcionamiento ........................... 37 4.7. Resultados y conclusiones ............................ 37 ´ INDICE GENERAL vii 5. Conclusiones y Trabajo Futuro 39 5.1. Conclusiones ................................... 39 5.2. Trabajo Futuro .................................. 40 6. Introduction 41 6.1. Motivation .................................... 41 6.2. Context ...................................... 42 6.3. Work plan ..................................... 42 6.4. Work structure .................................. 43 7. Conclusions and Future Work 45 7.1. Conclusions .................................... 45 7.2. Future Work ................................... 46 A. Requisitos funcionales 47 Bibliograf´ ıa 53 ´ Indice de Figuras 1.1. Diagrama de Gantt ................................ 4 2.1. Modelo Cascada ................................. 10 2.2. Modelo V ..................................... 12 2.3. Modelo Espiral .................................. 13 2.4. Ejemplo de ruta cr´ıtica (A-C-G-H). Se han omitido los tiempo de cada tarea. 14 2.5. Ejemplo de tablero Kanban [1] ......................... 17 2.6. Flujo de trabajo en XP ............................. 19 4.1. Flujo de la propuesta ............................... 30 4.2. Modelo-Vista-Controlador ............................ 31 4.3. Formulario de propuesta ............................. 36 6.1. Diagrama de Gantt ................................ 43 ix Resumen Con la creciente complejidad de la burocracia, la Polic´ıa Nacional necesita un sistema eficiente para gestionar proyectos, tareas y recursos de forma eficaz. Este Trabajo Fin de Grado explora la importancia de utilizar Redmine, una potente herramienta de gesti´on de proyectos, para automatizar diversas actividades relacionadas con los proyectos. En concreto, se centra en la transici´on de una base de trabajo diaria a una base de datos centralizada en Redmine. El cambio a Redmine aporta numerosas ventajas, como una mejor colaboraci´on, una mayor precisi´on de los datos, un seguimiento en tiempo real y amplias capacidades de elaboraci´on de informes. Al aprovechar las funciones de automatizaci´on que ofrece Redmine, los gestores de proyectos pueden optimizar sus flujos de trabajo, asignar recursos de forma eficaz y lograr una mayor eficiencia en los proyectos. Keywords: Automatizaci´on, Automatizaci´on de tareas, Colaboraci´on, Eficiencia de proyectos, Gesti´on de proyectos, Redmine. xvii Cap´ıtulo 1 Introducci´on 1.1. Motivaci´on Las herramientas cuya finalidad es la gesti´on de proyectos han demostrado ser activos indispensables para organizaciones de diversos sectores. Estas herramientas sirven como soluciones integrales para agilizar los flujos de trabajo de los proyectos, mejorar la colaboraci´on y garantizar el ´exito en la entrega de los proyectos [2]. La motivaci´on que subyace al desarrollo y la utilizaci´on de herramientas de gesti´on de proyectos se deriva de varios factores clave que abordan los desaf´ıos propuestos a los equipos de proyectos y las organizaciones. Esta secci´on explora las principales motivaciones que subyacen a la adopci´on de gestores de proyectos y su impacto en el correcto desarrollo de un proyecto. Una de las principales motivaciones para utilizar herramientas gestoras de proyectos es lograr una gesti´on eficiente de las tareas. Estas herramientas proporcionan una plataforma centralizada en la que los equipos de proyecto pueden crear, asignar y realizar un seguimiento de las tareas a lo largo del desarrollo del proyecto. Gracias a las funciones de gesti´on de tareas, los miembros del equipo pueden priorizar las asignaciones, fijar plazos y supervisar el progreso. Esta motivaci´on surge de la necesidad de poder distribuir de una manera ´optima de los recursos disponibles, evitar retrasos y cumplir eficazmente los hitos del proyecto. La colaboraci´on eficiente resulta fundamental para lograr el ´exito del proyecto, especialmente cuando se trata de equipos multifuncionales o entornos descentralizados. Las herramientas gestionadoras de proyectos ofrecen funciones de colaboraci´on como calendarios compartidos, documentos compartidos, foros de debate y canales de comunicaci´on en tiempo real. Al facilitar una colaboraci´on fluida, estas herramientas promueven el intercambio de conocimientos, la transparencia y la toma de decisiones eficaz entre los integrantes del equipo de trabajo. La motivaci´on para mejorar la colaboraci´on es poder ser capaz de garantizar la comunicaci´on eficiente, fomentar el trabajo realizado de manera grupal y, en ´ultima instancia, impulsar el ´exito del proyecto. La gesti´on eficiente de los recursos es crucial para el ´exito del proyecto [3]. Las herramientas de gesti´on de proyectos ofrecen funciones para planificar, asignar y hacer un seguimiento eficaz de los recursos. Con funciones como calendarios de recursos, seguimiento de las asignaciones de tareas y visibilidad de los recursos disponibles, estas herramientas ayudan a los gestores de proyectos a optimizar la asignaci´on de recursos, evitar la sobrecarga o infrautilizaci´on y garantizar que se est´an asignando los recursos adecuados 1 2Cap´ ıtulo 1. Introducci´ on a las tareas correctas en el momento oportuno. La motivaci´on detr´as de la planificaci´on y asignaci´on de recursos es maximizar la utilizaci´on de los recursos, reducir los puntos de congesti´on y aumentar la eficiencia general del proyecto. El seguimiento del progreso del proyecto y la generaci´on de informes esclarecedores son esenciales para que las partes interesadas se mantengan informadas y tomen decisiones fundamentadas. Las herramientas gestoras de proyectos ofrecen s´olidas capacidades de seguimiento e informes, lo que permite a las personas designadas para gestionar proyectos supervisar los hitos, realizar un seguimiento de las tareas y generar informes personalizados sobre el estado del proyecto, la utilizaci´on de los recursos, el presupuesto y otras m´etricas cr´ıticas. La motivaci´on detr´as de la supervisi´on continua del progreso y la presentaci´on de informes es proporcionar a las partes interesadas informaci´on precisa y actualizada, identificar posibles riesgos o retrasos y permitir intervenciones oportunas para el ´exito del proyecto. Todo proyecto conlleva riesgos inherentes que pueden afectar a sus resultados. Las herramientas de gesti´on de proyectos permiten identificar, evaluar y mitigar los riesgos. Estas herramientas permiten a los equipos de proyecto documentar los riesgos, asignar propietarios, definir estrategias de mitigaci´on y realizar un seguimiento del progreso de la mitigaci´on de riesgos. La motivaci´on de la administraci´on de posibles riesgos es identificar y abordar proactivamente los riesgos potenciales, minimizar su impacto que puedan tener en la finalidad del proyecto y fortalecer la resiliencia de las partes implicadas en el desarrollo de cualquier actividad. Es decir, la motivaci´on detr´as de las herramientas gestoras de proyectos radica en abordar los desaf´ıos que enfrentan los equipos de proyecto, mejorar la colaboraci´on, optimizar la asignaci´on de recursos, permitir el seguimiento del progreso y gestionar los riesgos del proyecto. Al adoptar estas herramientas, las organizaciones pueden agilizar los flujos de trabajo de los proyectos, mejorar la comunicaci´on y garantizar el ´exito de la correcta finalizaci´on de los proyectos. El perfeccionamiento continuo de las herramientas de gesti´on de proyectos demuestran el compromiso permanente de poder cumplir con las necesidades cambiantes de los equipos de proyecto y las organizaciones en un panorama empresarial cada vez m´as complejo y din´amico. 1.2. Contexto La gesti´on de numerosos proyectos complejos requieren una gesti´on eficaz de las tareas. Al principio, la Polic´ıa Nacional utilizaba sistemas dispares, principalmente Microsoft Excel para el seguimiento de tareas y Microsoft Access para administrar su base de datos. Sin embargo, la naturaleza fragmentada de estas herramientas dificultaba la gesti´on eficaz de los proyectos, lo que provocaba tediosos procesos en la comunicaci´on y en la elaboraci´on de informes. Para hacer frente a estos retos, la Polic´ıa Nacional busc´o una soluci´on integral que pudiera unificar sus necesidades de gesti´on de tareas y bases de datos. Redmine surgi´o como la herramienta de gesti´on de proyectos ideal, ya que ofrec´ıa una plataforma centralizada que integraba a la perfecci´on las funciones de seguimiento de tareas y gesti´on de bases de datos. Con la adopci´on de Redmine, la Polic´ıa Nacional pretend´ıa consolidar sus procesos de gesti´on de proyectos, agilizar la comunicaci´on y la colaboraci´on, garantizar una gesti´on precisa de los datos y generar informes detallados para tomar decisiones con conocimiento de causa. 1.3. Plan de Trabajo 3 El presente Trabajo de Fin de Grado pretende satisfacer la necesidad de la Polic´ıa Nacional de gestionar todos aquellos proyectos propuestos por el Programa Horizonte Europa, sucesor de Horizonte 2020. El trabajo ha sido desarrollado en conjunto con el departamento de innovaci´on y desarrollo de la Polic´ıa nacional. 1.3. Plan de Trabajo Se ha decidido llevar a cabo el trabajo las siguientes fases: 1. Investigaci´ on: La fase de Investigaci´on consisti´o en dar respuesta a porqu´e es necesario organizarse con metodolog´ıas de trabajo a la hora de desarrollar un proyecto software. Asimismo, se escoge una metodolog´ıa de trabajo en concreto. Los resultados de esta fase sentaron las bases para las dos fases posteriores, al proporcionar una gu´ıa para el proceso de Desarrollo y de Experimentaci´on. 2. Desarrollo: La fase de desarrollo fue dividida en dos, la primera consisti´o en llevar a cabo una investigaci´on y an´alisis exhaustivos para conocer en profundidad los objetivos del proyecto, los requisitos y las necesidades espec´ıficas de la Polic´ıa Nacional a la hora de gestionar proyectos en el marco del Programa Horizonte Europa. Esta fase implic´o una revisi´on en profundidad de la metodolog´ıa de trabajo utlizada actualmente por la Polic´ıa Nacional, adem´as de llevar a cabo entrevistas para obtener la informaci´on requerida para el cumplimiento de los requisitos propuestos. Asimismo, se realiz´o una investigaci´on de las herramientas gestoras existentes, compar´andolas entre s´ı y seleccionando la que mejor se adecuara a las necesidades planteadas por los requisitos especificados en la anterior parte. La segunda parte se centra en la creaci´on e implantaci´on de la soluci´on de gesti´on de proyectos para la Polic´ıa Nacional. Bas´andose en las conclusiones de la fase de Investigaci´on, esta fase implic´o la personalizaci´on de la herramienta gestora de proyectos seleccionada y la integraci´on de las funcionalidades necesarias para cumplir los requisitos espec´ıficos del Programa Horizonte Europa. La fase de Desarrollo incluy´o tareas como el dise˜no de la base de datos, el desarrollo de la interfaz de usuario, la implementaci´on del flujo de trabajo y las pruebas del sistema para garantizar la funcionalidad, usabilidad y fiabilidad de la soluci´on. 3. Realizaci´ on de pruebas: La fase de pruebas tuvo como objetivo validar la eficacia y eficiencia de la soluci´on gestora de proyectos desarrollada. Durante esta fase, la soluci´on se despleg´o en un entorno controlado dentro de la plataforma fly.io, y se simularon escenarios y proyectos reales del Programa Horizonte Europa. El objetivo fue evaluar el rendimiento de la soluci´on, su capacidad para gestionar tareas y datos relacionados con los proyectos, y su compatibilidad con los flujos de trabajo y procesos existentes en la Polic´ıa Nacional. Los resultados de esta fase proporcionaron informaci´on valiosa para perfeccionar y optimizar la soluci´on antes de su implementaci´on final. El Desarrollo y la Realizaci´on de pruebas se repitieron a lo largo del trabajo dada la naturaleza de la metodolog´ıa de trabajo escogida en la Investigaci´on. A continuaci´on se muestra un diagrama de Gantt mostrando las actividades desarrolladas durante el trabajo. 4Cap´ ıtulo 1. Introducci´ on Figura 1.1: Diagrama de Gantt 1.4. Estructura del Trabajo 5 1.4. Estructura del Trabajo El trabajo se divide en 7 cap´ıtulos, siguiendo la siguiente estructura propuesta: El Cap´ıtulo 2presenta el marco te´orico del trabajo, en el que se investiga qu´e son las metodolog´ıas de trabajo y porqu´e se deben emplear. Asimismo, se realiza una investigaci´on de las metodolog´ıas de trabajo m´as utilizadas actualmente. El Cap´ıtulo 3presenta el Estado del Arte de los gestores de proyectos que existen actualmente, se listan los gestores de proyectos m´as utilizados y se hace una descripci´on de las caracter´ısticas de cada uno. Finalmente se a˜nade una tabla comparativa para juntar la informaci´on de cada gestor, permitiendo entender porqu´e se elige Redmine como gestor final. En el Cap´ıtulo 4, primero se lleva a cabo una investigaci´on para obtener los requisitos espec´ıficos que debe cumplir el gestor de proyectos pedido por la Polic´ıa Nacional. Se hace una propuesta formal de requisitos. Asimismo, se obtiene el flujo de trabajo que deber´ıan seguir las propuestas recibidas. Despu´es se desglosa la implementaci´on de las aplicaciones basadas en Ruby on Rails. Seguida de la explicaci´on de la implementaci´on de Redmine y sus posibles extensiones, junto con la implementaci´on del flujo de trabajo descrito. Por ´ultimo, se describe qu´e proceso se ha llevado a cabo para asegurar la efectividad de la implementaci´on realizada. El Cap´ıtulo 5se exponen las conclusiones principales de este estudio, as´ı como las ´areas de investigaci´on futuras que se plantean. Por ´ultimo, los cap´ıtulos 6y7son las traducciones al ingl´es de la Introducci´on y de las Conclusiones. Cap´ıtulo 2 Marco te´orico 2.1. ¿Qu´e es una metodolog´ıa? La metodolog´ıa hace referencia al conjunto de ideas, enfoques, principios y pr´acticas que se utilizan para llevar a cabo un proceso de trabajo o investigaci´on de manera sistem´atica y organizada. Proporciona una gu´ıa estructurada para poder llevar a cabo un objetivo espec´ıfico o resolver un problema de manera eficiente y efectiva [4]. En el contexto de gestionar proyectos, una metodolog´ıa de trabajo es un marco de referencia que establece los pasos y las actividades a seguir para completar un proyecto con ´exito. Define las reglas, los procesos y las herramientas necesarias para planificar, ejecutar y controlar todas las etapas que se realizan en un proyecto, desde las meras ideas hasta la implementaci´on final. Una metodolog´ıa de trabajo efectiva proporciona una estructura clara para el equipo de proyecto y permite una gesti´on eficiente de los recursos, el tiempo y los riesgos involucrados. Tambi´en establece roles y responsabilidades, define los entregables y los hitos importantes, y promueve la comunicaci´on y el desarrollo de actividades de manera colaborativa entre los integrantes del equipo. Cada metodolog´ıa de trabajo puede tener caracter´ısticas ´unicas y adaptarse a diferentes tipos de proyectos o entornos organizativos. Algunas metodolog´ıas, siguen un enfoque secuencial y r´ıgido, mientras que otras, se centran en la adaptabilidad, la iteraci´on y la respuesta r´apida a los cambios. La elecci´on de la metodolog´ıa adecuada depende de factores como el tama˜no del proyecto, la naturaleza del trabajo, los requisitos del cliente, el nivel de incertidumbre y la cultura organizativa. Las metodolog´ıas tambi´en pueden combinarse o adaptarse seg´un las necesidades espec´ıficas del proyecto. 2.2. Importancia de organizarse con metodolog´ıas En el entorno empresarial actual, gestionar proyectos se ha convertido en una disciplina fundamental para lograr el ´exito en la ejecuci´on de iniciativas y alcanzar los objetivos establecidos. La gesti´on efectiva de proyectos requiere una estructura y un enfoque organizado, y es ah´ı donde entran en juego las metodolog´ıas. Estas metodolog´ıas proporcionan un marco de trabajo sistem´atico que gu´ıa a los equipos en cada etapa del 7 14 Cap´ ıtulo 2. Marco te´ orico Identificaci´ on de actividades: En esta etapa, se identifican todas las actividades necesarias para completar el proyecto. Cada actividad debe ser claramente definida y representar una tarea o un conjunto de tareas que requieren tiempo y recursos para su ejecuci´on. Secuenciaci´ on de actividades: Una vez identificadas las actividades, se establecen las dependencias entre ellas. Esto implica determinar qu´e actividades deben completarse antes de que otras puedan comenzar. Se crean relaciones de precedencia que indican la secuencia l´ogica en la que deben llevarse a cabo las actividades. Estimaci´ on de tiempos: En esta fase, se estima la duraci´on de cada actividad. Se pueden utilizar diferentes t´ecnicas, como la experiencia previa, la consulta a expertos o el an´alisis hist´orico, para determinar el tiempo necesario para completar cada actividad. Creaci´ on del diagrama de red: Utilizando la informaci´on recopilada en los pasos anteriores, se crea un diagrama de red que representa las actividades, sus dependencias y los tiempos estimados de duraci´on. El diagrama de red puede ser representado mediante la t´ecnica de flechas (Diagrama de Flechas) o mediante el m´etodo de los nodos (Diagrama de Precedencia). Determinaci´ on de la ruta cr´ ıtica: Una vez que se ha construido el diagrama de red, se determina la ruta cr´ıtica del proyecto. La ruta cr´ıtica es la secuencia de actividades que tiene el tiempo total m´as largo y, por lo tanto, determina la duraci´on m´ınima del proyecto. Las actividades en la ruta cr´ıtica no tienen holgura, lo que significa que cualquier retraso en estas actividades retrasar´a todo el proyecto. Programaci´ on y control del proyecto: Con la ruta cr´ıtica identificada, se establece un cronograma de ejecuci´on del proyecto. Se asignan los recursos necesarios para cada actividad y se establecen las fechas de inicio y finalizaci´on esperadas. Durante la ejecuci´on del proyecto, se realiza un seguimiento del avance de las actividades y se comparan los resultados reales con el cronograma planificado para controlar el progreso y tomar acciones correctivas si es necesario. Un ejemplo de ruta diagrama de red podr´ıa ser el que se presenta en la Figura 2.4. Figura 2.4: Ejemplo de ruta cr´ıtica (A-C-G-H). Se han omitido los tiempo de cada tarea. El M´etodo de la Ruta Cr´ıtica es especialmente ´util para proyectos que tienen restricciones de tiempo y donde se busca optimizar los recursos disponibles. Al identificar 2.3. Metodolog´ ıas existentes 15 la ruta cr´ıtica y las actividades m´as cr´ıticas, se pueden asignar los recursos de manera m´as eficiente y anticiparse a posibles retrasos o problemas. El CPM ofrece varias ventajas significativas. En primer lugar, proporciona una visi´on clara y visual del proyecto, lo que facilita la comprensi´on de las relaciones entre las actividades y la determinaci´on de la ruta cr´ıtica. Esto permite a los equipos de proyecto identificar las actividades m´as cr´ıticas y priorizar sus esfuerzos y recursos en funci´on de ellas. Adem´as, el CPM permite una programaci´on precisa y realista del proyecto. Al estimar los tiempos de duraci´on de las actividades y determinar la ruta cr´ıtica, se obtiene una estimaci´on de la duraci´on total del proyecto. Esto es especialmente valioso cuando se trata de proyectos con plazos ajustados o proyectos en los que se requiere una entrega oportuna. El seguimiento y control del proyecto tambi´en se simplifican con el CPM. Al comparar el avance real con el cronograma planificado, se pueden identificar desviaciones y tomar acciones correctivas de manera oportuna. Esto ayuda a mantener el proyecto en el camino correcto y evitar retrasos costosos. Sin embargo, es importante tener en cuenta que el CPM tiene algunas limitaciones. En primer lugar, se basa en estimaciones de tiempo y depende de la precisi´on de estas estimaciones. Si las estimaciones no son precisas, esto puede afectar la planificaci´on y el control del proyecto. Adem´as, el CPM no tiene en cuenta las limitaciones de recursos, lo que significa que es posible que se requiera una optimizaci´on adicional para asignar eficientemente los recursos disponibles. En resumen, el M´etodo de la Ruta Cr´ıtica es una metodolog´ıa cl´asica de gesti´on de proyectos que se basa en la representaci´on gr´afica de actividades, dependencias y tiempos estimados. A trav´es de la identificaci´on de actividades, la secuenciaci´on, la estimaci´on de tiempos, la creaci´on del diagrama de red, la determinaci´on de la ruta cr´ıtica y la programaci´on y control del proyecto, el CPM permite planificar y controlar de manera efectiva la ejecuci´on de un proyecto. 2.3.2. Metodolog´ıas ´ Agiles 2.3.2.1. Kanban La metodolog´ıa ´agil Kanban es un enfoque visual basado en el flujo de trabajo para la gesti´on de proyectos y tareas. Se origin´o en el ´ambito de la fabricaci´on y se ha adaptado exitosamente al desarrollo de software y a otros campos. Kanban se centra en la mejora continua, la eficiencia y la entrega de valor de manera constante. A continuaci´on, se detallan los elementos clave y los principios de la metodolog´ıa ´agil Kanban [12]: Tablero Kanban: El tablero Kanban es la representaci´on visual del flujo de trabajo del proyecto o del equipo. Se divide en columnas que representan las etapas del proceso, como “Por hacer”, “En progreso” y “Finalizado”. Cada tarea o elemento de trabajo se representa mediante tarjetas, y se mueven de una columna a otra a medida que avanzan en el flujo de trabajo. L´ ımites de trabajo en proceso (Work in progress (WIP)): Kanban establece l´ımites claros para la cantidad m´axima de elementos de trabajo que se pueden 16 Cap´ ıtulo 2. Marco te´ orico tener en cada columna del tablero Kanban. Esto evita la sobrecarga de trabajo y ayuda a mantener un flujo constante y equilibrado. Los l´ımites de WIP fomentan la finalizaci´on de las tareas existentes antes de comenzar nuevas, lo que ayuda a evitar la acumulaci´on de trabajo en progreso. Flujo continuo: Kanban promueve un flujo de trabajo continuo y equilibrado. Las tareas se mueven de una columna a otra de acuerdo con el progreso real, sin saltos ni interrupciones innecesarias. El objetivo es identificar y eliminar los cuellos de botella y los obst´aculos para mantener un flujo constante y entregar valor de manera m´as r´apida y eficiente. Mejora continua: Kanban se basa en el principio de mejora continua. Se alienta a los equipos a realizar mejoras incrementales y evolutivas en su flujo de trabajo y procesos. A trav´es de la retroalimentaci´on constante y el an´alisis de m´etricas, se identifican oportunidades de mejora y se implementan cambios para optimizar el rendimiento y la eficiencia. Transparencia y colaboraci´ on: Kanban promueve la transparencia y la colaboraci´on en todo el equipo. Al utilizar un tablero Kanban visible para todos los miembros del equipo, se fomenta la comunicaci´on y la visibilidad de las tareas en curso. Esto facilita la colaboraci´on, la asignaci´on de recursos y la resoluci´on conjunta de problemas. Enfoque en el valor: Kanban se centra en la entrega de valor de manera constante. A trav´es de la priorizaci´on adecuada de las tareas y la entrega continua de elementos terminados, se busca maximizar el valor entregado al cliente o usuario final. Esto permite obtener retroalimentaci´on temprana y ajustar las prioridades y el alcance del proyecto seg´un sea necesario. Existen numerosas herramientas web que proporcionan una implementaci´on gratuita del tablero Kanban, por ejemplo, Canva. En la Figura 2.5. Kanban es especialmente adecuado para proyectos y equipos que requieren una mayor flexibilidad y adaptabilidad. Su enfoque visual, basado en el flujo de trabajo y en la entrega continua de valor, permite una mayor visibilidad, control y capacidad de respuesta a medida que evolucionn los requisitos y las necesidades cambiantes del proyecto. Algunos beneficios de utilizar Kanban en la gesti´on de proyectos son: 1. Mayor visibilidad y transparencia: El tablero Kanban hace posible tener una visi´on del estado de las tareas y el flujo de trabajo. Todos los integrantes del equipo tienen acceso a esta informaci´on en tiempo real, lo que facilita la coordinaci´on, la toma de decisiones y la identificaci´on de posibles obst´aculos. 2. Flexibilidad y adaptabilidad: Kanban se adapta bien a entornos donde los requisitos y las prioridades pueden cambiar con frecuencia. Al no establecer plazos r´ıgidos y permitir que el equipo se enfoque en un n´umero manejable de tareas, se puede responder r´apidamente a los cambios y ajustar el flujo de trabajo seg´un sea necesario. 3. Optimizaci´ on del flujo de trabajo: Al limitar la cantidad de trabajo en proceso en cada etapa del flujo, Kanban evita la sobrecarga y los cuellos de botella. Esto 2.3. Metodolog´ ıas existentes 17 conduce a un flujo de trabajo m´as equilibrado y eficiente, lo que mejora los tiempos de entrega y reduce el tiempo de respuesta. 4. Enfoque en la calidad: Kanban promueve la entrega de tareas completas y de alta calidad en lugar de simplemente avanzar en el proceso. Al establecer l´ımites de trabajo en proceso y enfocarse en la finalizaci´on antes de comenzar nuevas tareas, se fomenta la calidad del trabajo realizado. 5. Mejora continua y aprendizaje: La metodolog´ıa Kanban fomenta la mejora continua a trav´es del an´alisis de m´etricas y la retroalimentaci´on del equipo y los stakeholders. Al medir el rendimiento, identificar ´areas de mejora y realizar ajustes graduales, el equipo puede aprender de sus experiencias y optimizar su flujo de trabajo con el tiempo. La implementaci´on exitosa de Kanban requiere un compromiso y una colaboraci´on activa de todo el equipo. La comunicaci´on abierta, el seguimiento constante del flujo de trabajo y la disposici´on para adaptarse a medida que surjan nuevos desaf´ıos son fundamentales para aprovechar al m´aximo los beneficios de esta metodolog´ıa ´agil. En resumen, Kanban es una metodolog´ıa ´agil que se basa en la visualizaci´on del flujo de trabajo y la entrega continua de valor. Al promover la transparencia, la adaptabilidad y la mejora continua, Kanban ayuda a los equipos a gestionar proyectos de manera eficiente, optimizando el flujo de trabajo y entregando valor de manera constante. Figura 2.5: Ejemplo de tablero Kanban [1] 2.3.2.2. Programaci´ on extrema Extreme Programming (XP) es una metodolog´ıa ´agil de desarrollo de software que se centra en la calidad del producto, la adaptabilidad a los cambios y la colaboraci´on entre los miembros del equipo. XP se basa en una serie de pr´acticas y valores fundamentales que promueven un enfoque iterativo e incremental para la entrega de software [13]. 18 Cap´ ıtulo 2. Marco te´ orico A continuaci´on, se detallan los elementos clave y los principios de la metodolog´ıa ´agil XP: Comunicaci´on constante: se enfatiza la comunicaci´on abierta y frecuente entre todos los miembros del equipo, incluyendo a los desarrolladores, los stakeholders y los clientes. La comunicaci´on constante ayuda a comprender los requisitos y las expectativas, aclarar dudas y tomar decisiones r´apidas y efectivas. Retroalimentaci´on continua: XP se basa en la retroalimentaci´on constante para mejorar el proceso de desarrollo. Los desarrolladores trabajan estrechamente con los clientes y los stakeholders para recibir comentarios sobre el producto en etapas tempranas y frecuentes. Esta retroalimentaci´on se utiliza para ajustar y mejorar el software en cada iteraci´on. Desarrollo incremental: se sigue un enfoque iterativo e incremental para el desarrollo de software. En lugar de esperar a tener todos los requisitos y funcionalidades definidos desde el inicio, se desarrolla y entrega software funcional en peque˜nas iteraciones. Esto permite una entrega temprana de valor y la posibilidad de adaptarse a los cambios y requisitos emergentes. Pruebas unitarias: las pruebas unitarias son una parte integral de este m´etodo ´agil. Los desarrolladores escriben pruebas automatizadas para cada pieza de c´odigo que producen. Estas pruebas ayudan a garantizar que el software funcione correctamente y que los cambios no introduzcan errores en el c´odigo existente. Adem´as, las pruebas unitarias act´uan como una documentaci´on viva del sistema. Integraci´on continua: lo que implica que los cambios realizados por los desarrolladores se integran y se prueban de manera frecuente. Esto permite detectar y corregir problemas de forma temprana, facilitando la entrega de software funcional y estable en todo momento. Dise˜no simple: se evita la sobreingenier´ıa y se busca la soluci´on m´as sencilla para cumplir con los requisitos. Esto facilita la comprensi´on y el mantenimiento del c´odigo, y permite adaptarse de manera ´agil a los cambios en los requisitos. Juego de pruebas: El juego de pruebas, o “programaci´on en parejas”, es una pr´actica com´un en XP. Dos desarrolladores trabajan juntos en una misma estaci´on de trabajo, compartiendo conocimientos y revisando el c´odigo del otro. Esta pr´actica fomenta la colaboraci´on, el aprendizaje y la calidad del c´odigo. Propiedad compartida: En XP, se fomenta la propiedad compartida del c´odigo y la responsabilidad de todo el equipo. Todos los miembros tienen voz y voto en la toma de decisiones y se fomenta la colaboraci´on y la contribuci´on activa de cada persona. En la figura 2.6 se representa el flujo de trabajo en XP. XP se centra en la entrega temprana y frecuente de software funcional, la adaptabilidad a los cambios y la mejora continua. Al utilizar pr´acticas como la comunicaci´on constante, las pruebas unitarias y la integraci´on continua. Ayuda a los equipos a entregar productos de alta calidad de manera ´agil y efectiva. 2.3. Metodolog´ ıas existentes 19 Figura 2.6: Flujo de trabajo en XP 2.3.2.3. Desarrollo basado en funcionalidades Desarrollo basado en funcionalidades (Feature Driven Development (FDD)) es una metodolog´ıa ´agil de desarrollo de software que se centra en la entrega incremental y en la construcci´on de funcionalidades (features) clave en el desarrollo de un proyecto. FDD se basa en una serie de principios y pr´acticas orientadas a la colaboraci´on efectiva, la comunicaci´on clara y la entrega continua de software de calidad [14]. A diferencia de otras metodolog´ıas ´agiles, se enfatiza la gesti´on por funcionalidades. Estas funcionalidades se dividen en caracter´ısticas m´as peque˜nas y manejables que se pueden desarrollar en un per´ıodo de tiempo espec´ıfico, generalmente en semanas. Cada funcionalidad se asigna a un equipo o a un desarrollador espec´ıfico responsable de su implementaci´on. El proceso de desarrollo de FDD se divide en cinco etapas clave: Desarrollo del modelo global: En esta etapa, se identifican y definen las principales caracter´ısticas del sistema. El equipo trabaja en conjunto para comprender los requisitos del sistema y crear un modelo global que describa la estructura y las interacciones de las funcionalidades. Lista de funcionalidades: En esta etapa, se crea una lista exhaustiva de todas las funcionalidades del sistema. Cada funcionalidad se describe en t´erminos claros y concisos, y se prioriza seg´un su importancia y valor para el cliente. Planificaci´on por funcionalidades: En esta etapa, el equipo de desarrollo selecciona un conjunto de funcionalidades para ser implementadas en un per´ıodo de tiempo determinado, generalmente en una iteraci´on corta. Se asignan recursos y se define un plan detallado para el desarrollo de cada funcionalidad. Dise˜no por funcionalidades: En esta etapa, cada funcionalidad seleccionada se dise˜na de manera individual. Se establecen las interfaces, se definen los componentes necesarios y se realiza una estimaci´on precisa del tiempo y los recursos requeridos para su implementaci´on. Construcci´on por funcionalidades: En esta etapa, el equipo de desarrollo implementa cada funcionalidad de manera incremental. Se lleva a cabo la codificaci´on, las pruebas 20 Cap´ ıtulo 2. Marco te´ orico y la integraci´on continua de las funcionalidades desarrolladas. Al finalizar cada iteraci´on, se entrega una funcionalidad completa y probada. FDD tambi´en hace hincapi´e en la colaboraci´on activa y la comunicaci´on efectiva dentro del equipo de desarrollo. Se fomenta la transparencia y se establecen mecanismos de seguimiento para garantizar el progreso adecuado del proyecto. En resumen, FDD se enfoca en la entrega incremental de funcionalidades clave. Se basa en una serie de principios y pr´acticas que promueven la colaboraci´on, la comunicaci´on y la entrega continua de software de calidad. 2.3.2.4. Scrum Scrum es una de las metodolog´ıas ´agiles m´as reconocidas y ampliamente utilizadas, se destaca por su enfoque iterativo e incremental para la gesti´on de proyectos. En este apartado, exploraremos Scrum en detalle, analizando sus principios, roles, artefactos y eventos clave [15]. Scrum se basa en una serie de principios que orientan su enfoque ´agil. Estos principios incluyen: Transparencia: Todos los aspectos del proyecto deben ser visibles y comprensibles para todos los involucrados. Inspecci´on: Se deben realizar inspecciones peri´odicas de los artefactos y el progreso del proyecto para identificar posibles mejoras. Adaptaci´on: Se fomenta la adaptaci´on continua para abordar los cambios y desaf´ıos que puedan surgir durante el proyecto. Scrum define tres roles principales que desempe˜nan funciones clave en el proyecto: Product Owner: Es responsable de definir y priorizar los elementos del backlog del producto, representando los intereses del cliente o stakeholders. Scrum Master: Act´ua como facilitador y defensor de Scrum, asegurando que se sigan las pr´acticas y ayudando al equipo a alcanzar su m´aximo potencial. Equipo de Desarrollo: Est´a compuesto por profesionales multifuncionales que trabajan juntos para desarrollar y entregar los incrementos del producto. Por otro lado, Scrum utiliza tres artefactos principales para gestionar el flujo de trabajo y la entrega del producto: Product Backlog: Es una lista priorizada de todas las funcionalidades, requisitos y mejoras deseadas para el producto. Sprint Backlog: Es una lista de elementos seleccionados del Product Backlog para el Sprint actual, junto con un plan para su implementaci´on. Incremento: Es el resultado tangible y potencialmente entregable de cada Sprint, que agrega valor al producto en desarrollo. 2.4. Metodolog´ ıa aplicada a este proyecto 21 Por ´ultimo, Scrum establece eventos espec´ıficos que ayudan a estructurar el flujo de trabajo y fomentar la colaboraci´on: Sprint: Es un periodo de tiempo fijo y regular durante el cual se lleva a cabo el trabajo. Generalmente tiene una duraci´on de dos a cuatro semanas. Reuni´on de Planificaci´on del Sprint: En esta reuni´on, el equipo selecciona los elementos del Product Backlog para el pr´oximo Sprint y crea el Sprint Backlog. Reuni´on Diaria (Daily Scrum): Es una breve reuni´on diaria en la que el equipo de desarrollo sincroniza su trabajo y actualiza el progreso. Revisi´on del Sprint: Al final de cada Sprint, el equipo muestra el incremento completado a los stakeholders y recibe su retroalimentaci´on. Retrospectiva del Sprint: Es una reuni´on que se lleva a cabo al final de cada Sprint, donde el equipo reflexiona sobre el Sprint anterior y busca mejoras en su proceso de trabajo. En definitiva, Scrum es una metodolog´ıa ´agil ampliamente adoptada que ofrece un enfoque iterativo e incremental para la gesti´on de proyectos. Sus principios, roles, artefactos y eventos clave trabajan en conjunto para fomentar la transparencia, inspecci´on y adaptaci´on continua. Al enfocarse en la entrega de incrementos de valor en intervalos regulares, Scrum permite poder dar respuesta de manera r´apida y efectiva a cambios en los requisitos. A trav´es de la colaboraci´on estrecha y la retroalimentaci´on constante, Scrum ayuda a los equipos a optimizar su rendimiento y a entregar productos de alta calidad. Al comprender y aplicar Scrum de manera efectiva, las organizaciones pueden mejorar su capacidad para gestionar proyectos de manera ´agil y exitosa. 2.4. Metodolog´ıa aplicada a este proyecto La metodolog´ıa de trabajo empleada en este proyecto fue Scrum, un marco ´agil que se centra en la colaboraci´on, la entrega de valor y la adaptabilidad a los cambios. Aunque Scrum generalmente se implementa con un equipo multidisciplinario, en este caso particular, asum´ı el desaf´ıo de llevar a cabo el proyecto de manera individual, siendo el ´unico miembro del equipo de trabajo. En este rol multifac´etico, asum´ı varias responsabilidades. Como Product Owner, fui responsable de definir los objetivos del proyecto y establecer las prioridades de las funcionalidades a desarrollar. Me asegur´e de entender las necesidades y requerimientos de la Polic´ıa Nacional, para as´ı poder representar sus intereses de la mejor manera posible. Adem´as, asum´ı el papel de Equipo de Desarrollo. Esto implic´o dise˜nar, implementar y probar la aplicaci´on por mi cuenta. Desde la concepci´on inicial hasta la fase de implementaci´on final, trabaj´e en cada etapa del proceso, asegur´andome de aplicar las mejores pr´acticas de desarrollo de software. Aunque no hubo un Scrum Master espec´ıfico en el proyecto, tom´e la responsabilidad de guiar el proceso de acuerdo con los principios de Scrum. Me asegur´e de seguir los rituales establecidos, como las reuniones de planificaci´on, las revisiones de Sprint y las retrospectivas, adapt´andolos a las necesidades del proyecto y manteniendo un enfoque ´agil y flexible. 22 Cap´ ıtulo 2. Marco te´ orico A pesar de que este proyecto se llev´o a cabo de manera individual, reconoc´ı la importancia de obtener feedback de los clientes. Por lo tanto, organic´e reuniones peri´odicas con ellos para mostrarles el estado actual de la aplicaci´on y recibir sus comentarios y sugerencias. Esta retroalimentaci´on fue valiosa para ajustar las prioridades y realizar mejoras continuas en el producto. Cap´ıtulo 3 Estado del Arte 3.1. Herramientas de trabajo utilizadas actualmente En el actual m´etodo de trabajo que se quiere mencionar se destaca el uso extensivo de documentos Excel para gestionar una gran cantidad de informaci´on. Estos archivos son gestionados por cada investigador que participa en los proyectos, registrando las horas realizadas diariamente en cada proyecto en el que se trabaja. El gestor del archivo Excel se encarga de recopilar manualmente la informaci´on de todos estos archivos dispersos. La gesti´on de estas hojas de c´alculo en Excel tienen el prop´osito de satisfacer las labrores burocr´aticas presentadas por la necesidad de gestionar el presupuesto dado a cada proyecto. Sin embargo, este proceso de gesti´on de hojas de c´alculo presenta diversas limitaciones y desaf´ıos que dificultan la eficiencia y eficacia. El enfoque manual de recopilar los datos de cada hoja de c´alculo es tedioso y consume un tiempo considerable, lo cual puede resultar en demoras, errores o p´erdida de productividad. Para superar estas limitaciones, se plantea realizar este este proceso mediante el uso de herramientas tecnol´ogicas, en concreto, gestores de proyectos. El proceso de trabajo de la Polic´ıa Nacional revela la necesidad de superar el enfoque manual y tedioso de gesti´on de documentos Excel. En consecuencia, se realiza una investigaci´on sobre las herramientas que podr´ıan solventar esta necesidad. 3.2. Gestores de proyectos existentes En esta secci´on se llev´o a cabo una b´usqueda de diversos gestores de proyectos con el objetivo de evaluar c´omo se alineaban con los requisitos identificados durante la investigaci´on. Se exploraron diferentes alternativas disponibles en el mercado, analizando sus caracter´ısticas, funcionalidades y capacidades para satisfacer las necesidades espec´ıficas del proyecto. El an´alisis comparativo de estas soluciones permiti´o obtener una visi´on del estado actual de las herramientas gestionadoras de proyectos y establecer una base s´olida para la selecci´on de la soluci´on m´as adecuada. A continuaci´on, se presentan los gestores estudiados: 23 30 Cap´ ıtulo 4. Implementaci´ on de proyectos con Redmine Figura 4.1: Flujo de la propuesta se proporciona una explicaci´on de los componentes m´as importantes de una aplicaci´on desarrollada en Ruby on Rails [20]. 4.2.1. Patr´on Modelo-Vista-Controlador El patr´on Modelo-Vista-Controlador (MVC) [21] es un patr´on de dise˜no arquitect´onico ampliamente utilizado en el desarrollo de aplicaciones de software. Proporciona una estructura organizada y modularizada que separa la l´ogica de la aplicaci´on en tres componentes principales: el Modelo, la Vista y el Controlador. Cada uno de estos componentes tiene responsabilidades espec´ıficas y se comunica con los otros componentes de manera definida. A continuaci´on, se explican en detalle cada uno de estos componentes y su funcionamiento: Modelo: El Modelo representa los datos y la l´ogica de negocio de la aplicaci´on. Es responsable de gestionar y mantener el estado de los datos, as´ı como de realizar las operaciones relacionadas con la persistencia y manipulaci´on de los mismos. El Modelo encapsula la l´ogica de negocio y proporciona m´etodos para acceder, actualizar y manipular los datos subyacentes. Esto puede incluir operaciones como la lectura y escritura en la base de datos, c´alculos y validaciones de datos, y la implementaci´on de reglas de negocio. El Modelo no tiene conocimiento sobre la interfaz de usuario ni sobre c´omo se presentan los datos al usuario. Vista: La Vista es responsable de la presentaci´on de los datos al usuario y de la interacci´on con el mismo. Representa la interfaz de usuario y se encarga de mostrar los datos de manera visualmente atractiva y comprensible. La Vista recibe informaci´on del Modelo y la utiliza para generar la representaci´on gr´afica o textual que se muestra al usuario. Esto puede incluir la generaci´on de p´aginas web, la creaci´on 4.2. Implementaci´ on de Ruby on Rails 31 de interfaces de usuario interactivas, la visualizaci´on de informes y gr´aficos, entre otros. La Vista no tiene conocimiento directo sobre el Modelo ni sobre la l´ogica de negocio de la aplicaci´on. Controlador: El Controlador act´ua como intermediario entre el Modelo y la Vista. Es responsable de recibir las interacciones del usuario a trav´es de la interfaz de usuario y de controlar el flujo de la aplicaci´on. El Controlador interpreta las acciones del usuario y coordina las respuestas correspondientes del Modelo y la Vista. Cuando el usuario realiza una acci´on, como hacer clic en un bot´on o enviar un formulario, el Controlador recibe esta acci´on y toma las decisiones apropiadas. Puede invocar m´etodos del Modelo para realizar operaciones en los datos y actualizar su estado, y tambi´en puede actualizar la Vista para reflejar los cambios realizados en los datos. El Controlador no tiene conocimiento sobre c´omo se almacenan los datos ni c´omo se presentan visualmente. El flujo de la aplicaci´on en el patr´on MVC se basa en la interacci´on entre estos tres componentes. Cuando el usuario realiza una acci´on en la interfaz de usuario, como enviar un formulario, el Controlador captura esta acci´on y decide c´omo responder. Puede interactuar con el Modelo para obtener los datos necesarios, procesarlos y realizar operaciones, como validar la informaci´on ingresada por el usuario. Una vez que el Modelo ha realizado las operaciones requeridas, el Controlador actualiza la Vista correspondiente para reflejar los cambios realizados en los datos. Esto puede implicar la actualizaci´on de la interfaz de usuario, la generaci´on de mensajes de confirmaci´on, la visualizaci´on de errores, entre otros. La Vista, a su vez, muestra la informaci´on actualizada al usuario y permite nuevas interacciones. En la figura 4.2 se representa el flujo de trabajo en el patr´on MVC. Figura 4.2: Modelo-Vista-Controlador El patr´on MVC proporciona varios beneficios y ventajas en el desarrollo de aplicaciones [21]: 32 Cap´ ıtulo 4. Implementaci´ on de proyectos con Redmine Separaci´on de responsabilidades: Al dividir la l´ogica de la aplicaci´on en tres componentes distintos, el patr´on MVC permite una mejor organizaci´on y separaci´on de las responsabilidades. Esto facilita el mantenimiento y la evoluci´on de la aplicaci´on, ya que cada componente tiene un prop´osito espec´ıfico y puede modificarse de manera independiente. Reutilizaci´on de c´odigo: La separaci´on de la l´ogica de negocio del Modelo y la presentaci´on en la Vista permite reutilizar ambos componentes en diferentes contextos. Por ejemplo, se puede utilizar el mismo Modelo para diferentes interfaces de usuario o se puede utilizar una Vista para mostrar diferentes representaciones de los mismos datos. Facilidad de pruebas: El patr´on MVC facilita las pruebas unitarias, ya que los componentes son independientes entre s´ı y se pueden probar por separado. Por ejemplo, se pueden realizar pruebas en el Modelo sin necesidad de la Vista o el Controlador, lo que permite una mayor cobertura de pruebas y una mejor detecci´on de errores. Flexibilidad y escalabilidad: Al separar la l´ogica de la aplicaci´on en componentes distintos, el patr´on MVC permite una mayor flexibilidad y escalabilidad. Por ejemplo, se puede cambiar la Vista sin afectar el Modelo, o se puede agregar un nuevo Controlador para manejar nuevos flujos de la aplicaci´on sin modificar los dem´as componentes. En resumen, el patr´on MVC proporciona una estructura clara y modularizada para el desarrollo de aplicaciones. Al separar la l´ogica de negocio, la presentaci´on y el control de la aplicaci´on, el patr´on MVC mejora la organizaci´on, la reutilizaci´on de c´odigo, la facilidad de pruebas y la flexibilidad de la aplicaci´on. Es ampliamente utilizado en el desarrollo de aplicaciones web y de software en general, y ha demostrado ser efectivo en la construcci´on de sistemas robustos y escalables. 4.2.2. Patr´on Active Record El patr´on Active Record es un patr´on de dise˜no de software que combina el manejo de datos y la l´ogica de negocio en una sola clase, lo que permite interactuar con la base de datos de forma sencilla y transparente. Este patr´on se utiliza com´unmente en el desarrollo de aplicaciones que requieren un acceso persistente a datos, como aplicaciones web y sistemas de gesti´on de bases de datos. En el patr´on Active Record, cada clase del modelo representa una tabla en la base de datos y cada instancia de esa clase representa una fila en esa tabla. Cada atributo de la clase se mapea a una columna en la tabla, lo que permite acceder y manipular los datos de manera intuitiva. El patr´on Active Record se basa en varios principios clave [22]: Conexi´on a la base de datos: La clase Active Record se encarga de establecer la conexi´on con la base de datos y proporciona m´etodos para ejecutar consultas y transacciones. Mapeo objeto-relacional: El patr´on Active Record utiliza t´ecnicas de mapeo objeto-relacional para establecer la correspondencia entre los objetos de la clase 4.3. Implementaci´ on de Redmine 33 y las filas de la tabla en la base de datos. Esto implica mapear los atributos de la clase a las columnas de la tabla y proporcionar m´etodos para realizar operaciones Create, Read, Update, Delete (CRUD) en la base de datos. Validaci´on de datos: El patr´on Active Record incluye la capacidad de validar los datos antes de almacenarlos en la base de datos. Esto se logra mediante la definici´on de reglas de validaci´on en la clase Active Record, como la longitud m´ınima o m´axima de un campo, el formato de un campo de fecha, etc. Estas reglas se aplican autom´aticamente antes de realizar cualquier operaci´on de escritura en la base de datos, lo que ayuda a mantener la integridad de los datos. Relaciones entre objetos: El patr´on Active Record permite establecer relaciones entre las clases del modelo, lo que refleja las relaciones entre las tablas en la base de datos. Por ejemplo, una clase puede tener una relaci´on de uno a muchos con otra clase, lo que significa que una instancia de la clase puede tener varias instancias relacionadas en otra clase. Estas relaciones se definen mediante la asociaci´on de claves primarias y externas en las tablas, y se proporcionan m´etodos en la clase Active Record para acceder y manipular estas relaciones. Persistencia de datos: El patr´on Active Record se encarga de la persistencia de datos, es decir, de almacenar y recuperar objetos desde la base de datos. Proporciona m´etodos para guardar un objeto en la base de datos, actualizar sus atributos, eliminarlo de la base de datos y recuperar objetos de la base de datos basados en condiciones espec´ıficas. Las ventajas que presenta el patr´on son las siguientes: Simplicidad: Al combinar la l´ogica de negocio y el acceso a datos en una sola clase, el patr´on Active Record simplifica el desarrollo y el mantenimiento del c´odigo. Transparencia: La interacci´on con la base de datos se realiza de forma transparente a trav´es de los m´etodos de la clase Active Record, lo que facilita el manejo de datos persistentes. Rapidez de desarrollo: El patr´on Active Record permite crear r´apidamente modelos de datos y realizar operaciones CRUD sin necesidad de escribir consultas SQL personalizadas, lo que agiliza el desarrollo de la aplicaci´on. Facilidad de uso: El patr´on Active Record proporciona una interfaz sencilla y coherente para interactuar con los datos, lo que facilita su uso para desarrolladores que no est´an familiarizados con detalles espec´ıficos de la base de datos. Portabilidad: Al abstraer la capa de acceso a datos, el patr´on Active Record permite que la aplicaci´on sea m´as port´atil, ya que los detalles espec´ıficos de la base de datos se encapsulan dentro de la implementaci´on del Active Record. 4.3. Implementaci´on de Redmine La implementaci´on de Redmine es bastante extensa y compleja, ya que se trata de un sistema de gesti´on de proyectos completo con m´ultiples funcionalidades. Comprendidos los 34 Cap´ ıtulo 4. Implementaci´ on de proyectos con Redmine conceptos anteriormente explicados, se presentan algunos de los modelos m´as importantes en Redmine [23]: Issue: El modelo Issue representa una petici´on o tarea dentro de un proyecto en Redmine. Es uno de los modelos fundamentales y contiene informaci´on detallada sobre cada problema, como su t´ıtulo, descripci´on, estado, prioridad, asignado a, fecha de inicio, fecha de vencimiento, entre otros. Est´a estrechamente relacionado con muchos modelos ya que se trata de la herramienta de trabajo. Tracker: El modelo Tracker se utiliza para clasificar y organizar las peticiones o tareas (issues) dentro de un proyecto. El t´ermino ”tracker”se puede traducir como rastreador.o”seguimiento.en espa˜nol, y hace referencia a los tipos de peticiones que pueden existir en Redmine. Cada proyecto en Redmine puede tener diferentes Trackers definidos, lo que permite adaptar la herramienta a las necesidades espec´ıficas de cada proyecto. Por ejemplo, un proyecto de desarrollo de software tendr´a Trackers diferente a un proyecto de gesti´on de ventas. El Modelo Tracker en Redmine almacena la informaci´on relacionada con cada tipo de problema, incluyendo su nombre, descripci´on y configuraciones adicionales. Algunas de las configuraciones comunes asociadas a los trackers son: •Flujo de trabajo: Cada Tracker puede tener su propio flujo de trabajo, que define los diferentes estados que un problema puede tener y las transiciones permitidas entre ellos. •Campos personalizados: Los Trackers permiten definir campos personalizados adicionales que pueden ser espec´ıficos de cada tipo de problema. Estos campos pueden ser de diferentes tipos, como texto, fecha, lista desplegable, entre otros, y se utilizan para capturar informaci´on adicional relevante para cada tipo de problema. •Configuraci´on de visibilidad: Los Trackers pueden tener configuraciones de visibilidad que determinan qui´enes pueden ver y acceder a los problemas asociados a ese Tracker. Esto permite restringir el acceso solo a usuarios espec´ıficos o grupos de usuarios. Project: El modelo Project representa un proyecto en Redmine. Contiene informaci´on general sobre el proyecto, como su nombre, descripci´on, identificador ´unico, fecha de inicio, fecha de finalizaci´on, entre otros. Un proyecto es la unidad de organizaci´on de Redmine. User: El modelo User representa un usuario en Redmine. Almacena informaci´on sobre los usuarios registrados en el sistema, como su nombre, direcci´on de correo electr´onico, contrase˜na, roles asignados, preferencias de visualizaci´on, entre otros. 4.3.1. Extensiones Una extensi´on en Redmine tiene m´ultiples usos y aporta funcionalidades adicionales a la plataforma base. A continuaci´on, se detallan algunas de las principales razones por las que las extensiones son valiosas en Redmine [24]: Extender la funcionalidad: Las extensiones permiten extender las capacidades de Redmine agregando nuevas caracter´ısticas y herramientas. Pueden agregar m´odulos 4.4. Implementaci´ on del flujo de trabajo 35 espec´ıficos, como seguimiento de tiempo adicional, integraci´on con sistemas externos, generaci´on de informes personalizados, integraci´on con control de versiones, entre otros. Esto permite adaptar Redmine a las necesidades espec´ıficas de un proyecto o una organizaci´on. Personalizaci´on y adaptabilidad: Las extensiones proporcionan la capacidad de personalizar y adaptar Redmine seg´un los requisitos espec´ıficos de una organizaci´on. Esto puede incluir la personalizaci´on de la interfaz de usuario, la adici´on de campos personalizados, la creaci´on de flujos de trabajo personalizados, la configuraci´on de reglas de negocio espec´ıficas y la incorporaci´on de procesos personalizados. Las extensiones permiten que Redmine se ajuste a los flujos de trabajo existentes y a las pr´acticas de una organizaci´on. Integraci´on con otras herramientas y sistemas: Las extensiones pueden facilitar la integraci´on de Redmine con otras herramientas y sistemas utilizados en una organizaci´on. Esto incluye integraciones con servicios de almacenamiento en la nube como Dropbox oGoogle Drive , sistemas de automatizaci´on como Jenkins, entre otros. Estas integraciones mejoran la productividad y la colaboraci´on al permitir que Redmine se conecte y comparta informaci´on con otras herramientas. Mejora de la productividad y eficiencia: Las extensiones pueden automatizar tareas repetitivas, proporcionar acceso r´apido a informaci´on relevante y optimizar procesos dentro de Redmine. Por ejemplo, una extensi´on podr´ıa agregar plantillas predefinidas para la creaci´on r´apida de nuevos elementos, proporcionar atajos de teclado personalizados, agregar recordatorios o notificaciones automatizadas, o generar informes y m´etricas para el seguimiento del progreso del proyecto. Estas mejoras ayudan a ahorrar tiempo y aumentan la eficiencia en el uso de Redmine. Complementar las capacidades existentes: Algunas veces, Redmine puede carecer de ciertas caracter´ısticas o tener limitaciones en su funcionalidad base. Las extensiones pueden llenar esas brechas agregando las capacidades faltantes. Por ejemplo, una extensi´on podr´ıa agregar soporte para diagramas de Gantt, gr´aficos para seguimiento ´agil, capacidades avanzadas de gesti´on de documentos, integraci´on con herramientas de chat y colaboraci´on en tiempo real, entre otros. Esto permite aprovechar al m´aximo Redmine y ampliar su alcance. 4.4. Implementaci´on del flujo de trabajo Para implementar el flujo de trabajo dentro de Redmine, en primer lugar el Consorcio debe enviar la propuesta, dicha propuesta se crea con un formulario en el que se introducen los siguientes datos, a petici´on de la Polc´ıa Nacional, estos datos est´an nombrados en ingl´es: Proposal Acronym Call Type of Action Topic Budget 36 Cap´ ıtulo 4. Implementaci´ on de proyectos con Redmine Budget allocate to Spanish National Police Keywords Abstract Workload expeted from Spanish National Police Coordinating organization Main Contact Person Email address Department Telephone Deadline El formulario resultante es el representado por la figura 4.3. Figura 4.3: Formulario de propuesta Una vez cumplimentado dicho formulario, la propuesta se crea, haciendo que el departamento que gestiona los proyectos del Consorcio sea avisado mediante correo electr´onico. En este punto, la Polic´ıa Nacional lleva a cabo una serie de reuniones para aceptar o rechazar la propuesta, cambiando el estado de la propuesta a En negociaciones. En caso de que se rechace la propuesta, simplemente se cambia su estado a Rechazada y se guarda en la base de datos una entrada con la propuesta rechazada. En el caso de que la propuesta resulte aceptada, se crea un proyecto asociado a dicha propuesta para que se puedan generar los informes que pide el Consorcio. 4.5. Pruebas y Resultados 37 4.5. Pruebas y Resultados 4.5.1. Introducci´on En esta secci´on, se presentan los resultados obtenidos despu´es de la implementaci´on del gestor de proyectos en Redmine. Para garantizar la calidad y la adecuaci´on a los requisitos, se utilizaron varias estrategias, incluyendo la realizaci´on de reuniones en las que se hac´ıan pruebas de concepto y la aplicaci´on de pruebas unitarias. 4.5.2. Pruebas de concepto Para asegurar que la implementaci´on del gestor de proyectos en Redmine cumpl´ıa con las necesidades espec´ıficas de la Polic´ıa Nacional, se llevaron a cabo reuniones con los representantes de la instituci´on. Estas reuniones permitieron mostrar las caracter´ısticas desarrolladas hasta el momento y obtener una retroalimentaci´on de los usuarios finales del gestor. Tal como se describe en la metodolog´ıa Scrum, tras recibir la retroalimentaci´on de la Polic´ıa Nacional, se realizaban los ajustes y modificaciones necesarias en la implementaci´on del gestor de proyectos. Este proceso de coordinaci´on y retroalimentaci´on se repet´ıa en cada iteraci´on, permitiendo una colaboraci´on estrecha y asegurando que el sistema se ajustara a las necesidades reales de los usuarios. 4.6. Pruebas de funcionamiento Adem´as de las reuniones con la Polic´ıa Nacional, se realizaron pruebas funcionales para garantizar la calidad y el correcto funcionamiento del gestor de proyectos en Redmine. Se utilizaron pruebas unitarias tanto de Redmine como de los plugins desarrollados. Las pruebas unitarias consistieron en la ejecuci´on de las pruebas automatizados proporcionados por Redmine y de las extensiones. Estas pruebas verificaban el funcionamiento de los componentes individuales del sistema, como los modelos, controladores y vistas. Se aseguraba que las funcionalidades desarrolladas cumpl´ıan con los criterios de aceptaci´on definidos durante la etapa de an´alisis y dise˜no. La ejecuci´on de pruebas unitarias no solo permiti´o verificar el comportamiento esperado de la aplicaci´on, sino que tambi´en facilit´o la detecci´on temprana de posibles errores y problemas de integraci´on. Se realizaron pruebas exhaustivas para cubrir diferentes escenarios y se corrigieron los problemas identificados antes de proceder con la implementaci´on final [24]. 4.7. Resultados y conclusiones Gracias a la aplicaci´on de reuniones de retroalimentaci´on con la Polic´ıa Nacional y la realizaci´on de pruebas unitarias, se lograron obtener resultados satisfactorios en la implementaci´on del gestor de proyectos en Redmine. Las reuniones con los usuarios finales del gestor permitieron recopilar valiosos comentarios y sugerencias que se tuvieron en cuenta para ajustar y mejorar la 38 Cap´ ıtulo 4. Implementaci´ on de proyectos con Redmine implementaci´on del sistema. La metodolog´ıa de implementaci´on iterativa y las reuniones peri´odicas de coordinaci´on fueron fundamentales para asegurar la adaptaci´on del gestor de proyectos a las necesidades espec´ıficas de la instituci´on. Por otro lado, las pruebas unitarias de Redmine y de las extensiones garantizaron el correcto funcionamiento de las funcionalidades implementadas. Se detectaron y solucionaron errores antes de la puesta en producci´on, lo que contribuy´o a la estabilidad y confiabilidad del sistema. Las pruebas unitarias permitieron verificar el comportamiento esperado de cada componente, asegurando que cumpliera con los criterios de aceptaci´on definidos previamente. En conclusi´on, la combinaci´on de entrevistas con los usuarios y la realizaci´on pruebas unitarias fue crucial para evaluar y validar la implementaci´on del gestor. Estas estrategias garantizaron que el sistema cumpliera con los requisitos espec´ıficos de la Polic´ıa Nacional, al tiempo que se aseguraba la calidad y el correcto funcionamiento del software. La retroalimentaci´on recibida y los ajustes realizados en cada etapa del desarrollo contribuyeron a la satisfacci´on de los usuarios finales y al ´exito de la implementaci´on del gestor de proyectos. Cap´ıtulo 5 Conclusiones y Trabajo Futuro 5.1. Conclusiones En conclusi´on, el trabajo realizado brind´o una oportunidad invaluable para aplicar los conocimientos adquiridos durante el estudio de la Ingenier´ıa. Este proyecto permiti´o explorar en profundidad las distintas metodolog´ıas de trabajo utilizadas en la industria y comprender su importancia para la eficiencia y el ´exito de los proyectos de desarrollo de software. Adem´as, se analizaron en detalle las principales herramientas inform´aticas disponibles para la gesti´on de proyectos, brindando una visi´on integral de c´omo utilizar eficazmente estas herramientas para planificar, coordinar y controlar el progreso del trabajo. El trabajo de investigaci´on y an´alisis llevado a cabo en este proyecto proporcion´o una comprensi´on s´olida de las diferentes metodolog´ıas de trabajo, incluyendo enfoques tradicionales y ´agiles como Scrum, Kanban y Cascada. Se evaluaron sus ventajas, desaf´ıos y ´areas de aplicaci´on m´as adecuadas, lo que permiti´o una visi´on cr´ıtica y fundamentada sobre cu´al metodolog´ıa es m´as adecuada para cada tipo de proyecto. Adem´as, se profundiz´o en el uso de herramientas inform´aticas espec´ıficas para la gesti´on de proyectos, como Jira o Redmine, examinando sus caracter´ısticas, funcionalidades y mejores pr´acticas para su implementaci´on exitosa. Se exploraron aspectos clave, como la gesti´on de tareas, el seguimiento del progreso, la asignaci´on de recursos y la comunicaci´on efectiva dentro de los equipos de trabajo. Se emple´o la experiencia en t´ecnicas de desarrollo de software, comprensi´on de requisitos y dise˜no de sistemas para abordar las necesidades y desaf´ıos presentes en la gesti´on de proyectos con herramientas inform´aticas. Este proyecto no solo proporcion´o una visi´on pr´actica y aplicada de las metodolog´ıas de trabajo y la gesti´on de proyectos, sino que tambi´en permiti´o desarrollar habilidades de investigaci´on, an´alisis cr´ıtico y toma de decisiones. Estas habilidades son fundamentales para enfrentar los desaf´ıos del mundo laboral y contribuir de manera efectiva en proyectos de desarrollo de software. 39 46 Cap´ ıtulo 7. Conclusions and Future Work 7.2. Future Work Possible future work may include the following: •Expand functionality of the manager: currently the implemented manager allows the management of project proposals received from Horizon Europe, among others. Given the close relationship of the research group to which the directors of the work belong with the National Police, it is proposed to expand with the management of Final Degree Projects carried out in this faculty. •Search for extensions: it is proposed to research new extensions to satisfy other types of needs that the National Police does not have, but that could be of interest to them. For example: Redmine Agile Plugin,Redmine Finance Plugin or Redmine Messenger Plugin. •Upgrade version: it is also proposed to migrate Redmine to a newer version, taking into account that some extensions used may not be compatible with this new version. Ap´endice A Requisitos funcionales Tabla A.1: Organizaci´on de usuarios en proyectos ID RF-001 Actores Usuario gestor Precondici´ on Se encuentran usuarios y proyectos creados Descripci´ on La herramienta debe dar la posibilidad de asignar usuarios a proyectos Estos usuarios pueden tener diferentes roles, teniendo as´ı diferente visibilidad en las tareas que se encuentra en el proyecto. Postcondici´ on Se confirma la uni´on del usuario al proyecto Tabla A.2: Uso de conteo de horas ID RF-002 Actores Cualquier usuario Precondici´ on Usuario se encuentra autentificado en el sistema y forma parte del proyecto al que se quiere a˜nadir horas Descripci´ on Los usuarios ser´an capaces de a˜nadir sus propias a horas a determinados tipos de tareas de un proyecto dado Postcondici´ on Tras el ingreso de horas, se confirmar´a con un mensaje Tabla A.3: Acceso mediante navegador ID RF-003 Actores Cualquier usuario Precondici´ on Usuario tiene acceso a Internet e introduce dominio en su navegador web Descripci´ on La herramienta ser´a accesible v´ıa protocolo TCP/HTTP a trav´es de navegadores HTML Chrome, Firefox e Internet Explorer. Postcondici´ on Ser´a mostrada la herramienta en el navegador web 47 48 Cap´ ıtulo A. Requisitos funcionales Tabla A.4: Autentificaci´on de usuarios ID RF-004 Actores Cualquier usuario Precondici´ on Usuario introduce credenciales que son su identificador de usuario y contrase˜na Descripci´ on Los usuarios deben ser capaces de autentificarse en el sistema mediante uso de usuario y contrase˜na Postcondici´ on Usuario es identificado en el sistema, en caso de que las credenciales no sean correctas se vuelven a pedir los datos Tabla A.5: Registro de usuarios ID RF-005 Actores Cualquier usuario Precondici´ on Usuario introduce los datos necesarios para la creaci´on de su cuenta. Entre estos datos se encuentra un correo electr´onico v´alido, este no puede estar siendo utilizado por otro usuario del sistema Descripci´ on Los usuarios deben ser capaces de registrarse en el sistema, introduciendo los datos necesarios para ello. Una vez registrado un usuario, un administrador debe activar su cuenta, este proceso se debe poder automatizar Postcondici´ on El usuario recibe confirmaci´on de su creaci´on de cuenta de usuario y debe esperar a que se le active la cuenta, puede recibir confirmaci´on por su correo electr´onico Tabla A.6: Modificaci´on de datos de usuario ID RF-006 Actores Cualquier usuario Precondici´ on Usuario est´a autentificado en la aplicaci´on Descripci´ on Los usuarios de la aplicaci´on deben ser capaces de modificar su informaci´on, esto es, su nombre, apellido y correo electr´onico Postcondici´ on Usuario recibe confirmaci´on del cambio de los datos Tabla A.7: Borrado de usuarios ID RF-007 Actores Gestor Precondici´ on Se encuentran usuarios creados en la aplicaci´on Descripci´ on La aplicaci´on debe dar la posibilidad de eliminar los datos de un usuario Postcondici´ on Usuario recibe confirmaci´on del borrado Tabla A.8: Bloqueo de usuarios ID RF-008 Actores Gestor Precondici´ on Se encuentran usuarios creados en la aplicaci´on Descripci´ on La aplicaci´on debe dar la posibilidad de bloquear usuarios. Los usuarios bloqueados no podr´an acceder a la aplicaci´on hasta que se desbloqueen. Tampoco se les podr´a asignar tareas, asignarlos como observadores o recibir correos electr´onicos Postcondici´ on Usuario recibe confirmaci´on del bloqueo 49 Tabla A.9: Generar contrase˜na autom´aticamente ID RF-009 Actores Gestor Precondici´ on Se encuentran usuarios creados en la aplicaci´on Descripci´ on La aplicaci´on debe dar la posibilidad de cambiar y generar una contrase˜na segura para un usuario. Estas nuevas credenciales podr´an ser enviadas por correo electr´onico al usuario Postcondici´ on Usuario recibe confirmaci´on del cambio de contrase˜na Tabla A.10: Creaci´on de grupos de usuarios ID RF-010 Actores Gestor Precondici´ on N/A Descripci´ on Los usuarios deben ser capaces de organizarse en grupos, hay dos grupos de usuarios por defecto: Usuarios no registrados y Usuarios an´onimos (no autentificados) Postcondici´ on Tras la introducci´on de datos necesarios para crear un grupo, se recibe su confirmaci´on Tabla A.11: Organizaci´on de usuarios en grupos ID RF-011 Actores Gestor Precondici´ on Se encuentran usuarios y grupos creados en la aplicaci´on Descripci´ on Los usuarios deben ser capaces de organizarse en grupos, los grupos son simplemente un conjunto de usuarios bajo un mismo nombre. Los grupos pueden ser a˜nadidos a proyectos, de la misma manera que se a˜naden usuarios normales Postcondici´ on Se recibe confirmaci´on de que el usuario ha sido a˜nadido al grupo Tabla A.12: Creaci´on de proyectos ID RF-012 Actores Gestor Precondici´ on N/A Descripci´ on Los usuarios gestores deben ser capaces de crear proyectos. Estos proyectos podr´an tener subproyectos dependientes Postcondici´ on Tras la introducci´on de los datos necesarios para la creaci´on de un proyecto, el usuario recibe confirmaci´on de su creaci´on Tabla A.13: Editar informaci´on de proyectos ID RF-013 Actores Gestor Precondici´ on N/A Descripci´ on La aplicaci´on debe dar la posibilidad de cambiar la informaci´on de un proyecto. Por defecto la informaci´on de un proyecto es su nombre, su descripci´on. Se puede modificar tambi´en los m´odulos que utiliza un proyecto, los m´odulos son las funcionalidades como conteo del tiempo, creaci´on de tareas, etc. Postcondici´ on Usuario recibe confirmaci´on del cambio de informaci´on 50 Cap´ ıtulo A. Requisitos funcionales Tabla A.14: Creaci´on de roles y permisos ID RF-014 Actores Gestor Precondici´ on N/A Descripci´ on La aplicaci´on debe dar la posibilidad de crear roles. Un rol es una colecci´on de permisos que aplican a un proyecto, un usuario puede tener varios roles dentro de un mismo proyecto Postcondici´ on Tras la introducci´on de los datos necesarios para crear un rol, se confirma su creaci´on Tabla A.15: Asignar roles a usuarios ID RF-015 Actores Gestor Precondici´ on Se encuentran usuarios creados en la aplicaci´on. El gestor se encuentra autentificado en el sistema Descripci´ on Los usuarios podr´an ser asignados roles, dependiendo del rol que sea, se tendr´an unos permisos u otros Postcondici´ on Usuario recibe confirmaci´on de la asignaci´on Tabla A.16: Creaci´on de tipos de tareas ID RF-016 Actores Gestor Precondici´ on N/A Descripci´ on El tipo de una tarea es una manera de organizar informaci´on. Para cada tipo de tarea, se puede definir su nombre, el estado por defecto de las tareas, su flujo de trabajo y campos especiales creados por el gestor Postcondici´ on Usuario recibe confirmaci´on de la asignaci´on Tabla A.17: Creaci´on de campos personalizados ID RF-017 Actores Gestor Precondici´ on N/A Descripci´ on La aplicaci´on debe ser capaz de crear y asignar campos personalizados. Los campos personalizados es informaci´on arbitraria que se puede a˜nadir a cualquier entidad del sistema, entre ellos: tipos de tareas, tareas, tiempo invertido en una tarea, proyectos, usuarios, grupos de usuarios, etc. Postcondici´ on Usuario recibe confirmaci´on de la creaci´on del campo personalizado Tabla A.18: Repositorio de datos ID RF-018 Actores Cualquier usuario Precondici´ on Usuario tiene permiso para hacer subida de datos Descripci´ on Los usuarios deben ser capaces de subir archivos al sistema. Las extensiones de archivos aceptadas y el tama˜no m´aximo de subida se debe poder configurar en la aplicaci´on Postcondici´ on Usuario recibe confirmaci´on de la subida 51 Tabla A.19: Capacidad para configurar notificaciones por correo electr´onico ID RF-019 Actores Gestor Precondici´ on N/A Descripci´ on Los usuarios pueden ser notificados de ciertos cambios por correo electr´onico, por ejemplo, se deber´ıa poder avisar cada vez que se crea una tarea o cuando un usuario es asignado a una tarea Postcondici´ on Usuario recibe confirmaci´on de la creaci´on de notificaciones por correo electr´onico Bibliograf´ıa [1] Canva. Tablero kanban. https://marketplace.canva.com/EAElcD3jpX0/1/0/1600w/ canva-memphis-tablero-kanban-lluvia-de-ideas-8flm3lKElDQ.jpg, 2023 (accessed May 15, 2023). [2] Julie Delisle. Working time in multi-project settings: How project workers manage work overload. International Journal of Project Management, 38(7):419–428, 2020. Actors, Practices and Strategy Connections in Multi-Project Management. [3] Pablo Lled´o and Gustavo Rivarola. Gesti´on de proyectos. Pearson Educaci´on Buenos Aires, 2007. [4] Esteban Gabriel Maida and Juli´an Pacienzia. Metodolog´ıas de desarrollo de software. Tesis de Licenciatura en Sistemas y Computaci´on, pages 12–30, 2015. [5] AK Munns and BF Bjeirmi. The role of project management in achieving project success. International Journal of Project Management, 14(2):81–87, 1996. [6] Juan David Yepes Gonz´alez, C´esar Jes´us Pardo Calvache, and Omar Salvador G´omez G´omez. Revisi´on sistem´atica acerca de la implementaci´on de metodolog´ıas ´agiles y otros modelos en micro, peque˜nas y medianas empresas de software. Revista Tecnol´ogica-ESPOL, 28(5), 2015. [7] Kumar Gaurav and Bhatia Pradeep. Comparative Analysis of Software Engineering Models from Traditional to Modern Methodologies. pages 189–191, 2014. [8] Winston W Royce. Managing the development of large software systems: concepts and techniques. In Proceedings of the 9th international conference on Software Engineering, pages 328–329, 1987. [9] Sundramoorthy Balaji and M Sundararajan Murugaiyan. Waterfall vs. v-model vs. agile: A comparative study on sdlc. International Journal of Information Technology and Business Management, 2(1):26–30, 2012. [10] R Galo Fari˜no. Modelo espiral de un proyecto de desarrollo de software. Obtenido de http://www.ojovisual.net/galofarino/modeloespiral.pdf, 2011. [11] Jesse Santiago and Desirae Magallon. Critical path method. CEE320, Winter 2013, 2009. [12] Rob Cole and Edward Scotcher. Brilliant Agile project management: a practical guide to using Agile, Scrum and Kanban. Pearson UK, 2016. [13] Jos´e Joskowicz. Reglas y pr´acticas en extreme programming. Universidad de Vigo, 22, 2008. [14] Christian Misobi Budoya, Mussa M Kissaka, and Joel S Mtebe. Instructional design enabled agile method using addie model and feature driven development process. International Journal of Education and Development Using Information and Communication Technology, 15(1):n1, 2019. [15] Ken Schwaber. Scrum development process. In Business Object Design and Implementation: OOPSLA’95 Workshop Proceedings 16 October 1995, Austin, Texas, pages 117–134. Springer, 1997. 53 54 BIBLIOGRAF´ IA [16] Aleksandar Arnautovi´c. Managing project using jira software. Serbian Journal of Engineering Management, 7(2):40–46, 2022. [17] Tˆania Ferreira, Juncal Guti´errez-Artacho, and Jorge Bernardino. Freemium project management tools: Asana, freedcamp and ace project. In Trends and Advances in Information Systems and Technologies: Volume 1 6, pages 1026–1037. Springer, 2018. [18] Muhammad Sajad, Muhammad Sadiq, Khawar Naveed, and Muhammad Shahid Iqbal. Software project management: Tools assessment, comparison and suggestions for future development. International Journal of Computer Science and Network Security (IJCSNS), 16(1):36–37, 2016. [19] David Heinemeier Hansson. Ruby on rails guides. https://rubyonrails.org, 2023 (accessed April 15, 2023). [20] Julia Plekhanova. Evaluating web development frameworks: Django, ruby on rails and cakephp. Institute for Business and Information Technology, 20:3–15, 2009. [21] James Bucanek. Model-view-controller pattern. Learn Objective-C for Java Developers, pages 353–356, 2009. [22] Pawe l Luczak, Aneta Poniszewska-Maranda, and Vincent Karoviˇc. The process of creating web applications in ruby on rails. Developments in Information & Knowledge Management for Business Applications: Volume 1, pages 375,382–386, 2021. [23] Denis O Zmeev, Oleg A Zmeev, and Daniil V Tamazlykar. Implementation of essence practice into project management system redmine. In 2019 Actual Problems of Systems and Software Engineering (APSSE), pages 119–123. IEEE, 2019. [24] Alex Bevilacqua. Redmine plugin extension and development. Packt Publishing Ltd, 2014.