Desarrollo de una herramienta para la gestión de proyectos utilizando la metodología RUP

Texto completo

(1)Desarrollo de una Herramienta para la gestión de proyectos utilizando la metodologı́a RUP. Álvaro J. Aragoneses Martı́n Trabajo Fin de Máster Tutor: Luis Fernández Muñoz Máster Universitario en Ingenierı́a Web - UPM Junio 2015.

(2) A mis padres, Pedro y Ma Ángeles A Jennifer A Salva y Eli Y a todos los que siempre están ahı́.. I.

(3) Si la única herramienta que tiene es un martillo, pensará que cada problema que surge es un clavo. Frase atribuida a Mark Twain.. En el momento en que entiendo verdaderamente a mi enemigo, en el momento en que le entiendo lo suficientemente bien como para derrotarle, entonces, en ese preciso instante, también le quiero. “El juego de Ender”, de Orson Scott Card.. II.

(4) Resumen El presente documento expone el trabajo realizado para documentar el desarrollo de una aplicación sencilla de gestión de proyectos utilizando la metodologı́a RUP, centrándose en el desarrollo previo de los casos de uso, el diseño de la arquitectura y las decisiones tecnológicas tomadas.. A lo largo del primer capı́tulo, se expondrán brevemente los motivos por los que se escogió este proyecto, además de los objetivos propuestos a cumplir y el alcance al que se prevé llegar.. Durante el segundo capı́tulo, se exponen todos los casos de uso analizados, tanto la primera aproximación, basada en la hoja de cálculo original sobre la que se implementó la herramienta, como la aproximación final, centrada más en la interacción con el usuario; además, se exponen los actores, los objetos del sistema y el prototipo de la interfaz de usuario.. A lo largo del tercer capı́tulo, se describirá la arquitectura elegida y las decisiones que llevaron a tomar esa decisión; tras esto, se describirá un primer diseño tanto de la interacción entre las clases como el primer diseño de la interfaz, además de incluir el plan de pruebas elegido para comprobar la aplicación.. A lo largo del cuarto capı́tulo se detallarán los pormenores de la implementación, como el soporte tecnológico que se va a utilizar en cada uno de los elementos, tanto el cliente como el servidor, detallando en el lado del cliente los plugins utilizados, ası́ como los métodos que se utilizarán para implementar las distintas baterı́as de pruebas. AnalisisCasos Por último, en el quinto capı́tulo se expondrán las conclusiones obtenidas del desarrollo del presente documento, además de indicar unas futuras lı́neas de trabajo para modificar y ampliar en el futuro ésta plataforma.. III.

(5) Abstract This docoment shows the work made to document the development of a simple application using the Rational Unified Process methodology, focus on the previous development of the use cases, the architecture desing and the choices made. On the first chapter, the goals and motivations of the present work are shown. Throug the second chapter, the use cases are shown, using the original excel file as reference and expand the use cases and refactor them. On the thrid chapter, the explanation of the architectural choices are shown, and after that, the design of the interface and the test plan are described. On the fourth chapter, the details of implementation are showing, focus on the chosen technologies, frameworks and plugins used toi build the application. Finally, the fifth chapcher shows the conclusions of the work done and future lines of development.. IV.

(6) Índice 1 Introducción 1.1 Motivación y Objetivos . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Casos de uso y análisis 2.1 Aproximación al problema y Actores . . 2.2 Casos de uso . . . . . . . . . . . . . . . 2.2.1 Primera aproximación a los casos 2.2.2 Casos de Uso definitivos . . . . . 2.3 Priorización de los casos de uso . . . . . 2.4 Prototipo de la interfaz de usuario . . .. . . . . . . . . de uso . . . . . . . . . . . .. 1 2 2 3. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 4 4 6 6 14 21 23. 3 Arquitectura, Análisis, Diseño y Tecnologı́as 3.1 Arquitectura . . . . . . . . . . . . . . . . . . 3.2 Análisis de la arquitectura . . . . . . . . . . . 3.3 Plan de pruebas . . . . . . . . . . . . . . . . . 3.4 Diseño . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Análisis de las clases . . . . . . . . . . 3.4.2 Análisis de la arquitectura . . . . . . . 3.4.3 Diseño de la arquitectura . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 27 27 28 33 35 35 42 45. 4 Implementación 4.1 Soporte tecnológico . . . . . . 4.2 Cliente . . . . . . . . . . . . . 4.2.1 Plugins usados . . . . 4.3 Servidor . . . . . . . . . . . . 4.3.1 Modelo de persistencia 4.4 Pruebas . . . . . . . . . . . . 4.4.1 Pruebas del Cliente . . 4.4.2 Pruebas del Servidor .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 46 46 46 48 51 51 52 52 52. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 5 Conclusiones y lı́neas futuras de trabajo 53 5.1 Futuras lı́neas de trabajo . . . . . . . . . . . . . . . . . . . . . . 53. Índice de figuras 1 2 3 4 5 6. Diagrama de los objetos del sistema y su relación . . Primera aproximación de los Casos de Uso y Actores Especificación del caso de uso “Editar Fechas” . . . Especificación del caso de uso “Editar Calendario” . Especificación del caso de uso “Editar Horario” . . . Especificación del caso de uso “Editar Equipo” . . .. V. . . del . . . . . . . .. . . . . . sistema . . . . . . . . . . . . . . . . . . . .. 5 6 8 9 10 11.

