Reingeniería de una aplicación web para gestionar proyectos de … · 2017-10-17 ·...

Alan Vallejo Belshaw

Francisco José García Izquierdo

Facultad de Ciencia y Tecnología

Grado en Ingeniería Informática

2015-2016

Título

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

Reingeniería de una aplicación web para gestionarproyectos de software

Autor/es

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2016

publicaciones.unirioja.esE-mail: [email protected]

Reingeniería de una aplicación web para gestionar proyectos de software,trabajo fin de grado

de Alan Vallejo Belshaw, dirigido por Francisco José García Izquierdo (publicado por laUniversidad de La Rioja), se difunde bajo una Licencia

Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los

titulares del copyright.

Facultad de Ciencia y Tecnología

TRABAJO FIN DE GRADO

Grado en Ingeniería Informática

Reingeniería de una aplicación web para gestionar proyectos de software.

Alumno:

Alan Vallejo Belshaw Tutores:

Francisco García Izquierdo

Logroño, Junio de 2016

Reingeniería de una aplicación web para gestionar proyectos de software Alan Vallejo Belshaw __________________________________________________________________________________________

1

Índice

Resumen...........................................................................................................................3

Abstract............................................................................................................................3

Agradecimientos...............................................................................................................4

1 Introducción................................................................................................................51.1 Contexto...........................................................................................................................51.2 Tecnologías.......................................................................................................................51.3 Alcance.............................................................................................................................61.3.1 Conocerlaestructuraylastecnologías............................................................................61.3.2 Implementarnuevafuncionalidad...................................................................................61.3.3 Realizarunnuevodiseñográfico......................................................................................7

1.4 Gestióndeltrabajofindegrado........................................................................................81.4.1 Estructuradedescomposicióndelproyecto(EDP)...........................................................81.4.2 Descripcióndelastareas..................................................................................................91.4.3 DiagramadeGantt.........................................................................................................101.4.4 DiagramadeHitos..........................................................................................................111.4.5 Seguimientoycontrol.....................................................................................................111.4.6 Plandecomunicaciones.................................................................................................111.4.7 Reuniones.......................................................................................................................111.4.8 Plandecalidad................................................................................................................11

2 Etapa1:Conocerlaestructuraysolucionarerrores...................................................152.1 Adquirirconocimientos..................................................................................................152.2 Estructuradelaaplicación..............................................................................................152.3 Localizarysolucionarerrores..........................................................................................162.4 Implementación.............................................................................................................17

3 Etapa2:Implementacióndenuevafuncionalidad.....................................................193.1 Módulodepresupuestos................................................................................................193.1.1 Análisis............................................................................................................................193.1.2 Diseño.............................................................................................................................203.1.3 Implementación..............................................................................................................213.1.4 Pruebas...........................................................................................................................23

3.2 Móduloestadísticas........................................................................................................253.2.1 Análisis............................................................................................................................253.2.2 Diseño.............................................................................................................................283.2.3 Implementación..............................................................................................................313.2.4 Pruebas...........................................................................................................................34

3.3 Mejorarlausabilidad......................................................................................................363.3.1 Implementarunapáginadeerror..................................................................................363.3.2 MejorarlarecoleccióndedatosenlapáginaHome......................................................383.3.3 VisualizarlosdatosguardadosenlapáginaHome.........................................................41


2

3.3.4 InsertarnuevainformaciónenlapáginaHome.............................................................443.3.5 Mejorarlanavegabilidaddelaaplicaciónyeliminarinformacióninnecesaria..............463.3.6 Crearnuevasalertasysustituirlasyaexistentes...........................................................473.3.7 FacilitarlabúsquedadetareasenlapáginaHistoricoHoras..........................................48

4 Etapa3:Diseñográficodelaaplicación.....................................................................51

5 Conclusiones.............................................................................................................535.1 Tablacomparativaentreeltiempoestimadoyeltiemporealizado................................54

6 Bibliografía...............................................................................................................55


3

Resumen

La empresa Netbrain Solutions S.L. dispone de una aplicación para gestionar y controlar las horas que invierten los empleados en sus diferentes proyectos. Al finalizar la jornada laboral, dichos empleados entran en la aplicación y anotan una serie de datos sobre las tareas realizadas que posteriormente analiza el director de proyectos con el fin de comparar las horas reales invertidas con las inicialmente presupuestadas.

Este trabajo ha sido propuesto por D. Hernán González Buteler, director de proyectos de dicha empresa, con el fin de realizar una reingeniería de la mencionada aplicación que consiga mejorar y ampliar la información ofrecida, así como desarrollar la navegabilidad entre sus diferentes páginas y el diseño de las mismas. Además, quiere solucionar un conjunto de errores que actualmente impiden su correcto funcionamiento e incluir unas estadísticas que permitan obtener datos adicionales que generen un conocimiento aplicable a posibles nuevos presupuestos.

Las mejoras perseguidas a través de este proyecto están dirigidas a convertir la aplicación en una herramienta valiosa para la sociedad anteriormente mencionada.

Abstract

The Company Netbrain Solutions S.L. currently uses an application to manage and control the time spent by each employee in fulfilling its different projects. At the end of every working day, the employees use the application to register various aspects relating to the tasks carried out that are later analysed by the Director of Projects so as to compare the real time required with the initially estimated time.

Mr. Hernán González Buteler, Director of Projects, proposed this project with the aim of re-engineering the above-mentioned application to improve and extend the information that it offers, as well as to perfect its design and the surfing between its different pages. He also wishes to find a solution for a group of errors that currently prevent the application from functioning correctly and to include statistics that will provide additional data, generating useful knowledge that can be applied to possible new estimates.

The improvements object of this project are aimed at converting the application in a valuable tool for the above-mentioned enterprise.


4

Agradecimientos

En primer lugar me gustaría expresar mi agradecimiento a la empresa NetBrain Solution S.L. y en especial a su director de proyectos, Hernán González Búteler, por la dedicación y las directrices dadas así como la confianza depositada en mí para la realización de este proyecto.

Asimismo, agradezco al tutor Francisco García Izquierdo, su paciencia y apoyo en las diferentes fases que han comprendido este TFG.

Por último, me gustaría destacar la confianza y los ánimos proporcionados por mis padres durante estos años de carrera, ya que sin ellos habría sido mucho más difícil llegar hasta aquí.


5

1 Introducción

El motivo de la presente memoria es recoger los puntos más destacados del Trabajo Fin de Grado realizado por Alan Vallejo Belshaw bajo el título “Reingeniería de una aplicación web para gestionar proyectos de software”. Este proyecto ha sido desarrollado para la empresa Netbrain Solutions S.L. .

1.1 Contexto

La empresa Netbrain Solutions S.L. gestiona y realiza a diario diferentes proyectos web. Para poder tener un control sobre la duración de los proyectos y de las horas invertidas por cada trabajador, disponen de una aplicación web en su red interna de nombre Timetracker.

Esta aplicación muestra más o menos información dependiendo del tipo de usuario que esté conectado a la misma. Existen dos: user y admin.

El usuario “user” está destinado a los empleados, y les permite introducir las horas que realizan diariamente en los diferentes proyectos de la empresa. Además, pueden dar de alta y editar proyectos con ciertas restricciones, ya que no tienen permiso para realizar ningún tipo de presupuesto. Tienen la posibilidad de consultar el estado, las horas estimadas, las horas realizadas y la fecha final de cada proyecto, además de tener acceso a la información de contacto de otros trabajadores.

El usuario “admin” es utilizado por el director de proyectos para llevar un control sobre los proyectos y los trabajadores. Puede llevar a cabo las mismas acciones que un usuario normal, además de poder establecer la cantidad presupuestada y consultar información más detallada sobre los proyectos.

Actualmente al director de proyectos le gustaría mejorar la información en las estadísticas de los proyectos y construir una herramienta para obtener estadísticas de los empleados. Querría mejorar la funcionalidad, la navegabilidad, el aspecto de la aplicación y llevar a cabo una reestructuración del código para mejorar la mantenibilidad y la lectura del mismo. Además, la aplicación recoge una serie de errores que desearía que fueran solucionados en la mayor brevedad posible.

Para solucionar los errores existentes y llevar a cabo la renovación funcional y visual de la aplicación nace este proyecto.

Este Trabajo Fin de Grado ha sido propuesto por D. Hernán González Buteler, director de proyectos de la empresa Netbrain Solutions S.L. el cuál actúa como cliente de la aplicación, y tutorado por D. Francisco García Izquierdo, director de estudios del Grado de Ingeniería informática.

1.2 Tecnologías

En el presente existen muchos frameworks para la realización de aplicaciones web que permiten agilizar el desarrollo y ayudar al programador a construir dichas aplicaciones. Cada uno de ellos tiene sus pros y sus contras, y permiten una mayor o menor abstracción.

Para el desarrollo de Timetracker voy a utilizar un framework de Php llamado Laravel. La filosofía de dicho framework es desarrollar código Php elegante y simple, evitando el “código espagueti”. Provee de herramientas muy útiles e intuitivas para el desarrollo web. En concreto, destacaría dos:

1. Para el Backend está Eloquent ORM, un sistema de mapeo de datos relacional que facilita la creación de modelos. Además, permite interactuar fácilmente con los datos.

2. En el Frontend, nos encontramos con Blade, un sistema de plantillas que favorece un código más limpio en las vistas. Asimismo, incluye un sistema de caché que lo hace muy rápido.


6

Para la maquetación y el diseño de las páginas he utilizado Bootstrap. Se trata de un framework de HTML5, JavaScript y CSS, que simplifica el diseño y la maquetación de la aplicación. La particularidad de Bootstrap es que permite adaptar la interfaz de la aplicación al tamaño del dispositivo (tablet, móvil u ordenador) en que se visualice, lo que en inglés es conocido como Responsive Web Design.

Para visualizar los datos de la aplicación voy a utilizar PhpMyAdmin, herramienta utilizada para administrar bases de datos MySQL.

1.3 Alcance

Este Trabajado Fin de Grado consiste en hacer una reingeniería de la aplicación Timetracker donde mejoraremos y añadiremos funcionalidad que permitirá al director de la empresa Netbrain S.L. obtener conocimiento útil de los proyectos y de los empleados. Así, podrá gestionar los recursos de la empresa entre los diferentes proyectos que estén activos, para conseguir entregar cada uno de ellos en la fecha lo más próxima a la prevista. Por otro lado, podrá utilizar el conocimiento adquirido gracias a la aplicación para calcular el coste y el tiempo a invertir en futuros proyectos.

Para comenzar, hemos dividido el trabajo en tres etapas. En cada una, realizaremos una serie de pasos para llevar a cabo la reingeniería de la aplicación. Primero, estudiaremos detalladamente la estructura de la aplicación y las tecnologías utilizadas, ofreceremos soluciones a los errores que existen actualmente en la aplicación y revisaremos toda su funcionalidad. En la segunda, implementaremos la nueva funcionalidad solicitada por el cliente y, en la tercera, rediseñaremos la estética de la aplicación.

1.3.1 Conocer la estructura y las tecnologías

Al tratarse de una aplicación web, será necesario conocer qué lenguajes y qué versiones de los mismos se están utilizando, para así saber si nos hará falta realizar algún tipo de formación antes de comenzar con la segunda etapa.

Por otro lado, será imprescindible analizar la forma en que está estructurada la aplicación. De esta manera, conoceremos si se ha utilizado algún tipo de patrón a la hora de implementar el código, y estudiaremos si éste ha sido aplicado correctamente.

Además, en la primera reunión, el cliente nos ha comunicado la existencia de dos errores a los que daremos solución. Para evitar que en el futuro vuelvan a repetirse, intentaremos reproducirlos y encontraremos su origen. También realizaremos un estudio exhaustivo dónde comprobaremos la funcionalidad en busca de posibles errores que hayan podido pasar desapercibidos para los anteriores desarrolladores de la aplicación.

1.3.2 Implementar nueva funcionalidad

El cliente ha pedido nuevas características que le gustaría incluir dentro de la aplicación. Desearía mejorar ciertas partes de ella y obtener información más útil. De esta manera, incrementaría el control sobre los proyectos y conseguiría un conocimiento más amplio para calcular el presupuesto y el tiempo de realización de uno nuevo. También le gustaría conocer en qué emplean el tiempo sus trabajadores y a qué tipos de proyectos dedican más horas.

Una vez finalizado el proyecto la aplicación ha de tener los siguientes requisitos :

Presupuestos a medida

Para que el director de proyectos pueda realizar y generar presupuestos a medida, crearemos un nuevo módulo que dependiendo de los criterios que vienen detallados en el apartado 3.1.1, sugiera las horas necesarias y el coste aproximado para cada proyecto a realizar. El módulo incluirá varias páginas que


7

permitan consultar un listado de todos los presupuestos que hay en la aplicación, así como ver y editar la información de cada uno de ellos.

