4. Método de trabajo 33
4.7. Planificación
4.7.6. Iteración 5: Refinamiento del proceso de extracción del conocimien-
En la última iteración se ha refinado el proceso de descubrimiento de conocimiento y se han realizado pruebas en el sistema. La iteración se ha desarrollado entre la segunda quincena del año 2015 y la primera quincena del año 2016.
Figura 4.17: Iteración 5. Duración
Figura 4.18: Iteración 5. Desglose por características
Capítulo 5
Resultados
C
OMO se ha indicado anteriormente, este trabajo se ha realizado a través de seis itera- ciones principales. En primer lugar se ofrece una visión general del proyecto y poste- riormente se muestra el desarrollo de cada iteración.5.1 Visión general
Para comenzar se mostrarán los documentosVision Board y Road Mapexplicados ante- riormente en la seccion 4.5, que sirven de apoyo para afrontar cualquier proyecto. Con el documentoVision Board se pretende dar una idea general del sistema creado, planteando la visión del producto, el alcance, el segmento del mercado al que va dirigido, etc., (ver figura 5.1). Por otro lado, el documentoRoad Mapse utiliza para planificar este proyecto en blo- ques de hitos principales, estableciendo así los objetivos que se desean alcanzar (ver figura 5.2).
En el siguiente subapartado se describen los requisitos, tanto funcionales como no funcio- nales, establecidos para el desarrollo del sistema y, por último, se detallará la arquitectura general del sistema.
Tablero de visión del producto
Visión general
Sector dirigido Necesidades Producto Valor Competidores
El sector al que va dirigido es a personas que sientan la necesidad de mejorar la organización de sus actividades y estén sometidas constantemente a situaciones de estrés.
Por ejemplo, estudiantes o desarrolladores
involucrados en proyectos.
El problema que se pretende resolver es intentar que la persona que utilice el producto lleve una vida más organizada.
El usuario recibe indicaciones acerca del estrés y la organización del tiempo invertido en el desarrollo de las tareas.
Lo que hace especial a este producto son las conclusiones ofrecidas que se asemejan a patrones obtenidos mediante un estudio de extracción del conocimiento.
El desarrollo de este producto es factible, ya que se disponen de los medios y tecnologías necesarios.
El valor añadido de este producto es la integración de sus registros de tareas en la aplicación desde múltiples herramientas de time tracking.
Otro valor añadido es el estudio de las tareas registradas para ofrecer una serie de consejos y recomendaciones
Existen algunas aplicaciones que se asemejan a funciones realizadas en CRONOS- ANALYZER.
Timeful, que es una herramienta de organización del tiempo.
Emvio es un reloj que cuantifica el nivel de estrés, aunque aún no ha sido lanzado al mercado.
Tick, herramienta de gestión de proyectos y seguimiento del tiempo invertido.
Based on Roman Pichler's Product Vision Board (http://www.romanpichler.com/blog/agile-product-innovation/the-product-vision-board) Licensed under the Creative Commons CC BY-SA license
Creación de una herramienta donde el usuario obtendrá conclusiones, consejos y predicciones sobre la organización de su tiempo, tras analizar sus datos previamente importados
Figura 5.1: Tablero de visión del producto
56
Fecha Deadline: últimos de mayo
Deadline: últimos de julio
Deadline: últimos de septiembre
Deadline: últimos de octubre
Deadline: primera quincena de
septiembre
Deadline: primera quincena de enero
Nombre Iteración 0 Iteración 1 Iteración 2 Iteración 3 Iteración 4 Iteración 5
Meta
Anteproyecto entregado.
Elección de herramientas.
Creación del esqueleto del
sistema.
Primera versión de la extracción de
conocimiento.
Desarrollo de algunos capítulos
de la memoria.
Prototipo inicial de aplicación que permite gestión de
usuarios e importación de
registros.
Creación del módulo de monitorización.
Creación del módulo de predicción.
Primera versión de la documentación.
Refinamiento del proceso de extracción de conocimiento.
Desarrollo de pruebas.
Características
Configuración del proyecto y adición
de librerías.
Primeras conclusiones del
estudio.
Importación de registros.
Registro y login en el sistema.
Personalización de algunos
atributos.
Monitorización básica.
Monitorización avanzada.
Ofrecer recomendaciones
al usuario.
Predicción de carga de trabajo en próximos días.
Predicción del nivel de estrés que
el usuario tendrá en esa semana.
Obtención de factores con la ayuda del experto.
Definir y realizar pruebas en el
sistema.
Métricas
Historias de usuario completadas.
Validación de Scrum Master.
Historias de usuario completadas.
Validación de Scrum Master.
Historias de usuario completadas.
Validación de Scrum Master.
Historias de usuario completadas.
Validación de Scrum Master.
Historias de usuario completadas.
Validación de Scrum Master.
Historias de usuario completadas.
Validación de Scrum Master.
Validación del experto.
Resultado de las pruebas.
Planificación
www.romanpichler.com Licensed under the Creative Commons CC BY-SA license
57
5.1.1 Requisitos deseables de la aplicación web
En esta sección se detallan los requisitos establecidos para el desarrollo de este trabajo. En la tabla 5.1 se muestran los requisitos funcionales y en la tabla 5.2 los no funcionales.
Nombre Descripción
REQ_F_01 Disponibilidad de una interfaz de registro de usuarios y acceso al sistema REQ_F_02 Desarrollo de un proceso de importación de registros procedentes
de diversas herramientas detime tracking
REQ_F_03 Existencia de una pestaña de configuración de usuario para personalizar ciertos atributos
REQ_F_04 Proceso de predicción de carga de trabajo en futuras semanas
REQ_F_05 Visualización de información sobre los días registrados con el fin de evaluar
la productividad del usuario y clasificar los días en función del tipo de trabajo realizado REQ_F_06 Seguimiento de los días registrados en el sistema ofreciendo una serie de
recomendaciones basadas en ellos
Tabla 5.1: Requisitos funcionales
Nombre Descripción
REQ_NF_01 Es deseable que la aplicación web tenga compatibilidad con diversos navegadores
REQ_NF_02 Una de las características con la que tiene que contar la aplicación es la concurrencia, ya que puede haber más de un usuario a la vez en el sistema realizando peticiones a la base de datos REQ_NF_03 La aplicación tiene que integrar un módulo de seguridad con el fin de que un usuario no pueda
acceder a las funcionalidades del sistema sin estar autentificado
REQ_NF_04 Adición de un sistema que permita el cierre de sesión de un usuario tras un determinado tiempo de inactividad
REQ_NF_05 Con respecto a la accesibilidad, la navegación entre las distintas páginas debe de ser lo más intuitiva posible para el usuario
REQ_NF_06 Definición de reglas y patrones en archivos externos al sistema. De esta manera no es necesario recompilar el sistema si se desea realizar modificaciones (configurabilidad).
Tabla 5.2: Requisitos no funcionales
5.1.2 Arquitectura del sistema
En esta sección se muestran dos esquemas de la arquitectura del sistema. El primero de ellos es la arquitectura general de la aplicación (ver figura 5.3) que muestra la importancia en este proyecto de la interacción con la base de datos y las reglas generadas con el proceso de descubrimiento de conocimiento. La siguiente figura es un diagrama más específico donde se ofrece una visión de la aplicación con la interacción entre los distintos módulos (ver figura 5.4).
Extracción del conocimiento
Base de datos Figura 5.3: Arquitectura general del sistema
Figura 5.4: Arquitectura de la aplicación
5.2 Iteración 0: Preparación del proyecto y esqueleto de la aplicación web
El punto de partida de este trabajo es la configuración de las herramientas principales utilizadas a lo largo de todo el proyecto, que sonTrello, TogglyGit. La primera sirve para gestionar y planificar el proyecto, la segunda para llevar un seguimiento del tiempo invertido en las tareas y la tercera es un software de control de versiones. El lector puede profundizar en los medios software utilizados en la sección 4.6.2. Para el desarrollo de la aplicación se plantearon dos posibles opciones, desarrollar una aplicación web o móvil paraAndroid.
La aplicación en Androidfue descartada debido a que la instalación del lenguajeR en este sistema es tediosa para el usuario, por lo que finalmente se decidió realizar su desarrollo como una aplicación web.
El lenguaje elegido para la generación de gráficos fue Rpor dos motivos principales. El primero de ellos es el alto número de librerías existentes para la generación de éstos y el segundo, el hecho de que su licencia es GPL.
El lenguaje elegido para el desarrollo de la aplicación fueJava, y por tanto se ha utilizado Spring Framework. Un plus en cuanto a la creación del proyecto con Java es la integra- ción con Maven1, una herramienta muy útil para la adición y actualización de librerías de forma autónoma. Al tener como objetivo una aplicación web, Bootstrap fue seleccionado para construir la partefront-endyMySQLcomo sistema gestor de base de datos. Respecto a Bootstrap, existe una gran cantidad de documentación y plantillas libres, por lo que facilita el desarrollo.
La estructura de este trabajo se puede observar en la figura 5.5 y se divide en dos bloques principales, los directoriosjavaywebapp. El primero contiene todos los ficheros fuente de java, que pueden ser de dos tipos, controladores o procesos. Los controladores son aquellas clases que actúan de intermediario entre el cliente y el servidor, mientras que los procesos realizan la lógica de la aplicación. Por último, contiene una carpeta de recursos donde se al- macenanscripts, como por ejemplo el código fuente del lenguajeRy el resto de componentes que interactúan en el lado del servidor.
Por otro lado, el directoriowebappcontiene las vistas, algunas librerías utilizadas en el proyecto y los archivos que definen los beans2. También contiene una carpeta de recursos, que se diferencia principalmente de la otra carpeta de recursos comentada en el párrafo ante- rior en que ésta almacena recursos que se ejecutan en el lado del cliente, comoCSVy javas- cript. Por último, el ficheroweb.xmlcontiene la configuración de la aplicación. Por ejemplo, en este fichero se define el DispatcherServlet, que es el encargado de enviar las peticiones a los manejadores3. En la sección D.0.2 se pueden encontrar algunas de la configuraciones realizadas.
1https://maven.apache.org/
2http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html 3http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/web/servlet/
DispatcherServlet.html
Figura 5.5: Estructura del proyecto
5.3 Iteración 1: Extracción de conocimiento
En este apartado se introduce el proceso de extracción de conocimiento donde, a partir de unos datos iniciales, se realiza una serie de procesos con el fin de obtener conocimiento. El proceso se aborda con un desarrollo en espiral ya que algunas etapas requieren más de una iteración hasta que se obtienen los resultados deseados. La realización de estos procesos es compleja, ya que para llevarlos a cabo es necesario entender y analizar los datos, y enfren- tarse a ciertos aspectos, como por ejemplo, el manejo de datos perdidos y la identificación de atributos que aportan información [FPS96].
5.3.1 Datos disponibles y selección
Para la realización de este trabajo se dispone de unos archivos de un profesor universitario dedicado a la docencia e investigación que contienen registros de tareas de aproximadamente 6 años (desde el año 2006 al 2013). Este profesor asumirá el rol de experto, puesto que en etapas finales será determinante su análisis.
Se dispone de alrededor de 18.000 registros y de 17 atributos que se explicarán a conti- nuación.
Número de semana: Número de la semana de un año dado.
Día de la semana: Contiene la inicial del día de la semana.
Fecha: La fecha de realización en formato día/mes/año.
Inicio: Hora de inicio de la tarea.
Fin: Hora de finalización de la tarea.
Interrupción: Tiempo invertido durante la realización de la tarea en otro asunto, como podría ser una llamada telefónica inesperada.
Tiempo efectivo: El tiempo invertido en la realización de la tarea sin añadir las inte- rrupciones.
Grupo de la tarea: Cada tarea se clasifica en un grupo. Por ejemplo, RESEARCH son aquellas tareas relacionadas con investigación y CLASSES las relacionadas con docencia.
Proyecto de la tarea: Es una etiqueta que engloba todos los grupos de tarea similares.
Por ejemplo, el grupoENGLISHcontiene proyectos cuyos nombres sonREADINGo LISTENING.
Descripción de la tarea: Breve resumen de lo que se realiza en la tarea.
Lugar de realización de la tarea: Contiene un carácter que indica el lugar de realiza- ción de la tarea. Por ejemplo ’C’ hace referencia a casa y ’U’ a universidad.
Prevista o imprevista: Si la tarea está planificada con anterioridad o es imprevista.
Porcentaje de finalización: Porcentaje del desarrollo de la tarea.
Año: Contiene el año en la que la tarea es realizada. Aunque exista el campo fecha es de interés reflejar aparte el atributo año, ya que puede tener un carácter discriminatorio.
En primer lugar, el conjunto de atributos elegidos que conforman la base de datos se con- sideran válidos para cubrir razonablemente el espacio de entrada. Por ahora se ha optado por valorar todos los atributos como válidos para la tarjeta de datos, pudiendo considerarse útiles debido al aporte de información. En la figura 5.6 se muestra un grupo de registros.
Figura 5.6: Ejemplo de registros
Una vez valorada la importancia de los atributos hay que valorar el rango de registros que se desea estudiar. En este caso se han obviado los registros correspondientes al año 2006 y 2007 ya que contienen un menor número de registros comparado con el resto de años y, al tratarse de tareas diarias, contienen numerosos saltos temporales que podrían añadir un mayor grado de imprecisión al estudio. Por tanto, para el desarrollo de este estudio se utilizan los registros correspondientes al periodo que va desde el 2008 hasta el 2013, disponiéndose aproximadamente de un total de 17.000 registros (Ver tabla 5.3).
Tras estudiar esta base de datos se puede considerar que es deseable para realizar KDD porque no es perfecta y contiene ruido, su tamaño es considerable, y no contiene resúmenes debido a que se dispone de los datos enbruto.
Año Total de registros
2006 280
2007 492
2008 1572
2009 2663
2010 3599
2011 3423
2012 3245
2013 2961
Tabla 5.3: Total de registros por año
5.3.2 Preproceso
En esta etapa se realiza una limpieza y preprocesado de algunos datos. A continuación se enumeran y describen de forma breve y concisa los pasos realizados, que pueden verse de forma gráfica en la figura 5.7.
Eliminación de fechas inconsistentes.
Unión de registros en un único fichero.
Eliminación de ruido y resto de inconsistencias.
Obtención e inserción de parámetros meteorológicos.
Figura 5.7: Esquema de preprocesado
El tratamiento de fechas y su correspondiente comprobación es una tarea compleja. Los años son más sencillos de comprobar que los meses, ya que cada base de datos contiene registros de un mismo año. En el siguiente ejemplo se tienen 4 registros con las siguientes fechas en el siguiente orden: 14/07/2010, 14/07/2010, 15/08/2010, 15/07/2010. Lo primero en que se puede pensar es que la fecha 15/08/2010 no es válida, puesto que sus adyacentes son del mes de julio. Pero puede ser que, el 14 de julio, la persona que introdujo estos registros tuviese vacaciones hasta el 15 de agosto, fecha que retomó para volver a introducir registros, y por tanto el fallo estuviese en el último registro (15/07/2010). Por tanto, aplicar una lógica correcta a la resolución de este conflicto de una forma automática no es trivial.
El segundo paso es la unión de los registros en un almacén de datos común. Éstos estaban separados en ficheros por años y para realizar un mejor procesamiento de ellos se ha realizado un proceso que unifica todos los registros.
A continuación se tratan el resto de atributos que contienen ruido e inconsistencias. Se han observado que existen diversos campos incompletos, como el número de semana, la inicial del día, el porcentaje de finalización, lugar de realización y naturaleza de las tareas. Los dos primeros se obtienen de manera directa, ya que son datos precisos. Para el resto se ha usado la moda con el fin de mitigar la mayor imprecisión posible. Los resultados son los siguientes:
Porcentaje_Finalización: 100 % Lugar_Realización_Tarea: ’C’ (Casa) Prevista_O_Imprevista: ’P’ (Prevista)
Para la comprobación del número de la semana se ha seguido la normaISO 8601, la cual considera que la primera semana del año es aquella que contiene el 4 de enero. También considera que el primer día de la semana es el lunes [FS04].
Por otro lado, si el campo del Proyecto tarea está vacío, se asigna el mismo campo que tenga Grupo tarea. Por último se ha eliminado el símbolo % del campo que contiene el porcentaje de finalización.
Respecto al lugar de realización de la tarea, las posibilidades se han reducido a dos, ’C’ y
’U’, que hacen referencia a casa y universidad respectivamente. Por ejemplo, las tareas que contenían ’V’, las cuales hacen referencia a viaje, o ’T’ detravel, eran aquellas tareas que se habían realizado en la universidad, por lo que se había realizado un desplazamiento ya que se considera casa la localidad de Ciudad Real y Universidad la localidad de Toledo.
La inmensa mayoría de erratas detectadas en los registros han sido provocadas por el factor humano, ya que los datos han sido introducidos de forma manual. Estos fallos son de diversa naturaleza, como la introducción de números fuera de un rango o caracteres no válidos, o simplemente el hecho de arrastrar un error mediante la copia del atributo en nuevos registros.
En la tabla 5.4 se muestran el número de inconsistencias y atributos vacíos localizados en los registros durante esta fase.
Atributo inconsistencias/nulos Porcentaje total
Fechas 1535 8.78 %
Inicial del día 1260 7.21 %
Numero de Semana 8845 50.62 %
Porcentaje de finalización 1855 10.61 %
Lugar de realización 452 2.58 %
Prevista/Imprevista 568 3.25 %
Tabla 5.4: Inconsistencias detectadas
En paralelo se ha creado una base de datos con los atributos de meteorología de Ciudad Real y Toledo desde el año 2008 al 2013, para posteriormente adicionar los datos necesarios a los registros de tareas, ya que se consideró interesante añadir al estudio factores meteoro- lógicos para comprobar si estos afectan de alguna forma en el rendimiento del trabajador . El acceso a estos datos es sencillo, ya que existen múltiples páginas web donde pueden ser encontrados. Sin embargo, obtener estos datos de forma manual, tratándose de una base de datos con un tamaño considerable, supondría la inversión de una cantidad ingente de tiempo.
Por esta razón, se ha diseñado un módulo de Web Scraping para la obtención de datos de forma automatizada.
Web Scrapinges un término que hace referencia a la obtención automática de información de sitios web. La página utilizada como fuente es Ogimet4, que contiene una base de datos de registros de meteorología de distintas localidades. Los campos significativos e interesantes para este estudio son las temperaturas, máxima, mínima y media, la humedad relativa y las características del propio día, es decir, si fue soleado, lluvioso, etc.
Ogimet clasifica las características del día en granizo, tormenta, lluvia, niebla y nieve. Para el almacenamiento de estos atributos, en primer lugar se han ordenado las características en función del grado de impacto que puede tener sobre la realización de las tareas, quedando de la siguiente manera: lluvia, granizo, tormenta, nieve y niebla. Si el trabajador se desplaza un día con niebla o nieve, quizá se retrase la hora en la que empieza a realizar sus tareas.
Algunos de los datos relacionados con la temperatura y la humedad relativa no quedaban registrados debido a que la base de datos deOgimetno tiene almacenadas entradas en algunas fechas. Para solventar este problema se ha realizado una nueva modificación, que consiste en asignarle a un campo vacío al atributo de la entrada anterior.
5.3.3 Transformación
La siguiente etapa realizada se denomina transformación. La filosofía seguida en esta etapa consiste en transformar los datos preprocesados, tanto en días como en semanas, con el fin de obtener resúmenes de ellos. Se comienza estudiando los días, puesto que el conocimiento generado se aplica como entrada a la transformación de semanas.
5.3.3.1. Agregación por días
En primer lugar se realiza una agregación de los días, es decir, un resumen de los datos agrupando las tareas de un mismo día en un único registro (ver figura 5.8). Para realizar este proceso, en primer lugar se ha obtenido un campo de amplitud, el cual es la diferencia entre el inicio de la tarea más temprana y el final de la última tarea. Por otro lado se han sumado las horas correspondientes a las interrupciones y el tiempo efectivo. Estos tres campos se han convertido a un formato decimal para que sean aplicables a un proceso posterior de normalización.
Para las temperaturas se ha creado una escala obteniendo los límites de los intervalos me- diante los cuartiles. En cuanto a la humedad relativa adecuada para el confort de las personas, este valor no debe de ser ni muy alto ni muy bajo. Como el intervalo de valores se encuentra entre 0 y 100, se ha usado la media y la desviación típica para obtener un intervalo, con- cretamente el comprendido entre el 44 y el 65. Los atributos que se encuentren dentro del intervalo indican una buena humedad relativa, por tanto se le asigna ’1’, mientras que los que quedan fuera del intervalo son identificados con un ’0’.
4http://www.ogimet.com/gclimat.phtml