(7) 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50. Especificación del caso de uso “Revisar Fases y Disciplinas” . . . Especificación del caso de uso “Revisar Plan de Fases” . . . . . . Contexto de los casos de uso . . . . . . . . . . . . . . . . . . . . . Casos de Uso y Actores del sistema . . . . . . . . . . . . . . . . . Especificación del caso de uso “Editar Fechas” . . . . . . . . . . Especificación del caso de uso “Editar Horario Empresa” . . . . . Especificación del caso de uso “Editar Recursos” . . . . . . . . . Especificación del caso de uso “Editar Equipo” . . . . . . . . . . Especificación del caso de uso “Asignar Roles Definitivos” . . . . Contexto de los casos de uso . . . . . . . . . . . . . . . . . . . . . Priorización de los casos de uso . . . . . . . . . . . . . . . . . . . Prototipo de la interfaz de usuario “Editar Fechas” . . . . . . . . Prototipo de la interfaz de usuario “EditarEquipo” . . . . . . . . Prototipo de la interfaz de usuario “EditarHorario” . . . . . . . . Prototipo de la interfaz de usuario “ListaEmpleados” . . . . . . . Prototipo de la interfaz de usuario “Persona” . . . . . . . . . . . Diagrama de trazabilidad entre las vistas y los casos de uso . . . Diagrama con la arquitectura del proyecto . . . . . . . . . . . . . Diagrama de clases del caso de uso “Editar Fechas” . . . . . . . . Diagrama de clases del caso de uso “Editar Horario Empresa” . . Diagrama de clases del caso de uso “Editar Recursos” . . . . . . Diagrama de clases del caso de uso “Editar Equipo” . . . . . . . Diagrama de clases del caso de uso “Asignar Roles Definitivos” . Diagrama de colaboración del caso de uso “Editar Fechas” . . . . Diagrama de colaboración del caso de uso “Editar Horario Empresa” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de colaboración del caso de uso “Editar Recursos” . . Diagrama de colaboración del caso de uso “Editar Equipo” . . . Diagrama de colaboración del caso de uso “Asignar Roles Definitivos” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Esquema del plan de pruebas . . . . . . . . . . . . . . . . . . . . Diagrama de la clase “EditarFechasController” . . . . . . . . . . Diagrama de la clase “EditarHorarioEmpresaController” . . . . . Diagrama de la clase “EditarRecursosController” . . . . . . . . . Diagrama de la clase “EditarEquipoController” . . . . . . . . . . Diagrama de la clase “AsignarRolesDefinitivosController” . . . . Diagrama de la clase “CalendarioEntity” . . . . . . . . . . . . . . Diagrama de la clase “EquipoEntity” . . . . . . . . . . . . . . . . Diagrama de la clase “PersonaEntity” . . . . . . . . . . . . . . . Diagrama de la clase “CalendarioView” . . . . . . . . . . . . . . Diagrama de la clase “EquipoView” . . . . . . . . . . . . . . . . Diagrama de la clase “HorarioView” . . . . . . . . . . . . . . . . Diagrama de la clase “ListaEmpleadosView” . . . . . . . . . . . Diagrama de la clase “PersonaView” . . . . . . . . . . . . . . . . Análisis del paquete “Controllers” . . . . . . . . . . . . . . . . . Análisis del paquete “Models” . . . . . . . . . . . . . . . . . . . . VI. 12 13 13 14 15 16 17 18 19 21 22 23 24 24 25 25 26 27 28 29 29 29 30 31 31 32 32 32 34 35 36 36 37 37 38 38 39 39 40 40 41 41 42 43.

(8) 51 52 53 54. Análisis del paquete “Views” . . . . Diagrama que muestra la división de tintas partes de la arquitectura . . . Página del plugin JQueryUI . . . . . Página del plugin colResaizable . . .. VII. . . los . . . . . .. . . . . . . . . . paquetes entre . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . las . . . . . .. . . . dis. . . . . . . . .. 44 45 49 50.

(9) 1. Introducción. A lo largo de la asignatura “Metodologı́as Pesadas para el Desarrollo Web”, en la que se nos presentó la metodologı́a RUP (Rationa Unified Process, Proceso unificado de Rational), se hizo especial hincapié en que las metodologı́as son una parte fundamental del desarrollo de proyectos, más allá de las destrezas y conocimientos técnicos de cada uno de los integrantes de los equipos. Una buena organización es fundamental, sobre todo a la hora de abordar proyectos de un tamaño medio o grande. En mi breve experiencia laboral he adolecido del problema de falta de organización, si bien he tratado de buscar metodologı́as de trabajo que me ayudaran a resultar más eficiente, mi falta de base teórica siempre ha resultado patente, ofreciéndome dichas metodologı́as un paupérrimo resultado. Por esto, cuando cursé la citada asignatura, pude ver que RUP, si bien no es una metodologı́a perfecta, ya que ninguna lo es, se puede adaptar bastante a mi manera de organizar el trabajo. Cabe destacar que a lo largo del máster hemos visto más metodologı́as, destacando las denominadas “Metodologı́as ligeras”, pero dado que ya he tenido una cierta experiencia laboral con dichas metodologı́as, deseaba investigar acerca de cómo funciona, a efectos prácticos, la metodologı́a de trabajo RUP; ver los aspectos teóricos de una metodologı́a y aplicarla son dos aspectos muy distintos y normalmente, bastante divergentes. El primer punto que pude apreciar es que RUP no es válido para cualquier tipo de proyecto, y es una mentalidad que hay que establecer desde el primer momento. Si bien es una metodologı́a que admite una determinada cantidad de variaciones en los casos de uso, no resulta tan flexible como otras metodologı́as de las llamadas ágiles, como la combinación de Scrumm y Test-driven Development (Desarrollo guiado por test, en castellano); por contra, RUP ofrece una serie de mecanismos que simplifican enormemente la comunicación entre distintos miembros del equipo gracias a la utilización de diagramas UML como su herramienta principal de expresión. El segundo punto que diferencia a RUP de otras metodologı́as es su escalabilidad; la literatura existente en torno a, por ejemplo, la metodologı́a Scrumm especifica que el número ideal de miembros de un equipo oscila entre los 5 y 9, y si en algún momento ese número es superado, es recomendable crear una división en los distintos grupos. RUP, por contra, admite cualquier número de integrantes en los distintos equipos, siempre que éste número esté adecuado a las necesidades del proyecto. A tenor de éste punto, podemos destacar también como punto divergente entre RUP y otras metodologı́as es la composición de los equipos, siendo en metodologı́as ágiles equipos multidisciplinares, en contra de los equipos de RUP en los que es bastante menos frecuente asignar varios roles a una misma persona. Si bien éste punto puede parecer desfavorable para RUP, dado que le resta flexibi1.