Obtener estadísticas detalladas

Incluiremos una página que permitirá al administrador visualizar las estadísticas de cada uno de los empleados. En ella podremos contrastar para cada proyecto el número de horas y el porcentaje de tiempo invertidos por un empleado determinado con respecto a los demás que han participado. Dicha página deberá contener dos filtros: el primero de ellos mostrará los proyectos en los que ha participado un empleado y el segundo establecerá el rango de fechas para el que queremos obtener las estadísticas.

A continuación mejoraremos las estadísticas de los proyectos, incorporando nuevos datos e incluyendo herramientas que permitan visualizarlos de manera intuitiva. Añadiremos una barra de progreso para cada proyecto, donde se pueda ver a primera vista el progreso real e ideal del mismo. También incluiremos tablas y diagramas circulares donde veremos el porcentaje de tiempo invertido en las tareas y en los módulos de cada proyecto, así como una comparativa de los tiempos realizados por los empleados que han participado.

Mejorar la usabilidad

Por otro lado, modificaremos ciertas funciones ya existentes en la aplicación para facilitar su uso así como su navegabilidad. En un futuro el cliente podría plantearse comercializar la aplicación, por ello desea que creemos una página de error, para tratar los fallos que suelen ocurrir a la hora de utilizar una aplicación web.

Además quiere ampliar la página de inicio para que los empleados puedan visualizar para cada proyecto el tiempo estimado y el tiempo realizado. También quiere incluir nueva funcionalidad en dicha página que mejore el envío de datos al servidor.

También desea colocar enlaces en los nombres de las de listas de los proyectos y de los trabajadores que le permitan un rápido acceso a los datos estadísticos. Por otro lado, eliminaremos los identificadores de las tablas que muestran los proyectos, los trabajadores y las tareas, ya que no aportan información útil.

Actualmente las alertas de la aplicación hacen uso de la función alert de JS. Para que sean más visuales, la sustituiremos por otra función que haga uso de una ventana modal.

En la tabla que lista todos los proyectos, añadiremos un nuevo campo con alertas que informen al administrador sobre los datos necesarios para que la información mostrada por la función estadística de la aplicación sea lo más completa posible.

Por último, paginaremos por fecha la tabla que muestra las tareas realizadas por los empleados y añadiremos un cuadro resumen que permita ver en el día seleccionado, las horas totales realizadas por cada uno.

1.3.3 Realizar un nuevo diseño gráfico

En esta última fase, nos centraremos en renovar todas las páginas de la aplicación mejorando el aspecto estético de las vistas. Primero, analizaremos diferentes páginas para ver qué diseños pueden ajustarse más a este tipo de herramienta. Más tarde, estudiaremos la forma en la que se puede modificar la estética y la tecnología que vamos a utilizar para ello. Luego, rediseñaremos la aplicación centrándonos en adaptar los colores del logotipo de la empresa a nuestra nueva interfaz. Sustituiremos el menú principal por otro más moderno e interactivo que permita en cada uno de sus diferentes apartados incluir iconos y añadir subcategorías y, por último, insertaremos un pie de página con información sobre la empresa y su logotipo. �


8

1.4 Gestión del trabajo fin de grado.

Para llevar a cabo las actividades y las tareas exigidas por el trabajo fin de grado, definiremos una serie de apartados con el fin de planificar, controlar y gestionar su desarrollo. Para planificar las tareas que lo componen, hemos tenido en cuenta la limitación de 300 horas correspondientes a los 12 créditos que ocupa dicho trabajo.

Para completar el TFG antes de la fecha en la que hay que hacer el depósito (22-24 junio), hemos dividido el tiempo de tal manera que dedicaremos 20 horas semanales con 4h diarias de lunes a viernes. La fecha de inicio será el lunes 15 de Febrero de 2016, mientras que la de finalización será el 2 de Junio de 2016. Hemos dejado un margen de 20 días por si fuesen necesarios debido a causas ajenas al proyecto que podrían suceder y afectar a la fecha de entrega del mismo. En cuanto al calendario hemos optado por dejar 5 días libres entre los días 21 y 25 de Marzo ambos inclusive, coincidiendo con la Semana Santa de este año.

Por otro lado, a la hora de desarrollar el proyecto, utilizaremos la metodología incremental ya que por sus características es la que mejor se adapta al mismo.

1.4.1 Estructura de descomposición del proyecto (EDP)

Antes de realizar cualquier tipo de estimación, necesitaremos conocer las diferentes tareas a realizar para poder completar con éxito el alcance definido en el capítulo 1. Con el fin de diferenciar y categorizar dichas tareas, a continuación en la Figura 1.1 podemos ver el EDP del trabajo fin de grado.

Figura 1.1 EDP del proyecto

1ReingenieríadelaaplicaciónwebTimetracker

1.1Direcciónygestióndelproyecto.

1.1.1Análisisgeneral

1.1.2Planificación

1.1.3Documentación

TFG

1.2Conocerla

estructuraylastecnologías

1.3.1Análisis

1.3.2Implementación

1.3.2Pruebas

1.3Implementación

denuevafuncionalidad

1.3.1Módulo

presupuestos

1.3.1.1Análisis

1.3.1.2Diseño

1.3.1.3Implementación

1.3.1.4Pruebas

1.3.2Módulo

estadísiticas

1.3.2.1Análisis

1.3.2.2Diseño


1.3.2.4Pruebas

1.3.3Mejorasenlausabilidad

1.3.3.1Análisis

1.3.3.2Diseño


1.3.3.4Pruebas

1.4Diseño

gráficodelaaplicación

1.4.1Análisisde

otraspáginas

1.4.2Diseñarlas

vistas

1.4.3Implementarlosdiseños

1.4.4Pruebas

1.5Redactar elmanualdeusuario


9

1.4.2 Descripción de las tareas

Para entender mejor la EDP, en las Tablas 1.1 y 1.2 podemos ver los códigos y los nombres de los paquetes de trabajo junto con la descripción de las tareas y las horas estimadas para completarlas.

Código Nombre Descripción h. Estimadas

1.1 Dirección y Gestión del proyecto

82 h.

1.1.1 Análisis general Estudiar y realizar un análisis inicial de las partes de la aplicación que el cliente desea mejorar para definir el alcance del proyecto. 16 h.

1.1.2 Planificación Definir el alcance, realizar una EDP, identificar las tareas a realizar, construir los diagramas de Gantt y de Hitos, decidir la manera en que nos vamos a comunicar con el tutor de la empresa y el tutor del TFG.

12 h.

1.1.3 Documentación memoria TFG

Documentar aquellos aspectos necesarios para facilitar la comprensión de las tareas y de los incrementos realizados en la aplicación durante las diferentes fases del desarrollo del proyecto, además de recoger el análisis general y la planificación del proyecto.

54 h.

1.2 Conocer la estructura y las tecnologías

30 h.

1.2.1 Análisis

Estudiar la estructura de la aplicación, ver en que métodos es necesario controlar posibles errores o excepciones que puedan ocurrir durante su ejecución. Comprobar su funcionamiento y apuntar/estudiar los posibles errores que pueden surgir durante esta tarea. Reproducir los errores comunicados por el cliente para estudiar su origen.

6 h.

1.2.2 Implementación Ofrecer una solución a todos los errores, tanto los que han sido comunicados por el cliente como los que hemos detectado durante el análisis.

22 h.

1.2.3 Pruebas Probar toda la funcionalidad que hayamos desarrollado y modificado para comprobar los resultados y confirmar que hemos solucionado los errores.

2 h.

1.3 Implementación de nueva funcionalidad

154 h.

1.3.1 Módulo presupuestos 22 h.

1.3.1.1 Análisis

Analizar dónde incluir la nueva funcionalidad. Tener una reunión con el cliente para que nos comunique qué campos le gustaría añadir dentro de este apartado y a ser posible refinar los requisitos inciales. Estudiar qué aspectos de la aplicación vamos a incluir y qué pasos vamos a realizar para ello.

2 h.

1.3.1.2 Diseño Diseñar la interfaz del apartado de presupuestos. Si el resultado del análisis confirma que es necesario incrementar la base datos, incluir los nuevos campos o tablas en ella.

2 h.

1.3.1.3 Implementación

Desarrollar la interfaz realizada en el diseño. Si es necesario modificar la base de datos, incluir toda la lógica necesaria para añadir/extraer toda la información de la misma. Añadir programación en frontend para que funcione dinámicamente.

16 h.

1.3.1.4 Pruebas Probar la nueva funcionalidad y comprobar que no hemos alterado la ya existente. 2 h.

Tabla 1.1 Diccionario de la EDP


10

Código Nombre Descripción h. Estimadas

1.3.2 Módulo estadísticas 72 h.

1.3.2.1 Análisis

Analizar dónde incluir la nueva funcionalidad. Tener una reunión con el cliente para que nos comunique qué le gustaría añadir dentro de este apartado. Estudiar qué aspectos de la aplicación vamos a modificar y qué pasos vamos a realizar para ello.

6 h.

1.3.2.2 Diseño

Diseñar las interfaces necesarias y modificar las ya existentes para mostrar la nueva información. Si como resultado del análisis es necesario modificar la base datos, incluir los nuevos campos o tablas en ella.

8 h.

1.3.2.3 Implementación

Implementar los diseños de la interfaces e incluir todos la lógica necesaria para extraer toda la información de las base de datos. Añadir programación en frontend para que funcione dinámicamente.

52 h.


1.3.3 Mejoras en la usabilidad 60 h.

1.3.3.1 Análisis Analizar dónde vamos a incluir la nueva funcionalidad. Estudiar qué aspectos de la aplicación vamos a cambiar y qué pasos vamos a realizar para modificarlos.

6 h.

1.3.3.2 Diseño

Diseñar las interfaces necesarias y modificar las ya existentes para mostrar la nueva información. Si como resultado del análisis es necesario modificar la base datos, incluir los nuevos campos o tablas en ella.

6 h.

1.3.3.3 Implementación Implementar los diseños de las interfaces e incluir toda la lógica necesaria para extraer toda la información de la base de datos. 44 h.


1.4 Diseño gráfico de la aplicación 28 h.

1.4.1 Análisis de otras páginas

Analizar otras páginas que muestren una cantidad considerable de información de características similares a nuestra aplicación. 4 h.

1.4.2 Diseñar las vistas

Modificar las interfaces de la aplicación basándonos en las plantillas ya existentes en nuestra aplicación. 6 h.

1.4.3 Implementar los diseños

Modificar las interfaces para que se asemejen a los bocetos planteados en el diseño. 16 h.

1.4.4 Pruebas Comprobar que la información mostrada por las interfaces antiguas sigue apareciendo en los nuevos diseños. 2 h.

1.5 Redactar el manual de usuario

Explicar y redactar los pasos necesarios para hacer uso de la funcionalidad desarrollada durante el proyecto. 8 h.

Tabla 1.2 Diccionario de la EDP

1.4.3 Diagrama de Gantt

Para visualizar el orden cronológico y el tiempo de dedicación previsto para cada paquete de trabajo, presentamos el diagrama de Gantt . En la Figura 1.2 de la página 12 vemos las tareas que realizaremos entre la primera y la octava semana del proyecto, mientras que en la Figura 1.3 de la página 13 , observamos aquellas que llevaremos a cabo entre la novena y la decimoquinta semana. También podemos ver el tiempo total de dedicación y la fecha final prevista para cada paquete de trabajo y tarea, así como el total de horas acumuladas para cada una de las semanas.


11

1.4.4 Diagrama de Hitos

En la Figura 1.4 de la página 14 aparece el diagrama de hitos dónde podemos visualizar las fechas en las que entregaremos los diferentes paquetes de la EDP, así como las reuniones que tendremos con el tutor de la empresa. También detallamos el inicio, fin y cierre del proyecto.

1.4.5 Seguimiento y control

Para gestionar los tiempos establecidos en la planificación, es imprescindible controlar el tiempo invertido en cada una de las tareas. Durante la realización del proyecto, la desviación entre el tiempo inicialmente planificado y el tiempo real necesario de una tarea puede ser notable. En este caso, tendríamos que tomar una decisión: recortar la calidad de dicha tarea o retrasar la realización de las tareas posteriores, recortando tiempo en otra tarea de menos importancia. Al finalizar cada tarea, compararemos las horas estimadas con las horas reales para así calcular las desviaciones de los tiempos. En caso de ser significativas, justificaremos los motivos.

1.4.6 Plan de comunicaciones

Durante la realización del proyecto, intentaremos mantener una comunicación semanal con el cliente. Dicha comunicación la llevaremos a cabo a través de los siguientes canales:

1. Correo electrónico: Utilizaremos la dirección de correo de Gmail que nos proporcionó el cliente al comenzar las prácticas.

2. Comunicación directa: Ya que el proyecto lo estamos realizando en las oficinas de la empresa, podemos mantener una comunicación fluida con el cliente.

