Plataforma para la gestión de recursos humanos y tecnológicos para empresas

Texto completo

(1)UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Máster Universitario en Ingeniería Web. Trabajo Fin de Máster Plataforma para la gestión de recursos humanos y tecnológicos para empresas. Autor Sandra Ortega Sánchez. Tutor Jesús Bernal Bermúdez. julio de 2019.

(2) [UPM] Máster en Ingeniería Web.

(3) Plataforma para la gestión de recursos humanos y tecnológicos. AGRADECIMIENTOS A mi hermana Nuria y mi familia por ser siempre incondicionales. A los docentes que despiertan la curiosidad y las ganas de afrontar nuevos retos: Jesús, Santiago, Raquel. A mis compañeros de profesión que son un aliciente de superación día a día..

(4) [UPM] Máster en Ingeniería Web.

(5) Plataforma para la gestión de recursos humanos y tecnológicos. RESUMEN En grandes empresas donde los recursos humanos y los acuerdos de negocio con clientes se coordinan fuera de los departamentos de desarrollo, resulta complicado promover iniciativas que tengan en cuenta todos los factores involucrados. Se presenta así la necesidad de encontrar el modo de coordinar los recursos eficazmente desde cada departamento. Éstos deben ser accesibles desde el mismo lugar: una herramienta que integre todos los recursos de interés. De modo que queden centralizados bajo el mismo sistema agilizando las labores de gestión del departamento.. P ALABRAS CLAVE Departamento, gestión, empleados, proyectos, tecnologías, formación, calendario.

(6) [UPM] Máster en Ingeniería Web.

(7) Plataforma para la gestión de recursos humanos y tecnológicos. ABSTRACT It is difficult to promote initiatives that consider all factors involved in the context of large companies where human resources and business agreements with clients are coordinated away from development departments. This scenario presents the need to find a way to coordinate capacities effectively from each department. All these resources must be reached from a single place: a platform which integrates all resources of interest. Thus, they will be centralized under the same system, streamlining management tasks of the department.. K EYWORDS Department, management, employees, projects, technologies, training, calendar.

(8) [UPM] Máster en Ingeniería Web.

(9) Plataforma para la gestión de recursos humanos y tecnológicos. TABLA DE CONTENIDOS Contenido Agradecimientos ................................................................................................................... 3 Resumen ............................................................................................................................... 5 Palabras clave ................................................................................................................... 5 Abstract................................................................................................................................. 7 Keywords .......................................................................................................................... 7 Tabla de Contenidos ............................................................................................................. 9 Tabla de Figuras .................................................................................................................. 12 Objetivos ............................................................................................................................. 15 Introducción........................................................................................................................ 16 User personas ................................................................................................................. 16 Stack tecnológico ............................................................................................................ 17 Spring .......................................................................................................................... 17 MongoDB .................................................................................................................... 19 Angular........................................................................................................................ 20 Transporte de datos ....................................................................................................... 20 Arquitectura API ................................................................................................................. 21 Especificación del API ......................................................................................................... 22 Operadores del API ......................................................................................................... 22 Paquetes y responsabilidades ........................................................................................ 25 Buddy Resource .......................................................................................................... 25 Coaching Resource...................................................................................................... 27 Technology Resource .................................................................................................. 28 Project Resource ......................................................................................................... 29 Training Resource ....................................................................................................... 31 Buddy Holidays Resource ........................................................................................... 32 Public Holidays Resource ............................................................................................ 33 Lógica de negocio ............................................................................................................... 35 Buddy Controller......................................................................................................... 36 Coaching Controller .................................................................................................... 36 Technology Controller ................................................................................................ 36.

(10) [UPM] Máster en Ingeniería Web Project Controller ....................................................................................................... 37 Training Controller ...................................................................................................... 37 BuddyHolidays Controller ........................................................................................... 37 PublicHolidays Controller ........................................................................................... 38 Paquete document...................................................................................................... 39 Diagrama de clases ..................................................................................................... 40 Arquitectura cliente ............................................................................................................ 41 Componentes.................................................................................................................. 42 Transporte de datos ................................................................................................... 46 Interfaz gráfica .................................................................................................................... 47 Buddies ........................................................................................................................... 47 Listado de Buddies ...................................................................................................... 47 Detalle de Buddy ......................................................................................................... 48 Creación de Buddy ...................................................................................................... 51 Edición de Buddy ........................................................................................................ 53 Eliminación de Buddy.................................................................................................. 54 Projects ........................................................................................................................... 56 Listado de Projects ...................................................................................................... 56 Detalle de Project ....................................................................................................... 57 Creación de Project ..................................................................................................... 58 Edición de Project ....................................................................................................... 60 Eliminación de Project ................................................................................................ 61 Technologies ................................................................................................................... 62 Listado de Technologies .............................................................................................. 62 Detalle de Technology ................................................................................................ 63 Creación de Technology .............................................................................................. 64 Edición de Technology ................................................................................................ 65 Eliminación de Technology ......................................................................................... 66 Training ........................................................................................................................... 67 Listado de Training ..................................................................................................... 67 Detalle de Training ..................................................................................................... 68 Creación de Training ................................................................................................... 69 Edición de Training ..................................................................................................... 71 Eliminación de Training .............................................................................................. 72.

(11) Plataforma para la gestión de recursos humanos y tecnológicos Calendar .......................................................................................................................... 73 Añadir PublicHolidays ................................................................................................. 73 Metodología ....................................................................................................................... 74 Descripción ..................................................................................................................... 74 Definición de las funcionalidades ............................................................................... 74 Diagrama de Gant ....................................................................................................... 75 User Stories Sprint 1 ....................................................................................................... 75 User Stories Sprint 2 ....................................................................................................... 77 User Stories Sprint 3 ....................................................................................................... 79 User Stories Sprint 4 ....................................................................................................... 82 Conclusiones y Posibles Ampliaciones................................................................................ 86 Bibliografía .......................................................................................................................... 89 Anexo I ................................................................................................................................ 91 Tratamiento de objetos Map en los Dto ........................................................................ 91 JSON de Typescript a Java........................................................................................... 91 JSON de Java a Typescript........................................................................................... 91 Tipos en la key de objetos Map ...................................................................................... 91 Anexo II ............................................................................................................................... 92 Planificación User Stories ............................................................................................... 92.