(10) lidad a la hora de afrontar determinados problemas, es necesario recordar que los perfiles multidisciplinares son, normalmente, más costosos y poco frecuentes. Con todo lo expuesto, y dado mi previo bagaje en el uso de metodologı́as ágiles, mi intención fue claramente la de emprender un proyecto relacionado con ésta metodologı́a, a fin de llegar a comprender todos sus entresijos y obtener del presente proyecto una visión más profunda y, sobre todo, práctica de la materia.. 1.1. Motivación y Objetivos. Una vez elegida la metodologı́a, restaba encontrar un proyecto de una dimensión abarcable por una única persona que se pudiera plantear desde el punto de vista deseado; La solución, una vez más, surgió de la asignatura “Metodologı́as Pesadas de Desarrollo Web”. Hacia el final de la asignatura se nos presentó una herramienta relacionada con la parte de gestión del proyecto, es decir, la asignación de tareas, cálculo de fechas de las distintas fases, iteraciones e inicio o final del proyecto o, incluso, el cálculo de los costes del proyecto. Sin embargo, dicha herramienta estaba construida utilizando una hoja de cálculo del programa Excel, el cual, si bien aporta una potencia y versatilidad descomunales, es dicha versatilidad la que en este caso jugaba en contra de los propósitos de la herramienta, ya que debido al sistema subyacente, algunas de las tareas resultaban más incómodas de realizar de lo deseable. Es por ello que, una vez observé la problemática de dicha herramienta, concerté una cita con mi tutor para exponerle mis intenciones: desarrollar una herramienta que paliara las deficiencias de la actual y utilizar, para su desarrollo, la metodologı́a RUP. Siguiendo los consejos de mi tutor, acordamos que uno de los detalles a tener en cuenta serı́a la usabilidad de la herramienta, utilizando herramientas visuales tales como el “Drag&Drop” (Arrastrar y soltar) para la asignación de tareas, o los Sliders (barras deslizadoras) múltiples para determinar el inicio y fin de las distintas fases, en lugar de la utilización de calendarios o formularios. Adicionalmente a éstos cambios visuales y de usabilidad, la herramienta requerı́a de un nuevo enfoque, por lo que debı́a ser previamente analizada con detenimiento, entendiendo el proceso subyacente y extrayendo de él las partes comunes que, ahora sin la limitación propia de las hojas de cálculo comerciales, podrı́an optimizarse. A la vista de todo esto, se fijaron los siguientes objetivos: 1.1.1. Objetivos. • Mostrar todos los pasos dados, aun siendo redundantes en algún caso, para mostrar el progreso a través de los avances dados, sobre todo en materia de diagramas de casos de uso, análisis y planes de prueba.. 2.

(11) • Centrar el contenido del presente trabajo en el desarrollo de todos los pasos previos a la implementación de la propia herramienta más que en la implementación en sı́ misma, que tendrá un papel secundario ya que interesa más el proceso de aprendizaje de la propia metodologı́a. • Detallar todas las tareas utilizando diagramas UML, que mostrarán los casos de uso, arquitectura, interrelación de objetos o clases, etc. • Especificar la arquitectura y las interfaces a implementar, de manera que, a la hora de realizar la propia implementación, se tengan absolutamente claros tanto el soporte tecnológico como las tareas a realizar, evitando utilizar el tiempo de implementación en tareas de diseño.. 1.2. Alcance. Dado el volumen del proyecto y el planteamiento más inherentemente teórico que de desarrollo, se hace patente señalar que el alcance deseable del presente trabajo será el establecimiento de todos los puntos necesarios para la realización de la aplicación, es decir, la creación y análisis de todos los casos de uso, el establecimiento de una arquitectura acorde a dichos casos de uso y el diseño de las interfaces y la especificación de un plan de pruebas para, efectivamente, probar el cumplimiento exacto de los antes citados casos de uso, dejando de lado todo aspecto de implementación hasta los últimos estadios del desarrollo de este proyecto.. 3.

(12) 2. Casos de uso y análisis. 2.1. Aproximación al problema y Actores. Como primer paso, se estudió la hoja de calculo facilitada por el profesor para tener un punto de partida, acompañado de toda la bibliografı́a del proceso dado en clase, con el que se empezaron a tomar las primeras decisiones de diseño generales que afectarı́an a la concepción misma del sistema. La primera de dichas decisiones vino dada por la inclusión, o no, de varios actores en el sistema, siendo éstos el gestor, actor que tendrı́a la capacidad de editar las variables y asignar las tareas a los miembros del equipo, y el resto de miembros del equipo, que se representarı́an por el actor “Miembro del equipo”, y que sólo tendrı́an acceso para la visualización de las tareas, y que no podrı́an modificar ninguna parte del proceso sin el permiso del gestor. A la vista de esto, se optó por hacer desaparecer a dicho actor, dejando sólo al gestor como actor del sistema, dado que la inclusión del actor antes citado inducı́a a una complejidad innecesaria para un proyecto de unas dimensiones tan reducidas como éste. El siguiente paso del proceso se centró en modelizar los elementos del proceso y establecer los términos correctos para referirse a ellos. Una vez analizada la hoja de cálculo, se obtuvieron los siguientes objetos del sistema: • Proyecto: Es el elemento principal y almacena la información básica del proyecto. • Calendario: Se trata del conjunto de fechas en las que se desarrollarán los proyectos; Su composición variará en función de las necesidades del gestor, pero incluirá periodos vacacionales y festivos, ası́ como indicaciones de inicio y fin de fases, iteraciones o del proyecto completo. • Horario: Determina el número de horas que un trabajador medio presta a la empresa. Es un número teórico, pudiéndose dar el caso de empleados que, por ejemplo, al trabajar media jornada, no cumplan, en consecuencia, todo el horario. • Personal: Se trata de una modelización de los trabajadores de la empresa, representando los activos disponibles. • Equipo: Representará el subconjunto de los trabajadores de la empresa a los que concierne el proyecto, y sobre los que se harán los cálculos de horas, costes y asignación de tareas. • Tareas: Resumen una tarea que se asociará a un trabajador, ası́ como la duración de dicha tarea. • Roles: Representa el conjunto de responsabilidades que un trabajador podrá adquirir a lo largo de un proyecto, pudiendo ostentar varios roles.. 4.

(13) Figura 1: Diagrama de los objetos del sistema y su relación. 5.

(14) 2.2 2.2.1. Casos de uso Primera aproximación a los casos de uso. Durante la primera aproximación al programa, se tomó como base una hoja de calculo vista en clase, en la que se detallaba el proceso para establecer las distintas fechas, carga de horas por persona en cada fase e iteración o los roles que adoptarán los miembros del equipo. Durante éste proceso, se extrajeron y detallaron 5 casos de uso, que posteriormente se descartaron en pro de utilizar una aproximación más cómoda para el usuario, resumiendo el proceso y eliminando, en la medida de lo posible, la linealidad de algunos de los puntos.. Figura 2: Primera aproximación de los Casos de Uso y Actores del sistema. 6.