Para el trato con el tutor del TFG, utilizaremos el correo de Outlook Office 365 proporcionado por la universidad y asociado a la CUASI. Intentaremos mantener una comunicación semanal en la que describiremos las últimas tareas.

1.4.7 Reuniones

Antes de comenzar con las tareas del proyecto, tendremos dos reuniones, una con el cliente y otra con el tutor del TFG. En la primera, recogeremos los requisitos que ha de tener la nueva aplicación e intentaremos conocer cómo quiere el cliente que la llevemos a cabo. En la segunda, obtendremos información sobre qué aspectos debemos tener en cuenta antes de empezar con la memoria del proyecto. Durante el desarrollo del TFG, antes de iniciar un nuevo incremento, nos reuniremos con el cliente para refinar sus requisitos. También realizaremos periódicamente diversas reuniones con el tutor del TFG para tratar diferentes aspectos del proyecto y la documentación del mismo.

1.4.8 Plan de calidad

Al finalizar cada paquete de trabajo, subiremos la aplicación al servidor de pruebas de la empresa para que el cliente pueda evaluar cada incremento. Antes de subir cualquier cambio, haremos las pruebas oportunas para comprobar que la aplicación funciona según lo previsto. Si el cliente da el visto bueno a la nueva funcionalidad, continuaremos con su documentación en la memoria del TFG. En caso contrario, se llevarán a cabo los mecanismos oportunos para mejorar los aspectos requeridos por el cliente. Hay que tener en cuenta que será complicado que esto ocurra, ya que habremos definido sus requisitos en las reuniones previas. En éstas, intentaremos hacer un esbozo tanto del diseño de la página como de la lógica a utilizar para introducir la nueva funcionalidad.


12

Figura 1.2 Diagrama de Gantt S1-S8


13

Figura 1.3 Diagrama de Gantt S9-S15


14

Figura 1.4 Diagrama de hitos


15

2 Etapa 1: Conocer la estructura y solucionar errores

En esta etapa, veremos cómo está estructurada la aplicación para estudiar si necesitaremos reorganizar las diferentes partes en las que está dividida. También comprobaremos su funcionalidad de forma exhaustiva para intentar encontrar posibles errores que han podido pasar desapercibidos para el cliente. Además, solucionaremos dos errores que fueron comunicados en la primera reunión reproduciéndolos y localizando su origen.

2.1 Adquirir conocimientos

Tras realizar un estudio de los ficheros, constatamos que no se había utilizado ninguna tecnología desconocida para nosotros. La mayoría de los conocimientos necesarios para modificar y desarrollar los nuevos apartados de la aplicación los hemos adquirido en el cuatrimestre anterior mientras realizábamos las prácticas en la empresa. También es cierto, que aún no dominamos al completo estas tecnologías (Laravel, Jquery, Bootstrap…) por lo que cada vez que realicemos un incremento, estudiaremos las posibilidades y las facilidades que estas nos ofrecen.

2.2 Estructura de la aplicación

Como hemos comentado en el apartado de tecnologías, la aplicación está desarrollada con Laravel. La versión utilizada es la 5.0 aunque actualmente existen dos versiones más modernas (5.1 LTS y 5.2). No podemos actualizar a ninguna de estas, ya que la versión de Php del servidor en el que se va a alojar la aplicación es la 5.5.3, y para utilizar estas nuevas versiones, es necesario tener instalada como mínimo la versión 5.5.9.

El patrón utilizado para desarrollar la aplicación es el MVC (Modelo Vista Controlador). Para localizar los ficheros correspondientes a cada una de las partes de dicho patrón, hemos inspeccionado la estructura de directorios. En la Figura 2.1, vemos que las vistas están contenidas en el directorio resources/views, los modelos se encuentran en el directorio app y los controladores dentro del mismo directorio en la carpeta http/Controlers.

Figura 2.1 Estructura de la aplicación


16

Estudiando los ficheros, observamos que algunas vistas contenían demasiado código ya que combinaban HTML con JavaScript. Para mejorar la lectura, mantenibilidad y limpieza del mismo, optamos por extraer todo el JavaScript de dichas vistas y almacenarlo en diferentes ficheros dentro del directorio con la siguiente ruta /timetracker/public/js/vistas.

Salvando esta minucia, verificamos que el patrón se había aplicado de manera correcta, pasando sin más dilación a la siguiente fase de esta etapa.

2.3 Localizar y solucionar errores

Para comenzar la última fase, hemos intentado recrear los errores que nos ha comunicado el cliente para así localizar su origen y ofrecer una solución a los mismos. Tras realizar la implementación para corregir dichos errores hemos pasado a estudiar exhaustivamente la funcionalidad existente.

Para facilitar la comprensión tanto de los errores descritos por el cliente como aquellos encontrados durante el análisis de la funcionalidad, presentamos las Tablas 2.1, 2.2 y 2.3 dónde explicaremos la localización, descripción y origen de cada error dentro de la implementación.

Errores descritos por el cliente

Error 1 Localización En la página Inicio/Home Descripción Situados en la página principal, habiendo seleccionado una fecha cualquiera que contenga

una fila en la que no se ha elegido ningún módulo: cambiamos de fecha para visualizar las tareas de otro día y volvemos a la fecha inicial. Observamos que en la fila anteriormente comentada el primer módulo de la lista está seleccionado y no debería estarlo.

Origen Fichero Home.js - Método mostrarTareasFecha(). Error 2 Localización En la página Inicio/Home Descripción Situados en la página principal con una fecha cualquiera seleccionada y cambiando cualquier

apartado de una o varias filas de las tareas realizadas ese día: tras pulsar el botón guardar, notamos que en vez de realizarse una modificación de las tareas existentes, se han agregado tantas filas como tareas han sido modificadas a las ya existentes.

Origen Controlador HomeController - Método guardar().

Tabla 2.1 Errores descritos por el cliente

Errores encontrados durante el análisis

Error 1 Localización En la página Crear proyecto. Descripción Cuando eliminamos un módulo existente del apartado "módulos", observamos que en la tabla

estimaciones dicho módulo no desaparece y debería hacerlo. Origen Fichero proyectoEdit.js - Método ConstructorFilaEstimaciónMódulo(). Error 2 Localización En la página Editar proyecto. Descripción Añadiendo un nuevo módulo, vemos que en la tabla estimaciones no aparece el nombre de

dicho módulo y debería crear una fila con su nombre para poder realizar una estimación. Continuando en esta vista, vemos que a la hora de agregar una nueva fila en el apartado módulos, los elementos que la componen no están maquetados de la misma manera que los elementos que contienen las filas de los módulos ya existentes.

Origen Falta implementación en fichero proyectoEdit.js .

Tabla 2.2 Errores encontrados durante el análisis


17

Errores encontrados durante el análisis

Error 3 Localización Durante el proceso renovación o cambio de contraseña de un usuario. Descripción Cuando el usuario pide renovar la contraseña, se envía un correo electrónico al usuario que

contiene un enlace que redirige a una página donde el usuario puede introducir una nueva contraseña. En dicha vista, se permite introducir el correo electrónico del usuario del cual se va a realizar el cambio de contraseña. Estamos ante un fallo grave de seguridad, ya que un usuario(empleado) puede introducir el email del administrador o de otro usuario, cambiarle la contraseña y visualizar o cambiar información a la que no debería tener acceso.

Origen Vista del cambio de contraseña. Error 4 Localización En la vista CrearProyectos y EditarProyectos. Descripción Cuando el usuario elimina un módulo utilizando el botón correspondiente en el apartado

“Módulos”, dicho módulo no desaparece de la tabla estimaciones. Origen Ficheros proyectoEdit.js y proyectoNew.js - Método eliminarFilaMódulo(). Error 5 Localización En la vista EditarProyectos, en el controlador ProyectosController y en el modelo

EstimaciónTarea. Descripción Cuando el usuario modifica las horas estimadas en la tabla correspondiente, dichas

estimaciones no se actualizan en la base de datos y como consecuencia tampoco se muestran en la vista EditarProyectos.

Origen Tres lugares: El código escrito en la vista EditarProyectos utilizado para mostrar las estimaciones no es el correcto. Falta código para tratar la actualización de las estimaciones dentro del controlador ProyectosController. El modelo EstimaciónTarea carece de un método para actualizar dicha información en la base de datos.

Error 6 Localización En la vista EditarProyectos, en el controlador ProyectosController y en el modelo

EstimaciónModulo. Descripción Cuando el usuario abre la vista editarProyectos no puede visualizar el nombre de los

módulos del proyecto, ni tampoco realizar ningún cambio en las horas estimadas para los mismos, ya que estás no se guardan correctamente en la base de datos.

Origen Falta implementación en proyectoEdit.js, en el controlador ProyectosController y en el módelo estimaciónMódulo.

Error 7 Localización En todos los controladores que contienen métodos que guardan datos en diferentes tablas

de la base de datos de la aplicación Descripción Cuando el usuario intenta guardar información a la hora de modificar o crear un proyecto

nuevo, hemos observado que dichas operaciones no se comportan como una transacción, es decir, las operaciones que se llevan a cabo antes de la parte del código que genera una excepción se completan y las que hay después de dicha parte no.

Origen Método guardar() y guardarEditado() en el controlador ProyectosController

Tabla 2.3 Errores encontrados durante el análisis

2.4 Implementación

En este apartado explicaremos como hemos solucionado un error que existía en la aplicación y que hemos considerado interesante comentar. Para facilitar la comprensión, utilizaremos partes de código extraídos del proyecto.

Precisamente en el error número 7, nos dimos cuenta que el proceso a la hora de guardar o editar un proyecto no se comportaba como una transacción.


18

En una de las pruebas que hicimos a la hora de insertar un nuevo proyecto en la aplicación dónde tuvo lugar una excepción, observamos que las estimaciones que habíamos realizado para las diferentes tareas del proyecto, no se habían almacenado en la base de datos. Es decir, notamos que algunas operaciones se completaban y otras no.

En el ejemplo de la , en el método que utilizamos para guardar un nuevo proyecto, vemos que existen cuatro métodos crearProyecto(), setEstimacionesTareas(), setModulos() y setEstimacionesModulos() que pertenecen a las clases Empresa y Proyecto. Dichos métodos realizan operaciones de inserción en la base de datos y en consecuencia, pueden generar una excepción.

Figura 2.2 Guardar un nuevo proyecto

Para conseguir que se lleven a cabo las cuatro operaciones como una sola, Laravel facilita el método estático transaction() perteneciente a la clase DB. Éste permite la agrupación de un conjunto de operaciones que han de realizarse como una transacción. Si por algún motivo tiene lugar una excepción en alguna de ellas, automáticamente deshace todas las operaciones que se han llevado a cabo con anterioridad (rollback) para más tarde informar de la excepción al usuario que está ejecutando la aplicación. A continuación en la Figura 2.3, vemos como queda el código anterior protegido con dicho método.

Figura 2.3 Guardar un nuevo proyecto usando transaction()


19

3 Etapa 2: Implementación de nueva funcionalidad

Hemos dividido en tres categorías la funcionalidad desarrollado durante este proyecto. En la primera explicaremos las diferentes fases realizadas para completar la herramienta que genera presupuestos para nuestro cliente. En la segunda, describiremos las operaciones llevadas a cabo para mejorar el apartado de estadísticas y, en la tercera, detallaremos los pasos completados para mejorar la usabilidad de la aplicación.

3.1 Módulo de presupuestos

Durante este apartado detallaremos el análisis, el diseño, la implementación y pruebas que hemos realizado para crear el módulo de la aplicación encargado de elaborar presupuestos para nuestro cliente.

3.1.1 Análisis

El cliente quiere que elaboremos una herramienta que le permita crear presupuestos para tres tipos diferentes de plataforma (WordPress, WooComerce y PrestaShop). Todos ellos contendrán una serie de características que definirán el coste y las horas necesarias para completar las partes del presupuesto. Para ello crearemos una página que realice una serie de preguntas, y en función de lo contestado por el director de proyectos, elaborará el presupuesto final desglosando el coste y las horas requeridas en cada una de sus partes. Seguidamente, mostramos las características que ha de tener un presupuesto realizado en nuestra aplicación.

• Nombre de la empresa y nombre del proyecto. • Tipo de plataforma. • Conocer si será necesario realizar un diseño. • Conocer si será necesario realizar el diseño de un logotipo. • Número de páginas. • Cantidad de idiomas. • Conocer si será necesario migrar posts de una plataforma anterior. • Conocer si será necesario crear un dominio, contratar hosting y emails. • Horas en tareas SEO. • Horas para cumplir la LOPD. • Horas de formación.

Si el cliente elige como tipo de plataforma WooComerce o PrestaShop, la aplicación deberá recoger información sobre:

• El número de categorías que va a contener. • El número de productos que se van a incluir. • Los métodos de pago que va a permitir la aplicación. • Conocer si será necesario generar una factura o no.