(12) [UPM] Máster en Ingeniería Web. TABLA DE FIGURAS Figure 1 Generación proyecto Spring ................................................................................. 17 Figure 2 Metadata proyecto Spring .................................................................................... 18 Figure 3 Dependencias proyecto Spring ............................................................................. 19 Figure 4 Stack tecnológico .................................................................................................. 20 Figure 5 Arquitectura Proyecto Spring ............................................................................... 21 Figure 6 Recursos del paquete rest_controllers ................................................................. 22 Figure 7 Operaciones recurso Buddy.................................................................................. 22 Figure 8 Operaciones recurso Coaching ............................................................................. 23 Figure 9 Operaciones recurso Technology ......................................................................... 23 Figure 10 Operaciones recurso Project .............................................................................. 24 Figure 11 Operaciones recurso Training ............................................................................. 24 Figure 12 Operaciones recurso Buddy Holidays ................................................................. 24 Figure 13 Operaciones recurso Public Holidays ................................................................. 25 Figure 14 Controlador del API Buddy ................................................................................. 26 Figure 15 Dto de entrada BuddyInputDto .......................................................................... 26 Figure 16 Dto de salida BuddyOutputDto .......................................................................... 26 Figure 17 Controlador del API Coaching ............................................................................ 27 Figure 18 Dto de entrada y salida CoachingDto ................................................................. 28 Figure 19 Controlador del API Technology ........................................................................ 29 Figure 20 Dto de entrada y salida TechnologyDto ............................................................. 29 Figure 21 Controlador del API Project ............................................................................... 30 Figure 22 Dto de entrada ProjectInputDto ......................................................................... 30 Figure 23 Dto de salida ProjectOutputDto ......................................................................... 31 Figure 24 Controlador del API Training.............................................................................. 32 Figure 25 Dto de entrada y salida TrainingDto ................................................................... 32 Figure 26 Controlador del API BuddyHolidays ................................................................... 33 Figure 27 Dto de entrada BuddyHolidaysInputDto ............................................................ 33 Figure 28 Dto de salida BuddyHolidaysOutputDto ............................................................. 33 Figure 29 Controlador del API PublicHolidays ................................................................... 34 Figure 30 Dto de entrada y salida PublicHolidaysDto ........................................................ 34 Figure 31 Paquete de controladores business_controllers ................................................ 35 Figure 32 Paquete de los repositorios ................................................................................ 35 Figure 33 Controlador Buddy y su relación con BuddyRepository ..................................... 36 Figure 34 Controlador Coaching y su relación con CoachingRepository ............................ 36 Figure 35 Controlador Technology y su relación con TechnologyRepository ................... 36 Figure 36 Controlador Project y su relación con ProjectRepository .................................. 37 Figure 37 Controlador Training y su relación con TrainingRepository ............................... 37 Figure 38 Controlador BuddyHolidays y su relación con BuddyHolidaysRepository ......... 37 Figure 39 Controlador PublicHolidays y su relación con PublicHolidaysRepository .......... 38 Figure 40 Paquete documents ............................................................................................ 39 Figure 41 Diagrama de clases ............................................................................................. 40.

(13) Plataforma para la gestión de recursos humanos y tecnológicos Figure 42 Arquitectura Proyecto Angular ........................................................................... 41 Figure 43 paquete services ................................................................................................. 41 Figure 44 Detalle de las rutas de la aplicación Angular ...................................................... 42 Figure 45 Detalle del paquete de componentes buddy ..................................................... 43 Figure 46 Servicio BuddyService ......................................................................................... 43 Figure 47 Servicio BuddyHolidays ....................................................................................... 44 Figure 48 Servicio CoachingService .................................................................................... 45 Figure 49 Modelos relacionados con el paquete Buddy .................................................... 46 Figure 50 Listado de Buddies .............................................................................................. 47 Figure 51 Detalle de Buddy................................................................................................. 48 Figure 52 Detalle de Buddy con asignación de BuddyHolidays .......................................... 49 Figure 53 Detalle de Buddy con listado de BuddyHolidays ................................................ 50 Figure 54 Creación de Buddy con detalle de validación ..................................................... 51 Figure 55 Creación de Buddy .............................................................................................. 52 Figure 56 Eliminación de mentor con buddies asignados .................................................. 54 Figure 57 Eliminación de mentor sin buddies asignados ................................................... 55 Figure 58 Listado de Projects .............................................................................................. 56 Figure 59 Detalle de Project ............................................................................................... 57 Figure 60 Creación de Project con detalle de validación.................................................... 58 Figure 61 Creación de project............................................................................................. 59 Figure 62 Edición de Project ............................................................................................... 60 Figure 63 Eliminación de Project ........................................................................................ 61 Figure 64 Listado de technologies ...................................................................................... 62 Figure 65 Detalle Technology ............................................................................................. 63 Figure 66 Creación de Technology ..................................................................................... 64 Figure 67 Edición de Technology ........................................................................................ 65 Figure 68 Eliminar Technology ........................................................................................... 66 Figure 69 Listado Training................................................................................................... 67 Figure 70 Detalle de Training .............................................................................................. 68 Figure 71 Creación de Training I ......................................................................................... 69 Figure 72 Creación de Training II ........................................................................................ 70 Figure 73 Edición Training .................................................................................................. 71 Figure 74 Eliminar Training ................................................................................................. 72 Figure 75 Añadir PublicHolidays ......................................................................................... 73 Figure 76 Tabla estimación US............................................................................................ 74 Figure 77 Diagrama Gantt de US ........................................................................................ 75 Figure 78 Diagrama Gantt Sprint 1 ..................................................................................... 76 Figure 79 Diagrama Gantt Sprint 2 ..................................................................................... 79 Figure 80 Diagrama Gantt Sprint 3 ..................................................................................... 82 Figure 81 Diagrama Gantt Sprint 4 ..................................................................................... 85.

(14) [UPM] Máster en Ingeniería Web.

(15) Plataforma para la gestión de recursos humanos y tecnológicos. OBJETIVOS El objetivo de la aplicación que se propone es desarrollar una herramienta que facilite la administración de tareas en un departamento de desarrollo. La aplicación, además debe tener como fin centralizar la gestión de recursos en un mismo sistema, para que de esta manera sea más inmediato tomar decisiones en cuanto a la planificación del trabajo. Los principales aspectos que debe abordar la aplicación son los siguientes: 1. Gestionar los desarrolladores del departamento 2. Gestionar los proyectos en desarrollo 3. Gestionar las tecnologías que se manejan en el departamento 4. Gestionar los talleres de formación organizados 5. Crear un calendario de eventos Por otra parte, el desarrollo de esta aplicación ha de ir en consonancia con los estándares de usabilidad, para garantizar una buena experiencia en el manejo del interfaz: debe ser eficaz e intuitiva. Como punto de partida para afrontar el desarrollo será necesario: 1. Familiarizarse con las herramientas de trabajo: Angular, Spring y herramientas de integración continua como Gitlab, Sonar o Docker. 2. Establecer un plan de acción. 3. Poner en marcha el ecosistema de tecnologías. 4. Llevar el control de versiones. El proyecto estará versionado con git para trabajar de manera consistente y productiva. Establecer un flujo de trabajo con git facilita el desarrollo de las issues de manera independiente y nos permite revisar el estado del desarrollo en etapas anteriores.. Sandra Ortega Sánchez. Página 15.