(15) Estos casos de uso se plantearon y describieron siguiendo los modelos y diagramas vistos en clase y se obtuvo de ellos la información suficiente para comenzar a describir a grandes rasgos la arquitectura que tendrı́a la plataforma, lo que, posteriormente, ayudó a tomar algunas decisiones de diseño. A continuación, se exponen dichos casos de uso: • Editar Fechas: En este caso de uso, el gestor puede especificar las fechas de inicio y fin del proyecto, la longitud de las iteraciones o los festivos globales de la empresa. • Editar Calendario: Éste caso de uso, dependiente del anterior, permite especificar que fase se desarrollará en cada una de las iteraciones anteriormente definidas. • Editar Horario: Gracias a este caso de uso, el gestor puede establecer los meses laborables del año, el número de dı́as laborables de cada mes y el número de horas de trabajo de cada dı́a de la semana, estableciéndose ası́ el total de las horas disponibles para realizar un proyecto entre unas fechas dadas, ya que para realizar éste cálculo es necesario saber los dı́as hábiles, horas de cada dı́a y meses laborables de la empresa, además de los festivos globales. • Editar Equipo: Éste caso de uso permite al gestor introducir nuevos empleados en el sistema, asignándoles las horas en función del tipo de contrato que posean, el o los roles que son capaces de ejercer y otra serie de datos personales de relevancia para el gestor; además, en este caso de uso se podrán asignar las horas que cada miembro del equipo deberá emplear en cada fase. • Revisar Fases y Disciplinas: Éste caso de uso permite al gestor visualizar tanto las fases como las disciplinas, encontrando en ellas la proporción de horas dedicadas por cada uno de los trabajadores. • Revisar Plan de Fases: Por último, éste caso de uso ofrece una visualización total del proyecto, englobando tanto la visualización de las fases como de las disciplinas, ofreciendo un nivel de detalle menor que en el caso de uso anterior. Éstos casos de uso se interrelacionan siguiendo el siguiente modelo de contexto, en el que pueden apreciarse las dependencias en los casos de usos reflejadas en los distintos estados de la máquina mostrada. 7.

(16) Figura 3: Especificación del caso de uso “Editar Fechas”. 8.

(17) Figura 4: Especificación del caso de uso “Editar Calendario”. 9.

(18) Figura 5: Especificación del caso de uso “Editar Horario”. 10.

(19) Figura 6: Especificación del caso de uso “Editar Equipo”. 11.

(20) Figura 7: Especificación del caso de uso “Revisar Fases y Disciplinas”. 12.

(21) Figura 8: Especificación del caso de uso “Revisar Plan de Fases”. Figura 9: Contexto de los casos de uso. 13.

(22) 2.2.2. Casos de Uso definitivos. Tras una reunión con el Tutor del proyecto, y a la vista de que el planteamiento, si bien era válido, obviaba en gran medida la usabilidad del programa, además de requerir un segundo análisis para determinar si, tal y como ocurrió, algunos de esos casos de uso podı́an ser resumidos por tener partes comunes con otros. De ésta forma, se obtuvieron un total de 5 casos de uso, cuya concepción, si bien es muy similar al planteamiento original, difieren al proponer una serie de decisiones no redundantes, todo ello con el fin de mejorar la interacción del gestor con la plataforma, haciendo mucho más simple y cómoda la introducción de nuevas tareas, miembros del equipo, etc.. Figura 10: Casos de Uso y Actores del sistema. 14.

(23) Figura 11: Especificación del caso de uso “Editar Fechas”. 15.

(24) Figura 12: Especificación del caso de uso “Editar Horario Empresa”. 16.

(25) Figura 13: Especificación del caso de uso “Editar Recursos”. 17.

(26) Figura 14: Especificación del caso de uso “Editar Equipo”. 18.

(27) Figura 15: Especificación del caso de uso “Asignar Roles Definitivos”. 19.

(28) Los diagramas resultantes son muy parecidos a los anteriormente planteados, si bien presentan diferencias apreciables; pasamos a explicar someramente el contenido de dichos diagramas: • Editar Fechas Éste caso de uso tiene su contrapartida en la versión anterior con el caso de uso “Editar Calendario”, pero, a diferencia de ése, el caso de uso que nos ocupa se plantea de manera que el sistema genera automáticamente una serie de fechas sugeridas para las distintas iteraciones y fases, ası́ como la longitud de éstas; frente a este comportamiento, el caso de uso “Editar Calendario” presentaba una interacción con el actor en el que le pedı́a, en forma de bucle, que introdujera las fechas deseadas para cada fase o la longitud de la interacción. Éste comportamiento, si bien puede parecer intrascendente, ahorra esfuerzo al gestor, en la medida de que ya no debe tener a mano la tabla de porcentajes recomendado para cada fase. • Editar Horario Empresa En este caso de uso, el gestor puede definir el horario de cada uno de los dı́as de la semana, estableciendo para cada uno de ellos el número de horas de trabajo a realizar; esta granularidad permite establecer particularidades del horario, como que, por ejemplo, los viernes sólo se trabaje media jornada. Adicionalmente, se solicita al gestor los meses laborables del año y el numero de dı́as laborables de cada mes, a fin de establecer de una manera apropiada el número total de horas de un periodo concreto, sin tener en cuenta festivos ni periodos vacacionales o de cierre de la empresa. • Editar Recursos Éste caso de uso es el resultante de la división, en la versión anterior, del caso de uso “Editar Equipo”, ya que se consideró que la adición de personal potencial y la formación del equipo debı́an ser dos tareas bien diferenciadas. En éste caso, el gestor se encargará de cumplimentar los datos necesarios para dar de alta a un nuevo trabajador en el sistema, centrándose, principalmente, en las vacaciones de dicho trabajador, las horas asignadas para trabajar ( si trabajara a media jornada o jornada completa, por ejemplo) o los roles que se le podrı́an asignar. • Editar Equipo Segunda parte resultante de la división del caso de uso “Editar Equipo” en la primera versión, en este caso el gestor podrá elegir, de entre los 20.