Además de lo anterior, recogeremos información sobre la compra de módulos adicionales que han podido ser ofrecidos o pedidos por la empresa a la cual se le va a realizar el presupuesto. También daremos la posibilidad de colocar un porcentaje de riesgo que variará dependiendo del conocimiento que se tenga para realizar el proyecto solicitado.

Para finalizar distinguiremos el tipo de cliente para el que estamos realizando el presupuesto. Existirán diez niveles para definir un cliente. El más bajo indicará un grado de detallismo normal, con conocimientos técnicos bajos. Por otro lado, el más alto indicará un cliente con un alto conocimiento técnico y un alto nivel de detallismo. Si el cliente es conocido, el director de proyectos puede afinar este parámetro modificando el


20

valor si un cliente tiene un grado de exigencia excesiva o si el número de interrupciones en un proyecto anterior por parte del cliente fue alto.

Después de que el director de proyectos haya completado todas las características del proyecto, la aplicación estimará la cantidad a presupuestar en euros, así como las horas que han de invertirse para llevar a cabo su realización en cada uno de sus partes. Éstas vienen definidas por una serie de fórmulas confidenciales que el cliente establecerá una vez haya acabado el proyecto.

Estas fórmulas contendrán unos parámetros iguales para todos los proyectos que concretaremos en un fichero de configuración para que el cliente pueda modificarlos si lo desea. A continuación, podemos ver la lista de de las partes del presupuesto acompañadas de los parámetros que intervienen para su cálculo:

• Análisis: analisisMin , analisisMax, analisisPorPagina y cantidadHoraAnálisis. • Diseño: diseñoMin, diseñoMax , diseñoPorPagina y cantidadHoraDiseño. • Instalación, plantillas y módulos: cantidadInstalacion , cantidadInstalaciónExtraIdiomas y

cantidadInstalaciónConfigExtraPorIidoma. • SEO: horasSeo y cantidadHoraSeo. • LOPD: horasLOPD y cantidadHoraLOPD. • Carga de contenido por idioma: horasCargarPagina y cantidadHoraCargaDeContenido. • Formación: FormaciónMin, FormaciónMax, CantidadHoraFormación. • Hosting: CantidadHoraAltaHosting. • Configuración: CantidadHoraConfiguración. • Beneficio: PorcentajeDeBeneficio.

Una vez calculado el presupuesto, lo guardaremos en la aplicación para que el director de proyectos pueda consultarlo más tarde. Para finalizar, haremos una página que mostrará el detalle del coste estimado para la empresa.

3.1.2 Diseño

Para poder incluir los presupuestos en la aplicación, crearemos dos nuevas tablas en la base de datos. La primera permitirá almacenar toda la información sobre los presupuestos realizados y la segunda guardará los datos de los módulos incluidos en dichos presupuestos. A continuación en la Figura 3.1 vemos las nuevas tablas junto con sus campos y tipos.

Para poder crear y modificar un presupuesto, crearemos una página con un formulario dónde incluiremos todas las características relativas al mismo y que hemos descrito en el análisis. En dicho formulario, cuándo el usuario modifique el tipo de plataforma, mostraremos u ocultaremos elementos dinámicamente que adapten la información a cumplimentar. Continuaremos diseñando una nueva página dónde visualizaremos la lista de presupuestos creados con la aplicación. Dicha página incluirá un tabla con los siguientes campos: Proyecto, Empresa/Cliente, Plataforma, Porcentaje de riesgo y Tipo de cliente. Además, al final de cada fila, añadiremos tres pequeñas imágenes que referenciarán a los métodos del controlador Presupuestos encargados de (1) mostrar la información ampliada de un presupuesto, (2) redirigir a la página de edición de un presupuesto y (3) eliminar un presupuesto.


21

Figura 3.1 Tablas presupuestos y modulos_presupuestos

Para ver los datos generados por la aplicación de un presupuesto determinado, crearemos una última página donde insertaremos dos tablas. La primera, reflejará los datos introducidos por el director de proyectos a la hora de crear el presupuesto. La segunda mostrará el coste y las horas de cada una de las partes en que está divido, así como el coste total y las horas necesarias para realizar el proyecto.

Luego crearemos un fichero de configuración donde agregaremos los parámetros y sus valores, que serán iguales para todos los proyectos.

3.1.3 Implementación

Hemos utilizado el sistema de migraciones que ofrece Laravel, para crear las tablas. Dichas migraciones funcionan como un control de versiones de la base de datos y facilitan sus modificaciones. Para crearlas, nos situamos con la terminal en el directorio raíz del proyecto y escribimos dos comandos asignando a cada migración un nombre que describa el contenido que va a tener. En la Figura 3.2 vemos el comando que ha generado la migración tabla presupuestos:

Figura 3.2 Tablas presupuestos y modulos_presupuestos

Seguidamente en la carpeta database/migrations se han creado dos ficheros php a los que Laravel ha agregado la fecha de creación a su nombre. A continuación en la Figura 3.3 de la página 22 vemos que el contenido del fichero para crear la tabla presupuestos está formado por los métodos up() y down() (se apoyan en la clase Schema para modificar la base de datos). En el primero vamos a incluir todas las directrices que nos proporciona la clase de ayuda Blueprint para crear las columnas de la tabla y asignarles sus tipos. En el segundo hemos colocado todos pasos necesarios para revertir los cambios introducidos en el método anterior.


22

Figura 3.3 Método up() migración create_table_presupuestos

A continuación en la Figura 3.4 vemos como ha quedado el método up() una vez introducidos todos sus campos. Además, hemos agregado la clave extranjera en la columna idempresa que apuntará a la columna id de la tabla Empresa.

Figura 3.4 Método up() migración create_table_presupuestos

A continuación, hemos vuelto a abrir la terminal para teclear el comando “php artisan migrate”. Éste, es el encargado de ejecutar el contenido de los métodos up() de las migraciones. Para finalizar, hemos accedido a PhpMyAdmin para verificar que se ha creado la tabla presupuestos correctamente.

Una vez terminado con las migraciones, nos hemos puesto con el fichero de configuración. En Laravel, todos los ficheros de configuración tienen la misma estructura: clase Php que devuelve un array (clave, valor). Estos están almacenados en la carpeta config, dónde hemos creado uno con nombre presupuestos.php. En la Figura 3.5 vemos parte del contenido de este fichero.


23

Figura 3.5 Parte del contenido del fichero de configuración prepuestos.php

Utilizaremos dichos parámetros en el modelo Presupuesto.php para calcular las diferentes partes que formarán el presupuesto. Para cada una de estas hemos creado dos métodos. El primero calculará el número de horas necesarias para realizar esa parte, mientras que el segundo calculará el coste económico que será utilizada para generar el coste total del presupuesto. A continuación, en la Figura 3.6 vemos el método que hemos creado para calcular el coste del análisis, así como la clase estática de ayuda Config proporcionada para acceder a los parámetros del fichero de configuración.

Figura 3.6 Método getCosteAnálisis()

Cambiando de tercio, para crear el formulario en las vistas presupuesto_new.blade.php y presupuesto_edit.blade.php hemos agregado el ServiceProvider Illuminate\Html\HtmlServiceProvider que nos proporciona la clase FormFacade y que es muy útil a la hora de construir formularios en HTML.

En la Figuras 3.7 y 3.8 vemos el código de las directrices que hemos utilizado para crear las etiquetas de abrir y cerrar el formulario, así como el HTML generado por las mismas.

Figura 3.7 Abrir y cerrar formulario con HtmlServiceProvider

Figura 3.8 Código generado por HtmlServiceProvider

3.1.4 Pruebas

Para realizar las pruebas vamos a incluir un nuevo presupuesto en la aplicación con nombre “NetbrainPrueba”. Primero, vamos a comprobar el correcto funcionamiento de las partes dinámicas del formulario y editaremos sus campos, agregando un nuevo módulo “ModernSlide” tal y como vemos en la Figura 3.9 de la siguiente página.


24

Figura 3.9 Elementos dinámicos página presupuesto_new

Seguidamente rellenamos y enviamos el formulario comprobando que dicho presupuesto se ha guardado en la base de datos. Para ello, hemos accedido a la página que lista todos los presupuestos de la aplicación (Figura 3.10) constatando este proceso.

Figura 3.10 Panel presupuestos

Para finalizar, accederemos a la página que muestra todo el detalle del presupuesto. En las Figuras 3.11 y 3.12, vemos las dos tablas que están incluidas en dicha páginas y que almacenan los datos introducidos en el formulario y los cálculos generados por la aplicación.

Figura 3.11 Tabla parámetros formulario


25

Figura 3.12 Tabla campos generados

3.2 Módulo estadísticas

A continuación detallaremos el análisis, el diseño, la implementación y las pruebas que hemos llevado a cabo para obtener y visualizar las estadísticas de los empleados y de los proyectos de la empresa.

3.2.1 Análisis

Comenzaremos este análisis describiendo los requisitos que ha de cumplir la página dedicada a los empleados. Continuaremos explicando que necesitaremos para mejorar las estadísticas de los proyectos y finalizaremos realizando un breve estudio de las diferentes librerías que existen para dibujar gráficos en una página web.

En la página dedicada a las estadísticas de los trabajadores tendremos la posibilidad de elegir el empleado del cuál queremos obtener información. Tras seleccionar uno de ellos, podremos visualizar dos tablas y cuatro gráficos. A continuación, describimos la información de cada una de las tablas.

1. En la primera, veremos todas las tareas realizadas por el empleado junto con el número de horas dedicadas a cada una de ellas.

2. La segunda mostrará el nombre de los proyectos en los que ha participado, junto con las horas invertidas en cada uno de ellos, así como su cuota sobre el total de horas trabajadas en ese proyecto.

En cuanto a los gráficos, los dos primeros irán ligados a la información mostrada en la segunda tabla, el tercero se asociará con la tabla tareas y el cuarto ampliará la información del segundo gráfico. A continuación, detallaremos los tipos de gráficos y la información que visualizaremos en cada uno de ellos:

1. El primero será un gráfico de sectores dónde cada uno de ellos representará el porcentaje de tiempo dedicado por el empleado en cada uno de los proyectos en los que ha participado.

2. El segundo será un diagrama de barras. En él, visualizaremos para cada proyecto dos segmentos. El primero mostrará el tiempo (en horas) invertido hasta ese momento en un proyecto por todos los participantes, y el segundo el tiempo completado por el empleado.

3. El tercero será similar al primero, pero en vez de dividir los sectores por proyectos los dividiremos por tareas.


26

4. El cuarto tendrá una estructura similar al segundo y será del mismo tipo. En él visualizaremos para cada proyecto una barra que ocupará el ancho total del gráfico. Dicha barra representará el tiempo dedicado a un proyecto por el empleado y se dividirá en sectores que reflejarán el tiempo dedicado a cada tarea.

Por otro lado, para que el administrador pueda ver la información de las tareas realizadas por un empleado en un proyecto, incluiremos un nuevo filtro dónde éste podrá seleccionar el proyecto entre aquellos en los que ha participado. En este caso, la información cambiará y mostraremos una tabla junto con dos gráficos.

En esta tabla, visualizaremos las tareas realizadas en el proyecto, junto con el número de horas realizadas por el empleado, comparado con el número de horas totales realizadas para cada una de ellas y el porcentaje completado por dicho empleado.

Utilizaremos dos tipos de gráficos, uno circular y otro de barras. El primero comparará el tiempo realizado por el empleado con el tiempo realizado por los compañeros. El segundo comparará el tiempo realizado por el empleado en una tarea con el tiempo total dedicado a cada una de ellas. Para ello dibujaremos dos barras por cada una de las tareas y se asemejará al segundo gráfico descrito para la información general de un empleado.

Continuando con las estadísticas, aunque cambiando de tercio, nos situamos en la página que crearemos para mostrar los datos sobre los proyectos. La estructura de esta página será similar a la anterior. En ella tendremos que seleccionar el proyecto del cuál queremos obtener la información y seguidamente la dividiremos en tres secciones:

1. Información general. 2. Información del progreso y del rendimiento. 3. Información de las tareas, de los módulos y de los empleados.

En la sección Información general, mostraremos una tabla con datos generales del proyecto, dónde incluiremos: el nombre, la descripción, el área, el tipo, la fecha de inicio, la fecha fin y el estado.

Para las dos secciones siguientes, cada una de las tablas que incorporaremos irán acompañadas de un gráfico que facilitará la lectura de los datos.

En la sección Información del progreso y del rendimiento, añadiremos una tabla que recogerá información de las horas y del rendimiento. Para las horas obtendremos las horas reales, las estimadas y la desviación que ha tenido lugar. Para el rendimiento mostraremos el presupuesto en euros y en horas, el coste de su desarrollo (mano de obra), los gastos y, por último, el beneficio obtenido en euros y el porcentaje que representa.