(16) [UPM] Máster en Ingeniería Web. INTRODUCCIÓN El presente proyecto pretende conseguir una gestión eficiente de los recursos humanos y tecnológicos presentes en un departamento de desarrollo. Se trata de un número alto de desarrolladores del mismo perfil técnico involucrado en un número de proyectos en los que participan de uno a doce desarrolladores. Los recursos que se desean gestionar son: - Buddies: son los desarrolladores, compañeros del departamento. Aproximadamente son un total de 100. A parte de los datos personales, cada buddy posee una serie de rasgos profesionales que lo hace diferente a los demás y categorizarlas facilita las labores de gestión. Cada buddy tiene asociado unas características técnicas como su formación, plan de carrera y tasa que se cobra por ellos; pero también unas características personales como convenio, antigüedad, vacaciones, etc. - Proyectos. Aproximadamente conviven unos 50 proyectos, sumando los que están en desarrollo más los que están pendientes de asignación. Cada proyecto tiene unas necesidades diferentes como lo son la localización, la tecnología que implementan, los plazos de tiempo, el presupuesto disponible, etc. - Tecnologías son las disponibles que existen en un departamento. Por un lado, habrá desarrolladores expertos en una serie de herramientas y por otro estarán las necesidades de un proyecto. Se tendrá que ver la disponibilidad de los desarrolladores que sepan trabajar con una cierta tecnología para poder implementar los proyectos que la vayan a requerir. - Eventos de formación: pueden ser internos o externos y de duración variada: desde unas horas hasta varios días.. User personas La plataforma que se propone va dirigida a la persona o personas encargadas de la gestión de los recursos del departamento, sin diferenciación por tipo de recurso. El o los usuarios de la aplicación además pertenecen al departamento y tienen un perfil técnico. Es por ello que existirá un único rol en la aplicación. Entre las funciones que realiza destacaría: - Tener control sobre los desarrolladores en plantilla y de empresas externas. - Tener presente todos los proyectos en desarrollo, por desarrollar y la búsqueda de nuevos proyectos. - Promover iniciativas que fomenten la buena evolución profesional, como la búsqueda de eventos relacionados con el desempeño del departamento y la organización de éstos para que asistan aquellos perfiles que mejor encajen en la convocatoria.. Página 16.

(17) Plataforma para la gestión de recursos humanos y tecnológicos. Stack tecnológico Para construir esta plataforma es necesaria una interfaz con la que interactuar, un repositorio de datos y un servicio que manipule los datos del repositorio a través de instrucciones recibidas desde la interfaz.. Spring Spring es una tecnología basada en lenguaje Java que permite crear aplicaciones web con las mínimas configuraciones necesarias. Es un framework ligero de código abierto altamente configurable y basado en la inyección de dependencias. Esta última característica permite el bajo acoplamiento entre los módulos y objectos que lo conforman, lo cual deriva en una arquitectura flexible. Por todas estas razones es la tecnología elegida para implementar el API que dará servicio a la plataforma. Para crear el proyecto Spring se ha generado un proyecto Maven con tecnología basada en Java utilizando la herramienta Spring Initializr:. Figure 1 Generación proyecto Spring. Spring Initializr es una herramienta muy útil para crear proyectos desde cero como es el caso. Las dependencias, así como la información que se indican en estos pasos, pasarán a formar el fichero pom.xml (Project Object Model), que es la guía a seguir para construir el proyecto, y podrá ser ampliado o modificado en función de las necesidades de cada momento.. Sandra Ortega Sánchez. Página 17.

(18) [UPM] Máster en Ingeniería Web A continuación, se definen los metadatos del proyecto que irán definidos en el pom.. Figure 2 Metadata proyecto Spring. Página 18.

(19) Plataforma para la gestión de recursos humanos y tecnológicos Por último, se especifican las dependencias que se desean incluir en el proyecto.. Figure 3 Dependencias proyecto Spring. Spring Data Reactive MongoDB proporciona un modelo de programación que facilita el acceso a la capa de datos y la interacción con los datos del repositorio.. MongoDB La principal característica de MongoDB es que se trata de una base de datos no relacional. La elección de esta base de datos radica en que, además de resolver las necesidades planteadas, tiene una excelente compatibilidad con Spring gracias a Spring Data. A través del fichero application.properties localizado en el directorio src/main/resources del proyecto deben indicarse los detalles de la conexión con la base de datos. Dado que se tienen dos entornos, el de desarrollo y el de producción, se tienen asimismo dos configuraciones para la conexión con base de datos: application-dev.properties y application-prod.properties.. Sandra Ortega Sánchez. Página 19.

(20) [UPM] Máster en Ingeniería Web. Angular La solución a la capa cliente se ha abordado con Angular, un framework open-source basado en lenguaje TypeScript. La potencia de esta tecnología Angular radica en la organización del contenido que proporciona, lo que facilita el desarrollo de las aplicaciones web. Además, apostar por Angular cuenta con la ventaja de tener una gran comunidad de desarrolladores que dan soporte, entre quienes se encuentra Google.. SPRING-BOOT. SPRING-FRAMEWORK. ANGULAR. MONGODB SPRING-SECURITY. SPRING-DATA. Figure 4 Stack tecnológico. Transporte de datos Los datos que viajan en la comunicación cliente – servidor lo hacen en formato JSON, un formato de intercambio de datos ligero, sencillo de implementar por las distintas tecnologías.. Página 20.

(21) Plataforma para la gestión de recursos humanos y tecnológicos. ARQUITECTURA API La aplicación arranca por la clase Application. Esta clase tiene la anotación @SpringBootApplication que engloba a auto configuración de Spring, habilita el escaneo de pacquetes para indicar dónde está localizada la aplicación y permite registrar otros beans en el contexto de la aplicación.. Figure 5 Arquitectura Proyecto Spring. La arquitectura del proyecto se ha organizado de la siguiente forma: ▪ Paquete config. Contiene clases de configuración de la aplicación, transversales a ella. ▪ Paquete exceptions. Contiene las clases encargadas de manejar los errores que puedan ocurrir durante el procesamiento de una petición. ▪ Paquete rest_controllers. Contiene las clases responsables de gestionar las peticiones que llegan al API. ▪ Paquete business_controller. Contiene las clases responsables de llevar a cabo la lógica de negocio. ▪ Paquete services. Contiene clases soporte que dan servicio a otras clases de la aplicación. ▪ Paquete repositories. Contiene las interfaces de los repositorios de la base de datos. ▪ Paquete documents. Contiene las clases de los documentos de cada colección de la base de datos. ▪ Paquete dto. Contiene las clases de los objetos que viajan en las peticiones. En los siguientes capítulos se detallarán las funciones y responsabilidades de cada paquete.. Sandra Ortega Sánchez. Página 21.

(22) [UPM] Máster en Ingeniería Web. ESPECIFICACIÓN DEL API El paquete rest_controllers contiene las clases de los recursos del API, y a su vez estas clases definen las operaciones que el API es capaz de resolver.. Figure 6 Recursos del paquete rest_controllers. Operadores del API A continuación, se presenta un resumen de los operadores de cada recurso del paquete de controladores del API:. Figure 7 Operaciones recurso Buddy. Página 22.

(23) Plataforma para la gestión de recursos humanos y tecnológicos. Figure 8 Operaciones recurso Coaching. Figure 9 Operaciones recurso Technology. Sandra Ortega Sánchez. Página 23.

(24) [UPM] Máster en Ingeniería Web. Figure 10 Operaciones recurso Project. Figure 11 Operaciones recurso Training. Figure 12 Operaciones recurso Buddy Holidays. Página 24.