(29) activos disponibles, a aquellos que considere que deben formar parte del equipo. Adicionalmente, se permite al gestor en este punto la creación y asignación de tareas a dichos miembros del equipo. • Asignar Roles Definitivos Por último, éste caso de uso permite, a la vista de las tarea asignadas a cada miembro del equipo, ası́ como de los posibles roles que es capaz de adoptar cada uno de los integrantes de dicho equipo, asignar de manera definitiva uno o varios roles, que serán los desempeñados a lo largo del proyecto.. 2.3. Priorización de los casos de uso. Una vez detallados los casos de uso que definen el comportamiento de la aplicación, es necesario determinar cuáles de ellos son más prioritarios, y, para ello, es imprescindible conocer la forma en la que éstos se relacionan. El siguiente diagrama muestra, como una máquina de estados, los distintos caminos que pueden tomarse para recorrer los distintos casos de uso de la aplicación:. Figura 16: Contexto de los casos de uso Tal y como puede apreciarse, existen una serie de casos de uso que pueden 21.

(30) darse en cualquier orden, mientras que otros requieren de algún paso previo para no incurrir en inconsistencias en el proceso. Por lo tanto, podemos extraer la siguiente priorización de casos de uso:. Figura 17: Priorización de los casos de uso. 22.

(31) 2.4. Prototipo de la interfaz de usuario. Para la interfaz de usuario, se trató desde el primer momento de ofrecer una visión diametralmente opuesta a la que ofrecı́a la herramienta desarrollada con anterioridad, optando por una interfaz en la que primara el aspecto visual y la usabilidad, facilitando la asignación de las distintas variables y tareas utilizando elementos gráficos tales como los sliders múltiples o un sistema de cajas dragand-drop para la asignación de las distintas tareas a los miembros del equipo.. Figura 18: Prototipo de la interfaz de usuario “Editar Fechas”. 23.

(32) Figura 19: Prototipo de la interfaz de usuario “EditarEquipo”. Figura 20: Prototipo de la interfaz de usuario “EditarHorario” 24.

(33) Figura 21: Prototipo de la interfaz de usuario “ListaEmpleados”. Figura 22: Prototipo de la interfaz de usuario “Persona”. 25.

(34) Figura 23: Diagrama de trazabilidad entre las vistas y los casos de uso. 26.

(35) 3. Arquitectura, Análisis, Diseño y Tecnologı́as. 3.1. Arquitectura. A la hora de plantear una arquitectura en lı́neas generales, y a la vista de los casos de uso encontrados y analizados, se decidió por implementar una arquitectura Modelo-Vista-Controlador (MVC a partir de ahora); De esta forma, podemos implementar los casos de uso como clases concretas de éste modelo, asignar vistas a dichas clases y extraer entidades de los objetos del negocio y del dominio analizados en fases anteriores. A continuación, se muestra un esquema general de la arquitectura planteada:. Figura 24: Diagrama con la arquitectura del proyecto. 27.

(36) Como puede observarse, se ha optado por una arquitectura basada en un controlador por cada caso de uso, de manera que la conversión de éstos sea inmediata. Por otro lado, tras analizar el modelo del dominio, se ha llegado a la conclusión de que las entidades aquı́ mostradas son más que suficientes para modelizar todo el proceso. Cabe destacar con respecto a dichas entidades que, por dotar de sencillez al desarrollo de esta plataforma, tal y como se explicó en el capı́tulo 1, se optó por utilizar un modelo de persistencia en memoria. Dicho modelo se tratará con más detalle en el capı́tulo 4. Por último, a la hora de establecer las vistas, se han tenido en cuenta los modelos previos extraı́dos de las reuniones con el tutor, resultando en el modelo de clases anterior.. 3.2. Análisis de la arquitectura. Una vez establecidas las bases de la arquitectura, ası́ como las distintas clases que intervienen en el proceso, es necesario trazar los caminos que conectan dichas clases entre si para conformar los casos de uso que el gestor podrá realizar. Adicionalmente, éste análisis de qué clases interactúan en qué clases de uso determinará una primera aproximación al diseño de las interfaces que luego se perfilarán con mayor detalle en la fase de implementación. Como primer paso, se muestran los llamados “diagramas de clase”, en los que se muestran las conexiones entre las distintas clases del diseño, sin incluir en dichos diagramas referencia alguna a los mensajes que se envı́an entre ellas.. Figura 25: Diagrama de clases del caso de uso “Editar Fechas”. 28.

(37) Figura 26: Diagrama de clases del caso de uso “Editar Horario Empresa”. Figura 27: Diagrama de clases del caso de uso “Editar Recursos”. Figura 28: Diagrama de clases del caso de uso “Editar Equipo”. 29.

(38) Figura 29: Diagrama de clases del caso de uso “Asignar Roles Definitivos”. 30.

(39) Los siguientes diagramas aquı́ mostrados, llamados diagramas de colaboración, marcan, al mismo tiempo, las interacciones entre las clases, ası́ como los mensajes que entre dichas clases se envı́an y su direccionalidad, conformando de ésta forma una suerte de diseño preliminar de la interfaz de cada una de las clases.. Figura 30: Diagrama de colaboración del caso de uso “Editar Fechas”. Figura 31: Diagrama de colaboración del caso de uso “Editar Horario Empresa”. 31.

(40) Figura 32: Diagrama de colaboración del caso de uso “Editar Recursos”. Figura 33: Diagrama de colaboración del caso de uso “Editar Equipo”. Figura 34: Diagrama de colaboración del caso de uso “Asignar Roles Definitivos” 32.

(41) Cabe destacar que ésta interfaz no es ni mucho menos definitiva, sino un bosquejo de los métodos definitivos. Ası́ mismo, la interacción entre clases aquı́ descrita puede estar sujeta a cambios durante la fase de implementación, donde pueden surgir dependencias no contempladas en esta fase; sin embargo, en lı́neas generales la interacción entre clases se mantendrá tal y como está aquı́ descrita, respetando en todo momento el principio de encapsulamiento de las distintas zonas definidas por la arquitectura MVC; por ejemplo, las entidades en ningún momento tendrán conocimiento de ninguna otra clase, es decir, ninguno de sus métodos hará referencia a clases de la interfaz gráfica o de los controladores.. 3.3. Plan de pruebas. Una parte esencial de todo desarrollo es el plan de pruebas que se va a implementar, buscando los puntos más débiles de la aplicación , más que la cobertura de todos los caminos. Para ello, se han tomado los casos de uso y de ellos se han extraı́do las pruebas a implementar, que serán en muchos casos recorridos concretos de un caso de uso. Éstas pruebas buscan como objetivo garantizar el cumplimiento por parte de la aplicación de los casos de uso comprometidos a realizar, por lo que servirı́an como una suerte de pruebas de aceptación del sistema, estableciendo los lı́mites entre los que la aplicación se moverá. Es importante definir éste plan en el momento previo a la fase de implementación, de manera que se permita obtener tanto un seguimiento del progreso como una limitación sobre las posibles entradas y salidas del sistema, facilitando de esta forma la labor de diseño definitiva de la interfaz ası́ como la implementación de las distintas clases que conforman la aplicación. A continuación, se muestra un esquema con los distintos casos de prueba que contempla en plan de pruebas para la aplicación, basados en los distintos caminos posibles para los casos de uso especificados.. 33.