En la misma sección y acompañando a la tabla anterior, situaremos un gráfico de líneas dónde dividiremos el eje horizontal del mismo en las diferentes fechas laborables comprendidas entre la fecha de inicio y la fecha fin del proyecto. En el eje vertical colocaremos las horas, situando en su parte más alta las horas presupuestadas.

Cuando dibujemos el gráfico, la primera línea representará las horas realizadas en el proyecto hasta la fecha actual, mientras que la segunda línea, trazará el camino ideal que debería seguir el proyecto, dicho de otra manera, las horas que se deberían haber realizado para la fecha en la que se está realizando la consulta. Así, nuestro cliente podrá ver si el proyecto se está desarrollando según lo previsto (primera línea situada a la misma altura), mejor de lo previsto (primera línea situada por encima de la segunda línea) o peor de lo previsto (primera línea situada por debajo de la segunda línea).

Para terminar con las secciones, en información de las tareas, los módulos y empleados, construiremos tres tablas y tres gráficos de sectores. Las dos primeras tablas recogerán información de las tareas y de los módulos. En ambos casos mostrarán para cada tarea/módulo del proyecto, el nombre, las horas realizadas,


27

las horas estimadas y la desviación. Estas dos tablas irán acompañadas de dos gráficos que mostrarán el porcentaje de horas realizadas en cada una de las tareas y los módulos.

La tercera tabla mostrará información acerca de los empleados. Para cada empleado, visualizaremos el nombre, las horas realizadas y el porcentaje completado del total del proyecto. Ésta también irá acompañada de un gráfico de sectores dónde dibujaremos el porcentaje de las horas realizadas por cada empleado.

Para afinar las estadísticas y obtener información de mayor utilidad, las dos páginas (estadísticas/empleados y estadísticas/proyectos) deberán contener un filtro que consistirá en elegir un rango de fechas para acotar los resultados al período seleccionado. Así por ejemplo, conseguiremos visualizar a qué proyectos y tareas ha dedicado el tiempo un empleado en un período específico del año. Análogamente podremos ver el tiempo invertido en las tareas realizadas dentro de un proyecto durante este período.

Una vez finalizado con los requisitos del cliente, hemos realizado un estudio de las herramientas y librerías que nos ofrece el sector tecnológico en internet para dibujar gráficos.

Tras estudiar las múltiples alternativas, hemos elegido los gráficos más visuales y que además no tienen coste alguno. Los compararemos y nos quedaremos con el que consideramos se adapte mejor a nuestras necesidades. Para realizar el estudio hemos tenido en cuenta los siguientes aspectos: documentación, mantenibilidad, facilidad de uso y apariencia.

Librería Documentación Facilidad de uso Mantenibilidad Apariencia Google Charts 10/10 9/10 10/10 8/10 Chart.js 8/10 8/10 7/10 7/10 Ember.js 8/10 - 8/10 7/10 uvCharts.js 7/10 9/10 9/10 9/10

Tabla 3.1 Comparativa APIs de Gráficos Web.

Como resultado de este pequeño estudio y tras mantener una breve conversación con el cliente, hemos decido utilizar los gráficos de Google Charts por las siguientes razones:

1. La documentación para incluir gráficos es excelente, además de ser la que más ejemplos ofrece en su página web.

2. Las opciones que provee para manipular y adaptar los gráficos a las necesidades del cliente son numerosas.

3. Es Google la empresa que se encuentra detrás de la librería de los gráficos, por lo tanto apenas existe la posibilidad de que abandonen la mejora y mantenimiento de la misma.

4. La apariencia es buena y del gusto de nuestro cliente.

El único contra que tiene Google Charts, es que necesitamos disponer de una conexión a internet para poder dibujar los gráficos. Dado que la aplicación únicamente va a utilizarse en las instalaciones de la empresa dónde siempre existe una conexión a internet (a no ser que se produzca un fallo en la red externa), no se ha tenido en cuenta este detalle.


28

3.2.2 Diseño

Para tratar las diferentes peticiones que generará la aplicación cuando el cliente modifique los filtros utilizaremos AJAX (Asynchronous JavaScript And XML), así conseguiremos obtener la información necesaria sin interferir con la visualización ni el comportamiento de la página.

Tras estudiar las peticiones del cliente y consultarle como le gustaría interactuar con la aplicación, hemos decidido que el siguiente diseño es el que más se ajusta a sus preferencias. En la Figura 3.13, podemos ver el diseño que tendrá la interfaz para ver las estadísticas acerca de un empleado.

En la parte superior del panel encontramos los selectores que el administrador puede combinar para obtener una información u otra. En el primero, aparecerán todos los empleados que están trabajando en la empresa, en el segundo, colocaremos dos “DatePicker” para que el usuario pueda seleccionar un rango de fechas y, en el tercero, presentaremos los proyectos en los que ha participado un empleado. Si no hay ningún empleado seleccionado, el selector de proyectos estará vacío.

En la parte inferior hemos colocado un contenedor dónde se mostrará la información que haya seleccionado el administrador. Cuando éste escoja un empleado y no seleccione un proyecto en particular, la información que mostraremos en dicho contenedor estará compuesta por dos tablas y cuatro gráficas, tal y como hemos descrito en el apartado del análisis. La disposición de los elementos la podemos ver en la Figura 3.14.

Si el administrador selecciona un proyecto en particular, la información que mostrará el contenedor estará compuesta por una tabla y dos gráficas. Por lo tanto, la apariencia del contenedor variará, sustituyendo los elementos que aparecían en el contendor anterior por unos nuevos, tal y como podemos ver en la Figura 3.15. Para que el administrador, pueda recuperar la vista anterior, colocaremos un botón que acompañe al filtro de proyectos y que permita reestablecer el valor del selector a nulo. De esta manera dispararemos un nuevo evento que apuntará al método dónde estará situado el código para realizar una nueva petición AJAX.

Figura 3.13 Diseño interfaz EstadisticasEmpleados


29

Figura 3.14 Diseño del contenedor(sin proyecto)

Figura 3.15 Diseño del contenedor(Con Proyecto)

Continuando con las estadísticas pero cambiando de página, en la Figura 3.16 vemos que la interfaz que utilizaremos para mostrar las estadísticas de los proyectos es similar a la utilizada en las estadísticas de los empleados.


30

Figura 3.16 Estadísticas empleados

En la parte superior de la página estarán los selectores de información dónde tendremos la posibilidad de elegir el proyecto del cuál queremos obtener la información, y si el administrador desea acotar los resultados a un rango de fechas, también ofreceremos dicha posibilidad.

En la parte inferior podremos visualizar la información que se ajusta a la selección realizada por el administrador como hemos descrito anteriormente en el apartado del análisis. Tal y como podemos ver en la Figura 3.17, quedará dividida en tres secciones:

1. La primera estará situada en la parte superior, recogerá la información general del proyecto y ocupará la anchura total del contenedor.

2. La segunda estará dividida por la mitad, en su parte izquierda situaremos la tabla que dedicaremos a mostrar la información acerca del progreso (Horas) y del rendimiento (Gastos y beneficio). En la parte derecha dibujaremos un gráfico de líneas dónde veremos a primera vista el progreso real e ideal del proyecto.

3. La tercera y última sección tendrá el mismo formato que la segunda. A la izquierda colocaremos las tablas que recogen la información sobre las tareas, los módulos y los empleados y a la derecha de cada una de ellas, un gráfico de sectores dónde podremos visualizar la información contenida en dichas tablas.

Nota: Las características de las tablas y de los gráficos ya las hemos descrito en el apartado del análisis.


31

Figura 3.17 Contenedor proyectos

3.2.3 Implementación

Como hemos comentado durante el diseño, hemos utilizado AJAX para obtener la información que el usuario necesita del servidor. En la página de estadísticas para los empleados, hemos construido un método que interpreta cuándo ha de recoger información del servidor, dependiendo de los valores de los filtros elegidos por el usuario. Cómo son varios los eventos que referencian a este método, hay que analizar las diferentes combinaciones que pueden producirse en los valores de los filtros para saber si es necesario llevar a cabo una petición.

Tal y como podemos ver en la Figura 3.18 de la página 32, las llamadas al servidor únicamente tienen lugar cuando la fecha inicio y la fecha fin del rango tienen valor o ambas son nulas. Las otras dos combinaciones (sólo una de las dos con valor), significarán que el usuario está eligiendo un rango de fechas y por lo tanto, habrá que esperar a que el usuario complete ambos campos para enviar la petición.


32

Figura 3.18 Función obtenerEstadisticasEmpleado

Una vez que hayamos analizado y comprobado toda la información obtenida de los valores de los filtros, estaremos preparados para enviar la solicitud al servidor. En la figura anterior observamos que en el envío de datos añadimos un string “_token” que variará para cada acción diferente realizada dentro de la aplicación y que previene contra ataques CSRF (Cross Site Request Forgery). Dichos tokens son generados aleatoriamente en el servidor y son guardados en la sesión del usuario, para en una futura petición, reenviar dicho token al servidor, compararlo y asegurar que la persona que está pidiendo la información tiene autorización.

Una vez enviados los datos, la información llegará a la función getEstadísticasTrabajador() (Figura 3.19) situada en el controlador EstadisticasController y la analizará para saber cuál de las dos funciones auxiliares habrá que utilizar: estadisticasGeneralesEmpleado() o estadisticasEmpleadoProyecto().

Figura 3.19 Función getEstadísticasTrabajador()

Dichas funciones son las encargadas de llamar a los diferentes métodos de los modelos que extraen la información de la base de datos para que el controlador la organice y la envíe a la vista. Por ejemplo, en la función estadisticasEmpleadoProyecto() de la Figura 3.20, vemos que es necesario utilizar cuatro funciones para obtener la información las cuáles variarán si el administrador ha insertado un rango de fechas o no. Estas las podemos localizar en las clases Proyecto.php y Trabajador.php.


33

Figura 3.20 Función estadisticasEmpleadoProyecto

Para acceder y extraer la información en los modelos, hemos utilizado Eloquent ORM que nos proporciona una sintaxis sencilla e intuitiva para realizar consultas. A continuación en la Figura 3.21 vemos un ejemplo de dicha sintaxis en la función getTareasHorasRealizadasEntreFechas() .

Figura 3.21 Función getTareasHorasRealizadasEntreFechas

Por otro lado, en las comunicaciones con AJAX, la respuesta del servidor siempre devolverá un objeto String en formato JSON que construiremos mediante un array que contendrá toda la información.

En la petición realizada en la Figura 3.18 de la página 30, una vez recibido el JSON la función callback de AJAX comprobará el objeto mostrarPlantillaProyecto contenido dentro de la misma. Si el valor de dicho objeto es “No” pasará la información a la función mostrarEstadisticasEmpleado(). Por el contrario, si es “Si”, el flujo de trabajo acabará en la función mostrarEstadisticasEmpleadoEnProyecto() . Ambas funciones tendrán como finalidad mostrar los datos en las diferentes plantillas que existen para los dos casos descritos anteriormente en el análisis y representados en el diseño.

Por otro lado, observamos que la función obtenerEstadisitcasEmpleado() que realiza la petición AJAX, recibe como parámetro un booleano con nombre eliminarIdProyecto. Dicho booleano sólo se utiliza para saber si la página ha de recuperar su formato/plantilla inicial. Esto lo conseguimos gracias a que hemos colocado un botón que permite reestablecer los valores iniciales del filtro proyecto, y que el administrador podrá utilizar para recuperar la visualización de las estadísticas generales en el caso de haber estado viendo las estadísticas de un empleado en un cierto proyecto. Para ello, el evento onclick de dicho botón, hará una llamada a la función de la Figura 3.22 pasándole el valor “true” como parámetro.


34

Figura 3.22 Función recuperarEstadoInicial

3.2.4 Pruebas

Durante las pruebas, y debido a la gran cantidad de información que había en la base de datos sobre los diferentes proyectos llevados a cabo en la empresa, nos dimos cuenta de que cuando realizábamos una consulta para visualizar las estadísticas de un cierto empleado, si el número de proyectos en los que había participado era alto, existía demasiada información que complicaba la lectura tanto en la tabla 2 como en los gráficos 2 y 4. Por ello, decidimos paginar una parte de la vista para que el usuario pudiera visualizar las estadísticas cómodamente.

Dividimos los proyectos en grupos de 5 e introdujimos en la página los mecanismos necesarios para avanzar y retroceder entre los diferentes grupos. En la Figura 3.23 vemos un ejemplo del funcionamiento descrito anteriormente. En ella, tras haber seleccionado un empleado, sabemos gracias al número de secciones en las que ha quedado dividida parte de la página, que ha participado en 30-35 proyectos. En la parte izquierda de la figura, vemos el primer grupo de 5 proyectos en los que ha trabajado, mientras que en la parte derecha, tras haber utilizado los botones colocados para desplazarnos entre los diferentes proyectos, podemos ver el cuarto grupo.