(25) Plataforma para la gestión de recursos humanos y tecnológicos. Figure 13 Operaciones recurso Public Holidays. Paquetes y responsabilidades Los recursos son clases que se encargan de definir la ruta de la petición, recibir las peticiones que llegan a ese endpoint y hacer el tratamiento oportuno con los datos y operador de la petición. Spring simplifica esta gestión con anotaciones como @RestController que indica que la clase es un controlador de recursos de API, o @RequestBody, @PathVariable que extraen el cuerpo de la petición y la ruta para poder operar con ellos de forma directa. Delegan en los DTO de entrada la validación de los datos recibidos en el cuerpo de la petición con la anotación @Valid, y delegan en los controladores el procesamiento de la petición. Una vez procesado con éxito, vuelve la acción al recurso para completar el proceso y enviar una respuesta al cliente. En este apartado se detallan los flujos de cada recurso por petición acompañado de un diagrama. Seguidamente se mostrarán los DTO de entrada (Input Data Transfer Object) y salida (Output Data Transfer Object) en cada caso.. Buddy Resource Este recurso tiene 5 operadores como se muestra en el diagrama: GET all, GET, POST, PUT y DELETE. El primer operador GET devuelve un listado de todos los buddies del repositorio mapeando cada uno a un objeto de la clase BuddyOutputDto. El segundo operador GET utiliza la anotación @PathVariable para indicar el recurso que se solicita, y si es encontrado se devuelve el objeto de la clase BuddyOutputDto. El operador POST recibe en el cuerpo de la petición el objeto de la clase BuddyInputDto que se desea crear y devuelve en caso de que se cree con éxito el objeto de la clase BuddyOutputDto. El operador PUT recibe el nick del recurso que se desea modificar a través de la anotación @PathVariable y el objeto de la clase BuddyInputDto en el cuerpo de la petición. Si la edición se completa con éxito, el recurso devolverá el nuevo objeto de la clase BuddyOutputDto. El operador DELETE recibe en el parámetro de la petición el nick1 del documento que se desea eliminar y si es encontrado y eliminado no devolverá ningún objeto.. 1. Atributo del modelo Buddy indexado con la anotación @Indexed. Sandra Ortega Sánchez. Página 25.

(26) [UPM] Máster en Ingeniería Web. Figure 14 Controlador del API Buddy. Los modelos utilizados en este recurso son el DTO de entrada BuddyInputDto para los operadores POST y PUT y el DTO de salida BuddyOutputDto para los operadores GET all, GET, POST y PUT.. Figure 15 Dto de entrada BuddyInputDto. Figure 16 Dto de salida BuddyOutputDto. Página 26.

(27) Plataforma para la gestión de recursos humanos y tecnológicos. Coaching Resource De forma análoga a la explicación del recurso anterior, se muestra el diagrama del flujo de peticiones al recurso Coaching Resource. Aquí se presentan 6 operadores del recurso: GET all, GET by mentor, GET by buddy, POST, PUT y DELETE. El primer operador GET devuelve un listado de todos los coaching del repositorio mapeando cada uno a un objeto de la clase CoachingDto. El segundo operador GET ataca al recurso “/coaching/mentor” y utiliza la anotación @PathVariable para indicar el nick del mentor que se solicita, y si es encontrado se devuelve el objeto de la clase CoachingDto. El tercer operador GET utiliza la anotación @PathVariable para indicar el recurso que se solicita, en este caso el nick buscado pertenecería a buddyList, y si es encontrado se devuelve el objeto de la clase CoachingDto. El operador POST recibe en el cuerpo de la petición el objeto de la clase CoachingDto que se desea crear y devuelve en caso de que se cree con éxito el objeto de la clase CoachingDto. El operador PUT recibe el nick del recurso que se desea modificar a través de la anotación @PathVariable y el objeto de la clase CoachingDto en el cuerpo de la petición. Si la edición se completa con éxito, el recurso devolverá el nuevo objeto de la clase CoachingDto. El operador DELETE recibe en el parámetro de la petición el nick del mentor del documento que se desea eliminar y si es encontrado y eliminado no devolverá ningún objeto.. Figure 17 Controlador del API Coaching. Sandra Ortega Sánchez. Página 27.

(28) [UPM] Máster en Ingeniería Web El modelo utilizado en este recurso es el DTO CoachingDto, tanto de entrada para los operadores POST y PUT, como de salida para los operadores GET all, GET by mentor, GET by buddy, POST y PUT.. Figure 18 Dto de entrada y salida CoachingDto. Technology Resource Se muestra el diagrama del flujo de peticiones al recurso Technology Resource, junto a sus 5 operadores: GET all, GET, POST, PUT y DELETE. El primer operador GET devuelve un listado de todos los technologies del repositorio mapeando cada uno a un objeto de la clase TechnologyDto. El segundo operador GET utiliza la anotación @PathVariable para indicar el recurso que se solicita, en este caso el name buscado pertenecería a la lista de tecnologías, y si es encontrado se devuelve el objeto de la clase TechnologyDto. El operador POST recibe en el cuerpo de la petición el objeto de la clase TechnologyDto que se desea crear y devuelve en caso de que se cree con éxito el objeto de la clase TechnologyDto. El operador PUT recibe el name del recurso que se desea modificar a través de la anotación @PathVariable y el objeto de la clase TechnologyDto en el cuerpo de la petición. Si la edición se completa con éxito, el recurso devolverá el nuevo objeto de la clase TechnologyDto. El operador DELETE recibe en el parámetro de la petición el atributo name del objeto Technology que se desea eliminar y si es encontrado y eliminado no devolverá ningún objeto.. Página 28.

(29) Plataforma para la gestión de recursos humanos y tecnológicos. Figure 19 Controlador del API Technology. El modelo utilizado en este recurso es el DTO TechnologyDto, tanto de entrada para los operadores POST y PUT, como de salida para los operadores GET all, GET, POST y PUT.. Figure 20 Dto de entrada y salida TechnologyDto. Project Resource Se muestra el diagrama del flujo de peticiones al recurso Project Resource, junto a sus 5 operadores: GET all, GET, POST, PUT y DELETE. El primer operador GET devuelve un listado de todos los projects del repositorio mapeando cada uno a un objeto de la clase ProjectOutputDto. El segundo operador GET utiliza la anotación @PathVariable para indicar el recurso que se solicita, y si es encontrado se devuelve el objeto de la clase ProjectOutputDto. El operador PUT recibe el name del recurso que se desea modificar a través de la anotación @PathVariable y el objeto de la clase ProjetInputDto en el cuerpo de la petición. Si la edición se completa con éxito, el recurso devolverá el nuevo objeto de la clase ProjectOutputDto. El operador POST recibe en el cuerpo de la petición el objeto de la clase ProjectInputDto que se desea crear y devuelve en caso de que se cree con éxito el objeto de la clase ProjectOutputDto.. Sandra Ortega Sánchez. Página 29.

(30) [UPM] Máster en Ingeniería Web El operador DELETE recibe en el parámetro de la petición el atributo name del objeto Project que se desea eliminar y si es encontrado y eliminado no devolverá ningún objeto.. Figure 21 Controlador del API Project. Los modelos utilizados en este recurso son el DTO de entrada ProjectInputDto para los operadores POST y PUT y el DTO de salida ProjectOutputDto para los operadores GET all, GET, POST y PUT.. Figure 22 Dto de entrada ProjectInputDto. Página 30.