(42) Figura 35: Esquema del plan de pruebas. 34.

(43) 3.4. Diseño. Una vez establecidos los elementos arquitectónicos básicos del proyecto, resta concretar en detalle dichos elementos, estableciendo las primeras interfaces por cada clase, ası́ como el contenido de los paquetes. 3.4.1. Análisis de las clases. El primer paso del análisis del proyecto será el análisis de clases, que consistirá en establecer, de forma unı́voca, la interfaz de cada clase, ası́ como establecer con qué clases se relaciona. Para ello, utilizaremos los diagramas de análisis de clase, que mostramos a continuación, en los que se muestra la interfaz de cada clase que se ha extraı́do de los diagramas de colaboración de los casos de uso, ası́ como la relación de dicha clase con las demás.. Figura 36: Diagrama de la clase “EditarFechasController”. 35.

(44) Figura 37: Diagrama de la clase “EditarHorarioEmpresaController”. Figura 38: Diagrama de la clase “EditarRecursosController”. 36.

(45) Figura 39: Diagrama de la clase “EditarEquipoController”. Figura 40: Diagrama de la clase “AsignarRolesDefinitivosController”. 37.

(46) Figura 41: Diagrama de la clase “CalendarioEntity”. Figura 42: Diagrama de la clase “EquipoEntity”. 38.

(47) Figura 43: Diagrama de la clase “PersonaEntity”. Figura 44: Diagrama de la clase “CalendarioView”. 39.

(48) Figura 45: Diagrama de la clase “EquipoView”. Figura 46: Diagrama de la clase “HorarioView”. 40.

(49) Figura 47: Diagrama de la clase “ListaEmpleadosView”. Figura 48: Diagrama de la clase “PersonaView”. 41.

(50) 3.4.2. Análisis de la arquitectura. Una vez establecidas las interfaces de diseño, es necesario incluir una serie de diagramas, llamados diagramas de de análisis de paquetes, en los que se muestra el contenido de cada paquete lógico, es decir, que clases formarán dicho paquete y cómo se interrelacionan dichas clases entre sı́ dentro de un mismo paquete. En éste caso, y tal y como puede apreciarse en los diagramas siguientes, no existe ninguna relación entre las clases internas a un paquete.. Figura 49: Análisis del paquete “Controllers”. 42.

(51) Figura 50: Análisis del paquete “Models”. 43.

(52) Figura 51: Análisis del paquete “Views”. 44.

(53) 3.4.3. Diseño de la arquitectura. Por último, es necesario describir la arquitectura fı́sica del proyecto, además de la distribución de los distintos paquetes lógicos entre la arquitectura fı́sica; para ello, se muestra el siguiente diagrama en el que queda patente esta separación, mostrando cómo el paquete “Views” será ejecutado en el lado del cliente, y la ejecucuı́on de los paquetes “Models” y “Controllers” se ejecutarán en el lado del servidor; ésta división, tal y como se explicará en mayor detenimiento en el capı́tulo 4 viene impupesta por las deciones tecnológicas, en concreto, el uso de los motores de ejecución de scripts en el lado del cliente.. Figura 52: Diagrama que muestra la división de los paquetes entre las distintas partes de la arquitectura. 45.

(54) 4. Implementación. A la hora de realizar la implementación, se partió de la base especificada en los casos de uso y las interfaces definidas en la fase de diseño para comenzar a realizar la implementación, siguiendo el modelo arquitectónico descrito anteriormente. Una vez especificados estos puntos, el desarrollo de la aplicación en sı́ se ha realizado utilizando las herramientas y técnicas que iremos describiendo a lo largo de este capı́tulo. Tal y como se especificó en el capı́tulo 3, la presente aplicación se sostiene sobre una arquitectura de tipo MVC; a la hora de llevar dicha arquitectura a la práctica, es necesario establecer que agentes realizarán qué funciones, dado que la aplicación se sustenta sobre una plataforma web y, por tanto, es viable, además de recomendable, distribuir la carga de trabajo entre el cliente y el servidor. De ésta forma, nos encontramos con una división muy clara entre cliente y servidor, y será en este capitulo en el que determinemos las responsabilidades de cada uno.. 4.1. Soporte tecnológico. A la vista de todo lo aportado anteriormente, pudimos establecer una arquitectura fı́sica siguiendo el modelo cliente-servidor, en el que utilizaremos un servidor Apache con el motor PHP5 para el procesamiento de los datos, tarea correspondiente al proceso del caso de uso de cada uno de los controladores; y tecnologı́as de Javascript en el lado del cliente, utilizando el framework JQuery y los plugins “JQueryUI” y “colResaizable”. Estos plugins serán tratados con mayor detalle en este mismo capı́tulo. Puede observarse que no se incluye ninguna tecnologı́a con respecto a bases de datos; esto es ası́ dado que, tal y como se explicó en el capı́tulo del alcance, la implementación en sı́ sólo se plantea a un nivel básico, y por tanto, la infraestructura necesaria para la inclusión de una base de datos, ası́ como la creación de las tablas necesarias para dicha base y la relación de dichas tablas con las entidades queda fuera del alcance actual de la aplicación, si bien se incluirá como una de las posibles mejoras a implementar. Sin embargo, si existe un sistema de persistencia en memoria, utilizando los elementos que facilita el lenguaje PHP, el cual será tratado posteriormente con detalle en éste mismo capitulo.. 4.2. Cliente. El cliente posee la responsabilidad de ejecutar adecuadamente las interfaces gráficas, contenidas en las vistas, y que poseen cierta capacidad de procesamiento, haciendo de esta manera más sencillo el trabajo del controlador ( alojado en el servidor). Para este caso, se ha optado por un nivel de complejidad moderado. 46.