Figura 3.23 Navegación entre proyectos


35

Por otro lado, en la página desarrollada para mostrar las estadísticas de los proyectos, notamos que era más cómodo mostrar el tiempo total realizado, el tiempo total estimado y la desviación entre estos dos últimos en las tablas que habíamos diseñado para mostrar las horas de las tareas, módulos y empleados. Cuándo consultamos la información de un proyecto y no aplicamos el filtro de fechas, dichos valores carecen de importancia ya que están contenidos dentro de la tabla rendimiento- Sin embargo, si insertamos un par de fechas nos damos cuenta de que es de gran utilidad colocar la información de los tiempos y la desviación en el periodo seleccionado, ya que la tabla dedicada al rendimiento no se ve afectada por dicho filtro. A continuación en la Figura 3.24, podemos ver un ejemplo de las tablas que hemos comentado con la suma de las horas reales y estimadas, así como la desviación que existe entre ambas.

Figura 3.24 Tiempos totales


36

3.3 Mejorar la usabilidad

Para describir las mejoras que hemos realizado en la usabilidad, detallaremos el análisis, el diseño, la implementación y las pruebas para de cada una de las funcionalidades a mejorar.

3.3.1 Implementar una página de error

Análisis

En la actualidad Timetracker carece de una página de error. Por ello, crearemos una a la que el usuario será redirigido en caso de ocurrir cualquier tipo de fallo. Dicha página debe incluir una breve explicación sobre el error que ha tenido lugar dentro de la aplicación.

A continuación en la Tabla 3.2 podemos ver una lista de errores http que trataremos en la aplicación:

Código Consecuencia 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 500 Internal Server Error

Tabla 3.2 Errores HTTP

Además la vista dispondrá de los mecanismos necesarios para poder volver a la página principal de la aplicación.

Diseño

Tras estudiar la forma adecuada de tratar los errores HTTP en Laravel, hemos visto que el framework nos proporciona una carpeta (errors) dónde deberemos crear una vista para cada tipo de error que queramos cubrir en la aplicación. Como la página que nosotros crearemos para los errores será idéntica para los diferentes casos, incluiremos una plantilla dentro de la carpeta partials y la invocaremos desde las diferentes vistas, cuya única diferencia será el código y el mensaje que mostraremos. En la Tabla 3.3 podemos ver los diferentes mensajes que colocaremos para los diferentes errores que vamos a tratar.

Errores Código Mensaje

400 Ha ocurrido un error, por favor compruebe su petición. 401 No tiene autorización para acceder a esta página. 403 Por favor, vuelva a iniciar sesión. 404 La página a la que está intentando acceder no existe. 500 Error de aplicación.

Tabla 3.3 Mensajes de error

A continuación en la Figura 3.25 vemos cómo quedará la vista dónde insertaremos los diferentes códigos con sus mensajes correspondientes. Además, para que el usuario pueda salir de la página de error colocaremos un botón y volver a la página de inicio.

Figura 3.25 Vista de la página de error.


37

Implementación

Para modificar las excepciones y la página de error que viene por defecto en Laravel, modificamos el método render() incluido en la clase Handler.php situado en la carpeta Exceptions.

Utilizando la función de ayuda isHttpException() para saber si es una excepción HTTP, llamamos a un nueva función que hemos creado en la misma clase donde determinaremos si ha tenido lugar uno de los errores contemplados en el análisis. En la Figura 3.26, podemos ver cómo era el método render(), mientras que en la Figura 3.27, vemos el resultado una vez modificado.

Figura 3.26 Método render() anterior en Handler.php

Figura 3.27 Nuevo método render() en Handler.php

A continuación en la Figura 3.28, visualizamos el método creado para redireccionar a las páginas de error en caso de producirse las excepciones http asociadas a los errores 400, 401, 403, 404 y 500. Obtenemos el código de error gracias al método getStatusCode() y seguidamente comprobamos si dicho código se corresponde con alguna de las páginas creadas para los errores web. Esta comprobación la realizamos con la función exists() perteneciente a la clase View. Si la vista existe, el mensaje y el código serán enviados para que ésta los muestre al usuario.

Figura 3.28 Método renderHttpException() en Handler.php

Pruebas

Mostramos el resultado obtenido al intentar acceder a la url /timetracker/public/clientes que no existe en nuestra aplicación. Cómo podemos ver en la Figura 3.29 tiene lugar un error 404 y el panel contenido dentro


38

de la página muestra la plantilla que hemos creado para mostrar el código de error y una breve descripción de dicho error.

Figura 3.29 Página de error 404

3.3.2 Mejorar la recolección de datos en la página Home

Análisis

En la página Home/Inicio de la aplicación renovaremos la interfaz encargada de recoger los datos. Dicha vista está divida en una serie de filas. Cada una de ellas se completa por un empleado con los datos de una de las actividades desarrolladas durante un día laboral. En este momento, la aplicación no sabe distinguir entre dos filas que contienen la misma información, es decir, cada fila contiene un proyecto, un módulo (opcional), una tarea (Análisis, diseño, programación...) y unas horas.

Si un usuario introduce dos filas en las que el proyecto, el módulo y la tarea son iguales, la aplicación sólo guardará en la base de datos las horas de la última fila introducida. Por lo tanto, habilitaremos una función que confirme si hay que sumar o no las horas de las tareas repetidas o eliminar la última tarea ya que ha podido ser introducida por error.

Diseño

Cuando un empleado introduzca dos filas con un mismo nombre de proyecto, módulo y tarea, la herramienta mostrará un “PopUp” para permitirle tomar una decisión. Este proceso conllevará una función en JavaScript que recorra y analice los datos de las filas de las tareas en varias fases. Si como resultado de este análisis, se detectan dos filas con la misma información, utilizaremos dicho “PopUp”. Para entender mejor este proceso, utilizaremos el siguiente ejemplo práctico:

Nº Fila (Índice) Proyecto Módulo Tarea Horas 1 Red Social Página de inicio Análisis 2 2 Tienda Virtual Pagos Implementación 1 3 Red Social Página de inicio Análisis 2 4 Casa de apuestas - Diseño 0.5 5 Tienda Virtual Ayuda Pruebas 0.5 6 Casa de Apuestas - Diseño 1 7 Tienda Virtual Ayuda Análisis 1 8 - - - -

Para comenzar, en la primera fase, comprobaremos qué filas no están vacías y guardaremos sus índices. En el ejemplo, como resultado obtendríamos ([1,2,3,4,5,6,7]). A continuación, comprobaremos qué filas de las anteriores contienen el mismo identificador de proyecto y volveremos a guardar sus índices. Como puede darse el caso de que existan distintos grupos de filas iguales, los agruparemos para analizarlos en las siguientes fases por separado. Resultado:


39

Nº Fila (Índice) Proyecto Módulo Tarea Horas 1 Red Social Página de inicio Análisis 2 2 Tienda Virtual Pagos Implementación 1.5 3 Red Social Página de inicio Análisis 2 4 Casa de apuestas - Diseño 0.5 5 Tienda Virtual Ayuda Pruebas 0.5 6 Casa de Apuestas Estadísticas Diseño 1.5 7 Tienda Virtual Ayuda Implementación 1

Nº Grupo Índices 0 [1,3] 1 [2,5,7] 2 [4,6]

En la segunda fase, compararemos todos los índices de las tareas que de un mismo grupo. Utilizando el ejemplo, el resultado sería el siguiente:

Nº Fila (Índice) Proyecto Módulo Tarea Horas 1 Red Social Página de inicio Análisis 2 3 Red Social Página de inicio Análisis 2

Nº Fila (Índice) Proyecto Módulo Tarea Horas 2 Tienda Virtual Pagos Implementación 1.5 5 Tienda Virtual Ayuda Pruebas 0.5 7 Tienda Virtual Ayuda Implementación 1

Nº Fila (Índice) Proyecto Módulo Tarea Horas 4 Casa de apuestas - Diseño 0.5 6 Casa de Apuestas Estadísticas Diseño 1.5

Nº Grupo Índices 0 [1,3] 1 [2,7] 2 [4,6]

En la tercera y última fase, para cada grupo, comprobaremos qué índices contienen y no contienen módulo y los separaremos. Continuando con el ejemplo:

Nº Grupo Índices Nº Grupo Índices Nº Grupo Índices 0 [1,3] 1 [2,7] 2 [4,6]

Con Módulo [1,3] Con Módulo [2,7] Con Módulo [6] Sin Módulo - Sin Módulo - Sin Módulo [4]

Para el grupo 0 y el grupo 1, hemos obtenido resultados similares, dos índices para las filas que contienen módulo. Sin embargo, para el grupo 2, sólo ha quedado un índice tanto en el grupo con módulo como en el grupo sin módulo. Cómo el tamaño de ambos no es superior a 1, ya habríamos acabado con la comparación para el grupo 2. Sin embargo en el grupo 0 y en el grupo 1 aún queda una última comparación por hacer. Si el identificador de los módulos es el mismo, entonces tendremos que guardar el índice de las filas para preguntarle al usuario qué es lo que quiere hacer con ellas.

Nº Fila (Índice) Proyecto Módulo Tarea Horas 1 Red Social Página de inicio Análisis 2 3 Red Social Página de inicio Análisis 2


40

Nº Fila (Índice) Proyecto Módulo Tarea Horas 2 Tienda Virtual Pagos Implementación 1.5 7 Tienda Virtual Ayuda Implementación 1

En la última comparación, nos quedaremos con el grupo 0 ya que los módulos de las filas 1 y 3 son iguales.

Grupo Filas iguales Índices 0 [1,3]

Seguidamente el usuario tendrá que decidir si sumar las horas de las filas o deshacerse de una de las dos. En ambos casos la fila 3 quedaría vacía en la pantalla de inicio y las tareas estarían listas para ser enviadas al servidor sin generar conflicto alguno.

Para sumar o eliminar filas, hemos diseñado el pop-up de la Figura 3.30. En él colocaremos dos botones que permitan realizar estas acciones.

Figura 3.30 Diseño del PopUp

Si el usuario pulsa en eliminar, en la pantalla de inicio todas las filas del conjunto excepto la primera quedarán vacías listas para ser utilizadas de nuevo. Por otro lado, si el usuario pulsa en el botón sumar, modificaremos el input horas en la fila situada en la página de inicio correspondiente a la primera fila del conjunto colocando la suma de todas las horas.

Implementación

Para llevar a cabo la eliminación o suma de filas duplicadas en la página de inicio de la aplicación, se han realizado las siguientes acciones:

1. Hemos creado una ventana modal en HTML y la hemos guardado en la carpeta “partials”. Dicha carpeta está destinada a contener aquellas porciones de HTML preparadas para ser insertadas en vistas. Cuando cargamos la vista, la ventana modal está oculta por defecto. A continuación en la Figura 3.31 podemos ver como es el HTML creado para la ventana modal.

Figura 3.31 HTML Ventana Modal


41

2. Hemos añadido una llamada a la función comprobarTareasIguales() en el evento “onclick” del botón guardar. Dicha función tiene como finalidad la búsqueda de filas con un mismo proyecto, módulo y tarea en la pantalla de inicio de la aplicación. Si encuentra duplicidades, llama a la función muestraPopUp(), de la Figura 3.32, que incorpora el título y la descripción necesaria dentro de la ventana modal, para más tarde insertar en el cuerpo de ella aquellos conjuntos de filas iguales que haya detectado. Luego mediante Jquery cambiamos la propiedad “display” del div padre de dicha ventana para que el usuario pueda visualizarla y, gracias al CSS incluido en personal.css, oscurecemos el resto de la pantalla para atraer la atención.

Figura 3.32 Función muestraPopUp

3. Hemos incorporado dos botones (sumar filas y eliminar duplicados) que en ambos casos eliminan las filas duplicadas, con lo cual ambas acciones acaban en un método que hemos diseñado para este propósito. Si el usuario pulsa en el botón sumar (función sumarHorasConflicto()), colocará en la primera fila del conjunto de duplicados situado en la pantalla de inicio la suma de todas las horas de dicho conjunto. Si por el contrario, pulsa en el botón eliminar duplicados (función eliminarDuplicados()), guardará la primera fila del conjunto y vaciará todos los inputs de las filas repetidas en la pantalla de inicio (función vaciarInputsFilaHome()). Para añadir los eventos necesarios en los botones comentados anteriormente hemos creado la función colocaEventosPopUp() cuyo código lo podemos ver en la Figura 3.33.

Figura 3.33 Función colocaEventos()

3.3.3 Visualizar los datos guardados en la página Home

Análisis

