TFE002197

TRABAJO FIN DE GRADO
Título
Reingeniería de una aplicación web para gestionar

proyectos de software
Autor/es
Alan Vallejo Belshaw
Director/es
Francisco José García Izquierdo
Facultad
Facultad de Ciencia y Tecnología

Titulación
Grado en Ingeniería Informática
Departamento
Curso Académico
2015-2016
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 la
Universidad 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.
© El autor
© Universidad de La Rioja, Servicio de Publicaciones, 2016
publicaciones.unirioja.es
E-mail: publicaciones@unirioja.es
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
__________________________________________________________________________________________
Índice

Resumen ........................................................................................................................... 3
Abstract ............................................................................................................................ 3
Agradecimientos ............................................................................................................... 4
1 Introducción ................................................................................................................ 5
1.1 Contexto ........................................................................................................................... 5
1.2 Tecnologías ....................................................................................................................... 5
1.3 Alcance ............................................................................................................................. 6
1.3.1 Conocer la estructura y las tecnologías ............................................................................ 6
1.3.2 Implementar nueva funcionalidad ................................................................................... 6
1.3.3 Realizar un nuevo diseño gráfico ...................................................................................... 7
1.4 Gestión del trabajo fin de grado. ....................................................................................... 8
1.4.1 Estructura de descomposición del proyecto (EDP) ........................................................... 8
1.4.2 Descripción de las tareas .................................................................................................. 9
1.4.3 Diagrama de Gantt ......................................................................................................... 10
1.4.4 Diagrama de Hitos .......................................................................................................... 11
1.4.5 Seguimiento y control ..................................................................................................... 11
1.4.6 Plan de comunicaciones ................................................................................................. 11
1.4.7 Reuniones ....................................................................................................................... 11
1.4.8 Plan de calidad ................................................................................................................ 11
2 Etapa 1: Conocer la estructura y solucionar errores ................................................... 15

2.1 Adquirir conocimientos .................................................................................................. 15
2.2 Estructura de la aplicación .............................................................................................. 15
2.3 Localizar y solucionar errores .......................................................................................... 16
2.4 Implementación ............................................................................................................. 17
3 Etapa 2: Implementación de nueva funcionalidad ..................................................... 19

3.1 Módulo de presupuestos ................................................................................................ 19
3.1.1 Análisis ............................................................................................................................ 19
3.1.2 Diseño ............................................................................................................................. 20
3.1.3 Implementación .............................................................................................................. 21
3.1.4 Pruebas ........................................................................................................................... 23
3.2 Módulo estadísticas ........................................................................................................ 25
3.2.1 Análisis ............................................................................................................................ 25
3.2.2 Diseño ............................................................................................................................. 28
3.2.3 Implementación .............................................................................................................. 31
3.2.4 Pruebas ........................................................................................................................... 34
3.3 Mejorar la usabilidad ...................................................................................................... 36
3.3.1 Implementar una página de error .................................................................................. 36
3.3.2 Mejorar la recolección de datos en la página Home ...................................................... 38
3.3.3 Visualizar los datos guardados en la página Home ......................................................... 41
1
__________________________________________________________________________________________
3.3.4 Insertar nueva información en la página Home ............................................................. 44

3.3.5 Mejorar la navegabilidad de la aplicación y eliminar información innecesaria .............. 46
3.3.6 Crear nuevas alertas y sustituir las ya existentes. .......................................................... 47
3.3.7 Facilitar la búsqueda de tareas en la página HistoricoHoras .......................................... 48
4 Etapa 3: Diseño gráfico de la aplicación ..................................................................... 51

5 Conclusiones ............................................................................................................. 53
5.1 Tabla comparativa entre el tiempo estimado y el tiempo realizado ................................ 54
6 Bibliografía ............................................................................................................... 55
2
__________________________________________________________________________________________
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.
3
__________________________________________________________________________________________
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í.
4
__________________________________________________________________________________________
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.
5
__________________________________________________________________________________________
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
6
__________________________________________________________________________________________
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.
7
__________________________________________________________________________________________
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.
1
Reingeniería de la aplicación web Timetracker
1.1 1.2 1.3 1.4 1.5

Dirección y Conocer la Implementación Diseño Redactar el
gestión del estructura y las de nueva gráfico de la manual de
proyecto. tecnologías funcionalidad aplicación usuario
1.3.1 1.3.2 1.3.3 1.4.1