(55) en el cliente, centrándose sólo en procesamiento más básico de los datos y dejando la responsabilidad del proceso más laborioso al controlador. Para ello, el cliente utiliza el motor de ejecución de scripts “Javascript” y se sustenta sobre una serie de frameworks para encapsular la complejidad de tareas secundarias, ası́ como para facilitar la labor de programación. Entre los frameworks existentes para interfaces de usuario, se ha elegido el uso de JQuery por ser el mejor documentado y el más idóneo para ésta situación; en un principio, se planteó el uso de AngularJS, pero tras un breve análisis, se descartó debido a los cambios en la arquitectura que su uso suponı́a, además de el tiempo que habrı́a de invertir en su aprendizaje. Se planteó en un primer estadı́o del proyecto el uso del framework Bootstrap, pero dado que se trata de un framework que simplemente aporta mejoras visuales y de comportamiento adaptable a distintos dispositivos, se decidió apartarlo y proponerlo como una mejora futura, tal y como se describe en el capı́tulo 5. Por último, cabe destacar que para la implementación de las vistas, se ha optado por utilizar HTML 4.1, dado que es el que mayor aceptación tiene entre los navegadores web existentes actualmente en el mercado, si bien el cambio a HTML 5 no aportarı́a grandes diferencias, pero su uso aún ésta menos extendido que el de la versión anterior. A la hora de implementar las vistas, se ha optado por un sistema básico de plantillas, sin utilizar ningún tipo de framework, para dotarlo de sencillez; dicho sistema entra en acción en el controlador, que será el encargado de inyectar los datos variables adecuados a la vista, ası́ como de incluir las cabeceras y pies de página, iguales en todos los puntos del programa, y de enviar el contenido resultante al cliente, en cual, si se diera el caso, utilizarı́a los scripts escritos en Javascript para visualizar adecuadamente el contenido, creando de manera dinámica elementos que de otra manera no serı́a posible. Entrando en detalle de los scripts utilizados, hay que remarcar que no se ha utilizado tecnologı́a AJAX, ya que si bien encaja mucho mejor en los desarrollos de interfaces centradas en los usuarios, añade una complejidad en el flujo de trabajo, principalmente por el intercambio de mensajes entre el cliente y el servidor, llegando al punto de, en ocasiones, desdoblar la funcionalidad de un controlador para adecuarse al uso de ésta herramienta. Los scripts, por tanto, realizarán sólo las siguientes labores: • Generar información para el cliente de manera autónoma al servidor, reduciendo la carga y, por tanto, los tiempos de espera propios del procesado de formularios. • Realizar, de ser necesario, una pequeña comprobación de los datos de entrada para reducir ası́ el tiempo de espera a la hora de aportar una retroalimentación al usuario, es decir, a la hora de informarle de errores cometidos en, por ejemplo, el formato de los datos introducidos. 47.

(56) • Aportar mejoras visuales y funcionales que no serı́an posibles de otra forma, tales como las herramientas de Drag&Drop. 4.2.1. Plugins usados. A la hora de mejorar la visualización de los elementos dados, se optó por la utilización de una serie de plugins para el framework JQuery, dado que, si bien es posible realizar el mismo trabajo utilizando solamente dicho framework, el volumen de trabajo se vuelve excesivo. Los plugins aquı́ mostrados son una solución perfecta, ya que, por un lado, aportan las mejoras visuales encontradas, y por el otro, están lo bastante bien documentados como para que el aprendizaje de su manejo sea asumible en una cantidad breve de tiempo. Después del análisis de los prototipos de la interfaz gráfica, se optó por buscar solamente dos plugins que implementaran las dos partes más complejas de la visualización. Pasamos a comentar dichas elecciones: • Drag&Drop: Para implementar de una manera más simple éste mecanismo, se optó por la utilización del plugin JQueryUI, que se bien está desarrollado por un equipo en colaboración con JQuery, se distribuye como un plugin al margen debido a que las funciones que ofrece son más visuales que funcionales, a diferencia de JQuery. Dentro de éste plugin se incluyen multitud de mejoras gráficas y envolturas para las operaciones ofrecidas por el framework que lo sustenta, y entre todas ellas encontramos una rica API de acceso, manejo y visualización de elementos que implementen la funcionalidad de arrastrar y soltar.. 48.

(57) Figura 53: Página del plugin JQueryUI. 49.

(58) • Slider múltiple: Para la implementación de una barra de deslizamiento, o Slider, con múltiples puntos de deslizamiento, para definir rangos de tamaño variable, se optó por la utilización del plugin colResaizable, el cual, si bien está principalmente pensado para realizar cambios en el tamaño de tablas, ofrece algunas funcionalidades para sliders múltiples.. Figura 54: Página del plugin colResaizable. 50.

(59) 4.3. Servidor. A la hora de afrontar las tareas del servidor, el cual ejecuta scripts de PHP5, se decidió desde un primer momento no utilizar ningún framework, a diferencia de la parte cliente de la aplicación. Ésta decisión viene dada por varios factores, siendo éstos: • La inclusión de un framework introduce un factor de complejidad muy elevado, dado que los frameworks existentes en el mercado actualmente aportan multitud de herramientas y soluciones que no son necesarias para este proyecto. • Asimismo, la inclusión de un framework fuerza la utilización de una arquitectura determinada, y si bien en general esa arquitectura se asemeja mucho a la utilizada en esta herramienta, no se ajusta del todo a la utilización de determinados modelos, como pudiera ser el patrón DAO para la modelización de entidades; muchas veces, los frameworks dan por hecho que se utilizará una base de datos y organizan su estructura en torno a ello, ofreciendo muchos de ellos un modelo de ORM (Object-Relational Mappging, mapeo objeto-relacional en castellano) con generación automática de las tablas en la base de datos. A la vista de esto, queda patente que el proyecto deberá implementar su propio sistema de enrutamiento, de carga de vistas ( del cual ya se ha hablado) y de persistencia, éste último detallándose en un epı́grafe posterior; por tanto, habrı́a que destacar que el planteamiento del sistema de enrutamiento se planteó como un único fichero llamado “rutas.php” que contiene las rutas absolutas a los distintos elementos de la aplicación, de manera que cualquier cambio en su ubicación sólo debe notificarse en dicho fichero. 4.3.1. Modelo de persistencia. Con respecto al modelo de persistencia utilizado, dado que se está utilizando el patrón DAO y que el cambio de un modelo de persistencia a otro es bastante rápido y para aligerar el proceso de creación, se ha optado por crear un primer sistema de persistencia en memoria, utilizando la estructura de almacenamiento $ SESSION ofrecida por PHP5 como soporte para el almacenamiento de los datos. Si bien es un sistema que sólo se mantendrá mientras la sesión siga abierta, es decir, mientras la aplicación se mantenga en funcionamiento, el hecho de utilizar el patrón DAO permite que, en un futuro, se puedan implementar otros sistemas de persistencia mejores. Éste tema se tratará en profundidad en la sección de lı́neas futuras del capı́tulo 5.. 51.