Existe otra funcionalidad a mejorar en la vista Home/Inicio. Actualmente podemos visualizar las tareas guardadas de una fecha usando el selector de “fecha” (ver Figura 3.34). Cuando seleccionamos una fecha diferente a la actual y modificamos alguno de los datos de las tareas mostradas para esa fecha, tras guardar, no nos permite visualizar dicho cambio, ya que de nuevo nos muestra las filas de la fecha actual. Por ello, cambiaremos la funcionalidad para que el usuario pueda visualizar los cambios correspondientes a la fecha para la que ha realizado modificaciones. Añadiremos el código necesario en el servidor para que se envíen las tareas que corresponden a la fecha en la que se efectuaron las modificaciones.


42


Diseño

Modificaremos la ruta que invoca al método index() del controlador HomeController.php para que pueda aceptar una fecha como parámetro. Seguidamente tendremos que cambiar la lógica existente en este método para que analice el contenido de dicho parámetro y actúe de manera diferente dependiendo del formato del mismo. Existen tres posibles vías a tratar:

1. Si el parámetro es nulo, obtendremos la fecha actual para posteriormente llamar al método obtenerTareasFecha($fecha) situado en el modelo Trabajador.php.

2. Si hay parámetro y la fecha es válida, llamaremos al método del primer punto con la fecha recibida. 3. Si hay parámetro pero la aplicación no es capaz de convertirlo a una fecha válida, redirigiremos al

usuario a la página de error 404. Este error sólo puede ocurrir si el usuario trata de manipular la url en el navegador.

Implementación

Hemos modificado la ruta que invoca al método index() del controlador HomeController.php para que opcionalmente pueda aceptar un parámetro. Este proceso comprende los siguientes pasos:

1. Hemos accedido al fichero routes.php para modificar la ruta. Como se puede ver en la Figura 3.35, Laravel permite indicar que un parámetro es opcional en una ruta simplemente añadiendo el signo “?” al final de su nombre:


2. Seguidamente hemos modificado el controlador para que pueda aceptar o no un parámetro. En la Figura 3.36 utilizamos la función strtotime de Php para comprobar si es posible convertir el parámetro a una fecha válida que entienda nuestra aplicación. Si el parámetro no es una fecha


43

válida, lanzaremos un error 404 informándole al usuario de que la página a la que está intentando acceder no existe.

Figura 3.36 Función index() HomeController

Pruebas

En la pantalla Home, nos percatamos de que existía un movimiento no deseado en la página cuando mostrábamos la ventana modal. El body de la página se desplazaba hacia la derecha, ya que cuando mostrábamos dicha ventana la barra de desplazamiento desaparecía. Para solucionar este problema, incluimos el CSS que podemos ver en la Figura 3.37.

Figura 3.37 CSS arreglo body

Realizando una serie de comprobaciones nuevas durante la implementación, solucionamos otro error que permitía la inclusión de conjuntos de filas vacíos dentro de la ventana modal. Este error únicamente aparecía cuando en la pantalla de inicio había dos filas iguales pero con distinto módulo. En la Figura 3.38 podemos visualizar dicho error.

Figura 3.38 Ventana modal con error


44

3.3.4 Insertar nueva información en la página Home

Análisis

Ampliaremos la información en la página Home para que los empleados puedan comparar las horas estimadas con las horas reales invertidas para cada proyecto, y ver la diferencia resultante. También ha pedido que agreguemos algún tipo de indicación para que los trabajadores vean el progreso de cada proyecto. Para realizar este cambio, tendremos que modificar el código en el controlador “HomeController” y en él, obtener la información de dichas estimaciones. Finalizaremos añadiendo tres nuevos inputs por cada fila dónde colocaremos esta información. Para que el trabajador tenga conocimiento de cómo va el desarrollo del proyecto, distinguiremos las siguientes situaciones:

1. Si el progreso del proyecto es inferior al 90%. 2. Si el progreso del proyecto está entre el 90% y el 100%. 3. Si las horas invertidas en el proyecto han superado las horas presupuestadas.

Diseño

En la Figura 3.39 vemos el diseño actual de una fila.

Figura 3.39 Diseño actual de una fila

Para añadir los nuevos campos descritos en el análisis, necesitaremos ampliar la anchura del panel y añadir tres nuevos input HTML para que puedan almacenar las horas estimadas, las horas realizadas y la diferencia de las mismas. Además para indicar el progreso del proyecto, incluiremos al final de cada fila un Glyphicon proporcionado por BootStrap. Una vez efectuados estos cambios, el resultado será el de la Figura 3.40.

Figura 3.40 Nuevo diseño de una fila

A continuación en la siguiente tabla veremos los diferentes glyphicons que mostraremos dependiendo del progreso del proyecto (P).

Progreso del proyecto Nombre del Glyphicon Apariencia P < 90% glyphicon-thumbs-up

90% < P < 100% glyphicon-hand-left P > 100% glyphicon-thumbs-down

Tabla 3.4 Glyphicons

Actualmente existe una petición AJAX para mostrar los módulos del proyecto seleccionado. Por lo tanto, utilizaremos dicha petición para recoger en el servidor la información necesaria para mostrar las estimaciones y su progreso.

Implementación

Para añadir la información descrita en el análisis y basándonos en el diseño, hemos incluido tres nuevos input deshabilitados. Para no confundir al usuario cuando tenga que introducir nuevas tareas, mediante css hemos decidido pintarlos de otro color tal y como se puede ver en la Figura 3.40 anterior.

Por otro lado, para conseguir los tiempos realizados, estimados y la diferencia que hemos de colocar en los inputs comentados en el párrafo anterior, hemos añadido el método obtenerEstimacionesTareas() dentro del controlador HomeController.php.


45

Cuando el usuario decide cambiar o seleccionar un nuevo proyecto en algunas de las filas de la pantalla de inicio, hemos de mostrar las estimaciones del mismo. Para ello, hemos creado la función obtenerEstimacionesProyecto() que realiza una llamada AJAX para obtener los valores de dichas estimaciones. A continuación en la Figura 3.41, vemos la función “callback” de dicha llamada. En ella observamos como cambiamos la información de los diferentes inputs además de eliminar el glyphicon de la fila que contenía la información del proyecto anterior (en caso de existir). A continuación, hará los cálculos necesarios y elegirá cuál de los glyphicons ha de dibujar.

Figura 3.41 Función mostrarEstimacionesProyecto()

Pruebas

Observamos dos errores que solucionamos modificando parte de la implementación. El primero ocurría al seleccionar un nuevo proyecto en una fila en la que habíamos seleccionado uno previamente, el glyphicon del proyecto anterior no desaparecía, es decir, el del nuevo proyecto se sobreponía sobre el antiguo. Para solucionar este error, añadimos dos líneas de código con las que conseguimos antes de dibujar el glyphicon nuevo, borrar el glyphicon ya existente. A continuación en la Figura 3.42, podemos ver un ejemplo del error. La solución a este error, la encontramos en el primer if de la función contenida en la Figura 3.41 anterior.

Figura 3.42 Error Glyphicons

Por otro lado, también observamos que para aquellos proyectos en los que no existía una estimación de las horas presupuestadas, no debíamos mostrar la diferencia existente ya que iba a ser siempre negativa. Por lo tanto, decidimos dejar el 0 en el input que muestra la diferencia, además de no dibujar ningún glyphicon. La solución a este error está en la comprobación que realizamos en el segundo if de la función contenida en la Figura 3.41. En la Figura 3.42 podemos ver una de las pruebas realizadas antes de solucionar el error.

Figura 3.43 Pruebas ver diferencia sin horas estimadas


46

3.3.5 Mejorar la navegabilidad de la aplicación y eliminar información innecesaria

Análisis

En las vistas Proyectos, Empleados e Histórico horas de la aplicación, haremos que los nombres de los proyectos y de los trabajadores pasen a ser enlaces que mejoren la navegabilidad y permitan un acceso rápido a la información estadística de la aplicación. A continuación, detallaremos las diferentes acciones que podrá realizar el administrador.

Si el administrador está situado en la vista Proyectos y pulsa en el enlace que colocaremos en el nombre del proyecto, le redirigiremos a la vista EstadisticaProyectos mostrando las estadísticas del mismo.

En la vista Empleados, haremos lo mismo para el nombre de los empleados, aunque esta vez la redirección será diferente. El administrador acabará en la vista EstadisticaEmpleados dónde visualizará las estadísticas generales de ese empleado.

Por otro lado, en las vistas anteriores eliminaremos las columnas de las tablas que incluyen los identificadores, ya que este tipo de información no es útil para el director de proyectos.

Diseño

Para colocar enlaces entre las diferentes páginas de la aplicación, modificaremos las rutas que invocan a los métodos index() para que acepten un parámetro de entrada y, sí es válido, incluyan la información estadística en las vistas. Seguidamente modificaremos las vistas para que muestren la información del proyecto o del empleado dependiendo de la información que está enviándose desde el servidor. Para este propósito utilizaremos un array que contenga toda la información estadística.

En el caso de que vengamos de otra página (proyectos o empleados), para poder pintar los gráficos, deberemos pasar a JS la información de las estadísticas. Para este propósito, añadiremos un input de tipo hidden dónde la colocaremos codificada en formato JSON.

También tendremos que modificar la función onload() de la página, para que está reconozca cuando ha de llamar a las funciones encargadas de dibujar los gráficos.

Implementación

Para mejorar la navegabilidad de la aplicación, los pasos llevados a cabo han sido similares a los realizados en el apartado visualizar los datos guardados en la página home, aunque hemos tenido que modificar partes del código del Frontend para poder dibujar los gráficos.

Primero, hemos modificado las rutas que acceden a las páginas estadísticas de la aplicación para que acepten un parámetro opcional. Seguidamente, en los métodos indexProyectos e indexEmpleados localizados en el controlador EstadisticasController, hemos realizado las comprobaciones necesarias para saber si el parámetro se corresponde con el identificador de algún proyecto o empleado.

Una vez realizadas las modificaciones descritas, para pintar los gráficos en la página, hemos tenido que hacer que los datos estadísticos estén disponibles para las funciones JS de Google encargadas de renderizar dichos gráficos. Para ello hemos usado un input de tipo Hidden que contendrá esta información en su propiedad value, así el JS de las páginas estadísticas podrá recogerla.

Por ello, hemos modificado la función callback que nos proporciona la librería de gráficos de google situada en dicha página para que compruebe si el input comentado anteriormente tiene o no tiene información a incorporar en los gráficos. En la página que muestra las estadísticas de los empleados, también inicializará todas las variables necesarias para realizar la paginación. A continuación, en la Figura 3.44 de la página 47, el código (fondo amarillo) que hemos incluido en dicha función.


47

Figura 3.44 Función setOnLoadCallBack para mostrar las estadísticas de los empleados

3.3.6 Crear nuevas alertas y sustituir las ya existentes.

Análisis

Durante esta fase, localizaremos todos los mensajes de alerta que tiene la aplicación en sus diferentes páginas y los sustituiremos por ventanas modales, que son más visuales y atraen más la atención. Además para distinguir entre errores más o menos críticos, modificaremos el color del cuadro de la ventana para que el usuario pueda interpretar el nivel de alerta de dicho mensaje.

En la página Proyectos, crearemos las alertas necesarias para avisar al administrador de los proyectos en los que no existen estimaciones. Esto será necesario para que el director de proyectos realice el presupuesto y haga las estimaciones oportunas. Así, las páginas estadísticas de la aplicación dispondrán de la información necesaria para hacer los cálculos lo más precisos posibles. Crearemos para cada proyecto las alertas descritas en la Tabla 3.5 incluida en el diseño.

Para finalizar, el cliente nos ha pedido que las alertas sean lo menos intrusivas posibles debido al alto número de proyectos que existen en la base de datos y para los cuáles no existía la funcionalidad que actualmente hay en la aplicación.

Diseño

Tendremos que sustituir las diferentes alertas de JS que existen en la aplicación y que utilizan la función alert() para que hagan uso de la ventana modal creada en la parte de diseño de la página home y que vemos en la Figura 3.30 de la página 40.

En la página dónde podemos ver el listado de todos los proyectos contenidos en la aplicación, añadiremos en cada una de las filas, las siguientes letras o signos. Así, el director de proyectos podrá ver aquellos en los que faltan datos para que la página de las estadísticas muestre toda información posible. A continuación, mostraremos los signos que utilizaremos para dichas alertas.

Letra/Signo Alerta T Cuando no existen estimaciones para las tareas. M Si el proyecto tiene módulos, cuando no existen estimaciones para los módulos. F Cuando la fecha de inicio y la fecha de fin del proyecto sean la misma. € Cuando el valor del presupuesto sea igual a 0.

Tabla 3.5 Alertas página proyectos.


48

Implementación

Para mostrar las nuevas alertas, hemos utilizado la ventana modal en cuyo cuerpo hemos incluido el texto ya existente en los diferentes alert situados en los archivos de JavaScript de la aplicación.

