Desarrollo de una aplicación para el tratamiento automático de encuestas

3 Contenido de la Portada Exterior Universidad de Valladolid Escuela de Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática (Mención … Título del trabajo Autor: D. Juan García García Mención en Computación Investigación y Desarrollo en Técnicas de Reconocimiento Biométrico mediante Dispositivos Ponibles Desarrollo de una Aplicación para el Tratamiento Automático de Encuestas D. Raúl Hernansanz Quevedo 4 Contenido de la Portada Interior Universidad de Valladolid Escuela de Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática (Mención … Autor: D. Juan García García Tutor: Dña. Juana García García Mención en Computación Investigación y Desarollo en Técnicas de Reconocimiento Biométrico mediante Dispositivos Ponibles (wearables) Dña. Irene Salvador Ortega D. Carlos Vivaracho Pascual Dña. María Aránzazu Simón Hurtado Tutores: Desarrollo de una Aplicación para el Tratamiento Automático de Encuestas D. Raúl Hernansanz Quevedo Agradecimientos El llegar hasta aquí y terminar este trabajo no ha sido esfuerzo de uno solo y, aunque se merezcan mucho más, me gustaría al menos dar las gracias al resto de personas que lo han hecho posible. Gracias a mi madre, Ana, por estar siempre ahí, por apoyarme en todo momento y por todo el cariño que me has dado durante estos cinco años, o bueno, durante estos 23 años. Gracias a mis tíos, Gemma y Javier, que aunque estén un poco más lejos, siempre están ahí para apoyarme y ayudarme. Gracias a esas dos personas que han hecho de esta etapa universitaria, una experiencia inolvidable. A Adrián por amenizar (casi todas) las clases y, con su sabiduría, solucionar hasta los peores problemas, y a Irene, por su paciencia, apoyo y por esa sonrisa que iluminaba los días más oscuros. Gracias una vez más y deciros que espero poder dároslas otra vez dentro de cinco, diez o quince años más. Gracias también a mis tutores, MaAránzazu Simón Hurtado y Carlos Vivaracho Pascual por el tiempo y apoyo que me han prestado durante la realización de este trabajo e incluso durante el resto de la carrera. Por último, quiero agradecer también a esas personas que, a pesar de no estar, sé que me están dando ánimos como los que más. Papá, abuelos, va por vosotros. 3 4 Índice general Índice de figuras 9 1. Introducción 13 1.1. Motivación.................................... 13 1.2. Objetivos .................................... 14 1.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2. Organización y proceso de gestión 17 2.1. Objetivos y prioridades de gestión . . . . . . . . . . . . . . . . . . . . . . . 17 2.2. Restricciones .................................. 17 2.3. Modelodeproceso ............................... 18 2.3.1. Marco general de SCRUM . . . . . . . . . . . . . . . . . . . . . . . 18 2.3.2. Adaptación de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4. Gestiónderiesgos................................ 20 2.4.1. Matriz de impacto / probabilidad . . . . . . . . . . . . . . . . . . . 23 3. Conceptos previos 25 3.1. Desarrollosoftware ............................... 25 3.2. Herramientas y lenguajes utilizados . . . . . . . . . . . . . . . . . . . . . . 27 3.2.1. Para la interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.2. Para el programa principal . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.3. Paralamemoria ............................ 27 5 6ÍNDICE GENERAL 4. Planificación 29 4.1. Requisitos.................................... 29 4.1.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2. ProductBacklog ................................ 32 4.3. Calendario de iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4. Costes ...................................... 34 4.4.1. Costelaboral .............................. 34 4.4.2. Costematerial.............................. 34 4.4.3. Gastosdeviajes............................. 35 4.4.4. Costes indirectos y beneficio empresarial . . . . . . . . . . . . . . . 35 4.4.5. Presupuesto detallado . . . . . . . . . . . . . . . . . . . . . . . . . 35 5. Seguimiento detallado 37 5.1. Primeraiteración................................ 37 5.1.1. Planificación de la primera iteración . . . . . . . . . . . . . . . . . . 37 5.1.2. Desarrollo de la primera iteración . . . . . . . . . . . . . . . . . . . 38 5.2. Segundaiteración................................ 38 5.2.1. Planificación de la segunda iteración . . . . . . . . . . . . . . . . . 38 5.2.2. Desarrollo de la segunda iteración . . . . . . . . . . . . . . . . . . . 40 5.3. Terceraiteración ................................ 40 5.3.1. Planificación de la tercera iteración . . . . . . . . . . . . . . . . . . 40 5.3.2. Desarrollo de la tercera iteración . . . . . . . . . . . . . . . . . . . 41 5.4. Cuartaiteración................................. 41 5.4.1. Planificación de la cuarta iteración . . . . . . . . . . . . . . . . . . 41 5.4.2. Desarrollo de la cuarta iteración . . . . . . . . . . . . . . . . . . . . 43 5.5. Quintaiteración................................. 43 5.5.1. Planificación de la quinta iteración . . . . . . . . . . . . . . . . . . 43 5.5.2. Desarrollo de la quinta iteración . . . . . . . . . . . . . . . . . . . . 43 5.6. Sextaiteración ................................. 44 5.6.1. Planificación de la sexta iteración . . . . . . . . . . . . . . . . . . . 44 5.6.2. Desarrollo de la sexta iteración . . . . . . . . . . . . . . . . . . . . 44 5.7. Séptimaiteración................................ 45 ÍNDICE GENERAL 7 5.7.1. Planificación de la séptima iteración . . . . . . . . . . . . . . . . . . 45 5.7.2. Desarrollo de la séptima iteración . . . . . . . . . . . . . . . . . . . 46 5.8. Octavaiteración................................. 46 5.8.1. Planificación de la octava iteración . . . . . . . . . . . . . . . . . . 46 5.8.2. Desarrollo de la octava iteración . . . . . . . . . . . . . . . . . . . . 46 5.9. Novenaiteración ................................ 46 5.9.1. Planificación de la novena iteración . . . . . . . . . . . . . . . . . . 46 5.9.2. Desarrollo de la novena iteración . . . . . . . . . . . . . . . . . . . 47 5.10.Décimaiteración ................................ 48 5.10.1. Planificación de la décima iteración . . . . . . . . . . . . . . . . . . 48 5.10.2. Desarrollo de la décima iteración . . . . . . . . . . . . . . . . . . . 48 5.11.Riesgospresentados............................... 48 6. Análisis 49 6.1. Modeladoconceptual.............................. 49 6.2. Modelodecasosdeuso............................. 51 6.3. Modelodedominio ............................... 53 6.4. Descripción de los casos de uso . . . . . . . . . . . . . . . . . . . . . . . . 53 6.4.1. Caso de uso Crear Diccionario . . . . . . . . . . . . . . . . . . . . . 56 6.4.2. Caso de uso Añadir variable . . . . . . . . . . . . . . . . . . . . . . 56 6.4.3. Caso de uso Eliminar variable . . . . . . . . . . . . . . . . . . . . . 56 6.4.4. Caso de uso Editar diccionario . . . . . . . . . . . . . . . . . . . . . 56 6.4.5. Caso de uso Crear Archivo de Parámetros . . . . . . . . . . . . . . 59 6.4.6. Caso de uso Crear Visualización . . . . . . . . . . . . . . . . . . . . 59 6.4.7. Caso de uso Eliminar Visualización . . . . . . . . . . . . . . . . . . 59 7. Diseño 63 7.1. Arquitectura de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.2. Realización en diseño de los casos de uso . . . . . . . . . . . . . . . . . . . 66 7.2.1. Caso de uso Añadir variable . . . . . . . . . . . . . . . . . . . . . . 66 7.2.2. Caso de uso Crear Archivo de Parámetros . . . . . . . . . . . . . . 71 7.3. Creación de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 7.3.1. Primerboceto.............................. 76 8ÍNDICE GENERAL 7.3.2. Encuesta inicial de usabilidad . . . . . . . . . . . . . . . . . . . . . 80 7.3.3. Primeraprueba............................. 80 7.3.4. Primera versión de la interfaz . . . . . . . . . . . . . . . . . . . . . 81 7.3.5. Segunda prueba y encuesta de usabilidad . . . . . . . . . . . . . . . 84 7.3.6. Tercera prueba y encuesta de usabilidad . . . . . . . . . . . . . . . 85 7.3.7. Sugerencias de los tutores . . . . . . . . . . . . . . . . . . . . . . . 86 7.4. Diseñodetallado ................................ 88 7.4.1. Clasescomunes ............................. 88 7.4.2. Modelo.................................. 91 7.4.3. Main................................... 93 7.4.4. Máquina de estados . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.4.5. InterfazPortada............................. 94 7.4.6. InterfazDiccionario . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 7.4.7. InterfazUsuario ............................. 99 8. Implementación y pruebas 105 8.1. Implementación.................................105 8.1.1. Paquetes utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 8.1.2. Dificultades en la implementación . . . . . . . . . . . . . . . . . . . 106 8.2. Pruebas .....................................107 9. Conclusiones y trabajo futuro 113 9.1. Conclusiones...................................113 9.2. Líneas de trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 10.Bibliografía 115 Anexos 117 A. Manual de Instalación de R 119 B. Manual de uso de la Interfaz 125 C. Contenido del CD 133 Índice de figuras 2.1. Matriz de impacto / probabilidad . . . . . . . . . . . . . . . . . . . . . . . 23 3.1. Proceso del desarrollo software . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.1. Calendarioglobal................................ 33 4.2. Presupuestodetallado ............................. 36 5.1. Primeratarea.................................. 37 5.2. Segundatarea.................................. 38 5.3. Terceratarea .................................. 39 5.4. Cuartatarea................................... 39 5.5. Quintatarea................................... 40 5.6. Sextatarea ................................... 41 5.7. Séptimatarea.................................. 42 5.8. Octavatarea................................... 42 5.9. Novenatarea .................................. 43 5.10.Décimatarea .................................. 44 5.11.Undécimatarea................................. 45 5.12.Décimosegundatarea ............................. 47 5.13.Décimoterceratarea .............................. 47 6.1. Diagrama de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.2. Esquema interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.3. Diagrama de modelo de casos de uso . . . . . . . . . . . . . . . . . . . . . 52 6.4. Diagrama de modelo de dominio . . . . . . . . . . . . . . . . . . . . . . . . 54 6.5. Descripción del caso de uso Crear Diccionario . . . . . . . . . . . . . . . . 55 6.6. Descripción del caso de uso Añadir Variable . . . . . . . . . . . . . . . . . 56 9 16 CAPÍTULO 1. INTRODUCCIÓN Capítulo 2 Organización y proceso de gestión A lo largo de esta sección se especificarán los objetivos principales del proyecto, así como las posibles restricciones que pueden darse. También se detallará el modelo de proceso elegido para la realización del trabajo y se enumerarán tanto los posibles riesgos como las medidas que se tomarán en el caso de que esos riesgos se den. 2.1. Objetivos y prioridades de gestión Para la realización de este proyecto, debido a la restricción de que todo el desarrollo debe ser realizado por una sola persona, las tareas de gestión se vuelven más complicadas que de costumbre, sin embargo, se van a intentar mantener los mismos objetivos que si fuera un proyecto normal, es decir: Productividad, se intentarán cumplir los plazos establecidos de la mejor forma posible para poder finalizar el proyecto en el tiempo estipulado. Reducción de los riesgos, se creará un plan de contingencia para todos los posibles riesgos que se crea que pueden surgir a lo largo de toda la realización del trabajo. Calidad, el objetivo principal es completar el proyecto, y que éste tenga la mayor calidad posible, procurando ir puliendo los fallos que puedan ir surgiendo durante su realización. 2.2. Restricciones Las restricciones fundamentales de este proyecto que serán enumeradas a continuación, son debidas a factores que limitarán la realización del mismo. Tiempo: El tiempo para la realización de este trabajo es limitado y llega hasta principios de Julio. 17 18 CAPÍTULO 2. ORGANIZACIÓN Y PROCESO DE GESTIÓN Recursos: Dado que se trata de un Trabajo Fin de Grado, no se dispone de una gran cantidad de recursos. Conocimientos limitados: Existen muchos detalles dentro del alcance del proyecto de los que apenas se poseen conocimientos, y por tanto esto implica la inversión de mayor cantidad de tiempo en adquirirlos. Equipo de trabajo: Como ya se ha mencionado anteriormente, al ser un Trabajo Fin de Grado, debe ser realizado únicamente por una persona. 2.3. Modelo de proceso Si se habla de desarrollo de software, se suele trabajar con el esquema tradicional de ciclo vida, ya que ha demostrado que es de bastante utilidad en numerosas situaciones. Sin embargo, su problema principal es que está enfocado a proyectos de gran tamaño y por tanto no parece ser el adecuado para el proyecto que se tiene entre manos. En el caso de proyectos de menor tamaño, las metodologías ágiles aportan una significativa simplificación y aun así no se pierde calidad. La estrella, por así decirlo, de estas metodologías ágiles es SCRUM[4], el cuál, además, es el que más se ha utilizado durante la carrera. A pesar de esto, debido a las restricciones mencionadas en la sección 2.2, no se puede aplicar SCRUM de forma pura y, por tanto, se aplicará una adaptación del mismo, la cual se detallará a continuación. 2.3.1. Marco general de SCRUM Los tres roles principales de esta metodología son los que siguen. Product Owner: Se trata del representante de los stakeholders o interesados del proyecto, es decir, el cliente. Scrum Master: Es la persona que más conocimiento posee de SCRUM y, por tanto, será el que se encargue de que se cumpla. Equipo de desarrollo: Los desarrolladores implicados en el proyecto. Al hablar de SCRUM debemos conocer y especificar una serie de eventos. Sprint: Son los periodos de trabajo en los que será dividido el proyecto, los cuales normalmente poseen una duración concreta y al final de los que se debe tener parte de la funcionalidad del proyecto. Hay que tener en cuenta que se debe planificar cada sprint antes de comenzarlo. Scrum meeting: Se tratan de reuniones diarias entre los miembros del equipo. 2.3. MODELO DE PROCESO 19 Sprint review: Es una reunión que se celebra al final un sprint en la que se echa la vista atrás para comprobar si se han cumplido los objetivos planeados, así como para hablar sobre la funcionalidad cubierta. Sprint retrospective: También se trata de una reunión que se produce al final de un sprint en la que se analizan los objetivos no cumplidos y se proponen medidas para poder mejorar en el siguiente sprint. 2.3.2. Adaptación de SCRUM Tras este pequeño resumen de en qué consiste SCRUM, se van a especificar los cambios a aplicar de cara al proyecto. En el caso de los roles, las personas que los van a llevar a cabo son las siguientes. Product Owner: Los tutores del trabajo, tanto los de la parte del Grado en Estadística como los del Grado en Informática. Scrum Master y equipo de desarrollo: Raúl Hernansanz Quevedo. La primera modificación a mencionar es la de que la duración de los sprints no estará fijada de antemano, de manera que cada uno de los que se realicen podrá tener una longitud variable. Debido a este motivo, se pasará a referirse a ellos como iteraciones en lugar de sprints. Esto es así debido al reducido equipo de desarrollo, así como a la existencia de otras tareas, entre las que se encuentran las Prácticas en empresa así como una asignatura del Grado. Sin embargo, todas las iteraciones realizadas finalizarán con una reunión con el cliente, ya sea de manera presencial o mediante un correo en el que se adjunte todo lo que se haya realizado en la iteración para que el cliente pueda validarlo y aportar su visión de la situación. A pesar de esto, durante los cuatro meses de duración del proyecto, se prevé la realización de ocho iteraciones, de aproximadamente dos semanas de duración. Aun así, como ya se ha mencionado, tanto la cantidad de iteraciones como la duración de las mismas podrá cambiar a lo largo de la realización del trabajo. La finalización de cada iteración conlleva una serie de tareas de las que ya se ha hablado en la sección 2.3.1. Realización del sprint review, aunque en el caso de esta adaptación, englobará también el sprint retrospective, de manera que analizará tanto la funcionalidad cubierta como la no cubierta. Además, como se ha decidido que no se realizarán sprints, sino iteraciones, se hará referencia a él de manera distinta. Reunión con los clientes para comprobar la funcionalidad añadida así como para detectar posibles fallos o correcciones. Planificación de la siguiente iteración, en base a las tareas no completadas, así como a las que restan. 20 CAPÍTULO 2. ORGANIZACIÓN Y PROCESO DE GESTIÓN Por último, otra de las cosas que variarán con respecto a SCRUM puro es que no se realizarán Scrum meeting debido a que no es necesaria la coordinación entre los miembros del equipo. La estructura que se seguirá en este documento para especificar la planificación y el seguimiento de las diferentes iteraciones será secuencial, de manera que habrá una sección para cada iteración y ésta estará dividida en dos partes, una para la planificación y otra para el seguimiento. 2.4. Gestión de riesgos La gestión de riesgos es una de las áreas más importantes que debe haber en la estructura de un proyecto, según propone el PMBOK [5]. El riesgo de no cumplir con los objetivos es más elevado al inicio del proyecto, debido al nivel de incertidumbre. La certeza de terminar con éxito aumenta gradualmente a medida que avanza el proyecto. A continuación se elaborará una lista de los posibles riesgos globales a los que se enfrenta el proyecto. Además de esto, al final del apartado de seguimiento se detallarán riesgos concretos que han aparecido en el desarrollo y los planes de contingencia aplicados a cada uno. Para cada riesgo identificado, se incluirá la siguiente plantilla. Identificador Identificador único del riesgo Descripción Descripción del riesgo Probabilidad Estimación de la probabilidad de ocurrencia del riesgo Consecuencias Consecuencias que puede tener la ocurrencia del riesgo Impacto Nivel de impacto que tendría en el proyecto el riesgo en cuestión Plan de contingencia Forma de actuar en el caso en que se produzca el riesgo Comentarios Comentarios sobre el riesgo Tabla 2.1: Plantilla de riesgos Una vez especificada la plantilla, se procederá a enumerar los riesgos globales del proyecto. 2.4. GESTIÓN DE RIESGOS 21 Identificador 1 Descripción Retrasos excesivos en las iteraciones Probabilidad Baja Consecuencias Los plazos estimados no se completan Impacto Muy elevado Plan de contingencia El plan de actuación en este caso es muy sencillo, habrá que aumentar el ritmo de producción, aumentando el número de horas diario invertido. Comentarios Identificador 2 Descripción Baja motivación Probabilidad Baja Consecuencias El ritmo de producción bajaría de forma considerable Impacto Muy elevado Plan de contingencia Para este riesgo no hay un plan de actuación como tal, pero para intentar minimizar el impacto se hablaría con los tutores para intentar buscar una solución. En el caso de que haya muchas holguras en los plazos se podría plantear un pequeño descanso para aumentar la motivación. Comentarios Identificador 3 Descripción Enfermedad de un miembro del equipo Probabilidad Media Consecuencias No se podría avanzar nada durante ese tiempo Impacto Elevado Plan de contingencia Comentarios En este caso, dado que sólo hay un miembro en el equipo, si la enfermedad le impide realizar tareas, habría que ajustar la planificación para contemplar ese tiempo sin avanzar. 22 CAPÍTULO 2. ORGANIZACIÓN Y PROCESO DE GESTIÓN Identificador 4 Descripción Poca disponibilidad de los clientes Probabilidad Baja Consecuencias No se podrían solucionar posibles problemas o dudas Impacto Elevado Plan de contingencia El miembro del equipo de desarrollo se deberá adaptar tanto como pueda a los horarios de los clientes y, en el caso de que aun así sea imposible tener reuniones con ellos, se deberán tratar todos los temas importantes a través del correo electrónico. Comentarios Identificador 5 Descripción Demasiada complejidad de los requisitos Probabilidad Media Consecuencias Posible reducción de los requisitos Impacto Elevado Plan de contingencia La forma de mitigar este riesgo es hablando con los clientes e intentando llegar a un acuerdo para reducir la complejidad de las tareas sin comprometer demasiado la funcionalidad deseada. Comentarios Identificador 6 Descripción Tiempo insuficiente Probabilidad Media Consecuencias Posible reducción de los requisitos Impacto Elevado Plan de contingencia Una vez más, la única solución posible es, ó aumentar las horas invertidas ó tratar con los clientes para reducir los objetivos del proyecto. Comentarios Identificador 7 Descripción Requisitos mal especificados o ambiguos Probabilidad Baja Consecuencias No se satisfacen las necesidades de los clientes Impacto Muy elevado Plan de contingencia Por último, la forma de reducir el impacto de este riesgo es mantener una reunión con los clientes para solventar los posibles problemas. Comentarios 2.4. GESTIÓN DE RIESGOS 23 2.4.1. Matriz de impacto / probabilidad En la siguiente tabla se resumirán los riesgos descritos en la sección 1.4. y además se indicará el impacto junto con una estimación de la probabilidad de ocurrencia de cada riesgo. Identificador Riesgo Impacto Probabilidad 1 Retrasos en las iteraciones 3 20 % 2 Baja motivación 2 5 % 3 Enfermedad de un miembro del equipo 1 15 % 4 Poca disponibilidad de los clientes 3 15 % 5 Complejidad elevada 4 10 % 6 Tiempo insuficiente 4 5 % 7 Requisitos mal especificados 3 5 % Tabla 2.2: Tabla de riesgos A partir de la tabla anterior se obtiene la siguiente matriz de riesgos. Figura 2.1: Matriz de impacto / probabilidad Como puede apreciarse en la figura 2.1, el riesgo número 1, Retrasos en las iteraciones es el que más hay que vigilar. Tampoco se pueden perder de vista el riesgo 5, Complejidad elevada, aunque tenga una probabilidad de ocurrencia baja, ni el riesgo 4, Poca disponibilidad de los clientes ya que este último también tiene un gran impacto y una probabilidad no despreciable. Todos los demás riesgos, aunque puedan tener consecuencias graves, las probabilidades de ocurrencia son muy bajas y, por tanto, no hay que prestarles demasiada atención, pero sin llegar a olvidarse de ellos. 24 CAPÍTULO 2. ORGANIZACIÓN Y PROCESO DE GESTIÓN Capítulo 3 Conceptos previos 3.1. Desarrollo software Esta breve sección estará dedicada a comentar todas las fases que se van a tratar en este documento, y que son necesarias en cualquier proyecto de desarrollo software. El proceso está dividido en cinco partes, las cuales aparecen listadas a continuación, además, en la figura 3.1 se puede ver de manera gráfica el proceso descrito. Análisis y planificación: Esta fase inicial consiste en la identificación de todos los requisitos que deberá tener la aplicación, así como planificar cómo va a ser desarrollada la misma. Aunque, al aplicar una variación de SCRUM, la parte de planificación irá evolucionando con el proyecto. Diseño: Es el primer paso en la fase de desarrollo de cualquier producto o sistema de ingeniería. Se trataría del proceso de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, proceso o sistemas con los suficientes detalles como para permitir su realización física. El objetivo del diseñador es producir un modelo que será construido mas adelante. Implementación: Es la parte en la que se programa la aplicación atendiendo tanto a los requisitos como al diseño creados en las fases anteriores. Pruebas: En esta fase se prueba todo lo desarrollado en la fase anterior buscando posibles fallos o problemas. Mantenimiento: Esta fase no se tendrá en cuenta en este proyecto. 25 32 CAPÍTULO 4. PLANIFICACIÓN 4.1.2. Requisitos no funcionales 18 Lenguaje Descripción La aplicación principal deberá estar programada en lenguaje R. Comentarios La forma de implementar dicha aplicación estará detallada en la memoria anexa [3] 19 Interfaz Descripción La aplicación deberá contar con una interfaz que permita indicar todos los datos necesarios así como ejecutar la aplicación sin necesidad de ver el código. Comentarios - 20 Sistema Descripción El sistema funcionará en el sistema operativo Windows. Comentarios - 21 Manual de usuario Descripción Se deberá proporcionar un manual de usuario que explique cómo funciona la aplicación. Comentarios - 4.2. Product Backlog En esta sección se van a listar las tareas por las que está compuesto el proyecto. La forma de indicarlas será de una manera global, es decir, cada tarea mostrada en la tabla 4.1 podría ser desglosada en varias subtareas con menor alcance. Estas subtareas estarán indicadas en la planificación de cada iteración junto con el elemento del Product Backlog al que hacen referencia. Backlog Item Horas Creación de la interfaz de usuario 120 Creación de un boceto y un prototipo de la interfaz de usuario 5 Desarrollo y aplicación de una serie de pruebas de cara a probar la usabilidad de la interfaz de usuario 25 Planteamiento y creación de los diagramas de diseño de la interfaz. 50 4.3. CALENDARIO DE ITERACIONES 33 Backlog Item Horas Creación del módulo de lectura de los diferentes formatos de los archivos de datos 15 Creación del módulo para la realización de tablas de 2 o 3 variables 15 Creación del módulo para la realización de gráficos de barras verticales u horizontales 15 Creación del módulo para la realización de gráficos de sectores 15 Creación del módulo que exporte los resultados a distintos formatos 45 Análisis de requisitos 20 Gestión (reuniones, etc.) 8 Pruebas integradas 12 Creación del manual de usuario 5 Creación de la memoria del proyecto 100 Total 450 Tabla 4.1: Product Backlog 4.3. Calendario de iteraciones Como la metodología de trabajo elegida ha sido SCRUM, no será necesario realizar un diagrama de Gantt que ilustre la planificación global del proyecto, puesto que, en SCRUM, la planificación se va realizando al finalizar cada iteración. No obstante, sí que se cree conveniente plantear un calendario global inicial para ilustrar cómo van a estar distribuidas las iteraciones, aunque dicho calendario podría cambiar dependiendo de las necesidades que vayan surgiendo. Figura 4.1: Calendario global 34 CAPÍTULO 4. PLANIFICACIÓN 4.4. Costes Por último, antes de comenzar a detallar la planificación real de cada iteración, así como su desarrollo, se va a detallar el coste total del desarrollo de esta aplicación. 4.4.1. Coste laboral Se va a partir de la base de que los que trabajan en el proyecto lo hacen en calidad de empleados de una empresa. Se debe tener en cuenta que el número de horas de trabajo efectivo de un trabajador ronda unas 1.500 horas al año, siendo un trabajo normal de 8 horas al día, 5 días a la semana. Como estamos considerando que se trata de una empresa, además del sueldo base habría que contar con la seguridad social, gastos médicos etc. Vamos a suponer que esto es un 30 % más sobre el salario base. Pongamos, por ejemplo, que el trabajador tiene un sueldo bajo de aprendiz de 1.200eal mes y que, los tutores, al tener más experiencia, cobran el doble, 2.400eal mes. Es decir, cada trabajador le cuesta a la empresa al año lo siguiente. Trabajador: 14 pagas x 1.200ex 1.3 = 21.840e Profesores: 14 pagas x 2.400ex 1.3 = 43.680e Entonces, si cada uno de ellos trabaja 1.500 horas, el coste por hora de cada trabajador sería: Trabajador: 21.840e/ 1.500 horas = 14.56e/hora Profesores: 43.680e/ 1.500 horas = 29.12e/hora Finalmente, llevando esos costes al caso que nos atañe, se debe pensar que para la realización del Trabajo Fin de Grado se dedican 450 horas, además, supongamos que al final del proyecto, se habrán invertido unas 8 horas de tutorías. Trabajador: 14.56e/hora x 450 horas = 6.552e Profesores: 29.12e/hora x 8 horas x 3 personas = 698.88e 4.4.2. Coste material En este apartado se tendrán en cuenta los costes del material necesario para la ejecución del proyecto. Será necesario un ordenador, el cual tiene una vida útil de 4 años, y se va a utilizar durante unos 5 meses. El coste de un ordenador normal es de unos 1.300epor tanto, para este proyecto, el coste es de: 4.4. COSTES 35 Ordenador: 1.300ex 5 meses / 48 meses = 125e Además, se utilizarán varios programas, sin embargo, son todos gratuitos, por lo que, en cuanto al software, solo habrá que tener en cuenta la licencia de Windows 10, la cual cuesta unos 140e. 4.4.3. Gastos de viajes A pesar de que yo viajo cada fin de semana al pueblo donde resido, solamente se van a tener en cuenta los viajes realizados para asistir a tutorías, que hemos dicho que iban a ser 8 horas, a una hora por cada tutoría, eso son 16 viajes. Entre Valladolid e Íscar hay 40 kilómetros, suponiendo que la empresa paga 0.30epor cada kilómetros se tiene el siguiente coste total. Viajes: 8 viajes x 40 km x 0.30e/km = 96e 4.4.4. Costes indirectos y beneficio empresarial Generalmente se tienen que tener en cuenta los costes indirectos, para ello, se considerará un porcentaje pequeño del coste total que se prevé cueste el proyecto, en este caso serán de un 5 %. Por último, hay que considerar que una empresa que produzca software desea obtener beneficio, por este motivo, supondremos que la empresa desea ganar un 50 % del coste total del proyecto. 4.4.5. Presupuesto detallado Teniendo en cuenta todo lo anterior, el presupuesto final que la empresa debería cobrar a los clientes por realizar este proyecto tendría una cuantía de 11.988,71e. 36 CAPÍTULO 4. PLANIFICACIÓN Figura 4.2: Presupuesto detallado Capítulo 5 Seguimiento detallado 5.1. Primera iteración 5.1.1. Planificación de la primera iteración Esta primera iteración, se centra en su mayor parte en la realización de varios apartados de la memoria principal, así como en otro de los elementos del Product Backlog. Estos dos elementos se encuentran indicados en las figuras 5.1 y 5.2. Figura 5.1: Primera tarea De esta tarea, se pretende escribir los siguientes apartados. Organización y proceso de gestión, y todas las sub-secciones correspondientes. Planificación, y todas las sub-secciones correspondientes, hasta la planificación de la segunda iteración. Diseño conceptual de la aplicación. 37 38 CAPÍTULO 5. SEGUIMIENTO DETALLADO Figura 5.2: Segunda tarea El motivo de que esta primera iteración esté centrada en la realización del informe es que el cliente no tiene disponibilidad debido a su trabajo y, por tanto, se ha decidido que la mejor opción es avanzar el informe hasta que se produzca una reunión con él para tratar una serie de temas de la implementación. 5.1.2. Desarrollo de la primera iteración En esta sección se detallará brevemente cómo ha ido el desarrollo de esta iteración, los posibles contratiempos surgidos, etc. Esta primera iteración ha finalizado de manera satisfactoria, pudiéndose realizar todas las tareas previstas. Además, se ha tenido una reunión con un profesor del Grado en Ingeniería Informática[12] para tratar temas relacionados con la organización y el proceso de gestión. 5.2. Segunda iteración 5.2.1. Planificación de la segunda iteración En esta segunda iteración, se va a continuar trabajando en temas necesarios para comenzar con el desarrollo de la aplicación, además de que se tiene prevista una reunión con el tutor del Grado en Estadística[13] para tratar temas del programa de R y, una vez realizada, se comenzará con la implementación de esa parte del programa. Continuando con la memoria, se pretende escribir los siguientes puntos. Planificación de la segunda iteración. Análisis de paquetes R para el tratamiento de encuestas. Adicionalmente a esto, se indican a continuación los elementos del Product Backlog que serán realizados en esta iteración. 5.2. SEGUNDA ITERACIÓN 39 Figura 5.3: Tercera tarea Figura 5.4: Cuarta tarea 40 CAPÍTULO 5. SEGUIMIENTO DETALLADO 5.2.2. Desarrollo de la segunda iteración La segunda iteración realizada también ha salido bastante bien, sin embargo, no se ha podido finalizar la tarea de diseño y, por tanto se continuará en posteriores iteraciones. En la reunión con el tutor se han aclarado bastantes aspectos relacionados con diversos temas del proyecto, además se ha mostrado el avance del mismo para obtener la aprobación del cliente. Gracias a esta reunión se podrá seguir avanzando de manera correcta en futuras iteraciones. 5.3. Tercera iteración 5.3.1. Planificación de la tercera iteración La tercera iteración, a diferencia de las dos primeras, estará más enfocada al apartado del desarrollo de la aplicación, no obstante, también se avanzará la memoria del proyecto. Por este motivo, una vez más, se avanzará en algunos elementos del Product Backlog además de otras tareas. En cuanto a la memoria correspondiente, se avanzará en los siguientes puntos. Planificación y desarrollo de la tercera iteración. Documentación de los módulos desarrollados de la aplicación. Reunión con los tutores de informática. Adicionalmente a esto, se pretende avanzar en algunos elementos del Product Backlog que se indicarán a continuación en la figura 5.5 y en la figura 5.6. Figura 5.5: Quinta tarea Esta vez, la iteración está centrada en el desarrollo, esto es así gracias a la reunión descrita en la sección anterior, en la que se clarificaron varios aspectos del proyecto. Además, de esto, se concertará una reunión con los tutores del Grado en Ingeniería Informática para tratar otra serie de temas relevantes para el proyecto de los que se hablará más adelante. 5.4. CUARTA ITERACIÓN 41 Figura 5.6: Sexta tarea 5.3.2. Desarrollo de la tercera iteración En esta sección, como en el caso anterior, se comentará de forma breve cómo se ha desarrollado esta tercera iteración. A lo largo de las dos semanas de iteración se ha producido un contratiempo personal que ha producido un poco de retraso en la planificación. Sin embargo, se ha completado todo lo planeado de manera correcta. Una vez más, al igual que en la iteración anterior, se ha concertado una reunión, esta vez con los tutores de informática en la cual se han resuelto temas relacionados con la interfaz de usuario que se va a desarrollar. Tras la finalización de esta iteración, se mostrará el avance conseguido al cliente para que dé su aprobación o proponga modificaciones. 5.4. Cuarta iteración 5.4.1. Planificación de la cuarta iteración Tras la reunión con los tutores, se va a comenzar con la realización de la interfaz además, se continuará con la tarea relacionada con el diseño que no se pudo completar en la segunda iteración. Por último, se mantendrá una reunión con un profesor de informática para solucionar las dudas relacionadas con el diseño. Las tareas con las que se va a avanzar se enumerarán a continuación. Planificación y desarrollo de la cuarta iteración. Reunión con un profesor del Grado Ingeniería Informática de cara a clarificar el diseño de la interfaz. Adicionalmente a esto, se pretende avanzar en varios elementos del Product Backlog que se indicarán a continuación en la figura 5.7 y en la figura 5.8. 48 CAPÍTULO 5. SEGUIMIENTO DETALLADO 5.10. Décima iteración 5.10.1. Planificación de la décima iteración Esta iteración está pensada para completar todas las tareas restantes que se tienen, es decir, la idea de esta iteración es completar el trabajo, sin tener en cuenta posibles correcciones planteadas por los tutores sobre la memoria, ni la preparación de la presentación para la exposición. Por tanto, las tareas indicadas en la iteración anterior, pasan a formar parte de estas. Dichas tareas pueden verse en las figuras 5.1, 5.12 y 5.13. 5.10.2. Desarrollo de la décima iteración La décima iteración ha sido finalizada de forma satisfactoria, habiendo completado todas las tareas planteadas. En la semana restante antes de la entrega del proyecto, se realizaran las posibles correcciones planteadas por los tutores así como añadir la bibliografía a la memoria final. 5.11. Riesgos presentados A lo largo del desarrollo completo del proyecto, se han producido una serie de problemas que han tenido un impacto en la planificación inicial. Dichos riesgos pueden ser resumidos en dos. Problemas con el desarrollo de la aplicación, causados por errores puntuales o por falta de conocimiento para realizar ciertas tareas. Problemas con la memoria, los cuales han sido debidos a una mala estimación de las horas necesarias para escribir la misma. La principal forma de suplir estos problemas, ha sido dedicar horas extra diarias a la realización de tareas, así como ampliar las 9 iteraciones inicialmente planeadas con una décima de dos semanas de duración, que ha permitido finalizar el proyecto, consiguiendo además una semana de margen para poder realizar posibles correcciones. Capítulo 6 Análisis Antes de dar paso al diseño de la aplicación, se va a realizar la parte de análisis. En ella se mostrarán todos los diagramas de modelado necesarios, así como una descripción de los casos de uso que debe abordar la aplicación. 6.1. Modelado conceptual En esa sección se tratará de explicar, de forma conceptual, en qué consiste la aplicación, y cuál es su objetivo. La forma de alcanzar ese objetivo, es decir, el funcionamiento interno, se detallará en secciones posteriores de este mismo documento. La idea general de la aplicación es el tratamiento automático de encuestas, es decir, el usuario provee a la aplicación de un archivo de datos procedentes de una encuesta, y solicita alguna de las visualizaciones ofertadas por la aplicación. De esta manera, la aplicación realizará esas visualizaciones y creará un documento con ellas en el formato que indique el usuario. Esto puede verse en forma de esquema en la figura 6.1 Para este proyecto, se ha decidido dividir la aplicación en dos partes diferenciadas, la primera de ellas se trata de la interfaz de usuario, que es de la que se va a hablar en este documento. La segunda parte es un programa en Rque creará las visualizaciones y obtendrá el documento solicitado pero, esta segunda parte se explicará en el documento anexo[3]. En lo que respecta a la parte de la interfaz, su función es proveer al programa en R de todo lo necesario para poder trabajar, esto es. Ruta en la que se encuentra R. Parámetro obligatorio. Ruta en la que se encuentra el fichero de datos. Parámetro obligatorio. Separador del fichero de datos. Parámetro obligatorio. Formato de destino del informe. Parámetro obligatorio. 49 50 CAPÍTULO 6. ANÁLISIS Figura 6.1: Diagrama de la aplicación Ruta en la que se guardará el informe final. Parámetro optativo. Visualizaciones que se desean. Obligatorio indicar al menos una. Diccionario de datos para la encuesta. Parámetro optativo. Nombre que tendrá el informe resultado. Parámetro obligatorio. Nombre del factor de elevación de la encuesta. Parámetro obligatorio. Para ello, la interfaz recibirá un archivo de texto en el que el usuario indicará los formatos de salida, los separadores y los tipos de visualizaciones. El motivo de esto es que el usuario pueda ampliar la funcionalidad de la aplicación sin necesidad de acceder al código fuente, teniendo en cuenta que deberá modificar el programa en R para contemplar los nuevos parámetros que cree. Una vez se han indicado todos los parámetros obligatorios y pulsado aceptar, la interfaz creará dos ficheros de texto, uno para el diccionario y otro para el resto de parámetros y llamará a la aplicación de R para que cree las visualizaciones utilizando esos ficheros. De manera interna, la interfaz está compuesta por distintas ventanas con la composición que se ve en la figura 6.2. Así pues, la mayor parte de la funcionalidad se encontraría en las ventanas principal y de diccionario, siendo las de portada y espera meramente decorativas, y la de warning tendrá la función de informar al usuario en el caso de que el archivo que desea crear ya exista en la ubicación que haya indicado, dándole la opción de reemplazarlo o de cancelar la operación. 6.2. MODELO DE CASOS DE USO 51 Figura 6.2: Esquema interfaz de usuario 6.2. Modelo de casos de uso A partir de la especificación de requisitos, se han obtenido los casos de uso del sistema. Como el objetivo de esta parte del proyecto es la creación de la interfaz, solo se distingue un actor que puede realizar los casos de uso. Usuario: usuario que utilizará la interfaz. A continuación, se van a detallar los casos de uso que se han encontrado y que pueden verse en la figura 6.3. Crear archivo de parámetros: se introducen todos los datos necesarios para la aplicación. Crear visualización: se añade una nueva visualización a la lista. Eliminar visualización: se elimina la visualización que desee el usuario. Crear diccionario: se crea un diccionario asociado. Añadir variable: se añade una variable al diccionario. 52 CAPÍTULO 6. ANÁLISIS Figura 6.3: Diagrama de modelo de casos de uso 6.3. MODELO DE DOMINIO 53 Eliminar variable: se elimina la variable del diccionario que desee el usuario. Editar diccionario: se edita el diccionario para añadir o eliminar variables. 6.3. Modelo de dominio En esta sección se describirá el modelado de dominio de la interfaz. A continuación, en la figura 6.4, se muestra el esquema del modelo en UML[14] (realizado con Astah) con las entidades y las relaciones entre ellas, incluyendo multiplicidades. También se muestran los atributos de cada entidad. El modelo contiene las siguientes entidades: FuenteDeDatos: representa la clase principal del sistema, contiene todos los elementos necesarios para el funcionamiento de la aplicación. Está relacionado con la clase Diccionario, y también con la clase Visualización. Diccionario: representa el diccionario asociado a los datos. Está relacionada con la clase FuenteDeDatos y con la clase Entrada. Entrada: representa cada componente por el que está formado el diccionario. Visualización: representa las visualizaciones requeridas por el usuario. Está relacionada con la clase FuenteDeDatos. En lo que respecta a las relaciones, simplemente mencionar que la que existe entre las entidades FuenteDeDatos y Diccionario, tiene multiplicidades 1 a 0..1 ya que no es necesaria la creación de un diccionario pero, en el caso de crearlo, solo se podría crear uno. Además, la relación entre la entidad Diccionario y la entidad Entrada, indica que para que exista un diccionario, tiene que existir al menos una entrada en el mismo. La otra relación existente, se trata de la que hay entre las entidades FuenteDeDatos y Visualización, con multiplicidades 1 a 1..*. Es este caso, para que la entidad Datos esté completa, debe contar al menos con una visualización, pero puede tener todas las que se quiera. 6.4. Descripción de los casos de uso En esta sección se detallarán todas las secuencias de cada uno de los casos de uso mostrados en la sección 4.1 54 CAPÍTULO 6. ANÁLISIS Figura 6.4: Diagrama de modelo de dominio 6.4. DESCRIPCIÓN DE LOS CASOS DE USO 55 Figura 6.5: Descripción del caso de uso Crear Diccionario 56 CAPÍTULO 6. ANÁLISIS 6.4.1. Caso de uso Crear Diccionario El primer caso de uso que se describirá será el de crear diccionario, su secuencia se encuentra detallada en la figura 6.5. 6.4.2. Caso de uso Añadir variable Este caso de uso es una parte incluida dentro del caso de uso descrito en la sección anterior, aun así, se indicará su secuencia en la figura 6.6. Figura 6.6: Descripción del caso de uso Añadir Variable 6.4.3. Caso de uso Eliminar variable Se muestra su secuencia en la figura 6.7. 6.4.4. Caso de uso Editar diccionario Se muestra su secuencia en la figura 6.8. 6.4. DESCRIPCIÓN DE LOS CASOS DE USO 57 Figura 6.7: Descripción del caso de uso Eliminar Variable 64 CAPÍTULO 7. DISEÑO actualizarse en tiempo real en el momento de actualización del Modelo. Esto está fundamentalmente pensado para aquellas aplicaciones en las que múltiples personas se encuentran trabajando globalmente. En el caso que nos ocupa, esto no se va a dar. A continuación se explican de manera breve los tres complementes de este patrón. Modelo: contiene toda la información final con la que trabaja la aplicación. Vista: encargada de mostrar la información al usuario. Controlador: se encarga de manejar las comunicaciones entre la vista y el modelo. Figura 7.1: Modelo Vista Controlador En la imagen 7.1, se muestra visualmente el funcionamiento de este modelo, su explicación es muy sencilla. El usuario realiza las peticiones al controlador, este a su vez, realiza las acciones pertinentes ya sea actualizando el modelo y/o la vista y, en el caso de actualizar el modelo, la vista se actualiza con los nuevos datos del modelo, mostrándoselos al usuario. La arquitectura global de la aplicación puede encontrarse en la figura 7.2. 7.1. ARQUITECTURA DE LA APLICACIÓN 65 Figura 7.2: Arquitectura de la Aplicación 66 CAPÍTULO 7. DISEÑO 7.2. Realización en diseño de los casos de uso En esta sección se van a describir, de forma detallada, tres de los casos de uso listados en la sección anterior. 7.2.1. Caso de uso Añadir variable En primer lugar, se mostrará la realización del caso de uso en la fase de análisis. A este nivel no nos preocupamos de los detalles técnicos de la solución final ni de las clases que la componen. La figura 7.3 muestra el diagrama de secuencia para este caso de uso. Una vez que los detalles de análisis están cubiertos, se procede a la realización en diseño de este caso de uso. La diferencia con el anterior diagrama de secuencia, será que el que se produzca en esta fase contendrá detalles sobre las clases que se crearán en nuestra aplicación, así como será dependiente del lenguaje de programación utilizado (en este caso, Java). Las figuras 7.4, 7.5 y 7.6 muestran el diagrama de secuencia producido en diseño. Dada su complejidad, ha sido dividido en tres trozos, donde cada uno es la continuación natural del anterior. El actor usuario pulsa sobre la vista de la Portada, la cual manda un evento a su controlador que le pide a la máquina de estados que muestre la ventana principal de la interfaz. Una vez ahí, el actor usuario presiona sobre el botón de crear/editar diccionario, una vez hecho esto, la vista actual le manda un evento a su controlador, que a su vez le pide a la máquina de estados que cambie a la ventana de creación de diccionario. Una vez se crea la vista de creación del diccionario, y su controlador asociado, dicho controlador creará un objeto diccionario vacío y lo almacenará de forma local. A continuación, solicitará a la clase Fuente de Datos, el diccionario, si existiera, que dicha clase tiene almacenado. Una vez obtenido, el controlador actualizará el diccionario que había creado inicialmente con los valores que contenga el obtenido de la Fuente de Datos. Tras esto, el actor usuario pulsa el botón añadir variable, la vista envía un evento a su controlador, el cual obtiene los tres campos en cuestión, nombre, código y descripción de su vista asociada, comprueba si son correctos y los añade a su diccionario local. Cuando el usuario ha finalizado de introducir variables, presiona el botón aceptar, que desencadena que la vista envíe un evento a su controlador, el cual actualiza el diccionario de la clase Fuente de Datos y le pide a la máquina de estados que vuelva a mostrar la ventana principal de la interfaz. 7.2. REALIZACIÓN EN DISEÑO DE LOS CASOS DE USO 67 Figura 7.3: Realización en análisis del CU Añadir Variable 68 CAPÍTULO 7. DISEÑO Figura 7.4: Realización en diseño del CU Añadir Variable parte 1 7.2. REALIZACIÓN EN DISEÑO DE LOS CASOS DE USO 69 Figura 7.5: Realización en diseño del CU Añadir Variable parte 2 70 CAPÍTULO 7. DISEÑO Figura 7.6: Realización en diseño del CU Añadir Variable parte 3 7.2. REALIZACIÓN EN DISEÑO DE LOS CASOS DE USO 71 7.2.2. Caso de uso Crear Archivo de Parámetros En primer lugar, se mostrará la realización del caso de uso en la fase de análisis. A este nivel no nos preocupamos de los detalles técnicos de la solución final ni de las clases que la componen. La figura 7.7 muestra el diagrama de secuencia para este caso de uso. Una vez que los detalles de análisis están cubiertos, se procede a la realización en diseño de este caso de uso. La diferencia con el anterior diagrama de secuencia, será que el que se produzca en esta fase contendrá detalles sobre las clases que se crearán en nuestra aplicación, así como será dependiente del lenguaje de programación utilizado (en este caso, Java). Las figuras 7.8, 7.9 y 7.10 muestran el diagrama de secuencia producido en diseño. Dada su complejidad, ha sido dividido en tres trozos, donde cada uno es la continuación natural del anterior. El actor usuario pulsa sobre la vista de la Portada, la cual manda un evento a su controlador que le pide a la máquina de estados que muestre la ventana principal de la interfaz. Una vez ahí, el actor usuario debe comenzar el caso de uso “Añadir visualización”, ya que es necesario crear al menos una. El actor usuario presionará el botón de añadir visualización, momento en el cual la vista le enviará un evento a su controlador, y este obtendrá todos los parámetros necesarios, es decir, el tipo, la medida, y las variables, creará una visualización con ellos, se la pasará a la clase Fuente de Datos, después pedirá a esa misma clase la lista de visualizaciones que tiene guardadas, y se la pasará a su vista asociada para que se actualice con ellas. Esto se repetirá tantas veces como el usuario desee. Una vez finalizado ese caso de uso, se continúa con el de “Crear archivo de Parámetros”, el actor usuario puede proceder de dos maneras. La primera es que pulse el botón crear/editar diccionario, momento en el cual se desencadenará el caso de uso “Crear o editar diccionario”. Este caso de uso no se va a detallar debido a su parecido con el que se ha explicado en la sección anterior. La segunda forma de proceder es que presione el botón aceptar. Si el actor usuario pulsa el botón aceptar, la vista enviará un evento a su controlador, el cual obtendrá todos los parámetros necesarios, véase la ruta de R, la ruta del archivo de datos, el separador, el formato de destino, la ruta de destino, el factor de elevación y el nombre de destino, actualizará la clase Fuente de datos con ellos y, tras comprobar que todos son correctos, creará los ficheros de texto con todos esos datos para, finalmente, realizar una llamada al programa de R utilizando la ruta en la que se encuentra, es decir, la ruta de R. La variable conocida como factor de elevación hace referencia a una variable calculada en base al diseño de la encuesta y que permite realizar los cálculos de forma sencilla, sin tener que trabajar con dicho diseño, ya que es el factor que hay que aplicar a cada observación para poder obtener lo que se quiera. Más información de esta variable puede ser obtenida en la memoria anexa[3]. 72 CAPÍTULO 7. DISEÑO Figura 7.7: Realización en análisis del CU Crear Archivo de parámetros 7.2. REALIZACIÓN EN DISEÑO DE LOS CASOS DE USO 73 Figura 7.8: Realización en diseño del CU Crear Archivo de parámetros parte 1 80 CAPÍTULO 7. DISEÑO 7.3.2. Encuesta inicial de usabilidad Una vez se tenía el boceto inicial de la aplicación, se procedió a realizar una encuesta de usabilidad con diferentes personas, en la cual, dichas personas debían realizar una tarea sin ayuda. La idea es que se pueda realizar la prueba a cualquier persona, ya sea alguien con experiencia tecnológica, o sin ella. Con esta encuesta se pretendía refinar la interfaz, modificando los aspectos más confusos o los que llevaran más tiempo, además de recopilar las posibles ideas que se les ocurrieran a los participantes. Al comenzar el ejercicio se les leía el siguiente párrafo a los usuarios. La aplicación que vas a utilizar sirve para crear, de manera automática, una serie de visualizaciones, como pueden ser diferentes tipos de gráficos, así como tablas, partiendo de archivos de datos de encuestas. En ella se deben indicar una serie de parámetros básicos sobre el fichero en el que están los datos y también, las visualizaciones que deseas. A continuación, se te propondrá una tarea a realizar, paso por paso, para comprobar la usabilidad de la interfaz de usuario diseñada para la aplicación. En ella, se te irá explicando poco a poco qué hacer en cada momento y se tomará nota de las partes que te cuesten más. Al finalizar la tarea, se te harán una serie de preguntas para valorar tu opinión y realizar las modificaciones pertinentes en dicha interfaz. Una vez dicho esto, se comenzaba inmediatamente a describir la prueba, la idea es que el usuario fuera realizando la tarea a medida que se le iba leyendo el enunciado. 7.3.3. Primera prueba Primero se expondrá el “enunciado” de esta prueba y, después, se adjuntará una imagen de los resultados obtenidos. Has obtenido un archivo de datos perteneciente a una encuesta sobre salarios en España y deseas crear dos tipos de gráficos y una tabla con el mismo. Lo primero que tienes que hacer es indicar dónde se encuentra el archivo de datos a la aplicación. En este caso el archivo de datos es una hoja de Excel, en la que el separador de cada columna es el punto y coma y, además, lo que tu deseas es obtener las visualizaciones en formato CSV. Como quieres que los nombres de los campos sean los adecuados, vas a crear un diccionario de datos para esta encuesta. Sabes que solo necesitas 2 variables diferentes con 2 niveles cada una. La primera variable es TSexo, y tiene dos códigos, el primero es H, que significa Hombre, el segundo es M, que significa Mujer. La segunda variable es TNacionalidad, también con dos códigos, el primero es 1que significa Español, el segundo es 2, que significa Alemán. Una vez aceptas la creación del diccionario, vuelves a la pantalla principal para indicar las visualizaciones que deseas. Lo primero que quieres es un gráfico de barras horizontales, que represente la media de la variable respuesta SALARIO frente al SEXO y a la NACIONALIDAD. 7.3. CREACIÓN DE LA INTERFAZ 81 El segundo gráfico se trata de un gráfico de sectores que represente lo mismo. Por último, quieres una tabla en la que se mida el total de la variable SALARIO frente al SEXO. Una vez tienes las 3 visualizaciones, indicas la ruta de destino en la que quieres el CSV y terminas. Figura 7.13: Resultados de la primera encuesta Como se puede ver en la figura 7.13, tanto los problemas surgidos como las sugerencias de mejora son cosas con poco impacto en el desarrollo. Esto puede ser debido a que la tarea a la que esta destinada la aplicación es sencilla e incluso gente poco familiarizada con la tecnología no ha tenido problemas a la hora de utilizar la “aplicación”. Cabe destacar que este primer “test” no ha sido realizado a los clientes principales de la aplicación debido a que se ha preferido esperar a tener la interfaz funcional desarrollada para que pudieran probarla directamente y encontrar fallos o mejoras directamente con toda la funcionalidad implementada. Una vez realizada la primera encuesta, se comenzó con el desarrollo de la aplicación. A continuación, se mostrará la primera versión de la interfaz sin entrar en su funcionamiento, el cual ya se detallará en secciones posteriores. Después de esto, se incluirá una nueva tabla con los resultados de la segunda encuesta de usabilidad y funcionalidad y, a raíz de ella, se detallarán los problemas surgidos y las modificaciones realizadas, teniendo en cuenta que esta vez sí que se incluirá a los clientes principales en la encuesta. 7.3.4. Primera versión de la interfaz En las imágenes 7.14 y 7.15 se muestra la primera versión de la interfaz ya implementada. 82 CAPÍTULO 7. DISEÑO Figura 7.14: Primera versión de la ventana principal 7.3. CREACIÓN DE LA INTERFAZ 83 Figura 7.15: Primera versión de la ventana de creación del diccionario 84 CAPÍTULO 7. DISEÑO Como puede verse, la mayor parte de las modificaciones han sido aplicadas a esta primera versión. Se han separado mediante marcos las zonas izquierda y derecha de la ventana principal y, además, se han añadido botones para eliminar tanto visualizaciones como variables en el diccionario. Una vez mostrada la interfaz, se va a explicar la realización de la segunda encuesta en la que, esta vez, se tenían que realizar dos tareas, la primera es la misma que ya se ha expuesto y, la segunda, intentaba centrarse en la nueva funcionalidad de eliminar visualizaciones y variables. 7.3.5. Segunda prueba y encuesta de usabilidad Como ya se ha indicado, esta prueba era la misma que la anterior, pero realizada sobre la interfaz ya implementada, por lo que no se volverá a indicar el enunciado, pero sí los resultados, los cuales se muestran en la figura 7.16. Figura 7.16: Resultados de la segunda encuesta Con estos resultados, se ve que a partir de la cuarta persona que probó la aplicación, no se produjeron más errores, esto es así porque a medida que aparecían los errores, se iban solucionando. A continuación se detallan los errores surgidos y cómo han sido solventados. 7.3. CREACIÓN DE LA INTERFAZ 85 Problemas con el diccionario: Los primeros problemas surgidos estaban relacionados con la forma de crear el diccionario, y consistían en que, al crear una variable, y darle a aceptar, esta variable se guardaba correctamente, sin embargo, si se editaba el diccionario y se eliminaba dicha variable, la interfaz seguía indicando que el diccionario estaba creado, aunque no hubiera ninguna variable añadida. Problemas al crear el archivo del diccionario: A raíz de solventar el primer problema, se tocó parte del código relacionado con la exportación de los datos a los ficheros, y esto provocó que el fichero del diccionario no se creara correctamente. Problemas con las visualizaciones: Al crear una visualización, se modificaban todas las ya creadas. Tras exponer los errores, se indicarán brevemente las soluciones que fueron aplicadas a los mismos. Problema del diccionario: Se ha modificado la forma de guardar las variables en el modelo y la forma en la que se creaban en el controlador, de esta forma todo funcionaba correctamente. Problemas de creación de ficheros: Se retocó la función que obtenía los datos del modelo. Problemas con las visualizaciones: Las variables en la clase estaban marcadas como estáticas y, por tanto, solo almacenaban el último valor indicado. 7.3.6. Tercera prueba y encuesta de usabilidad Una vez se solucionaron todos los problemas encontrados tras la anterior prueba, se procedió con un último ejercicio de cara a probar la funcionalidad nueva de eliminar visualización, el enunciado de la prueba es el siguiente. Esta segunda tarea será similar a la primera, pero centrada en probar el funcionamiento de los botones de eliminar. Una vez más comienzas por indicar dónde se encuentra el archivo de datos, pero esta vez el separador de las columnas es el tabulador y el formato de destino es pdf. Seguidamente piensas en crear un diccionario. Indicas la variable ESTUDIOS, con código 1 y descripción “Básicos” y el código 2 y descripción “Avanzados”. Aceptas la creación, pero después piensas que no necesitas el diccionario, por tanto lo editas, eliminas ambas variables y una vez más aceptas. En cuanto a las visualizaciones, para esta segunda tarea necesitas un gráfico de líneas que mida la media de la variable PATRIMONIO frente a la variable ESTUDIOS. Además, quieres una tabla que muestre el porcentaje de la variable PARADOS frente a las variables SEXO y NACIONALIDAD. 86 CAPÍTULO 7. DISEÑO Sin embargo, al crear esa tabla, te das cuenta de que está mal, por tanto la eliminas, y la vuelves a crear, esta vez midiendo solamente el numero de PARADOS frente al SEXO. En este caso el ejercicio salió de manera correcta y no se adjuntarán los resultados ya que no aportan nada relevante. Tras finalizar con las pruebas, se realizó una reunión con los tutores del Grado en Ingeniería Informática para que indicaran sugerencias, las cuales se listan en la siguiente sección. 7.3.7. Sugerencias de los tutores A pesar de no realizarles las pruebas como tal, se les explicó la funcionalidad implementada hasta el momento y, en base a eso, ellos aportaron sus ideas. Organizar los ficheros de salida en diferentes directorios o, en caso de no ser necesarios, eliminarlos. Modificar el código para obtener varios datos de manera dinámica a través de un fichero de texto, como los formatos de salida, los tipos de gráfico, etc. Lo que se busca con esto es intentar, en la medida de lo posible, que se puedan añadir nuevas funcionalidades sin tener que tocar el código fuente de Java. Sin embargo, en el caso en el que se añada un nuevo formato de destino no contemplado anteriormente, habría que modificar el código ya que para comprobar si el informe a crear, ya existe en la ubicación indicada, es necesario conocer la extensión del mismo y, actualmente, solo hay contempladas algunas. Añadir un campo para que el usuario pueda indicar el nombre del fichero donde obtendrá las visualizaciones. Al pulsar “Aceptar” se notificará al usuario si existe un fichero con el mismo nombre que el que va a crear en la misma ubicación, para no perder información. Poder eliminar el elemento deseado en vez del último. Tras esto, y antes de implementar los cambios, se ha realizado una reunión con el tutor del Grado en Estadística para obtener sus sugerencias también. En este caso, la mayor parte de los temas tratados con el tutor, ha sido referentes a la aplicación en R, por lo que no se indicarán aquí. Sin embargo, sí que se han encontrado problemas a la interfaz, así como pequeñas modificaciones que se deben añadir. Para realizar la conexión entre Java y R, así como para ejecutar el programa principal, se debe tener R instalado y, además, hay que indicarle a la aplicación la ruta en la que se encuentra el archivo ejecutable de R. Para tratar esto, se creará una vista inicial, en la que se muestre la imágen de la universidad, el nombre de la aplicación, y en la que haya que indicar la ruta de R. 7.3. CREACIÓN DE LA INTERFAZ 87 A la hora de crear visualizaciones, es necesario el campo “Factor de elevación” por lo que se debe añadir un nuevo campo para indicar el nombre exacto de dicho campo para la encuesta a tratar. En el caso de los gráficos de sectores, solo se debería poder indicar una variable de cruce, por lo que si el usuario indica que desea este tipo de visualización, se deberá deshabilitar el campo correspondiente a la segunda variable de cruce. Añadir dos nuevos formatos de obtención de resultados, en este caso, html y pptx. Debido a las complicaciones que supone la creación de un único archivo pdf con todas las visualizaciones, de momento se eliminará de los formatos de salida actuales. En las imágenes 7.17, 7.18, 7.20, 7.21 y 7.19 se muestra el resultado obtenido tras aplicar todas las modificaciones sugeridas por los tutores de ambos grados. Figura 7.17: Interfaz final, portada Cabe destacar la adición de tres nuevas ventanas, la portada, la de alerta y la de espera, de las cuales, la primera se abrirá cuando inicie la aplicación, la segunda, en el caso en el que el archivo solicitado ya exista en la ubicación que indique el usuario y la última, tras pulsar aceptar, para dar retroalimentación al usuario. 88 CAPÍTULO 7. DISEÑO Figura 7.18: Interfaz final, ventana alerta Figura 7.19: Interfaz final, ventana espera Otra de las novedades es la desaparición de los botones de eliminar variable o visualización, que han sido sustituidos por una etiqueta que indica que haciendo doble click, se elimina el elemento deseado. Además de esto, se han añadido algunos nuevos campos en la ventana principal y se han modificado los colores de la aplicación completa. El resto de cambios indicados anteriormente también han sido incluidos y se explicará su funcionamiento en posteriores secciones. 7.4. Diseño detallado A continuación se van detallar todas las clases que conforman la aplicación final, explicando cual es su función y, en algunos casos, mostrando un ejemplo de salida esperada. La sección se va a estructurar por paquetes, de la misma forma que se ha desarrollado la interfaz. 7.4.1. Clases comunes El primer paquete que se va a comentar, contiene las clases que pueden ser usadas por cualquier otra, en este caso son las tres siguientes. 7.4.1.1.0 Diccionario Esta clase tiene los siguientes tres atributos. Nombres: ArrayList de String que contiene los nombres de las variables añadidas al diccionario. 7.4. DISEÑO DETALLADO 89 Figura 7.20: Interfaz final, ventana principal 96 CAPÍTULO 7. DISEÑO limpiaNombre: función que limpia el campo de texto correspondiente con el nombre de la variable y restaura el color de la fuente a negro, solo se ejecuta cuando el usuario hace click en el campo. limpiaCodigo: función que limpia el campo de texto correspondiente con el código de la variable y restaura el color de la fuente a negro, solo se ejecuta cuando el usuario hace click en el campo. limpiaDescripcion: función que limpia el campo de texto correspondiente con la descripción de la variable y restaura el color de la fuente a negro, solo se ejecuta cuando el usuario hace click en el campo. errorNombre: función que se lanza cuando se produce un error en el nombre de la variable, muestra la palabra “Error” en el campo de texto y cambia el color de la fuente a rojo. errorCodigo: función que se lanza cuando se produce un error en el código de la variable, muestra la palabra “Error” en el campo de texto y cambia el color de la fuente a rojo. errorDescripción: función que se lanza cuando se produce un error en el código de la variable, muestra la palabra “Error” en el campo de texto y cambia el color de la fuente a rojo. actualizaDiccionario: función encargada de actualizar el campo de texto de la ventana con todos los elementos ya incluidos en el diccionario del modelo, separados por una línea discontinua. Además de estas funciones, existen otras ocho funciones encargadas de capturar determinados eventos y realizar las acciones pertinentes. La única de ellas que es más relevante es la función de eliminar variables, la cual debe capturar la posición relativa del ratón cuando el usuario hace click sobre la ventana de texto y, en el caso de que se produzcan dos clicks seguidos, avisar al controlador de que realice las acciones oportunas. 7.4.6.2.0 ControladorDiccionario Controlador asociado a la vista del Diccionario, encargado de gestionar las operaciones realizadas por el usuario sobre la vista. Está compuesto por dos atributos. mivista: vista gestionada por el controlador. dic: diccionario local en el que se añadirán todas las variables que desee el usuario y, que al terminar, se traspasará al modelo. Las funciones incluidas en esta clase están descritas a continuación. 7.4. DISEÑO DETALLADO 97 ControladorDiccionario: constructor de la clase. procesaCancelar: función encargada de limpiar el diccionario local y pedir a la máquina de estados que vuelva a la ventana principal. procesaAñadir: función que comprueba si existen errores en los campos de texto y, en caso de que no, añade los campos al diccionario local y le pide a su vista que se actualice. Los errores contemplados son los siguientes. •Que el nombre de la variable tenga una longitud menor que 3. Tras observar diferentes encuestas, se ha concluido que 3 es el tamaño mínimo que puede tener el nombre de una variable. •Que el código introducido no este en blanco. •Que la descripción de la variable tenga una longitud menor que 3. El motivo es el mismo que en el campo de nombre. limpiaNombre: función encargada de pedirle a la vista que limpie el campo del nombre de la variable. limpiaCodigo: función encargada de pedirle a la vista que limpie el campo del código de la variable. limpiaDescripcion: función encargada de pedirle a la vista que limpie el campo de la descripción de la variable. procesaAceptar: función que se ejecuta cuando el usuario pulsa el botón de aceptar y que se encarga de comprobar si el diccionario local no está vacío y, en caso de que no lo esté, actualiza el modelo con él y le pide a la máquina de estados que vuelva a la ventana principal. actualizar: función que se ejecuta cada vez que se abre la ventana del diccionario y que se encarga de traer el diccionario que exista en el modelo, actualizar el local con él y decirle a la vista que se actualice con las variables que existan. eliminaPorPos: función que se ejecuta cuando el usuario hace doble click en una variable existente para eliminarla y que se encarga de, en función del índice que calcula la función auxiliar “obtenerIndice”, se elimine la variable deseada y se actualice la vista. obtenerIndice: función auxiliar que obtiene el índice de la variable que desea eliminar el usuario en base a la posición relativa del ratón. Se ha tomado como base que cada variable mostrada en la ventana tiene una altura de 44 píxeles, a excepción del primer elemento que tendrá una altura de 55 píxeles debido a la estructura del panel de texto. De esta forma, un ejemplo de salida esperada de esta función se muestra en la figura 7.22. La forma de trabajar de la función es la siguiente. 98 CAPÍTULO 7. DISEÑO Figura 7.22: Ejemplo salida esperada función “obtenerIndice” 7.4. DISEÑO DETALLADO 99 7.4.7. InterfazUsuario Se trata del último paquete de la aplicación, contiene los elementos necesarios para mostrar y manejar la ventana de creación del diccionario de variables, en este caso, está compuesto de tres clases, dos vistas y un controlador. 7.4.7.1.0 VistaInterfaz Se trata del JFrame Form encargado de crear la ventana principal de la aplicación, contiene un único atributo. micontrol: controlador de esta vista que se encargará de realizar cualquier operación que desee el usuario, así como de actualizar el modelo en el caso de que fuera necesario. En lo que respecta a las funciones que la componen, se listan a continuación. VistaInterfaz: constructor de la clase, que inicializa los componentes de la ventana, crea su controlador y llama a los métodos encargados de actualizar la vista con las correspondientes visualizaciones. Getters: los correspondientes getters encargados de recuperar la información de los campos de texto de la ventana. Setters: los correspondientes setters para algunos de los campos de texto. En esta ventana están incluidos por si el usuario introduce algún campo, y cambia a la ventana del diccionario; de esta manera, cuando vuelva a la ventana principal, esos campos introducidos siguen estando. actualizaVisualizaciones: función encargada de actualizar el campo de texto en el que se listan las visualizaciones, con las que el usuario haya creado ya. limpiaCruce2: función que limpia el campo de texto de la variable de cruce 2. limpiaCruce1: función que limpia el campo de texto de la variable de cruce 1. limpiaRespuesta: función que limpia el campo de texto de la variable respuesta. limpiaElevacion: función que limpia el campo de texto de la variable de elevación. errorRespuesta: función que escribe “Falta la variable respuesta” en el campo correspondiente y modifica el color de la fuente a rojo. errorCruce1: función que escribe “Falta la variable de cruce” en el campo correspondiente y modifica el color de la fuente a rojo. 100 CAPÍTULO 7. DISEÑO errorElevacion: función que escribe “Introduce el factor de elevacion” en el campo correspondiente y modifica el color de la fuente a rojo. errorVisualizaciones: función que escribe “Introduce alguna visualización” en el campo correspondiente y modifica el color de la fuente a rojo. errorRutaOrigen: función que escribe “Introduce ruta de origen” en el campo correspondiente y modifica el color de la fuente a rojo. hayDiccionario: función que modifica la etiqueta que indica que sí existe un diccionario creado. deshabilitaCruce: función que deshabilita el campo para introducir la segunda variable de cruce en algunos tipos de visualización. habilitaCruce: función que habilita el campo para introducir la segunda variable de cruce en algunos tipos de visualización. componentesFichero: función que recibe como parámetros los formatos, separadores y tipos de visualización escritos en el archivo de texto y actualiza la vista con ellos. Además de estas funciones, existen otras catorce funciones encargadas de capturar determinados eventos y realizar las acciones pertinentes. La única de ellas que es más relevante es la función de eliminar visualizaciones, la cual debe capturar la posición relativa del ratón cuando el usuario hace click sobre la ventana de texto y, en el caso de que se produzcan dos clicks seguidos, avisar al controlador de que realice las acciones oportunas. 7.4.7.2.0 VistaWarning Se trata del JFrame Form encargado de crear la ventana de alerta de la aplicación, no posee ningún atributo. En cuanto a las funciones, solo existen tres, el constructor y las encargadas de capturar los eventos correspondientes a los dos botones por los que está formada y pedirle al controlador que realice las acciones pertinentes. 7.4.7.3.0 VistaGenerando Se trata del JFrame Form encargado de crear la ventana de espera de la aplicación, no posee ningún atributo ni ninguna función. 7.4. DISEÑO DETALLADO 101 7.4.7.4.0 ControladorInterfaz Controlador asociado a la vista principal de la aplicación, encargado de gestionar las operaciones realizadas por el usuario sobre la vista. Está compuesto por dos atributos. mivista: vista gestionada por el controlador. rutaCompleta: ruta que se utilizará para guardar el archivo resultante que obtenga la aplicación. Las funciones incluidas en esta clase están descritas a continuación. ControladorInterfaz: constructor de la clase. procesaSeparador: función que obtiene el separador que ha introducido el usuario en la vista y se lo pasa al modelo. procesaFormatoDestino: función que obtiene el formato de destino que ha introducido el usuario en la vista y se lo pasa al modelo. procesaCreaDiccionario: función que pide a la máquina de estados cambiar a la ventana de creación del diccionario. actualizar: función que, en función de la visualización seleccionada, actualiza las medidas que pueden ser elegidas o las variables de cruce que pueden ser introducidas. También comprueba si existe diccionario creado para actualizar la etiqueta que lo indica. procesaRutaOrigen: función que abre el explorador de archivos y obtiene la ruta del fichero de datos seleccionado por el usuario, pasándosela a la vista para que actualice la etiqueta correspondiente, y al modelo para que la almacene. procesaRutaDestino: función que abre el explorador de archivos y obtiene la ruta seleccionada por el usuario, pasándosela a la vista para que actualice la etiqueta correspondiente, y al modelo para que la almacene. procesaRutaR: función que abre el explorador de archivos y obtiene la ruta del ejecutable de R seleccionada por el usuario, pasándosela a la vista para que actualice la etiqueta correspondiente, y al modelo para que la almacene. procesaAñadir: función que comprobará si existen errores en los campos relacionados con la visualización que el usuario desea añadir y, en caso de que no existan, crea una nueva visualización con los parámetros indicados y se la pasa al modelo para que la añada a su ArrayList y a la vista para que actualice el campo de texto. limpiaCruce2: función que comprueba si el campo de texto de la segunda variable de cruce no ha sido modificado, en cuyo caso le pide a la vista que lo limpie. 102 CAPÍTULO 7. DISEÑO limpiaRespuesta: función que comprueba si el campo de texto de la variable respuesta tiene su valor de error y, en ese caso, le pide a la vista que lo limpie. limpiaCruce1: función que comprueba si el campo de texto de la primera variable de cruce tiene su valor de error y, en ese caso, le pide a la vista que lo limpie. limpiaElevacion: función que comprueba si el campo de texto del factor de elevación tiene su valor de error y, en ese caso, le pide a la vista que lo limpie. eliminaPorPos: función que se ejecuta cuando el usuario hace doble click en una visualización existente para eliminarla y que se encarga de, en función del índice que calcula la función auxiliar “obtenerIndice”, se elimine la visualización deseada y se actualice la vista. obtenerIndice: función auxiliar que obtiene el índice de la visualización que desea eliminar el usuario en base a la posición relativa del ratón. Se ha tomado como base que cada visualización mostrada en la ventana tiene una altura de 126 píxeles, a excepción del primer elemento que tendrá una altura de 134 píxeles debido a la estructura del panel de texto. leefichero: función encargada de leer el fichero de parámetros y pasárselo a la vista para que actualice las opciones seleccionables. actualizate: función que obtiene todos los elementos de la ventana principal ya existentes en el modelo, pasándoselos a la vista para que se actualice con toda la información actual. cancelarOperacion: una de las dos funciones referentes a la ventana de alerta, la cual le pide a la máquina de estados que destruya dicha ventana. reemplazarArchivo: segunda de las funciones referentes a la ventana de alerta, la cual se ejecuta si el usuario desea reemplazar el archivo que exista en la ubicación de destino, simplemente elimina dicho archivo para que el nuevo pueda ser creado, y cierra la aplicación. procesaAceptar: se trata de la función más compleja de la aplicación, realiza las siguientes tareas. 1. Comprueba si existen errores en todos los campos obligatorios, en cuyo caso, le pide a la vista que lo muestre. Si no existe error, la función continúa. 2. Comprueba si existe el primer fichero que va a crear, denominado “principal.txt” en la ruta por defecto. En caso de que no exista, lo crea, escribiendo en él toda la información obtenida de la ventana principal. Si el fichero existe, simplemente lo reemplaza. 3. Comprueba si existe el segundo fichero que va a crear, denominado “diccionario.txt” en la ruta por defecto, en caso de que no exista, lo crea, escribiendo 7.4. DISEÑO DETALLADO 103 en él toda la información obtenida de la ventana del diccionario. Si el fichero existe, simplemente lo reemplaza. 4. Comprueba si ya existe un fichero, en la ruta indicada, con el mismo nombre que el que el usuario desea crear. En el caso de que sí que exista, aparece la ventana de alerta. En caso contrario, se realiza la llamada al programa de R con normalidad, mostrándose la ventana de espera durante 25 segundos y volviendo una vez más a la ventana principal. generando: función que le solicita a la máquina de estados que muestre la ventana de espera. 104 CAPÍTULO 7. DISEÑO Capítulo 8 Implementación y pruebas 8.1. Implementación 8.1.1. Paquetes utilizados Para poder implementar las clases detalladas en la sección anterior, ha sido utilizado el entorno de desarrollo Netbeans y el lenguaje de programación Java. Junto con ellos, la librería gráfica Java Swing, la cual viene integrada con Netbeans, ha sido empleada para poder crear la interfaz. Estos tres elementos han sido básicos para la implementación de toda la interfaz, no obstante, se han necesitado otra serie de librerías de java que serán detalladas a continuación. Paquete java.util[17]: Se trata de una librería que contiene una gran cantidad de clases e interfaces. Dentro de ella, solo han sido necesarias dos APIs. •ArrayList: Esta API es la más usada en toda la interfaz, y es necesaria para crear objetos de ese tipo. •Logging: Ha sido usada para capturar las excepciones que se puedan producir. Paquete java.awt[18]: Esta librería contiene algunas clases para crear GUIs. Esta vez, han sido necesarias cinco clases. •Point: Utilizada para almacenar la posición del ratón cuando el usuario quiera eliminar una visualización o una variable. •Color: Se ha empleado para cambiar el color de algunos componentes de la interfaz cuando se producen errores. •Component y FileDialog: Usadas en las clases para abrir el explorador de archivos. 105 112 CAPÍTULO 8. IMPLEMENTACIÓN Y PRUEBAS Capítulo 9 Conclusiones y trabajo futuro 9.1. Conclusiones Al finalizar este trabajo fin de grado, se puede concluir que se han alcanzado los objetivos planteados en su inicio. Se ha desarrollado una interfaz de usuario para una aplicación que genera informes partiendo de datos de encuestas. En ella el usuario puede introducir todos los parámetros necesarios así como visualizar los que ya haya introducido de una manera simple y concisa. Puede crear visualizaciones o eliminarlas si lo desea. También tiene a su disposición una opción para crear un diccionario, añadiendo o eliminando variables del mismo. Todo esto está complementado con el hecho de que la interfaz sea fácil de usar, debido a la encuesta realizada a diferentes perfiles de usuarios con el objetivo de refinar y simplificar su diseño. Además de la parte de la programación, a lo largo de este proyecto se han abordado las cinco fases del desarrollo software. Se ha analizado el problema planteado inicialmente, obteniendo de esta forma los requisitos que debía cumplir la aplicación, así como otros elementos importantes. Una vez finalizada la fase de análisis, había que enfrentarse a la de planificación, la cual ha resultado más complicada, pues a pesar de la cantidad de trabajos que se han ido realizando a lo largo de la carrera, nunca había hecho falta planificar, de forma tan exhaustiva, cómo se iba a desarrollar algo. Sin embargo, al ser algo, relativamente nuevo, ha servido para perfeccionar esas habilidades, muy necesarias de cara al mundo laboral. También se ha entrado en la fase de diseño que, por la experiencia vivida a lo largo de las prácticas en empresa, es fundamental a la hora de desarrollar un proyecto. Por todo esto, no es solo el hecho de haber programado una interfaz y haberla documentado. Con este proyecto fin de grado se ha podido comprender mejor cómo va a funcionar, aunque evidentemente no en su totalidad, el mundo laboral que nos espera a los ingenieros informáticos, y todas las tareas que deberemos realizar en el futuro. 113 114 CAPÍTULO 9. CONCLUSIONES Y TRABAJO FUTURO 9.2. Líneas de trabajo futuro Se ha desarrollado toda la interfaz de manera que fuera lo más modular posible, ya que de esta manera, es muy sencillo implementar nueva funcionalidad sin modificar la ya existente. A continuación se enumeran algunas ideas que podrían llevarse a cabo en el futuro. Mejoras visuales en la interfaz, haciendo más vistosa la misma e incluso más usable. Contemplar en la interfaz las posibles ampliaciones realizadas en la aplicación de R, de las cuales se hablará en la memoria adjunta[3]. Modificar la aplicación para que no sea necesario crear ficheros de texto para comunicarse con R, una forma de realizar esto, habría sido implementar la interfaz con Shiny[21], la cual es una librería de R para crear aplicaciones web. De esta forma, no solo habría resultado más fácil la comunicación de la interfaz con la aplicación, sino que habrían podido realizarse gráficos más interactivos, además de que no sería necesario depender de un archivo jar para ejecutar dicha interfaz. Los motivos de no haber utilizado esta librería era el desconocimiento total de la misma y el tiempo limitado del que se disponía para la realización del trabajo fin de grado. Capítulo 10 Bibliografía [1] Microsoft Office, diversas herramientas de procesado de textos, etc. Fecha de último acceso, 8 de Julio de 2019. Página web https://products.office.com/es-es/home [2] The R Project for Statistical Computing, entorno de programación, fecha de último acceso, 9 de Julio de 2019. Página web https://www.r-project.org/ [3] Raúl Hernansanz Quevedo, 06 de junio de 2019, “Tratamiento automático de encuestas con R”, memoria del Trabajo de Fin de Grado de Estadística. [4] Pablo de la Fuente López, Yania Crespo Gonzalez-Carvajal, Curso 2018/2019, asignatura Planificación y Diseño de Sistemas Computacionales, Universidad de Valladolid. [5] Project Management Institute, 2008, “A guide to the project management body of knowledge (PMBOK Guide)”, Ed. Newton Sqare. Enlace web: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok [6] Apache Netbeans, entorno de desarrollo compatible con diferentes lenguajes, Fecha de último acceso, 8 de Julio de 2019. Página web https://netbeans.org/ [7] Lenguaje de programación, último acceso, 8 de Julio de 2019, información recuperada de https://es.wikipedia.org/wiki/Java_(lenguaje_de_programaci %C3 %B3n) [8] Editor de Latex online, último acceso, 8 de Julio de 2019. Página web https://es.overleaf.com [9] Sistema de composición de textos, último acceso, 8 de Julio de 2019. Información al respecto en https://es.wikibooks.org/wiki/Manual_de_LaTeX [10] UML and Data Modeling and diagraming tool, último acceso, 8 de Julio de 2019. Página web http://astah.net/ [11] Herramienta para realizar capturas de pantalla, último acceso, 8 de Julio de 2019. Página web https://lightscreen.com.ar/ 115 116 CAPÍTULO 10. BIBLIOGRAFÍA [12] Escuela de Ingeniería Informática de Valladolid, último acceso, 8 de Julio de 2019. Enlace web https://www.inf.uva.es/ [13] Departamento de Estadística e Investigación Operativa de Valladolid, último acceso, 8 de Julio de 2019. Enlace web http://www.eio.uva.es/ [14] Digital Guide, 26 de octubre de 2018, recuperado de https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/uml-lenguaje- unificado-de-modelado-orientado-a-objetos/ [15] Miriam García, 5 de octubre de 2018, recuperado de https://codingornot.com/mvcmodelo-vista-controlador-que-es-y-para-que-sirve [16] Antonio Leiva, último acceso el 14 de Marzo de 2019, recuperado de https://devexperto.com/principio-responsabilidad-unica/ [17] Paquete java.util. Información al respecto en la documentación de Oracle. Fecha último acceso, 8 de Julio de 2019. Página web https://docs.oracle.com/javase/7/docs/api/java/util/package-summary.html [18] Paquete java.awt. Información al respecto en la documentación de Oracle. Fecha último acceso, 8 de Julio de 2019. Página web https://docs.oracle.com/javase/7/docs/api/java/awt/package-summary.html [19] Paquete java.io. Información al respecto en la documentación de Oracle. Fecha último acceso, 8 de Julio de 2019. Página web https://docs.oracle.com/javase/7/docs/api/java/io/package-summary.html [20] Paquete java.swing. Información al respecto en la documentación de Oracle. Fecha último acceso, 8 de Julio de 2019. Página web https://docs.oracle.com/javase/7/docs/api/javax/swing/package-summary.html [21] Paquete de R para construir aplicaciones web, último acceso el 23 de Junio de 2019. Página web https://shiny.rstudio.com/ Anexos 117 Apéndice A Manual de Instalación de R En esta sección se van a explicar, de forma detallada, todos los pasos necesarios para realizar la instalación de la herramienta R, necesaria para poder utilizar la aplicación desarrollada en este proyecto. Antes de comenzar con las instrucciones para instalar R, cabe mencionar que, aunque dicha herramienta funciona en diversos sistemas operativos, como Windows,Linux o Mac, la aplicación desarrollada está pensada para Windows, por lo que este manual será para instalar R en este sistema operativo. El primer paso será hacer doble click sobre el acceso directo llamado R que está incluido en la carpeta de la aplicación. Esto nos llevará a la página principal de R, donde deberemos presionar en el enlace marcado en rojo en la figura A.1, una vez hecho esto, tendremos que entrar en el siguiente enlace, también marcado en rojo en la figura A.2 y, finalmente, en el enlace de descarga de la figura A.3. Figura A.1: Página web de R (parte 1) 119 120 APÉNDICE A. MANUAL DE INSTALACIÓN DE R Figura A.2: Página web de R (parte 2) Figura A.3: Página web de R (parte 3) 121 Seguidamente habrá que ejecutar el archivo que hemos descargado y seguir las instrucciones que se describirán a continuación. Para comenzar seleccionaremos el idioma en el que deseamos que esté la instalación, en mi caso será Español, una vez elegido, pulsaremos en Aceptar. Aparecerá entonces el acuerdo de licencia de la herramienta y tendremos que pulsar en Siguiente. Figura A.4: Instalación de R (parte 1) Figura A.5: Instalación de R (parte 2) A continuación deberemos indicar la ruta en la que deseamos instalar R, esta ruta habrá que tenerla presente puesto que la aplicación desarrollada hará uso de ella, pero eso ya se explicará más adelante en esta misma sección. Tras introducir la ruta que más nos interese, presionaremos en Siguiente. En la siguiente ventana, habrá que indicar los componentes que deseamos instalar. En este caso recomiendo instalar todos, para evitar posibles problemas. Con esto presente, pulsaremos en Siguiente tal y como aparece en la figura A.7. Ahora pincharemos en Siguiente en las dos ventanas que siguen a la de los componentes, es decir, figuras A.8 y A.9 hasta que el instalador pida seleccionar las tareas 128 APÉNDICE B. MANUAL DE USO DE LA INTERFAZ Figura B.5: Ruta de R (parte 2) Figura B.6: Ruta de R (parte 3) 129 Tras esto, podremos crear un diccionario, cuya utilidad ya ha sido explicada en diferentes puntos de este mismo documento. Para hacerlo, lo primero será pulsar en el botón “Crear o editar Diccionario”, mostrándose así la ventana de la figura B.7, una vez ahí, podremos crear o eliminar variables a nuestro gusto. Para crearlas, solo debemos introducir su nombre, código y descripción y pulsar sobre “Añadir”, de esta forma se mostrará la variable creada en el campo de texto inferior, para ilustrar esto, se ha creado la variable “ejemplo”. En el caso de que se desee eliminar dicha variable, solo habrá que hacer doble click sobre cualquier parte de ella en el panel de texto. Figura B.7: Creación del diccionario Hay que tener en cuenta que cuando se esté creando el diccionario, los cambios no se guardarán si el usuario no presiona el botón Aceptar. Cuando el diccionario esté creado o en el caso en el que no se desee crear, habrá que introducir la ruta donde queremos los resultados, si esta ruta no se indica, por defecto estará en la misma ubicación que la carpeta de la aplicación. Lo siguiente será escribir el nombre exacto del factor de elevación que se encuentra en la encuesta con la que vamos a trabajar. El último parámetro a indicar, será el nombre que el usuario desea dar al informe resultado. Cuando todos los parámetros estén indicados, habrá que introducir las visualizaciones que se deseen. Esto se hará en la parte derecha de la ventana principal, mostrada en la figura B.8, donde habrá que introducir el tipo de visualización deseada, la medida que queremos representar, la variable respuesta y, al menos, la primera variable de cruce. Todas las variables introducidas deben estar escritas de manera exacta a como están escritas en la encuesta con la que estemos trabajando, incluyendo si están o no en mayúsculas. Una vez se ha rellenado todo, pulsaremos “Añadir” y el resultado de la visualización aparecerá en el panel de texto derecho. Para este ejemplo, se ha solicitado un Gráfico de barras horizontales, que represente la media de la variable REJEMPLO frente a la variable CEJEMPLO1, como no se ha introducido una segunda variable de cruce, ese campo aparece con un guión. La forma de eliminar una visualización es la misma que la 130 APÉNDICE B. MANUAL DE USO DE LA INTERFAZ utilizada con las variables del diccionario, bastará con hacer doble click en cualquier parte de dicha visualización en el panel de texto. Figura B.8: Creación de visualizaciones Finalmente, cuando todo esté introducido, pulsaremos el botón Aceptar y, tras un poco de tiempo, se creará el informe en la ubicación indicada. En el caso de que no se cree, se deberán comprobar las variables introducidas por si hubiera algún error. Algo a tener en cuenta es que, si cuando presionamos Aceptar, el archivo que deseamos ya existe en la ubicación indicada, aparecerá una ventana de alerta, mostrada en la figura B.9, en este caso existirán dos opciones, la primera es reemplazar el archivo pulsando Reemplazar y la segunda es cancelar la operación pulsando Cancelar, si hacemos esto último, volveremos a la ventana de la interfaz. Figura B.9: Ruta de R (parte 4) Una observación importante es que, a la hora de depositar la carpeta que contiene todos los elementos de la aplicación, se debe hacer en un lugar con una ruta absoluta no muy larga, y sin caracteres raros, debido a la codificación de los ficheros de texto generados y de limitaciones de lectura en rutas demasiado extensas. 131 Una vez explicado el funcionamiento general de la aplicación, se van indicar algunas cosas que se pueden realizar para probarla. Empleando el archivo de Excel incluido entre el contenido del CD, se tendría que introducir, como factor de elevación, la variable “FACTOTAL” y, como separador del archivo, el tabulador. En la figura B.10 se muestran algunas variables que se pueden introducir como variables de cruce para las visualizaciones. Como variable respuesta, se introducirá “SALBRUTO”. Para mostrar un ejemplo, en la imagen B.11 se han introducidos todos los parámetros necesarios para crear un gráfico de barras horizontales. Figura B.10: Ejemplo de variables Figura B.11: Ejemplo de parámetros 132 APÉNDICE B. MANUAL DE USO DE LA INTERFAZ Apéndice C Contenido del CD / memoria.pdf.............................Memoria del Trabajo de Fin de Grado de Ingeniería Informática. InterfazUsuario.zip ................... Proyecto exportado mediante NetBeans, que contiene el código fuente de la interfaz, debido a las rutas, no se debe ejecutar la aplicación desde aquí. Datos_ES_2010.csv......................Fichero Excel con datos de ejemplo para probar la aplicación. Programa resultados...........................Carpeta donde se almacenarán las imágenes de las visualizaciones de forma temporal. temporales ..........................Carpeta donde se crearán los archivos de texto que leerá la aplicación de R. InterfazUsuario.jar ................ Ejecutable que lanza la aplicación. parametros.txt......................Documento de texto en el que se pueden introducir diversos parámetros. R.....................................Acceso directo a la página de descarga de R. tfg.R ................................ Código fuente de la aplicación R. 133