1.1.1 1.3.1
Módulo Módulo Mejoras en la Análisis de
Análisis general Análisis
presupuestos estadísiticas usabilidad otras páginas
1.4.2
1.1.2 1.3.2 1.3.1.1 1.3.2.1 1.3.3.1
Planificación Implementación Diseñar las
Análisis Análisis Análisis
vistas
1.1.3 1.3.2 1.3.1.2 1.3.2.2 1.3.3.2 1.4.3

Documentación Implementar
TFG Pruebas Diseño Diseño Diseño los diseños
1.3.1.3 1.3.2.3 1.3.3.3 1.4.4

Implementación Implementación Implementación Pruebas
1.3.1.4 1.3.2.4 1.3.3.4

Pruebas Pruebas Pruebas
Figura 1.1 EDP del proyecto
8
__________________________________________________________________________________________
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.
h.
Código Nombre Descripción Estimadas
Dirección y
1.1 Gestión del 82 h.
proyecto
Estudiar y realizar un análisis inicial de las partes de la aplicación que
1.1.1 Análisis general 16 h.
el cliente desea mejorar para definir el alcance del proyecto.
Definir el alcance, realizar una EDP, identificar las tareas a realizar,

1.1.2 Planificación construir los diagramas de Gantt y de Hitos, decidir la manera en que 12 h.
nos vamos a comunicar con el tutor de la empresa y el tutor del TFG.
Documentar aquellos aspectos necesarios para facilitar la
Documentación comprensión de las tareas y de los incrementos realizados en la
1.1.3 54 h.
memoria TFG aplicación durante las diferentes fases del desarrollo del proyecto,
además de recoger el análisis general y la planificación del proyecto.
Conocer la
1.2 estructura y las 30 h.
tecnologías
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
1.2.1 Análisis 6 h.
apuntar/estudiar los posibles errores que pueden surgir durante esta
tarea. Reproducir los errores comunicados por el cliente para estudiar
su origen.
Ofrecer una solución a todos los errores, tanto los que han sido
1.2.2 Implementación comunicados por el cliente como los que hemos detectado durante el 22 h.
análisis.
Probar toda la funcionalidad que hayamos desarrollado y modificado
1.2.3 Pruebas para comprobar los resultados y confirmar que hemos solucionado 2 h.
los errores.
Implementación
1.3 de nueva 154 h.
funcionalidad
Módulo
1.3.1 22 h.
presupuestos
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
1.3.1.1 Análisis 2 h.
requisitos inciales.
Estudiar qué aspectos de la aplicación vamos a incluir y qué pasos
vamos a realizar para ello.
Diseñar la interfaz del apartado de presupuestos.
1.3.1.2 Diseño Si el resultado del análisis confirma que es necesario incrementar la 2 h.
base datos, incluir los nuevos campos o tablas en ella.
Desarrollar la interfaz realizada en el diseño. Si es necesario
modificar la base de datos, incluir toda la lógica necesaria para
1.3.1.3 Implementación 16 h.
añadir/extraer toda la información de la misma. Añadir programación
en frontend para que funcione dinámicamente.
Probar la nueva funcionalidad y comprobar que no hemos alterado la
1.3.1.4 Pruebas 2 h.
ya existente.
Tabla 1.1 Diccionario de la EDP
9
__________________________________________________________________________________________
h.
Código Nombre Descripción Estimadas
Módulo
1.3.2 72 h.
estadísticas
Analizar dónde incluir la nueva funcionalidad.
Tener una reunión con el cliente para que nos comunique qué le
1.3.2.1 Análisis gustaría añadir dentro de este apartado. 6 h.
Estudiar qué aspectos de la aplicación vamos a modificar y qué pasos
vamos a realizar para ello.
Diseñar las interfaces necesarias y modificar las ya existentes para
mostrar la nueva información. Si como resultado del análisis es
1.3.2.2 Diseño 8 h.
necesario modificar la base datos, incluir los nuevos campos o tablas
en ella.
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.
Probar la nueva funcionalidad y comprobar que no hemos alterado
la ya existente.
Mejoras en la
1.3.3 60 h.
usabilidad
Analizar dónde vamos a incluir la nueva funcionalidad.
1.3.3.1 Análisis Estudiar qué aspectos de la aplicación vamos a cambiar y qué pasos 6 h.
vamos a realizar para modificarlos.
Diseñar las interfaces necesarias y modificar las ya existentes para
mostrar la nueva información. Si como resultado del análisis es
1.3.3.2 Diseño 6 h.
necesario modificar la base datos, incluir los nuevos campos o tablas
en ella.
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.
Probar la nueva funcionalidad y comprobar que no hemos alterado
la ya existente.
Diseño gráfico
1.4 28 h.
de la aplicación
Análisis de otras Analizar otras páginas que muestren una cantidad considerable de
1.4.1 4 h.
páginas información de características similares a nuestra aplicación.
Diseñar las Modificar las interfaces de la aplicación basándonos en las plantillas
1.4.2 6 h.
vistas ya existentes en nuestra aplicación.
Implementar los Modificar las interfaces para que se asemejen a los bocetos
1.4.3 16 h.
diseños planteados en el diseño.
Comprobar que la información mostrada por las interfaces antiguas
1.4.4 Pruebas 2 h.
sigue apareciendo en los nuevos diseños.
Redactar el
Explicar y redactar los pasos necesarios para hacer uso de la
1.5 manual de 8 h.
funcionalidad desarrollada durante el proyecto.
usuario
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.
10
__________________________________________________________________________________________
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.
11
__________________________________________________________________________________________
Figura 1.2 Diagrama de Gantt S1-S8
12
__________________________________________________________________________________________
Figura 1.3 Diagrama de Gantt S9-S15
13
__________________________________________________________________________________________
Figura 1.4 Diagrama de hitos
14
__________________________________________________________________________________________
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
15
__________________________________________________________________________________________
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
16
__________________________________________________________________________________________
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.
17
__________________________________________________________________________________________
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()
18
__________________________________________________________________________________________
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
19
__________________________________________________________________________________________
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.
20
__________________________________________________________________________________________
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.
21
__________________________________________________________________________________________
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.
22
__________________________________________________________________________________________
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.
23
__________________________________________________________________________________________
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
24
__________________________________________________________________________________________
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.
25
__________________________________________________________________________________________
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,
26
__________________________________________________________________________________________
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.
27
__________________________________________________________________________________________
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
28
__________________________________________________________________________________________
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.
29
__________________________________________________________________________________________
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.
30
__________________________________________________________________________________________
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.
31
__________________________________________________________________________________________
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.
32
__________________________________________________________________________________________
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.
33
__________________________________________________________________________________________
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
34
__________________________________________________________________________________________
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
35
__________________________________________________________________________________________
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.
36
__________________________________________________________________________________________
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
37
__________________________________________________________________________________________
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
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:
38
__________________________________________________________________________________________