Por otro lado, para crear las alertas estadísticas en la página de los proyectos, como vemos en la Figura 3.45, en el método index del controlador HomeController, hemos creado un array “alertas” al que asignamos los valores booleanos obtenidos en diferentes métodos del modelo Proyecto. Dichas alertas son enviadas a la vista, para que está compruebe cuando ha de dibujar las letras o signos que indican cuáles son las estimaciones que faltan.

Figura 3.45 Alertas en el método index del controlador ProyectosController

3.3.7 Facilitar la búsqueda de tareas en la página HistoricoHoras

Análisis

Actualmente, existe una página que muestra el histórico de las tareas dónde visualizamos toda la información contenida en la tabla HistoricoHoras de la base de datos. Dicha página tarda en cargar y en muchas ocasiones resulta complicado localizar datos. Siguiendo los requisitos del cliente, hemos decidido filtrar las tareas por su fecha de introducción. Así será mucho más fácil gestionar y visualizar la información almacenada en la base de datos.

Diseño

En la vista HistoricoHoras, modificaremos la tabla actual sustituyendo los identificadores de los empleados y de los módulos, por los nombres de éstos. Luego agruparemos las tareas por nombre de empleado y, para terminar, eliminaremos los identificadores restantes de cada fila. Por debajo de esta tabla, añadiremos una nueva, que muestre para cada empleado la suma de las horas realizadas y que será como un resumen de la anterior.

Cuando el usuario acceda a la página por primera vez, mostraremos las tareas realizadas el día laboral anterior. Es decir, si entramos un domingo o un lunes, la aplicación mostrará las tareas introducidas el viernes. Para los demás días de la semana (martes a sábado) se visualizarán las tareas del día anterior.

Para modificar la información mostrada en las tablas cuando el usuario realice un cambio de fecha, utilizaremos la tecnología AJAX al igual que en apartados anteriores.

A continuación, en la Figura 3.46 de la página 49 vemos cómo quedará la página que muestra el histórico de las horas. En la parte superior, colocaremos un datePicker para que el administrador puede escoger la fecha para la que quiere visualizar las tareas. Además, lo acompañaremos de dos botones que faciliten el


49

desplazamiento entre días contiguos. En la parte central, encontraremos una tabla dónde veremos las tareas agrupadas por nombre de empleado. Para cada histórico de horas existente en la base de datos, mostraremos el nombre del empleado, el módulo de la tarea (si es que existe), el nombre de la tarea y las horas realizadas. Para terminar en la parte inferior, colocaremos el cuadro resumen de las horas introducidas por cada empleado en la fecha elegida.

Figura 3.46 Página Histórico Horas.

Implementación

Hemos creado dos métodos en la clase Empresa. El primero getHistoricoHorasDia() tiene como finalidad obtener toda la información acerca de las tareas realizadas por todos los empleados de la empresa, mientras el segundo getHorasTotalesEmpleadosDia() permite obtener un array con las horas realizadas por cada empleado. Aunque antes, en el apartado de implementación de las estadísticas de la página 25, hemos comentado que utilizábamos la sintaxis de Eloquent ORM para realizar consultas a la base de datos, también podemos escribir la sentencia SQL directamente, ya que en algunas ocasiones se hace complicada la traducción al lenguaje de Eloquent, provocando una pérdida de tiempo y, en definitiva, el resultado que vamos a obtener es el mismo. A continuación en la Figura 3.47, vemos un ejemplo de ello dentro del método getHistoricoHorasDia().

Figura 3.47 Función getHistoricoHorasDia()

Las dos funciones comentadas en el párrafo anterior son invocadas en los métodos index() y obtenerHistoricoDia(), localizados en el controlador HistoricoHorasController. Estos envían la información


50

obtenida a la vista HistoricoHoras tanto en una primera visita a la página, como en las numerosas peticiones AJAX que el administrador realiza modificando el filtro de la fecha.

Para mejorar la experiencia de usuario, hemos colocado dos botones acompañando al filtro anterior que facilitan la visualización de las tareas entre fechas contiguas. El evento onclick de estos botones llama a la función JS cambiarFecha() que dispara el evento onchange del input fecha, realizando la petición AJAX y obteniendo la nueva información correspondiente a la nueva fecha. En el ejemplo de la Figura 3.48 vemos la implementación de este método.

Figura 3.48 Función cambiarFecha()


51

4 Etapa 3: Diseño gráfico de la aplicación

Para mejorar el diseño gráfico de la aplicación, primero visitamos un número de páginas para observar como utilizaban los diferentes colores, en función de los logotipos de sus compañías. Tras fijarnos en los detalles e investigar un poco el código del frontend de dichas aplicaciones, vimos que muchas de ellas contenían CSS personalizados.

Para personalizar el aspecto del menú, decidimos utilizar el configurador de http://work.smarchal.com/twbscolor/, que permite generar todas las clases necesarias para cambiar los colores de la barra de navegación de manera sencilla, rápida e intuitiva. Únicamente tuvimos que copiar el código y sustituir las clases generadas en el archivo css de Boostrap contenido en nuestro proyecto.

El css que cambia de aspecto de todos los demás elementos lo podemos encontrar en un nuevo archivo llamado “personal.css”, que redefine las clases que vienen por defecto en Bootstrap para los diferentes elementos HTML. Por eso, la referencia a este archivo hay que colocarla justo después del archivo CSS de BootStrap en la plantilla padre.

Además, hemos agregado la directiva @yield(‘css’) que ofrece Laravel en la plantilla padre y que nos permite agregar nuevos archivos CSS en las plantillas hijas. Esto será útil si en un futuro se desea agregar algún CSS específico y único en alguna página de la aplicación.

A continuación en la Figura 4.1 podemos ver todo lo comentado anteriormente.

Figura 4.1 Orden de los archicos css en la plantilla padre

Para ver un ejemplo, a continuación en la Figura 4.2, mostramos las clases de los botones que trae Bootstrap y que hemos modificado en el archivo personal.css para transformar los botones en “GhostButtons”, que respondan a la interacción con el usuario cambiando de color cuando éste hace clic o sitúa el puntero del ratón encima de uno de ellos.

Figura 4.2 Código necesario para cambiar el aspecto de los botones


52

Para poder ver el cambio visual llevado a cabo en la aplicación, en la Figura 4.3, vemos el aspecto que tenía la página de inicio antes de realizar cualquier modificación.

Figura 4.3 Página Home Anterior.

Por el contrario, en la Figura 4.4 visualizamos como ha cambiado el aspecto del menú, del panel y de los diferentes elementos HTML.

Figura 4.4 Página Home modificada.


53

5 Conclusiones

El proyecto desarrollado durante la realización de este TFG, ha supuesto un reto y una buena toma de contacto con lo que me puedo encontrar una vez finalizados los estudios en la universidad. Lo he realizado en un entorno muy similar al mundo laboral que me voy a encontrar en un futuro próximo.

Al tratarse de una reingeniería, en muchos partes del proyecto había que comprender y modificar el código que había desarrollado otro programador. Quizás hubiese sido más fácil empezar de cero.

Tal y como se trabaja hoy en día, he utilizado una herramienta de control de versiones. Con ella tenía la opción de usar la aplicación en el servidor de pruebas localizado en la empresa. De esta manera, los empleados y el director de proyectos podían probar la nueva funcionalidad añadida durante los diferentes incrementos desarrollados.

Por otro lado, he aprendido a desarrollar aplicaciones web con Php, un nuevo lenguaje que no había visto en mi período de estudiante en la universidad. Combinando dicho lenguaje con las diferentes facilidades y utilidades que ofrece un framework moderno y actual como es Laravel, he mejorado mis conocimientos tan necesarios hoy en día para ampliar mis horizontes profesionales.

Dadas las dificultades encontradas en el desarrollo del proyecto durante el período que ha durado el TFG, he mejorado notablemente los tiempos de resolución de problemas, ya que he aprendido a identificar su origen y en consecuencia, sé ofrecer una solución en menos tiempo de lo que para mí era habitual.

También he aprendido que cuando queramos implementar un nuevo requisito o corregir un error, antes hay que realizar una búsqueda en internet. En la mayoría de las ocasiones, existe alguien que ofrece una solución debido a que ha tenido que resolver un problema similar. En consecuencia, se puede reducir notablemente el tiempo de implementación.

Este proyecto es el más ambicioso que he realizado hasta el momento, y por lo tanto, ha significado un desafío personal y profesional. También me ha dado la opción de conocer y comenzar a manejar herramientas actualmente muy demandadas tales como Bootstrap, Jquery y Google Apis. Con todo ello, me siento mejor preparado para realizar un nuevo proyecto de similares características.


54

5.1 Tabla comparativa entre el tiempo estimado y el tiempo realizado

En la Tabla 5.1 vemos para cada tarea realizada el código, el nombre, la comparativa entre el tiempo estimado y el tiempo realizado, así como el motivo por el que se ha producido la desviación (si es significativa).

Código Nombre Tiempo Estimado

Tiempo Real Motivo de la desviación

1.1 Dirección y Gestión del proyecto 82 h. 103 h. -

1.1.1 Análisis general 16 h. 20 h. Inexperiencia a la hora de realizar un análisis en un proyecto de estas características.

1.1.2 Planificación 12 h. 15 h. Inexperiencia a la hora de realizar una planificación para un proyecto de 300 h.

1.1.3 Documentación memoria TFG 54 h. 68 h. Inexperiencia a la hora de documentar un proyecto de estas características

1.2 Conocer la estructura y las tecnologías 30 h. 29 h. -

1.2.1 Análisis 6 h. 5 h. Menos tiempo necesario para completar la tarea.

1.2.2 Implementación 22 h. 20 h. Menos tiempo necesario para completar la tarea.

1.2.3 Pruebas 2 h. 4 h. Más tiempo necesario para realizar todas las pruebas.

1.3 Implementación de nueva funcionalidad 154 h. 153 h. -

1.3.1 Módulo presupuestos 22 h. 23 h. - 1.3.1.1 Análisis 2 h. 3 h. - 1.3.1.2 Diseño 2 h. 2 h. -

1.3.1.3 Implementación 16 h. 15 h. Menos tiempo necesario para completar la tarea.

1.3.1.4 Pruebas 2 h. 3 h. - 1.3.2 Módulo estadísticas 72 h. 68 h. -

1.3.2.1 Análisis 6 h. 8 h. Más tiempo necesario para contemplar todos los requisitos pedidos.

1.3.2.2 Diseño 8 h. 7 h. Menos tiempo necesario para completar la tarea.


1.3.2.4 Pruebas 6 h. 8 h. Más tiempo necesario para realizar todas las pruebas.

1.3.3 Mejoras en la usabilidad 60 h. 62 h. - 1.3.3.1 Análisis 6 h. 7 h. - 1.3.3.2 Diseño 6 h. 7 h. -


1.3.3.4 Pruebas 4 h. 6 h. Más tiempo necesario para realizar todas las pruebas necesarias.

1.4 Diseño gráfico de la aplicación 28 h. 25 h. Menos tiempo necesario para completar la tarea.

1.4.1 Análisis de otras páginas 4 h. 3 h. Menos tiempo necesario para completar la tarea.

1.4.2 Diseñar las vistas 6 h. 4 h. Menos tiempo necesario para completar la tarea.

1.4.3 Implementar los diseños 16 h. 15 h. Menos tiempo necesario para completar la tarea.

1.4.4 Pruebas 2 h. 3 h. -

1.5 Redactar el manual de usuario 8 h. 5 h. Menos tiempo necesario para completar la tarea.

TOTAL: 300 h. 315 h. -

Tabla 5.1 Tabla comparativa tiempo estimado/tiempo realizado


55

6 Bibliografía • Manuales, documentación y foros para utilizar Laravel.

http://laraveles.com/foro/ https://laracasts.com https://styde.net https://laravel.com/docs/5.0 http://learninglaravel.net/cheatsheet/

• Documentación Php. http://php.net/docs.php

• Documentación y foros para utilizar Jquery, JavaScript, Bootstrap, HTML y CSS. http://www.w3schools.com/ https://api.jquery.com/

• Documentación y ayuda para utilizar MySQL. https://dev.mysql.com/doc/ http://www.w3schools.com/

• Foro de consulta para resolución de problemas.

http://stackoverflow.com/

• Manejo del IDE Php Storm e instalación de Xdebug. https://resources.jetbrains.com/storage/products/phpstorm/docs/PhpStorm_ReferenceCard.pdf https://www.jetbrains.com/help/phpstorm/10.0/keyboard-shortcuts-you-cannot-miss.html https://www.jetbrains.com/help/phpstorm/10.0/configuring-xdebug.html https://www.jetbrains.com/help/phpstorm/2016.1/meet-phpstorm.html

Reingeniería de una aplicación web para gestionar proyectos de … · 2017-10-17 ·...

Documents

Transcript of Reingeniería de una aplicación web para gestionar proyectos de … · 2017-10-17 ·...