(31) Plataforma para la gestión de recursos humanos y tecnológicos. Figure 23 Dto de salida ProjectOutputDto. Training Resource Se muestra el diagrama del flujo de peticiones al recurso Training Resource, junto a sus 5 operadores: GET all, GET, POST, PUT y DELETE. El primer operador GET devuelve un listado de todos los documentos Training del repositorio mapeando cada uno a un objeto de la clase TrainingDto. El segundo operador GET utiliza la anotación @PathVariable para indicar el recurso que se solicita, en este caso el title buscado pertenecería a una lista de training, y si es encontrado se devuelve el objeto de la clase TrainingDto. El operador POST recibe en el cuerpo de la petición el objeto de la clase TrainingDto que se desea crear y devuelve en caso de que se cree con éxito el objeto de la clase TrainingDto. El operador PUT recibe el atributo title del recurso que se desea modificar a través de la anotación @PathVariable y el objeto de la clase TrainingDto en el cuerpo de la petición. Si la edición se completa con éxito, el recurso devolverá el nuevo objeto de la clase TrainingDto. El operador DELETE recibe en el parámetro de la petición el title del training que se desea eliminar y si es encontrado y eliminado no devolverá ningún objeto.. Sandra Ortega Sánchez. Página 31.

(32) [UPM] Máster en Ingeniería Web. Figure 24 Controlador del API Training. Los modelos utilizados en este recurso es el DTO TrainingDto, tanto de entrada para los operadores POST y PUT, como de salida para los operadores GET all, GET, POST y PUT.. Figure 25 Dto de entrada y salida TrainingDto. Buddy Holidays Resource Este recurso tiene 3 operadores como se muestra en el diagrama: GET, POST y DELETE. El primero utiliza la anotación @PathVariable para indicar el recurso que se solicita, y si es encontrado se devuelve el objeto de la clase BuddyHolidaysOutputDto. El operador POST recibe en el cuerpo de la petición el objeto de la clase BuddyHolidaysInputDto que se desea crear y devuele en caso de que se cree con éxito el objeto creado de la clase BuddyHolidaysOutputDto. El operador DELETE recibe en el parámetro de la petición el id del documento que se desea eliminar y si es encontrado y eliminado no devolverá ningún objeto.. Página 32.

(33) Plataforma para la gestión de recursos humanos y tecnológicos. Figure 26 Controlador del API BuddyHolidays. Los modelos utilizados en este recurso son el DTO de entrada BuddyHolidaysInputDto para el operador POST y el DTO de salida BuddyHolidaysOutputDto para los operadores GET y POST.. Figure 27 Dto de entrada BuddyHolidaysInputDto. Figure 28 Dto de salida BuddyHolidaysOutputDto. Public Holidays Resource Este recurso tiene 3 operadores como se muestra en el diagrama: GET, POST y PUT. El operador GET utiliza la anotación @PathVariable para indicar el recurso que se solicita, y si es encontrado se devuelve el objeto de la clase PublicHolidayDto. El operador POST recibe en el cuerpo de la petición el objeto de la clase PublicHolidayDto que se desea crear y devuelve en caso de que se cree con éxito el objeto creado de la clase PublicHolidayDto.. Sandra Ortega Sánchez. Página 33.

(34) [UPM] Máster en Ingeniería Web El operador PUT recibe el year del recurso que se desea modificar a través de la anotación @PathVariable y el objeto de la clase PublicHolidayDto en el cuerpo de la petición. Si la edición se completa con éxito, el recurso devolverá el nuevo objeto de la clase PublicHolidayDto.. Figure 29 Controlador del API PublicHolidays. El modelo utilizado en este recurso es el DTO PublicHolidaysDto, tanto de entrada para los operadores POST y PUT, como de salida para los operadores GET, POST y PUT.. Figure 30 Dto de entrada y salida PublicHolidaysDto. Página 34.

(35) Plataforma para la gestión de recursos humanos y tecnológicos. LÓGICA DE NEGOCIO El paquete business_controllers es el responsable de llevar a cabo la lógica de negocio. Cada clase es invocada por un recurso para ejecutar un método que realice la operación del API que se desea. A su vez cada controlador se apoya en las clases del paquete repository para acceder a los documentos de la base de datos.. Figure 31 Paquete de controladores business_controllers. Figure 32 Paquete de los repositorios. Sandra Ortega Sánchez. Página 35.

(36) [UPM] Máster en Ingeniería Web A continuación, se introducen los controladores:. Buddy Controller. Figure 33 Controlador Buddy y su relación con BuddyRepository. Coaching Controller. Figure 34 Controlador Coaching y su relación con CoachingRepository. Technology Controller. Figure 35 Controlador Technology y su relación con TechnologyRepository. Página 36.

(37) Plataforma para la gestión de recursos humanos y tecnológicos. Project Controller. Figure 36 Controlador Project y su relación con ProjectRepository. Training Controller. Figure 37 Controlador Training y su relación con TrainingRepository. BuddyHolidays Controller. Figure 38 Controlador BuddyHolidays y su relación con BuddyHolidaysRepository. Sandra Ortega Sánchez. Página 37.

(38) [UPM] Máster en Ingeniería Web. PublicHolidays Controller. Figure 39 Controlador PublicHolidays y su relación con PublicHolidaysRepository. Página 38.

(39) Plataforma para la gestión de recursos humanos y tecnológicos. Paquete document A continuación, se presentan los documentos de la base de datos:. Figure 40 Paquete documents. Sandra Ortega Sánchez. Página 39.

(40) [UPM] Máster en Ingeniería Web. Diagrama de clases. Figure 41 Diagrama de clases. Página 40.

(41) Plataforma para la gestión de recursos humanos y tecnológicos. ARQUITECTURA CLIENTE La aplicación Angular empieza por el fichero main.ts que crea una instancia de AppModule bajo las condiciones del entorno activo: producción o desarrollo. AppModule es módulo principal de la aplicación, importa los componentes y servicios que necesita la aplicación, así como otros módulos, que a su vez importarán sus componentes y servicios. El módulo AppRoutingModule define los paths de la url para la navegación web. A su vez, AppComponent es en componente principal de la aplicación y es el punto de partida del interfaz web. En la aplicación Angular se ha seguido esta arquitectura:. Figure 42 Arquitectura Proyecto Angular. ▪. ▪. El paquete components contiene los componentes de la aplicación, son los encargados de generar la vista en el navegador. Delegan en el paquete services la petición de datos al API que alimentarán la vista. El paquete services contiene los servicios de la aplicación, éstos son los encargados de definir el path de cada petición a la API y crear la petición apoyándose en el servicio HttpClient de Angular. Además, se encarga de mapear los datos que se reciben en las peticiones a los modelos para que puedan ser tratados por la aplicación front.. Figure 43 paquete services. Sandra Ortega Sánchez. Página 41.

(42) [UPM] Máster en Ingeniería Web ▪. El paquete shared contiene ficheros de configuración transversales a la aplicación. Como por ejemplo las rutas de la aplicación web:. Figure 44 Detalle de las rutas de la aplicación Angular. ▪. El paquete models contiene los modelos que se manejan en front de cada entidad, y en algunos casos contienen un modelo Dto para la recepción de los objetos que han de ser preparados antes o después de la conversión a JSON. Para este tratamiento se apoya en las funciones declaradas en utils.ts.. Componentes Los componentes de la aplicación están organizados en los paquetes buddy, Project, technology y training. Estos cuatro paquetes funcionan de manera análoga, sirviéndose de los servicios transversales a la aplicación por igual, con la única excepción de que gestionan entidades diferentes y el posible impacto a entidades secundarias. Estos cuatro paquetes se reducen a tres componentes genéricos: uno que lista todos los elementos del repositorio, un segundo que muestra el detalle de un elemento, y un tercer componente que es un formulario para la creación de un nuevo elemento o modificación de uno existente. Explicaré en detalle el paquete Buddy ya que su tratamiento implica el de otras entidades por su relación con ellas: son Coaching y BuddyHolidays. Por analogía puede entenderse el funcionamiento de los otros tres paquetes. El paquete buddy contiene todos los componentes que gestionan el modelo Buddy. Estos componentes se apoyan en el servicio BuddyService para hacer peticiones al API.. Página 42.