2 Tienda Virtual Pagos Implementación 1.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:


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.
39
__________________________________________________________________________________________

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
40
__________________________________________________________________________________________
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.
41
__________________________________________________________________________________________
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
42
__________________________________________________________________________________________
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
43
__________________________________________________________________________________________
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.
44
__________________________________________________________________________________________
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
45
__________________________________________________________________________________________
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.
46
__________________________________________________________________________________________
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.
47
__________________________________________________________________________________________
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
48
__________________________________________________________________________________________
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
49
__________________________________________________________________________________________
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()
50
__________________________________________________________________________________________
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
51
__________________________________________________________________________________________
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.
52
__________________________________________________________________________________________
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.
53
__________________________________________________________________________________________
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).
Tiempo Tiempo
Código Nombre Estimado Real
Motivo de la desviación
1.1 Dirección y Gestión del proyecto 82 h. 103 h. -

Inexperiencia a la hora de realizar un análisis
1.1.1 Análisis general 16 h. 20 h.
en un proyecto de estas características.
Inexperiencia a la hora de realizar una
1.1.2 Planificación 12 h. 15 h.
planificación para un proyecto de 300 h.
Inexperiencia a la hora de documentar un
1.1.3 Documentación memoria TFG 54 h. 68 h.
proyecto de estas características
Conocer la estructura y las
1.2 30 h. 29 h. -
tecnologías
Menos tiempo necesario para completar la
1.2.1 Análisis 6 h. 5 h.
tarea.
1.2.2 Implementación 22 h. 20 h.
tarea.
Más tiempo necesario para realizar todas las
1.2.3 Pruebas 2 h. 4 h.
pruebas.
Implementación de nueva
1.3 154 h. 153 h. -
funcionalidad
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.
tarea.
1.3.1.4 Pruebas 2 h. 3 h. -
1.3.2 Módulo estadísticas 72 h. 68 h. -
Más tiempo necesario para contemplar todos
1.3.2.1 Análisis 6 h. 8 h.
los requisitos pedidos.
1.3.2.2 Diseño 8 h. 7 h.
tarea.
tarea.
1.3.2.4 Pruebas 6 h. 8 h.
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. -
tarea.
1.3.3.4 Pruebas 4 h. 6 h.
pruebas necesarias.
1.4 Diseño gráfico de la aplicación 28 h. 25 h.
tarea.
1.4.1 Análisis de otras páginas 4 h. 3 h.
tarea.
1.4.2 Diseñar las vistas 6 h. 4 h.
tarea.
1.4.3 Implementar los diseños 16 h. 15 h.
tarea.
1.4.4 Pruebas 2 h. 3 h. -
1.5 Redactar el manual de usuario 8 h. 5 h.
tarea.
TOTAL: 300 h. 315 h. -
Tabla 5.1 Tabla comparativa tiempo estimado/tiempo realizado
54
__________________________________________________________________________________________
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
55