(60) 4.4. Pruebas. A la hora de plantear las pruebas se hace de nuevo patente la separación entre el cliente y el servidor, y por ello lo trataremos en dos apartados diferenciados; no obstante, aunque las pruebas utilicen sistemas muy distintos para su realización, habrá un tercer conjunto de pruebas, las de aceptación, en las que se comprobará el correcto funcionamiento de la aplicación atendiendo a los casos de uso planteados. 4.4.1. Pruebas del Cliente. Para la realización de las pruebas en el lado del cliente, se optó por utilizar, de manera conjunta, un falso servidor cuyas respuestas siempre sean idénticas y una serie de scripts que simularan la interacción de un usuario con la interfaz gráfica, ejecutando las llamadas pertinentes. Se optó por la elección de éste sistema en lugar de la utilización de un programa externo para reducir, en la medida de lo posible, el aprendizaje de nuevas herramientas y tecnologı́as, si bien puede ser un sistema más complejo en éste caso. 4.4.2. Pruebas del Servidor. A la hora de plantar las pruebas en el lado del servidor, concretamente, las pruebas de los controladores, se optó por la utilización de los propios scritps de PHP para su realización, ejecutando los distintos casos de uso en ambientes controlados en los que se utilizarán falsas entidades para simular los accesos al sistema de persistencia. Por último, el sistema de persistencia ejecutará, de igual forma, su conjunto de pruebas unitarias en las que se monitorizará que la entrada y la salida sean las adecuadas en cada caso.. 52.

(61) 5. Conclusiones y lı́neas futuras de trabajo. Como conclusión a este proyecto, me gustarı́a realizar una reflexión a tener de todo el trabajo realizado y de su enfoque. Si bien el proyecto parecı́a, en un principio sencillo, la cantidad de material necesario para la realización de una buena documentación y un análisis apropiado ha sido, como se ha podido comprobar, muy elevada, y es ahı́ donde radica, en mi opinión, la diferencia entre éste y otros proyectos del mismo tipo. Muchas veces tenemos la tendencia de enfocar el problema de una manera muy concreta, esto es, a enfrentarnos al código escribiéndolo, necesitando en ocasiones refactorizar nuestras primeras aproximaciones, o directamente desecharlas, para adecuarlas a los casos de uso dados, que no es más que lo que en el fondo el cliente requiere. Éste proceso de ensayo y error merma las horas de trabajo productivo y, por lo tanto, la calidad del producto, y es una manera poco productiva de afrontar un proyecto de una dimensión mediana o grande, pese a existir otras metodologı́as que, precisamente, se aprovechen de éste funcionamiento. Sin embargo, cuando la cantidad y complejidad del código sobrepasa determinados umbrales, es necesario un análisis más detallado y, por lo tanto, no podemos, sencillamente, sentarnos y escribir código que luego no servirá. De ahı́, en mi opinión, la importancia de una metodologı́a como la aquı́ expuesta en la que, si bien se ha utilizado la gran parte del tiempo en realizar los análisis de las distintas partes del código y su interrelación en lugar de, efectivamente, producir éste código, la creación del mismo ha sido y será mucho más directa y eficiente, ya que la inmensa mayorı́a de puntos conflictivos están resueltos, estudiados, y bien documentados, dejando poco margen al error. En cuanto a los objetivos marcados en el capı́tulo ??, creo que se han logrado todos ellos, aumentando ası́ mi conocimiento, tanto de la tipologı́a y uso de los diagramas UML, como de la metodologı́a en sı́, lo que me ha permitido adquirir algo de experiencia no solo con la metodologı́a o el uso de los citados diagramas, sino con el desarrollo desde cero de un proyecto, aunque se trate de uno de muy pequeñas dimensiones, que era el fı́n último de éste proyecto, más allá de la metodologı́a utilizada o el nivel de completitud logrado.. 5.1. Futuras lı́neas de trabajo. Entre las sugerencias de mejora de la herramienta, podemos encontrar las siguientes: • Implementación de un sistema de persistencia basado en BBDD: al y como se vio en el apartado de la implementación, quedaba fuera del alcance la gestión y creación de una base de datos para incluirla como modelo de persistencia de la plataforma, permitiendo de ésta manera que la gestión pueda realizarse en varios pasos, o que gestiones anteriores puedan ser heredadas de un proyecto a otro, función útil a priori si la empresa se. 53.

(62) maneja siempre con un equipo similar de personas. • Inclusión de frameworks que mejoren el aspecto visual: A la vista queda que el apartado visual no es el más apropiado, y por lo tanto, se sugieren la inclusión de frameworks como Bootstrap que no sólo añaden mejoras estéticas, sino también funcionales, ofreciendo un sistema de paga adaptativa cuyo tamaño y disposición de los elementos variará en función del tamaño del navegador en el que se visualice. • Migración del sistema a una API de tipo REST: La creación de un sistema tipo REST que ejecute los casos de uso permitirı́a, en un futuro, sustituir las vistas programadas con Javascript por unas mucho más detalladas e inteligentes basadas en, por ejemplo, ÁngularJS. • Creación de un cliente móvil: Aprovechándonos del punto anterior, serı́a sencillo establecer un cliente móvil cuyas vistas se comunicaran de manera remota con el servidor mediante llamadas a la API REST.. 54.

(63) Referencias [1] IT. Hello. Resumen de Scrum desde la trinchera. http://helloit.es/2014/ 09/resumen-de-scrum-desde-las-trincheras/. [Online; Último acceso 23/6/2015]. [2] Luis Fernández Muñoz. Apuntes de la asignatura “Metodologı́as Pesadas para Desarrollo Web”. https://moodle.upm.es/titulaciones/oficiales/ course/view.php?id=3269&section=10. [Online; Último acceso 1/7/2015]. [3] Wikipedia. Proceso unificado de Rational. org/wiki/Proceso_Unificado_de_Rational. 21/5/2015].. 55. https://es.wikipedia. [Online; Último acceso.

(64)