(43) Plataforma para la gestión de recursos humanos y tecnológicos. Figure 45 Detalle del paquete de componentes buddy. Figure 46 Servicio BuddyService. Sandra Ortega Sánchez. Página 43.

(44) [UPM] Máster en Ingeniería Web -. -. BuddyListComponent muestra el listado de buddies que hay en el repositorio. Se apoya en el servicio BuddyService para realizar la petición GET de todos los buddies al API. Desde este componente podrá eliminarse también un buddy. Para ello se invoca una ventana modal, desde el componente ModalComponent en el paquete “components/shared”, para confirmar si se desea eliminar. Para poder eliminar un buddy éste no puede ser mentor con otros buddies a su cargo. De ser así no está permitido su eliminación, será necesario asignar a esos buddies un mentor distinto. DetailBuddyComponent este componente, al cual se accede a través del parámetro nick en la ruta, muestra el detalle de un buddy. Se apoya en el servicio BuddyService para realizar la petición GET por {nick} al API. Este componente incorpora un apartado para mostrar las vacaciones que tenga este buddy, para lo cual se apoya en BuddyHolidaysService. Este servicio devolverá un array de BuddyHolidays que se mostrarán como un listado.. Figure 47 Servicio BuddyHolidays. -. -. -. BuddyHolidaysFormComponent es el formulario para la creación de vacaciones de un Buddy. Este formulario solo estará disponible desde el detalle de un Buddy, es decir, desde el componente DetailBuddyComponent. Cuando se modifican las vaciaciones, se crean aquellas BuddyHolidays que no existan y se borrarán las que hayan desaparecido. GenericBuddyComponent es el formulario para la creación de un nuevo Buddy o modificación de uno existente. El formulario se construye a partir de los componentes del paquete shared-forms, y delega en ellos la validación de los campos del formulario. Solo cuando todos han sido validados, se permite el procesamiento de los datos del formulario, que acabarán por ser tratados por el servicio BuddyService, bien para una operación POST, bien una de tipo PUT. Para facilitar el mapeo de todos los campos del formulario, se utiliza el método mapFormToBuddyDto que crea un objeto de tipo BuddyDto a partir de un objeto de tipo FormGroup. BuddyFormComponent es el formulario que tiene los campos del modelo Buddy.. Página 44.

(45) Plataforma para la gestión de recursos humanos y tecnológicos -. CoachingFormComponent es el formulario para la asignación del responsable funcional, mentor, de un buddy. Este formulario está integrado en el GenericBuddyComponent al igual que BuddyFormComponent ya que se trata de un atributo del modelo Buddy.. Figure 48 Servicio CoachingService. Sandra Ortega Sánchez. Página 45.

(46) [UPM] Máster en Ingeniería Web. Transporte de datos Dadas las incompatibilidades en los objetos Map2 entre servidor y cliente es necesario tener un modelo Buddy que se maneje en la aplicación y un segundo que sea el que viaje en formato JSON BuddyDto. De igual modo, es necesario preparar los objetos Date para facilitar el manejo en la aplicación, por ello se han definido dos modelos para el manejo de vacaciones de buddy, BuddyHolidays BuddyHolidays y BuddyHolidaysDto para el transporte en JSON.. Figure 49 Modelos relacionados con el paquete Buddy. 2. Ver Anexo I. Página 46.

(47) Plataforma para la gestión de recursos humanos y tecnológicos. INTERFAZ GRÁFICA Buddies Listado de Buddies. Figure 50 Listado de Buddies. Sandra Ortega Sánchez. Página 47.

(48) [UPM] Máster en Ingeniería Web. Detalle de Buddy. Figure 51 Detalle de Buddy. Página 48.

(49) Plataforma para la gestión de recursos humanos y tecnológicos. Figure 52 Detalle de Buddy con asignación de BuddyHolidays. Sandra Ortega Sánchez. Página 49.

(50) [UPM] Máster en Ingeniería Web. Figure 53 Detalle de Buddy con listado de BuddyHolidays. Página 50.

(51) Plataforma para la gestión de recursos humanos y tecnológicos. Creación de Buddy. Figure 54 Creación de Buddy con detalle de validación. Sandra Ortega Sánchez. Página 51.

(52) [UPM] Máster en Ingeniería Web. Figure 55 Creación de Buddy. Página 52.

(53) Plataforma para la gestión de recursos humanos y tecnológicos. Edición de Buddy. Sandra Ortega Sánchez. Página 53.

(54) [UPM] Máster en Ingeniería Web. Eliminación de Buddy. Figure 56 Eliminación de mentor con buddies asignados. Página 54.

(55) Plataforma para la gestión de recursos humanos y tecnológicos. Figure 57 Eliminación de mentor sin buddies asignados. Sandra Ortega Sánchez. Página 55.

(56) [UPM] Máster en Ingeniería Web. Projects Listado de Projects. Figure 58 Listado de Projects. Página 56.

(57) Plataforma para la gestión de recursos humanos y tecnológicos. Detalle de Project. Figure 59 Detalle de Project. Sandra Ortega Sánchez. Página 57.

(58) [UPM] Máster en Ingeniería Web. Creación de Project. Figure 60 Creación de Project con detalle de validación. Página 58.

(59) Plataforma para la gestión de recursos humanos y tecnológicos. Figure 61 Creación de project. Sandra Ortega Sánchez. Página 59.

(60) [UPM] Máster en Ingeniería Web. Edición de Project. Figure 62 Edición de Project. Página 60.

(61) Plataforma para la gestión de recursos humanos y tecnológicos. Eliminación de Project. Figure 63 Eliminación de Project. Sandra Ortega Sánchez. Página 61.

(62) [UPM] Máster en Ingeniería Web. Technologies Listado de Technologies. Figure 64 Listado de technologies. Página 62.

(63) Plataforma para la gestión de recursos humanos y tecnológicos. Detalle de Technology. Figure 65 Detalle Technology. Sandra Ortega Sánchez. Página 63.

(64) [UPM] Máster en Ingeniería Web. Creación de Technology. Figure 66 Creación de Technology. Página 64.

(65) Plataforma para la gestión de recursos humanos y tecnológicos. Edición de Technology. Figure 67 Edición de Technology. Sandra Ortega Sánchez. Página 65.

(66) [UPM] Máster en Ingeniería Web. Eliminación de Technology. Figure 68 Eliminar Technology. Página 66.

(67) Plataforma para la gestión de recursos humanos y tecnológicos. Training Listado de Training. Figure 69 Listado Training. Sandra Ortega Sánchez. Página 67.

(68) [UPM] Máster en Ingeniería Web. Detalle de Training. Figure 70 Detalle de Training. Página 68.

(69) Plataforma para la gestión de recursos humanos y tecnológicos. Creación de Training. Figure 71 Creación de Training I. Sandra Ortega Sánchez. Página 69.

(70) [UPM] Máster en Ingeniería Web. Figure 72 Creación de Training II. Página 70.