TFE002197

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TFE002197

Transféré par

Droits d'auteur :

Formats disponibles

TRABAJO FIN DE GRADO

Reingeniería de una aplicación web para gestionar

Alan Vallejo Belshaw

Francisco José García Izquierdo

Facultad de Ciencia y Tecnología

Grado en Ingeniería Informática

TRABAJO FIN DE GRADO

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

Logroño, Junio de 2016

2 Etapa 1: Conocer la estructura y solucionar errores ................................................... 15

3 Etapa 2: Implementación de nueva funcionalidad ..................................................... 19

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

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

1.3.1 Conocer la estructura y las tecnologías

1.3.2 Implementar nueva funcionalidad

Obtener estadísticas detalladas

1.3.3 Realizar un nuevo diseño gráfico

1.4 Gestión del trabajo fin de grado.

1.4.1 Estructura de descomposición del proyecto (EDP)

1.1 1.2 1.3 1.4 1.5

1.3.1 1.3.2 1.3.3 1.4.1

1.1.3 1.3.2 1.3.1.2 1.3.2.2 1.3.3.2 1.4.3

1.3.1.3 1.3.2.3 1.3.3.3 1.4.4

1.3.1.4 1.3.2.4 1.3.3.4

Figura 1.1 EDP del proyecto

1.4.2 Descripción de las tareas

Definir el alcance, realizar una EDP, identificar las tareas a realizar,

1.4.3 Diagrama de Gantt

1.4.4 Diagrama de Hitos

1.4.5 Seguimiento y control

1.4.6 Plan de comunicaciones

1.4.8 Plan de calidad

Figura 1.2 Diagrama de Gantt S1-S8

Figura 1.3 Diagrama de Gantt S9-S15

Figura 1.4 Diagrama de hitos

2 Etapa 1: Conocer la estructura y solucionar errores

2.1 Adquirir conocimientos

2.2 Estructura de la aplicación

Figura 2.1 Estructura de la aplicación

2.3 Localizar y solucionar errores

Errores descritos por el cliente

Errores encontrados durante el análisis

Errores encontrados durante el análisis

Figura 2.2 Guardar un nuevo proyecto

Figura 2.3 Guardar un nuevo proyecto usando transaction()

3 Etapa 2: Implementación de nueva funcionalidad

3.1 Módulo de presupuestos

valor si un cliente tiene un grado de exigencia excesiva o si el número de interrupciones en un proyecto

• Análisis: analisisMin , analisisMax, analisisPorPagina y cantidadHoraAnálisis.

Figura 3.1 Tablas presupuestos y modulos_presupuestos

Figura 3.2 Tablas presupuestos y modulos_presupuestos

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

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

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

Figura 3.6 Método getCosteAnálisis()

Cambiando de tercio, para crear el formulario en las vistas presupuesto_new.blade.php y

Figura 3.7 Abrir y cerrar formulario con HtmlServiceProvider

Figura 3.8 Código generado por HtmlServiceProvider

Figura 3.9 Elementos dinámicos página presupuesto_new

Seguidamente rellenamos y enviamos el formulario comprobando que dicho presupuesto se ha guardado en

Figura 3.10 Panel presupuestos

Figura 3.11 Tabla parámetros formulario

Figura 3.12 Tabla campos generados

3.2 Módulo estadísticas