(71) Plataforma para la gestión de recursos humanos y tecnológicos. Edición de Training. Figure 73 Edición Training. Sandra Ortega Sánchez. Página 71.

(72) [UPM] Máster en Ingeniería Web. Eliminación de Training. Figure 74 Eliminar Training. Página 72.

(73) Plataforma para la gestión de recursos humanos y tecnológicos. Calendar Añadir PublicHolidays. Figure 75 Añadir PublicHolidays. Sandra Ortega Sánchez. Página 73.

(74) [UPM] Máster en Ingeniería Web. METODOLOGÍA Descripción Abordar una plataforma con las características de la presente lleva consigo factores implícitos que ponen en riesgo el producto final. Dada la novedad que supone implantar esta plataforma en el departamento, se ha apostado por una metodología ágil que garantice un producto mínimo viable y que pueda ser ampliado con funcionalidades que mejoren la calidad. Para empezar, se mantienen conversaciones con el cliente a cerca de las necesidades existentes, de donde poder deducir los requisitos que se deben cubrir y asimismo establecer entre ellos las prioridades.. Definición de las funcionalidades Una plataforma de gestión para el departamento debe manejar el personal del departamento, los buddies, manejar también los proyectos que se gestionan desde el departamento, las tecnologías, y los cursos de formación que se organizan. Por último, se desea tener un calendario que recoja las vacaciones, tanto de los buddies como las del calendario laboral, que permita organizar mejor el trabajo. Entrando en el detalle de las funcionalidades definidas antes se deducen las historias de usuario a continuación: User Stories 1. Creación de la plataforma única 2. Registro de buddies 3. Validación de buddy 4. Asignar plan de carrera a buddy 5. Asignar responsible funcional 6. Registro de tecnologías 7. Asignar tecnologías a buddy 8. Registro de proyectos 9. Asignación de buddies a proyectos 10. Asignación tecnologías a proyecto 11. Información de negocio a proyectos 12. Asignación fechas a proyectos 13. Asignar prioridad 14. Registro de talleres de formación 15. Asignación de vacaciones a buddy 16. Asignación de buddies a training 17. Vacaciones públicas. Start Date Due Date Days Sprint pts 06-May 18-May 12 1 13 13-May 20-May 7 1 26 19-May 20-May 1 1 5 20-May 22-May 2 2 8 23-May 30-May 7 2 13 01-Jun 03-Jun 2 2 16 04-Jun 08-Jun 4 3 13 11-Jun 13-Jun 2 3 16 13-Jun 15-Jun 2 3 5 15-Jun 16-Jun 1 3 5 16-Jun 17-Jun 1 3 5 16-Jun 19-Jun 3 3 13 19-Jun 20-Jun 1 4 5 20-Jun 21-Jun 1 4 10 21-Jun 22-Jun 1 4 13 22-Jun 23-Jun 1 4 5 23-Jun 24-Jun 1 4 8. Figure 76 Tabla estimación US. Página 74.

(75) Plataforma para la gestión de recursos humanos y tecnológicos. Diagrama de Gant. Figure 77 Diagrama Gantt de US. User Stories Sprint 1 US 1 | Creación de la plataforma única Como gestor de recursos del departamento quiero gestionar desde un mismo sistema los recursos del departamento para centralizar su mantenimiento y actualización Para dar solución a este requerimiento se estudia y analiza las tecnologías con que puede llevarse a cabo, y se crean los proyectos de Spring y Angular tal y como se definió en la introducción. Estimación: 13pt US 2 | Registro de buddies Como gestor de recursos del departamento quiero quiero tener un registro de los buddies del departamento donde poder además modificar sus datos o eliminarlos del registro. Cada buddy tiene información básica (nombre, apellidos y correo) e información técnica (plan de carrera, tasa, responsable funcional y empresa para el caso de los empleados externos del departamento). Este registro será accesible desde el menú principal de la aplicación para consultar sus perfiles técnicos y tenerlos siempre actualizados. Para abordar esta historia de usuario se dividió en las siguientes tareas: 1. Definir el modelo Buddy 2. Crear listado de Buddies en front 3. Crear el API para leer Buddies Sandra Ortega Sánchez. Página 75.

(76) [UPM] Máster en Ingeniería Web 4. Crear página de detalle de un Buddy 5. Crear API para leer un Buddy específico 6. Crear formulario para crear un Buddy 7. Crear API para registrar un Buddy 8. Adaptar el formulario para modificar un Buddy existente 9. Crear API para editar un Buddy existente 10. Añadir acción bajo confirmación para eliminar un Buddy desde front 11. Crear API para eliminar un Buddy Estimación Front: 13pt Estimación API: 13pt US 3 | Validación de buddy Como gestor de recursos del departamento quiero quiero evitar dar de alta buddies que no hayan completado la información básica y técnica. para garantizar que la información necesaria está completada Esta validación se lleva a cabo desde front añadiendo la validación required a los campos del formulario, tanto para la creación como modificación de un Buddy. Esta validación se reafirma al llegar al servidor con anotaciones @NotNull en los atributos del Dto. Estimación: 5pt. Figure 78 Diagrama Gantt Sprint 1. Página 76.

(77) Plataforma para la gestión de recursos humanos y tecnológicos. User Stories Sprint 2 US 4 | Asignar plan de carrera a buddy Como gestor de recursos del departamento quiero poder asignar a cada buddy su plan de carrera dentro de la empresa. Esto es: - Carrera BTC (Business Technology Consulting). Tiene las siguientes categorías: o Analyst. Con 4 grados de madurez o Consultant. Con 6 grados de madurez o Senior Consultant. Con 2 grados de madurez o Project Manager. Con 2 grados de madurez o Senior Manager. Con 2 grados de madurez - Carrera BTO (Business Technology Operations). Tiene las siguientes categorías: o Analyst. Con 2 grados de madurez o Consultant. Con 3 grados de madurez o Senior Consultant. Con 1 grado de madurez o Project Manager. Con 1 grado de madurez o Senior Manager. Con 1 grado de madurez - Carrera Specialist. Tiene las siguientes categorías: o Specialist. Con 4 grados de madurez o Project Manager. Con 2 grados de madurez o Senior Manager. Con 2 grados de madurez para hacer seguimiento de su evolución. Esta funcionalidad se ha abordado desde front, ya que resulta más sencillo para el usuario que completa un formulario que sólo se muestren aquellas opciones que son válidas. La implementación se ha llevado a cabo las siguientes tareas: 1. Definición modelo CareerPlan 2. Creación de un método que calcule las posibles categorías dada una carrera 3. Creación de un método que calcule los posibles grados de madurez dada una categoría y su correspondiente carrera 4. Validaciones en el formulario de creación de Buddy que conduzcan a una selección ordenada: Carrera – categoría – grado de madurez Estimación: 8pt US 5 | Asignar responsable funcional a buddy Como gestor de recursos del departamento quiero para. poder asignar a cada buddy su responsable funcional, que será otro buddy del departamento consultar esta información en la plataforma. Sandra Ortega Sánchez. Página 77.

(78) [UPM] Máster en Ingeniería Web Para resolver este requisito se ha optado por la creación de una nueva entidad, Coaching, que se encargue de mantener la relación entre un mentor, el responsable funcional, y el listado de Buddies de quien es responsable. Para ello se siguen las tareas: 1. Definir modelo Coaching 2. Añadir formulario de coaching en la creación o modificación de un Buddy. Todo buddy tendrá un responsable funcional. Si un buddy es a su vez su propio responsable funcional, se creará un nuevo Coaching de la que será mentor. Si un buddy tiene un responsable funcional distinto a sí mismo se añadirá a la lista de buddies del Coaching del mentor seleccionado. 3. Crear API para crear Coaching 4. Crear API para modificar Coaching 5. Crear APIs para leer todos los Coaching, y el asociado a un buddy 6. Añadir validación para impedir la eliminación de un buddy si es mentor y tiene buddies a su cargo. Estimación: 13pt US 6 | Registro de tecnologías Como gestor de recursos del departamento quiero. para. quiero tener un registro de las tecnologías que se utilizan desde el departamento y poder además modificar el nombre en caso de que se lancen nuevas versiones. Este registro será accesible desde el menú principal de la aplicación facilitar la identificación en toda la aplicación de las tecnologías que manejamos. Esta historia de usuario consiste en un nuevo registro, pero de una entidad diferente, Technology, por ello se siguen las mismas pautas que se hizo en la US 2: 1. Definir el modelo Technology 2. Crear listado de Technologies en front 3. Crear el API para leer Technologies 4. Crear página de detalle de una Technology 5. Crear API para leer una Technology específica 6. Crear formulario para crear una Technology 7. Crear API para registrar una Technology 8. Adaptar el formulario para modificar una Technology existente 9. Crear API para editar una Technology existente 10. Añadir acción bajo confirmación para eliminar una Technology desde front 11. Crear API para eliminar una Technology Estimación Front: 8pt Estimación API: 8pt. Página 78.

(79) Plataforma para la gestión de recursos humanos y tecnológicos. Figure 79 Diagrama Gantt Sprint 2. User Stories Sprint 3 US 7 | Asignar listado de tecnologías a buddy Como gestor de recursos del departamento quiero añadir a la información de cada buddy las tecnologías que conoce y en qué porcentaje las domina para poder asignar a los proyectos que se desarrollen en dichas tecnologías Tareas que realizar: 1. Modificar modelo buddy para añadir el atributo technologyMap. Éste será un objeto Map<String, Integer> que llevará como clave el nombre de la tecnología en cuestión y su valor será el grado de conocimiento que el Buddy tiene en la tecnología. Por ejemplo, Java: 50. 2. Modificar los Dto de entrada y salida para que los objetos Map puedan viajar y ser tratados a su recepción, ya que los lenguajes Java y Typescript hacen tratamientos diferentes de estos objetos. 3 3. Modificar formulario para poder introducir esta información 4. Modificar el API para tratar el nuevo atributo 5. Modificar el detalle de Buddy para mostrar el nuevo campo Estimación: 13pt. 3. Detallado en el Anexo I. Sandra Ortega Sánchez. Página 79.

(80) [UPM] Máster en Ingeniería Web. US 8 | Registro de proyectos Como gestor de recursos del departamento quiero tener un registro de los proyectos que se están desarrollando desde el departamento, así como aquellos que lo harán en un futuro. En la información del proyecto aparecerá el nombre, que será único, responsable técnico del departamento y un resumen. Este registro será accesible desde el menú principal de la aplicación para poder acceder de fácilmente a esta información Siguiendo las pautas para crear nuevos registros: 1. Definir el modelo Project 2. Crear listado de Projects en front 3. Crear el API para leer Projects 4. Crear página de detalle de un project 5. Crear API para leer un Project específico 6. Crear formulario para crear un Project 7. Crear API para registrar un Project 8. Adaptar el formulario para modificar un Project existente 9. Crear API para editar un Project existente 10. Añadir acción bajo confirmación para eliminar un Project desde front 11. Crear API para eliminar un Project Estimación Front: 8pt Estimación API: 8pt US 9 | Asignación de buddies a proyectos Como gestor de recursos del departamento quiero para. poder relacionar cada proyecto con los buddies que trabajan en él y poder reflejar el porcentaje de carga al que están asignados por proyecto facilitar las asignaciones de buddies a proyectos. Este caso es similar al de la US 7. La solución adoptada es crear un objeto Map<String, Integer> que refleje la relación entre un Buddy, representado por su atributo nick y el porcentaje de asignación. Por ejemplo, sortegas: 100. 1. Modificar modelo Project para añadir el atributo buddyMap 2. Modificar los Dto de entrada y salida para poder ser tratados a su recepción 3. Modificar formulario para poder introducir esta información 4. Modificar el API para tratar el nuevo atributo 5. Modificar el detalle de Project para mostrar el nuevo campo Estimación: 5pt. Página 80.

(81) Plataforma para la gestión de recursos humanos y tecnológicos US 10 | Asignación de tecnologías a proyectos Como gestor de recursos del departamento quiero para. añadir a la información de cada proyecto una lista de tecnologías de front que se manejarán poder asignar los buddies que las dominen. Tareas que realizar: 1. Modificar modelo Project para añadir el atributo technologyList así como los Dto 2. Modificar los API para tratar el nuevo atributo 3. Modificar el formulario para poder introducir un listado de tecnologías 4. Modificar el detalle de Project para mostrar el nuevo campo Estimación: 5pt US 11 | Asignar información de negocio a proyectos Como gestor de recursos del departamento quiero poder añadir a cada proyecto información de negocio: cuál es el mercado, quién es el cliente, el presupuesto y el margen con el que cuenta para para poder consultarla en cualquier momento desde la plataforma Tareas que realizar: 1. Modificar modelo Project para añadir los nuevos atributos, así como los Dto 2. Modificar los API para tratar los nuevos atributos 3. Modificar el formulario para poder introducir los nuevos atributos 4. Modificar el detalle de Project para mostrar los nuevos campos Estimación: 5pt US 12 | Asignar fechas a proyectos Como gestor de recursos del departamento quiero Para. añadir las fechas en que se ha solicitado el proyecto, así como las fechas de inicio y fin previstas tener presente los tiempos con que se cuentan. Para una mejor gestión de las fechas, se crea la entidad DateRange, que agilizará el cálculo del tiempo entre la fecha inicio y fecha fin, y las validaciones pertinentes. 1. Definir el modelo DateRange 2. Modificar modelo Project para añadir los nuevos atributos dateRange y requestDate, así como los Dto 3. Modificar los API para tratar los nuevos atributos 4. Modificar el formulario para poder introducir los nuevos atributos 5. Modificar el detalle de Project para mostrar los nuevos campos. Sandra Ortega Sánchez. Página 81.

(82) [UPM] Máster en Ingeniería Web Estimación: 13pt. Figure 80 Diagrama Gantt Sprint 3. User Stories Sprint 4 US 13 | Asignar prioridad a proyectos Como gestor de recursos del departamento quiero añadir la prioridad del proyecto: alta, media o baja para para poder conocer este dato de manera rápida 1. Crear el enumerado Priority 2. Modificar modelo Project para añadir el nuevo atributo, así como en los Dto 3. Modificar los API para tratar el nuevo atributo 4. Modificar el formulario para poder introducir el nuevo atributo 5. Modificar el detalle de Project para mostrar la prioridad del proyecto Estimación: 5pt. Página 82.

Figure

Actualización...

Referencias

Actualización...