UNIVERSIDAD SIMÓN BOLÍVAR

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN SISTEMA DE ENCUESTAS USB Por: Pedro Rincón Edward Zambrano PROYECTO DE GRADO Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero de Computación Sartenejas, Octubre de 2012

2 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN SISTEMA DE ENCUESTAS USB Por: Pedro Rincón Edward Zambrano Realizado con la asesoría de: Ascánder Suárez PROYECTO DE GRADO Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero de Computación Sartenejas, Octubre de 2012

3

4

5 Sistema de encuestas USB por Pedro Rincón Edward Zambrano RESUMEN En este proyecto de grado se plantea el proceso de diseño y puesta en producción de una aplicación web, denominada Sistema de Encuestas, cuyo objetivo es el de brindar una herramienta funcional para la elaboración de encuestas y llenado de las mismas. Se utiliza como caso de estudio el prototipo de encuesta bajo el enfoque por competencias diseñado en conjunto por el Decanato de Estudios Generales, el Decanato de Estudios Profesionales y el Decanato de Estudios Tecnológicos. Esta aplicación, creada bajo la metodología de desarrollo extreme Programming (XP) utiliza el modelo de abstracción Modelo Vista Controlador (MVC) y se encuentra implementada en JAVA/JSP utilizando diversas tecnologías entre las que destacan Cohesión, Struts, Hibernate, Tomcat, BIRT y JQuery. El producto obtenido bajo este proyecto de grado se centra en el diseño, llenado y codificación de resultados de las encuestas realizadas por parte de los distintos decanatos mencionados anteriormente. Para esto se provee a los usuarios de la aplicación una interfaz intuitiva, sencilla y organizada de manera jerárquica. La aplicación obtenida es completamente funcional y ya ha sido utilizada para la realización de la encuesta para validar el perfil del egresado del Ciclo de Iniciación Universitaria (CIU), bajo el enfoque por competencias, por parte del Decanato de Estudios Generales. Es importante mencionar que la herramienta puede ser utilizada para la creación de encuestas cuyo enfoque no sea el de evaluación por competencias, lo que brinda una mayor flexibilidad al momento de diseñar encuestas con la aplicación. v

6 AGRADECIMIENTOS Agradecemos a nuestros padres por todo lo que han hecho durante nuestras vidas, a su amor incondicional y apoyo en los momentos difíciles. A la Decana María Gabriela Gómez por su atención y participación que hizo posible este proyecto de grado y a la Coordinadora Aurora Olivieri por ayudarnos a mantener la calma con su sonrisa pacificadora durante los momentos en que la aplicación presentaba problemas. A la Licenciada Maribel Alvarez por su atención y sugerencias en la elaboración de la aplicación y a todas aquellas personas que participaron de una u otra forma en el diseño de la aplicación. A la Profesora Marlene Goncalves por su disposición a ayudarnos a todo momento para el diseño del modelo de la base de datos y a la profesora Adelaide Bianchini por brindar sus conocimientos de diseño para la elaboración de los reportes. A Jhoerson Yagmour por su invaluable ayuda en el reporte de errores y criticas constructivas para mejorar el funcionamiento de la aplicación. Al personal del LDC por sus constantes palabras de ánimo y por permitirnos utilizar las instalaciones y servidores del laboratorio durante el desarrollo y mejoramiento de la aplicación. Especialmente a Michelle por siempre darnos un abrazo cuando más lo necesitábamos. A los desarrolladores que sin buscar nada a cambio colaboran día a día en el diseño de las tecnologías utilizadas en este y otros muchos proyectos a nivel mundial. Especialmente a la comunidad de Birt-Exchange por su ayuda en la resolución de los problemas presentados al comenzar a integrar BIRT con la aplicación. A todos los profesores que participaron en las pruebas piloto y nos ayudaron a mejorar el funcionamiento de la aplicación mediante sugerencias o corrección de errores. A Rosita por todos estos años que nos ha ayudado durante la carrera, por su increíble paciencia y disposición de atender a todos los estudiantes con una sonrisa. Por último un agradecimiento especial a nuestro tutor Ascánder, por ayudarnos durante este largo recorrido a solucionar los problemas en que no encontrábamos una salida. vi

7 ÍNDICE GENERAL ÍNDICE GENERAL ÍNDICE DE CUADROS ÍNDICE DE FIGURAS vii xi xii INTRODUCCIÓN 1 1 PLANTEAMIENTO DEL PROBLEMA Antecedentes y justificación Alcance Objetivo General Objetivos específicos MARCO TEÓRICO Modelo Vista Controlador (MVC) Java JSP Apache Tomcat JavaScript Struts Hibernate BIRT C3P0 / BoneCP Definición de términos básicos MARCO TECNOLÓGICO Java / JSP vii

8 3.2 Cohesión Apache Web Server Struts Apache Subversion Mantis Bug Tracker Netbeans Eclipse / BIRT PostgreSQL Cascading Style Sheets (CCS) SimpleTest C3P0 / BoneCP Dropbox MARCO METODOLÓGICO Y CARACTERIZACIÓN DEL SISTEMA Marco Metodológico Programación en pareja Cambios en los requerimientos de los usuarios Ciclos de desarrollo cortos Utilización pruebas unitarias Comunicación constante con el cliente Flujo de trabajo Caracterización del Sistema Metáfora del Sistema Roles de Usuario Super administrador Administrador Encuestado Requerimientos no funcionales Rendimiento Alta disponibilidad Seguridad Accesibilidad viii

9 Usabilidad Estabilidad Portabilidad Escabilidad Concurrencia Mantenibilidad DESARROLLO E IMPLEMENTACIÓN Aplicación de la metodología de desarrollo Fase de evaluación Fase de análisis Fase de desarrollo Fase de mejoramiento Consideraciones del sistema Administración del sistema Mantenimiento Usuarios CONCLUSIONES Y RECOMENDACIONES 49 REFERENCIAS 51 A ACTORES INVOLUCRADOS Y USUARIOS 53 A.1 Actores Involucrados A.2 Roles de usuario B MODELO ENTIDAD-RELACIÓN EXTENDIDO 55 C MANUAL DE IMPLANTACIÓN 58 C.1 Requerimientos mínimos C.2 Instalación D CASOS DE USO 60 D.1 Caso de uso del super administrador ix

10 D.2 Caso de uso del administrador D.3 Caso de uso del encuestado E DICCIONARIO DE DATOS 64 F DOCUMENTO DE ARQUITECTURA 67 G MANUAL DEL USUARIO 70 x

11 ÍNDICE DE CUADROS 5.1 Resumen de las reuniones realizadas durante el desarrollo de la aplicación Etapas para la realización de un instrumento Tiempos de respuesta (en segundos) entre los manejadores de conexiones A.1 Resumen de los actores involucrados en el desarrollo del sistema A.2 Resumen de los roles de usuario del sistema xi

12 ÍNDICE DE FIGURAS 4.1 Diagrama de flujo de un proyecto utilizando Extreme Programming Diagrama de flujo de una iteración en Extreme Programming Relación entre Roles de usuario Interfaz web original Interfaz web final Configuración de las pruebas de estrés B.1 Modelo Entidad-Relación Extendido xii

13 INTRODUCCIÓN La Internet como medio para la transmisión de información ha venido creciendo de manera exponencial durante los últimos años. Un proyecto que comenzó con el nombre de ARPANET dentro del Departamento de Defensa de Estados Unidos [1], en la actualidad es utilizado a nivel mundial para la investigación, comunicación, entretenimiento, entre otros muchos usos. Acciones que hace tan sólo una década podrían resultar engorrosas (buscar una dirección o comprar un producto en el extranjero) ahora pueden ser realizadas utilizando servicios como Google o Amazon desde cualquier dispositivo con una conexión a Internet. Con el fin de aprovechar los beneficios de utilizar la Internet como medio de transmisión, la Universidad Simón Bolívar (USB) mediante la Dirección de Ingeniería de Información (DII) se ha dedicado a migrar muchos de sus sistemas a la red como lo son el Sistema de inscripción en línea o el Sistema de Opinión Estudiantil. Esto ha beneficiado a la Universidad de muchas formas, entre las que destacan la facilidad para utilizar estos sistemas desde cualquier parte del mundo y la eliminación del uso de papel y, por ende, la reducción de los costos del material necesario para este tipo de procesos. Es por esto que resulta lógico que el prototipo para la realización de encuestas bajo el enfoque por competencias planteado por el Decanato de Estudios Generales, el Decanato de Estudios Profesionales y el Decanato de Estudios Tecnológicos de la Universidad Simón Bolívar sea realizado mediante una aplicación web, con el objetivo de que se beneficie de la misma manera que lo han hecho los sistemas mencionados anteriormente. Este proyecto de grado tiene como objetivo principal el desarrollo e implantación de una herramienta web para la creación de encuestas de distintos enfoques, entre las cuales se encuentra el enfoque por competencias solicitado por los decanatos mencionados anteriormente. La herramienta debe ser intuitiva, fácil de utilizar y debe permitir realizar encuestas anónimas a una población genérica. Se tomará como caso de estudio el prototipo de encuestas por 1

14 2 competencias descrito en el párrafo anterior. La implementación de la aplicación deberá contar con módulos que permitan el diseño de encuestas, totalización de resultados y manejo de encuestados. Todo esto podrá realizarse mediante el uso de una interfaz web que aproveche al máximo la arquitectura cliente/servidor. Como salida la aplicación debe generar archivos en formato PDF 1 o CSV 2 donde se reflejen las respuestas realizadas por los encuestados para una determinada encuesta utilizando un formato predeterminado. Además de esto, deberá contar con la ayuda online necesaria para la utilización de la herramienta por parte de nuevos usuarios. El presente trabajo consta de cinco capítulos. En el Capítulo 1 se habla de la motivación que da origen a la herramienta web y se analiza el caso de estudio con sus respectivos usuarios. En el Capítulo 2 se realiza una breve explicación teórica de los conceptos, lenguajes y las tecnologías utilizadas para la elaboración de la aplicación. Se definen además los términos involucrados en el funcionamiento de la aplicación. En el Capítulo 3 se mencionan los lenguajes y herramientas utilizadas con una breve explicación de sus características principales y las razones por las cuales fueron utilizadas durante el desarrollo del proyecto de grado. En el Capítulo 4 se desarrolla la metodología utilizada durante la creación de la herramienta y la caracterización del sistema. En el Capítulo 5 se explica al lector el proceso de desarrollo e implementación de la aplicación y cuales fueron las mejoras que fueron surgiendo conforme se iban cumpliendo los objetivos específicos del proyecto de grado. Finalmente se exponen al lector las conclusiones y recomendaciones para trabajos futuros. 1 PDF (sigla del inglés portable document format, formato de documento portátil) es un formato de almacenamiento de documentos. Este formato es de tipo compuesto (imagen vectorial, mapa de bits y texto). 2 CSV (del inglés comma-separated values) son un tipo de documento en formato abierto sencillo para representar datos en forma de tabla, en las que las columnas se separan por comas y las filas por saltos de línea.

15 CAPÍTULO 1 PLANTEAMIENTO DEL PROBLEMA La Dirección de Ingeniería de la Información (DII) es una Unidad Administrativa adscrita a la Secretaría de la USB cuya función principal es coordinar e integrar todos los procesos conducentes al diseño, desarrollo, implantación, mantenimiento y documentación de sistemas de información de misión crítica de la USB [2]. La DII administra muchos de los servicios utilizados por el estudiantado de la Universidad, entre los cuales resaltan: Sistema de reservas, Sistema de Opinión Estudiantil, Sistema de Saldo Comedor, Sistema de inscripción, entre otros. Ninguno de estos servicios permite la realización de encuestas a una población genérica. Así, el objetivo de este proyecto de grado es la creación de una aplicación web que permita la realización de encuestas a una población genérica, para luego agregar esta aplicación al conjunto de sistemas administrados por la DII para que se encuentre disponible para todos los departamentos, coordinaciones y decanatos de la Universidad. Como caso de estudio utilizado para el desarrollo de los requerimientos de la aplicación y posterior puesta en producción, se utilizará el prototipo de encuestas bajo el enfoque por competencias del Decanato de Estudios Generales, del Decanato de Estudios Profesionales y del Decanato de Estudios Tecnológicos de la Universidad Simón Bolívar. 1.1 Antecedentes y justificación En un principio el sistema de encuestas fue planteado como un proyecto para la materia de Taller de Desarrollo de Software en el período estudiantil Abril-Julio del 2011, bajo la tutoría del profesor Acánder Suárez. La aplicación lograda durante ese trimestre cumplía con parte de los requerimientos solicitados por los decanatos interesados, pero a medida que el sistema crecía, nuevos objetivos fueron apareciendo que requerían un mayor tiempo de análisis para su implementación. Es por esto que se decidió continuar con el desarrollo del

16 4 sistema mediante la modalidad de proyecto de grado. El prototipo de creación de encuestas por competencias de parte del Decanato de Estudios Generales, del Decanato de Estudios Profesionales y del Decanato de Estudios Tecnológicos había sido pensado para ser realizado de manera convencional diseñando encuestas impresas para luego ser repartidas en la población. Esta forma de realizar las encuestas generaba las siguientes dificultades: Se limitaba el alcance de las encuestas debido a los costos de impresión y al personal necesario para repartir el material a través de la población deseada. La totalización de resultados y análisis estadísticos resultaban engorrosos. Una vez elaborada la encuesta, su contenido no podía ser reordenado. La presentación impresa no era atractiva para los encuestados, por lo que los resultados finales podrían no reflejar de manera precisa la opinión de la población encuestada. Al no disponer la Universidad de una herramienta que lograra ajustarse satisfactoriamente a las necesidades de los decanatos participantes, se planteó la elaboración de un sistema web que solucionara los problemas planteados anteriormente. 1.2 Alcance El objetivo del sistema de encuestas es convertirse en una herramienta de fácil mantenimiento, escalable y amigable, que permita a la Universidad realizar de forma sencilla y rápida distintos tipos de encuestas y evaluar sus resultados. 1.3 Objetivo General Diseñar, desarrollar e implementar un sistema de encuestas para el Decanato de Estudios Generales, el Decanato de Estudios Profesionales y el Decanato de Estudios Tecnológicos de la Universidad Simón Bolívar.

17 5 1.4 Objetivos específicos Desarrollar el módulo de diseño de encuestas y manejo de encuestados. Desarrollar el módulo para responder las encuestas. Desarrollar el módulo de análisis y totalización de los resultados de una encuesta. Implantar pruebas pilotos en los decanatos voluntarios y evaluar el desempeño de la aplicación. Apoyar y brindar soporte a usuarios del sistema.

18 CAPÍTULO 2 MARCO TEÓRICO A continuación se explican los conceptos utilizados durante el desarrollo del proyecto de grado. Estos comprenden el Modelo Vista Controlador (MVC), los lenguajes de programación Java y Javascript, los frameworks Struts y Hibernate y, por último, la herramienta para elaboración de reportes BIRT. Además se definen los términos involucrados en el funcionamiento de la aplicación. 2.1 Modelo Vista Controlador (MVC) Las siglas provienen de Model View Controller, es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de negocio en tres capas distintas. Este modelo de trabajo se ve frecuentemente en aplicaciones web, donde la vista es la página que visita el usuario, el modelo es el sistema de gestión de base de datos y el controlador es el responsable de recibir los eventos de entrada desde la vista. Esta forma de trabajo tiene como objetivos principales la utilización del código ya implementado y el facilitar la evolución de manera independiente de los módulos del sistema [3] [4]. Al utilizar MVC para el desarrollo de aplicaciones es posible tener diferentes vistas para un mismo modelo permitiendo al desarrollador desplegar la información consistente de distintas formas mediante tablas o gráficos. MVC permite construir nuevas vistas sin necesidad de modificar el modelo previamente establecido, facilitando el desarrollo de forma modular. Descripción del patrón El patrón se encuentra divido en tres capas: Modelo: esta es la representación específica de la información sobre la cual funciona la aplicación. Es la encargada de acceder a la capa de almacenamiento de datos, siendo

19 7 independiente del medio o sistema de almacenamiento. El modelo además define las funcionalidades de la aplicación. Vista: se encarga de representar el modelo en un formato adecuado para interactuar, generalmente se refiere a la interfaz del usuario de la aplicación. La vista es la encargada de resaltar u ocultar ciertos atributos del modelo mediante el uso de filtros de presentación. La vista interactúa con el modelo mediante preguntas o mensajes que cumplen con una terminología y semántica pertenecientes al modelo. Controlador: este elemento se encarga de recibir, manejar y responder a eventos (usualmente desencadenados por el usuario), del flujo de trabajo de la aplicación, y de la lógica del sistema. El controlador interactúa tanto con el modelo como con la vista y es el encargado de mantener y gestionar la relación entre ambas capas. En la implementación de MVC para marcos de trabajo tipo web, el controlador se encarga de responder a las acciones del usuario, interactuar con el modelo y decidir que vista debe ser mostrada (en caso de ser necesario). Flujo de control Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente: El usuario realiza alguna acción que desencadena una respuesta por parte de la aplicación. El controlador se encarga de recibir la acción del usuario mediante el objeto asociado a la interfaz en la que se realizó la acción. El controlador accede al modelo y realiza las acciones solicitadas por el usuario. El controlador delega a los objetos de la vista la tarea de generar y desplegar la interfaz del usuario. La vista obtiene los datos del modelo donde se pueden ver reflejados los cambios hechos en el paso anterior. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.

20 8 2.2 Java Es un lenguaje de programación desarrollado originalmente por James Gosling en Sun Microsystems (ahora parte de la corporación Oracle), liberado en 1995 como una parte esencial de la plataforma Java de Sun. El lenguaje fue construido bajo el legado de los lenguajes de programación C y C++, agregando funcionalidades y refinamientos solicitados por los programadores y empresas a medida que se desarrollaba. Respondiendo al aumento del uso de las redes como medio de transmisión, Java ofrece capacidades para la programación de arquitecturas altamente distribuidas. Java nace de la necesidad de un lenguaje de programación que fuese independiente de la plataforma donde se ejecutara, permitiendo crear software que funcionara en distintos dispositivos electrónicos sin importar el CPU que utilizaran. La aparición de la World Wide web influyó de igual manera en el desarrollo de Java, dado que se generó un nuevo enfoque para Java donde el objetivo principal ya no eran los dispositivos electrónicos, sino la programación que utilizara la red como medio de transmisión [5]. Java es un lenguaje de programación orientado a objetos, enfocado en clases que evita en lo posible las dependencias de implementación. Las aplicaciones de Java son típicamente compiladas en bytecode para luego ser ejecutadas en máquinas virtuales de Java (JVM) sin importar la arquitectura del procesador. En cuanto al rendimiento de las aplicaciones desarrolladas en Java, es sabido que el tiempo de ejecución es mayor y que además solicita mayor cantidad de recursos del sistema si se compara con aplicaciones escritas en lenguajes como C. 2.3 JSP Es una tecnología que provee al desarrollador de una forma poderosa y eficiente de creación de contenido dinámico. JSP usa el lenguaje de programación Java para la creación de contenido dinámico por lo que las cualidades de Java como lo son la visión orientada a objetos, la independencia de la plataforma donde se ejecute y modelo de memoria protegida, permiten el desarrollo de contenido dinámico de una manera eficiente y rápida [6].

21 9 El funcionamiento general de la tecnología JSP se basa en que el servidor de aplicaciones interpreta el código contenido en la página JSP para construir el código Java del servlet a generar. Este servlet será el que genere el documento (típicamente HTML) que se presentará en la pantalla del Navegador del usuario. Al utilizar JSP existe una clara separación en cuanto al diseño de las páginas web y el funcionamiento de la aplicación. Esto permite separar el trabajo de diseño del de programación permitiendo a los desarrolladores crear aplicaciones sin necesidad de altos conocimientos del código Java que genera el contenido dinámico. Es posible enriquecer el lenguaje de etiquetas utilizado por JSP. Para ello se utiliza la capa de alto nivel JSP mediante la implementación de Bibliotecas de Etiquetas (Tags Libraries). Un ejemplo de estas bibliotecas son las proporcionadas por Sun bajo la denominación de JSTL o las distribuidas por Apache junto con el Framework de Struts. 2.4 Apache Tomcat Es una implementación Open Source de las tecnologías Java Servlet y JavaServer Pages de Oracle, ofreciendo un entorno Java para aplicaciones escritas en este lenguaje. Tomcat (Anteriormente conocido como Jakarta Tomcat) es la base de numerosas aplicaciones de gran escala y de misión crítica en un diverso espectro de industrias y organizaciones [7]. Tomcat está dividido en 3 componentes principales: Catalina: es el contenedor de servlets de Tomcat. Catalina implementa la especificación de Sun Microsystems para servlets y JavaServer Pages (JSP). Tomcat se encarga de gestionar la base de datos de nombres de usuarios, claves y roles asignados a dichos usuarios. Coyote: es el componente que conecta Tomcat con HTTP, utilizando el protocolo HTTP 1.1 para establecer la comunicación con el servidor web o el contenedor de la aplicación. Coyote espera por conexiones entrantes en un puerto TCP específico y redirige la solicitud al Motor de Tomcat para procesar la solicitud y enviar de regreso una respuesta al cliente que realizó la solicitud. Jasper: es el motor JSP de Tomcat. Jasper interpreta los archivos JSP para compilarlo

22 10 en código Java como servlets que pueden ser manejados por Catalina. Al momento de ejecución, Jasper detecta cambios en los archivos JSP y recompila los mismos. 2.5 JavaScript Es un lenguaje de programación interpretado del estándar ECMAScript. Se define como un lenguaje multiparadigma permitiendo los estilos de programación orientado a objetos, imperativo, dinámico y funcional con características de weak typing. Se utiliza principalmente del lado del cliente, implementado como parte de un navegador web permitiendo mejoras en la interfaz de usuario y páginas web dinámicas. JavaScript fue desarrollado originalmente por Brendan Eich de Netscape con el nombre de Mocha, el cuál fue renombrado posteriormente a LiveScript, para finalmente quedar como JavaScript. JavaScript se diseñó con una sintaxis similar al C, aunque adopta nombres y convenciones del lenguaje de programación Java. Sin embargo Java y JavaScript no están relacionados y tienen semánticas y propósitos diferentes. Todos los navegadores modernos interpretan el código JavaScript integrado en las páginas web. Tradicionalmente se venía utilizando en páginas web HTML para realizar operaciones y únicamente en el marco de la aplicación cliente, sin acceso a funciones del servidor. JQuery Es una biblioteca de JavaScript, creada por John Resig, que permite simplificar la manera de interactuar con los documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar animaciones y agregar interacción con la técnica AJAX a páginas web. jquery es software libre y de código abierto, posee un doble licenciamiento bajo la Licencia MIT y la Licencia Pública General de GNU v2, permitiendo su uso en proyectos libres y privativos. jquery, al igual que otras bibliotecas, ofrece una serie de funcionalidades basadas en JavaScript que de otra manera requerirían de mucho más código y tiempo de desarrollo. jquery consiste en un único archivo JavaScript que contiene las funcionalidades comunes de DOM, eventos, efectos y AJAX. La característica principal de la biblioteca es que permite cambiar el contenido de una página web sin necesidad de hacer un refresh de la página, mediante la manipulación del árbol DOM y peticiones AJAX.

23 Struts Es una herramienta de soporte para el desarrollo de aplicaciones web bajo el patrón MVC bajo la plataforma Java EE (Java Enterprise Edition). Struts se desarrollaba como parte del proyecto Jakarta de la Apache Software Foundation, pero actualmente es un proyecto independiente conocido como Apache Struts. Su carácter de software libre y su compatibilidad con todas las plataformas en las que Java Entreprise esté disponible lo convierten en una herramienta altamente utilizada por los desarrolladores. El uso de Struts promete el desarollo de software mejor elaborado de una manera más rápida. Struts provee un modelo fácil de usar que ya posee implementado muchos de los módulos que de otra manera serían necesarios construir manualmente (un proceso que puede llevar varias semanas). Struts fue construido por un grupo de los mejores y más conocidos desarrolladores del área por lo que el manejo de bugs ha sido atendido eficientemente garantizando un marco de trabajo sólido para el desarrollo de nuevas aplicaciones [8]. Struts (versión 1) es conocido por ser uno de los frameworks más utilizados para el desarrollo de aplicaciones web, pero al mismo tiempo es una de las herramientas más criticadas [9]. Entre las razones por las cuales se considera inadecuado utilizar Struts se encuentran: Struts asiste al desarrollador para la construcción de la aplicación desde el punto de vista de interacción con los usuarios, no se involucra con el modelo de la base de datos. Es por ello que el framework puede considerarse incompleto. Las etiquetas que utiliza Struts no poseen los mismos atributos que las etiquetas HTML estándar, lo cual influye negativamente en el tiempo de desarrollo. el método execute no cumple con los patrones de diseño estándar al requerir para su llamada de argumentos obligatorios que muchas veces no son necesarios dentro de la ejecución del método. La clase ActioForm utilizada por Struts para el manejo de las sesiones, permite únicamente datos tipo String y boolean por lo que no puede ser usada para representar con precisión el modelo de la base de datos. Esto obliga al desarrollador a utilizar de manera

24 12 paralela la clase ActionForm y el modelado de la base de datos. Esto se debe a que Struts no posee políticas para la traducción de request parameters a objetos de Java. Struts utiliza cast para obtener acceso a los objetos ActionForm, lo cual puede generar errores de ejecución. 2.7 Hibernate Es una herramienta de mapeo Objeto-Relacional para ambientes de trabajo Java que facilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicación mediante archivos declarativos. En la práctica esto crea una base de datos orientada a objetos virtual, sobre la base de datos relacional. Esto posibilita el uso de las características propias de la orientación a objetos (básicamente herencia y polimorfismo). Hibernate es software libre, distribuido bajo los términos de la licencia GNU LGPL [10]. Hibernate se encarga del mapeo de las clases de Java en tablas de una base de datos y de los tipos de datos en Java (String, int, boolean) a tipos de datos SQL y provee además del manejo de consultas o queries. El objetivo por el cual fue diseñado Hibernate fue el de liberar al desarrollador del 95 % de las tareas comunes relacionadas al manejo de datos en programas que utilizan SQL y JDBC. Hibernate utiliza HQL (Hibernate Query Language), un lenguaje de consultas en apariencia similar a SQL. Sin embargo, HQL esta completamente orientado a objetos y maneja conceptos como herencia, polimorfismo y asociación. 2.8 BIRT Es un proyecto de código abierto que provee de herramientas para el diseño y generación de reportes con capacidades de Business Intelligence (BI) para aplicaciones web, especialmente a aquellas desarrolladas en Java. BIRT (Business Intelligence and Reporting Tools) es uno de los proyectos de software principales dentro de la fundación Eclipse. Birt provee funcionalidades como lo son el etiquetado de reportes, creación de tablas y gráficos estadísticos, acceso a datos y uso de scripts para el manejo de la información [11 13]. BIRT esta compuesto por dos componentes principales: un diseñador de reportes (report

25 13 designer) integrado al entorno de desarrollo (IDE) Eclipse, y el componente de ejecución que puede ser agregado a las aplicaciones web para mostrar los reportes. Los reportes en BIRT están compuestos por cuatro componentes principales: Datos: Se refiere a las fuentes de información (bases de datos, servicios web, objetos en Java, archivos de texto). BIRT utiliza el marco de trabajo ODA (Open Data Access) que brinda una forma común de acceso a la información de manera estándar o personalizada. Una de las ventajas que ofrece BIRT, es que un reporte puede obtener información de distintas fuentes de manera concurrente para luego realizar la presentación de la manera que desee el usuario. Transformación de los datos: Los reportes presentan la información ordenada, resumida, filtrada y agrupada según las necesidades del usuario. Mientras que las bases de datos pueden realizar este trabajo de manera parcial, BIRT permite realizarlo de manera sencilla mediante la abstracción de data source. BIRT permite también el uso de operaciones sofisticadas como la agrupación de elementos bajo un criterio de búsqueda, o la totalización de la información para luego ser presentada en una gráfica o tabla. Lógica del negocio (BI): Muchos de los reportes solicitados por el usuario requieren un manejo específico de la información para que resulte útil al momento de ser presentada. BIRT permite realizar este tipo de análisis mediante el uso de código JavaScript o manejadores (Clases en Java). Presentación: Cuando la información se encuentra lista para ser presentada, BIRT provee de una serie de herramientas que permiten modificar la presentación final del reporte. Esto incluye: tablas, gráficos, texto, etc. Una de las cualidades más importantes de BIRT es la integración que permite realizar con aplicaciones de Java, mediante las interfaces de programación de aplicaciones (APIs) que ofrece. Para la generación de reportes directamente de una aplicación web, es necesario importar las librerías necesarias de BIRT, indicar la ubicación del archivo.rptdesign y ejecutar un bloque de código que indica las opciones necesarias para la generación del reporte en formato PDF, HTML o CSV según lo desee el usuario.

26 C3P0 / BoneCP Son manejadores de pools de conexiones para bases de datos utilizando el API JDBC, que tienen la finalidad de manejar de forma óptima el uso de conexiones a la base de datos en vez de utilizar el controlador de la base de datos de forma directa. C3P0 es una librería de Java de código abierto que realiza mejoras a los controladores JDBC convencionales al agregar funcionalidades definidas en la especificación jdbc3 y extensiones opcionales de jdbc2. BoneCP es otro proyecto de código abierto que implementa una librería para el manejo de pools de conexiones para base datos que se destaca por su velocidad y características avanzadas como particionar los pools de conexiones entre otras Definición de términos básicos Administrador: Un administrador es un rol de usuario que puede diseñar, editar, abrir y cerrar instrumentos. Los administradores además controlan las poblaciones asociadas a un instrumento. Entrada: Una entrada es el conjunto de respuestas enviadas por un encuestado sobre un instrumento. A partir de una entrada no es posible determinar la identidad del encuestado que respondió el instrumento. Encuestado: Un encuestado es un rol de usuario que puede responder instrumentos diseñados en el sistema. Estado de un instrumento: El estado se refiere a la etapa en la que se encuentra un instrumento. Los posibles estados son diseño, abierto y cerrado: Diseño: Durante esta fase el administrador crea, modifica o elimina las secciones y preguntas pertenecientes al instrumento. Abierto: La población asociada procede a responder el instrumento. El administrador puede generar reportes parciales de la información recolectada por el instrumento.

27 15 Cerrado: El administrador obtiene la totalización de las respuestas mediante la generación de reportes. Estudio: Un estudio es un conjunto de instrumentos pertenecientes a un administrador. Instrumento: Un instrumento es un conjunto de secciones con un orden especificado por el administrador. Instrumento de datos demográficos: Un instrumento de datos demográficos es un instrumento especial que esta asociado a cada estudio. En todos los instrumentos de un estudio se agregan de forma automática las preguntas del instrumento de datos demográficos. Las preguntas de datos demográficos pueden ser utilizadas como filtro para generar reportes. Pregunta de datos personales: Una pregunta de datos personales es una pregunta especial cuya respuesta está asociada a un encuestado. Estas preguntas permiten a los administradores conocer con mas detalle las características de los encuestados. Población: Una población es la relación entre un encuestado y un instrumento. Una población es un conjunto de encuestados que estan asociados a un instrumento en particular. Un encuestado puede pertenecer a varias poblaciones. Reporte: Un reporte es la presentación de las respuestas enviadas por los encuestados a un instrumento particular. Se pueden utilizar las preguntas del instrumento de datos demográficos como filtro de las respuestas mostradas. Sección: Una sección es una colección de preguntas agrupadas con un orden especificado por el administrador. Super Administrador: Un super administrador es un rol de usuario que puede crear, editar y deshabilitar administradores del sistema. Usuario: Un usuario es toda persona registrada en el sistema bajo alguno de los roles establecidos, los cuales pueden ser encuestado, administrador o super administrador.

28 CAPÍTULO 3 MARCO TECNOLÓGICO A continuación se presentarán los lenguajes de programación, los marcos de trabajo y tecnologías utilizadas para el desarrollo de la aplicación. 3.1 Java / JSP Para la implementación de la herramienta se utilizó el lenguaje de programación JAVA y la tecnología para la creación de páginas web JSP. 3.2 Cohesión Cohesión es una herramienta desarrollada en la Universidad Simón Bolívar por un grupo coordinado por el profesor Ascánder Suárez para la elaboración de aplicaciones web. Esta herramienta fue utilizada desde que el proyecto se inició como parte de la asignatura Taller de Desarrollo de Software y ha evolucionado de forma paralela al desarrollo del sistema de encuestas. Cohesión maneja los proyectos como diseños y modelos de datos que son desarrollados de forma separada. El modelo de datos contiene los Actores y Entidades del modelo y permite crear de forma rápida los elementos fundamentales de la aplicación. El Diseño permite a partir de un modelo crear los casos de uso básicos, generando vistas y acciones que pueden ser exportados como una una aplicación utilizando los frameworks Struts, Portlet o Django. El resultado del Taller de Desarrollo de Software fue el punto de inicio del proyecto, el cual a medida que fue evolucionando utilizó otras herramientas externas como librerías que no pueden ser importadas directamente a cohesión.

29 Apache Web Server El servidor web Apache es un servidor HTTP poderoso, flexible y extendible que cuenta con una amplia aceptación y soporte en la comunidad web, actualmente mas de la mitad de todos los servidores web del Internet utilizan Apache Web Server. El servidor cerf.labf.lal.usb.ve sirvió como plataforma de pruebas para el desarrollo de la aplicación, utilizando Apache como servidor web. Se decidió utilizar Apache por su estabilidad, facilidad de configuración y disponibilidad de documentación. 3.4 Struts Se utilizó el marco de trabajo Struts debido a que permite el desarrollo de aplicaciones web bajo el patrón MVC con el lenguaje de programación Java y la tecnología JSP. 3.5 Apache Subversion Apache Subversion es un software para el manejo de versiones y control de revisiones distribuido bajo una licencia open source. Este software fue utilizado junto con el repositorio web para el manejo de versiones del libro de grado y el código fuente de las pruebas hechas con la herramienta Simpletest, permitiendo integrar y manejar el desarrollo de la aplicación de forma ordenada y manteniendo una copia adicional en caso de ocurrir fallas en los ordenadores de los desarrolladores. 3.6 Mantis Bug Tracker Mantis Bug Tracker es un sistema web para el registro de anomalías de aplicaciones escrito en PHP. Esta aplicación fue instalada en el servidor shamir.ldc.usb.ve y fue utilizada durante el desarrollo del proyecto de grado para facilitar el reporte y la resolución de problemas encontrados con el sistema de encuestas. MantisBT fue utilizado principalmente por las personas encargadas de la elaboración de las encuestas por parte de los usuarios y por los desarrolladores para llevar un registro de las anomalías encontradas y además servir de registro de cambios de la aplicación.

30 18 Mantis utiliza formularios que permiten reportar de forma detallada cualquier problema con la aplicación, permitiendo al usuario definir el grado de severidad del problema, reproducibilidad, prioridad, pasos para reproducir y cualquier información adicional que pueda ayudar a la resolución del problema. Mantis también permite subir archivos como parte del reporte, como capturas de pantalla que ayuden a los desarrolladores a reproducir y resolver los problemas o agregar información adicional al reporte luego de haber sido enviado. Por otra parte, el usuario puede enterarse del estado del problema y ser notificado al momento de resolver el problema por correo, permitiendo un flujo bidireccional de información entre los usuarios y desarrolladores sobre el estado del sistema. 3.7 Netbeans Netbeans es un entorno de desarrollo de aplicaciones multiplataforma escrito en Java que soporta una gran variedad de lenguajes de programación y tipos de aplicaciones. El entorno de desarrollo Netbeans fue la principal herramienta utilizada durante la elaboración del proyecto de grado. Esta herramienta permite acoplar de forma integral los distintos componentes del sistema de encuestas como archivos fuentes, librerías, manejo de bases de datos, páginas JSP en un proyecto, además de tener una serie de herramientas útiles al momento de desarrollar y depurar el código elaborado para el sistema de encuestas. 3.8 Eclipse / BIRT BIRT es un herramienta que se integra con las aplicaciones Java para la creación de reportes mediante consultas a una o varias bases de datos. Para la creación de los reportes del sistema de encuestas fue necesaria la utilización del entorno de desarrollo Eclipse, debido a que este brinda al diseñador una interfaz rápida y sencilla para la elaboración de archivos.rptdesign que son utilizados por las librerías de BIRT para la generación de los reportes dentro de una aplicación web.

31 PostgreSQL PostgreSQL es un manejador de base de datos open source ampliamente utilizado para el desarrollo de aplicaciones web. Fue utilizado por su estabilidad, capacidad de extensión y su excelente documentación Cascading Style Sheets (CCS) CCS es un lenguaje utilizado para describir la semántica de la presentación, especificando la apariencia y el formato de un documento, generalmente utilizado para dar estilo a documentos Web. Su aplicación mas común es el dar estilo para páginas web escritas en HTML y XHTML, pero el lenguaje puede ser aplicado a cualquier clase de documento XML incluyendo XML plano, SVG y XUL. Cohesión genera un estilo especificado en ccs, pero este fué modificado de acuerdo a los requerimientos del sistema. Entre los cambios principales al estilo se encuentra la ampliación del área de la aplicación, mejorar la compatibilidad con Internet Explorer y otros cambios estéticos que fueron requeridos por los clientes o por consideraciones de usabilidad SimpleTest Simpletest es un framework de pruebas unitarias open source escrito en PHP, con una estructura similar a JUnit y PHPUnit. Simpletest fue utilizado para realizar pruebas unitarias, pruebas de regresión y pruebas de funcionalidad, facilitando la evaluación y validación de cada iteración antes de ser publicadas en el servidor de producción. Simpletest complementa de forma efectiva la metodología Extreme Programming utilizada durante la elaboración del proyecto de grado, permitiendo evaluaciones rápidas de funcionalidad y correctitud del proyecto durante todo su desarrollo C3P0 / BoneCP Son manejadores de pools de conexiones para bases de datos. Inicialmente se consideró utilizar c3p0 para el manejo de conexiones concurrentes del sistema a la base de datos, pero

32 20 debido a los resultados obtenidos mediante diversas pruebas de rendimiento (ver cuadro 5.3) se concluyó que el desempeño de BoneCP era más eficiente para el manejo de conexiones concurrentes en la aplicación Dropbox Dropbox es un servicio gratuito que permite compartir directorios como si fueran locales, manteniendo una copia en los servidores de dropbox en caso de emergencia. Dropbox fue utilizado para compartir archivos como libros de referencia, librerías de programas, documentación y otros archivos de utilidad general que no son modificados de forma directa por cada desarrollador. Dropbox resultó mas práctico para compartir archivos que rara vez cambian que al utilizar herramientas como subversion, que requieren de un manejo individual de cada archivo.

33 CAPÍTULO 4 MARCO METODOLÓGICO Y CARACTERIZACIÓN DEL SISTEMA En las siguientes secciones se expondrá de manera detallada el marco metodológico utilizado durante el desarrollo de la herramienta y la caracterización del sistema, producto del uso de esta metodología de desarrollo. 4.1 Marco Metodológico Para el desarrollo del sistema de encuestas se utilizó la metodología de programación extrema (XP por sus siglas en inglés), la cual al ser una metodología ágil con ciclos rápidos de desarrollo y requerimientos cambiantes se adecuó de forma efectiva al desarrollo de la aplicación comparado con otras metodologías mas rígidas. Entre los elementos más destacados de la metodología se tienen: Programación en pareja Cambios en los requerimientos de los usuarios Ciclos de desarrollo cortos Utilización de pruebas unitarias Comunicación constante con el cliente Flujo de trabajo Programación en pareja La programación en pareja es una técnica de desarrollo ágil que consiste en que los programadores trabajen juntos en una estación de trabajo. Uno de los programadores, llamado el conductor escribe el código mientras que el otro, el observador, verifica cada línea de

34 22 código. Estos roles son cambiados de forma frecuente. El desarrollo de software en parejas ha demostrado que produce menos errores y produce mejores diseños en comparación con los desarrolladores trabajan por separado, además de permitir intercambio de conocimiento entre los desarrolladores mientras trabajan al conocer los detalles específicos del sistema y aprendiendo de las técnicas de programación de cada uno. Por otra parte el desarrollo en parejas produce código de forma mas rápida que un solo programador Cambios en los requerimientos de los usuarios La metodología XP plantea que los requerimientos pueden cambiar a medida que pasa el tiempo y se entiende mejor el problema. En el caso del sistema de encuestas, otro factor que influyó en los requerimientos fue la incorporación de nuevos clientes, como el Decanato de Estudios Tecnológicos el cual fue incorporado en la tercera fase de la elaboración del proyecto de grado Ciclos de desarrollo cortos Como se menciona en la descripción de la metodología, Extreme Programming se basa en varios ciclos cortos de desarrollo, al contrario de un ciclo largo que abarque todo el desarrollo de la aplicación. El uso de ciclos de desarrollo cortos permiten a los desarrolladores realizar entregas funcionales a un ritmo constante, permitiendo además incluir a los clientes en el desarrollo de cada ciclo para discutir los requerimientos y proveer retroalimentación sobre la aplicación. En el caso del sistema de encuestas los ciclos de desarrollo duraron entre 2 y 3 semanas, dependiendo de la carga académica de los desarrolladores y de la dificultad al momento de implementar las nuevas funcionalidades del sistema Utilización pruebas unitarias El uso de pruebas unitarias es un pilar fundamental del desarrollo de la metodología Extreme Programming, ya que permiten garantizar la calidad del software desarrollado y evitar regresiones al momento de realizar cambios sobre las funcionalidades ya existentes. Para las pruebas unitarias del Sistema de Encuestas se utilizó la herramienta Simpletest Comunicación constante con el cliente La comunicación constante con el cliente permite desarrollar software que refleje de forma efectiva los requerimientos de los clientes. Durante cada iteración se busco tener la opinión de

35 23 los clientes para determinar los objetivos de la iteración. Durante el desarrollo de la aplicación se realizaron reuniones con los decanatos además de tener continua comunicación vía correo electrónico, la cual fue posteriormente complementada mediante el uso de la herramienta Mantis Bug Tracker para el reporte de desperfectos encontrados Flujo de trabajo En la figura 4.1 se muestra el flujo de trabajo de la metodología. Un proyecto esta compuesto por los siguientes elementos: Historias de Usuario: Las historias de usuario son similares a los casos de uso tradicionales, pero son utilizadas para crear estimados de tiempo en la planificación de publicación y como guía en lugar un documento de requerimientos. Las historias de usuario también son utilizadas para la creación de pruebas de aceptación, las cuales verifican la correcta implementación de la historia de usuario. Se sugiere que si una historia requiere mas de tres semanas de tiempo para implementarse, se subdivida en nuevas historias mientras que si una historia requiere menos de una semana esta se agrupe con otra historia de usuario. Planificación de Publicación: En esta fase se toma en consideración la importancia de las historias de usuario y cuales historias son prioritarias para el desarrollo en la próxima iteración. En esta planificación se incluyen aquellas historias de usuario que hayan surgido durante la iteración anterior y la velocidad del proyecto hasta el momento. Pico: Los picos son aquellos problemas que por su dificultad requieren un mayor tiempo por parte de los desarrolladores y pueden exceder la duración normal de las iteraciones. Estos picos son mitigados en la planificación al realizar historias de usuario con estimaciones confiables sobre el tiempo requerido para implementar una funcionalidad. Pico Arquitectónico: El pico arquitectónico ocurre al momento de diseñar la arquitectura de la aplicación, en el caso puntual del sistema de encuestas este ocurrió al diseñar la capa lógica de la aplicación. La metáfora del sistema es un producto de este pico y permite explicar de forma clara a todos los involucrados en el desarrollo cual es la funcionalidad del sistema.

36 24 Pruebas de Aceptación: Las pruebas de aceptación están basadas en las historias de usuario y se implementan como las pruebas funcionales, las cuales verifican la correcta implementación de la funcionalidad requerida. Publicación: Luego de que la funcionalidad esta implementada y comprobada, esta es presentada al cliente y en caso de ser aprobada por el cliente se procede a publicar una nueva versión. Las nuevas versiones fueron publicadas en el servidor cerf.ldc.usb.ve. Figura 4.1: Diagrama de flujo de un proyecto utilizando Extreme Programming En la figura 4.2 se muestra el flujo de trabajo de una iteración, la cual a su vez esta compuesta por los siguientes elementos elementos: Plan de publicación: El plan de publicación contiene las historias de usuario a desarrollar durante el proyecto. Siguiente Iteración: Al comenzar una nueva iteración, se toma en consideración la velocidad de desarrollo que lleva el proyecto para estimar la duración de cada iteración. Fallas: Las fallas son aquellos errores encontrados que deben ser solucionados y son parte de los objetivos a desarrollar durante la iteración. Al encontrar una falla, se recomienda realizar una nueva prueba funcional que detecte dicha falla para que la misma no vuelva a ser introducida en las versiones posteriores del sistema.

37 25 Nueva historia de usuario: Durante cualquier punto del desarrollo de la aplicación pueden surgir nuevos requerimientos que son incorporados al proyecto como nuevas historias de usuario. Velocidad de desarrollo: La velocidad de desarrollo se basa en cuantas historias de usuario fueron realizadas durante la iteración, la cual puede ser afectada por picos, la carga académica de los desarrolladores u otros factores externos. Planificación de iteración: En esta etapa se toma en consideración las historias de usuario por implementar, la velocidad de desarrollo, las fallas encontradas y las tareas incompletas de la iteración anterior para elaborar el plan de la iteración, el cual contiene las historias de usuario a desarrollar durante la nueva iteración y cuales pruebas funcionales deben ser creadas. Desarrollo: En esta fase los desarrolladores implementan los objetivos propuestos durante la planificación de la iteración. Última versión: Al terminar una iteración, se obtiene una nueva versión del software que es la base para futuras iteraciones. Figura 4.2: Diagrama de flujo de una iteración en Extreme Programming

38 Caracterización del Sistema A lo largo del desarrollo del sistema de encuestas, fueron surgiendo características del sistema que definen a la aplicación en cuanto a funcionalidad y enfoque, producto de las continuas iteraciones de la metodología XP y los requerimientos de los clientes. A continuación se explican aquellas características que fueron consideradas como las más importantes Metáfora del Sistema Al momento de planificar el funcionamiento y apariencia de la herramienta se decidió utilizar como metáfora la elaboración de una encuesta real a una población genérica. Este proceso se debe poder subdividir en: 1. Objetivos e información requerida: se determinan los objetivos de la encuesta y cual es la información que se desea obtener para cumplir con dichos objetivos. 2. Diseño: se elaboran las distintas preguntas que van a ser colocadas en el instrumento con sus conjuntos de respuestas posibles. 3. Trabajo de campo: se imprime el instrumento y se reparte entre la población deseada con el fin de que las personas expresen su opinión de manera anónima. 4. Conteo y codificación de resultados: se contabilizan y codifican los resultados por cada pregunta del instrumento. 5. Análisis y conclusiones: se procede a estudiar los resultados obtenidos con el fin de lograr los objetivos planteados. El sistema de encuestas desarrollado en este proyecto de grado busca facilitar de manera directa los pasos 2,3 y 4 al brindar una herramienta web que permita realizar estos subprocesos de manera sencilla y rápida. Es importante mencionar que al momento de diseñar la interfaz de la aplicación, se utilizaron como modelos encuestas diseñadas por la Universidad como prototipos para la evaluación de carreras por competencia, con el fin de lograr una similitud visual entre la versión impresa de la encuesta y la nueva presentación web. Este parecido facilitó el proceso de adaptación de los usuarios con la aplicación dado que desde un principio se sintieron familiarizados con el formato.

39 Roles de Usuario En un principio se diseñó la lógica del sistema realizando una diferenciación dentro de las poblaciones de profesores, egresados, estudiantes y personal obrero. No obstante debido a la complejidad que esto generaba en el diseño de la aplicación, se optó por realizar una abstracción de los usuarios y clasificarlos en super administrador, administrador y encuestado. Cada uno de estos roles cuenta con una lista de historias de usuario que permiten determinar cuales son las funcionalidades que pueden realizar en la aplicación. Aquellas historias de usuario que fueron consideradas esenciales para cumplir con los requerimientos funcionales de la herramienta son desarrolladas de manera detallada con la finalidad de ilustrar al lector la forma en la cual fueron implementadas en el sistema. En la figura 4.3 se presenta una representación de como se interrelacionan los roles de usuarios. Figura 4.3: Relación entre Roles de usuario Super administrador Durante el diseño del sistema de encuestas bajo la materia de Taller de Desarrollo de Software se crearon los roles de administrador y encuestado. Con esto surgía el problema de

40 28 que el conjunto de administradores sólo podía ser modificado de manera manual en la base de datos, lo cual resultaba inadecuado según los requerimientos iniciales. Por esta razón se diseña el rol de super administrador, el cual es el encargado exclusivamente del manejo de los administradores. No existe una limitante en cuanto al número de usuarios bajo este tipo de rol, pero debido a la responsabilidad que conlleva, se recomienda que sólo exista un usuario bajo el rol de super administrador, manejado por personal adscrito a la sección administrativa de los decanatos que utilizan la aplicación. Historias de usuario del super administrador 1. Recuperar contraseña: El super administrador previamente registrado debe poder recuperar su contraseña en caso de olvido suministrando su dirección de correo electrónico. 2. Iniciar sesión: El super administrador previamente registrado, ingresa su login y contraseña para hacer uso del sistema y de las funcionalidades asociadas a su rol. 3. Finalizar sesión: El super administrador finaliza la sesión de trabajo y abandona la aplicación. 4. Crear administrador: El super administrador debe tener la posibilidad de agregar nuevos administradores utilizando como datos de entrada su login, nombre y la dirección de correo electrónico. 5. Buscar administrador: El super administrador debe poder buscar un administrador en la base de datos utilizando como filtro parte del login. 6. Modificar perfil: El super administrador debe poder cambiar su correo electrónico y/o su contraseña. 7. Modificar perfil de los administradores: El super administrador debe poder modificar el perfil de los administradores, esto incluye los campos de login, nombre y correo electrónico.

41 29 8. Deshabilitar administrador: El super administrador debe poder deshabilitar a un administrador. Si un administrador es deshabilitado, este no podrá entrar al sistema, sin embargo las encuestas asociadas a él no son eliminadas Administrador El administrador es un usuario asociado a un decanato o un trabajador activo de la Universidad Simón Bolívar. Este rol es el encargado de todo lo relacionado a la creación y manejo de instrumentos con sus respectivas poblaciones, además de la gestión de los encuestados. Historias de usuario del administrador 1. Recuperar contraseña: El administrador previamente registrado debe poder recuperar su contraseña en caso de olvido suministrando su dirección de correo electrónico. 2. Iniciar sesión: El administrador ya registrado, ingresa su login y contraseña para hacer uso del sistema y de las funcionalidades asociadas a su rol. 3. Finalizar sesión: El administrador finaliza la sesión de trabajo y abandona la aplicación. 4. Modificar perfil: El administrador debe poder cambiar su nombre, correo electrónico o contraseña. 5. Listar estudios: El administrador debe poder listar los estudios creados por él. 6. Crear estudio: El administrador debe poder crear un estudio que sólo podrá ser administrado por él. 7. Buscar estudio: El administrador debe poder buscar un estudio creado por él utilizando como filtro parte del nombre. 8. Modificar estudio: El administrador debe poder modificar el nombre, descripción y el instrumento de datos demográficos de un estudio creado por él. 9. Eliminar estudio: El administrador debe poder eliminar un estudio creado por él. Al eliminar un estudio se eliminan todos sus instrumentos.

42 Listar instrumentos: Un administrador debe poder listar los instrumentos de un estudio creado por él. 11. Crear instrumento: Un administrador debe poder crear un instrumento dentro de un estudio creado por él. 12. Crear instrumento desde plantilla: Un administrador debe poder utilizar otro instrumento (creado por él o por otro administrador) como base para la creación de un nuevo instrumento. La propiedad de plantilla es similar a la acción de clonar instrumento con la diferencia que las plantillas son comunes para todos los administradores del sistema. Para realizar esta historia del administrador se flexibilizó el funcionamiento de la aplicación eliminando la independencia de los instrumentos entre administradores de manera controlada. 13. Buscar instrumento: El administrador debe poder buscar un instrumento utilizando como filtro parte del nombre. 14. Modificar instrumento: El administrador debe poder modificar la información perteneciente a un instrumento, esto es: nombre, estudio al que pertenece, descripción, y mensaje de invitación. El administrador debe poder también seleccionar el instrumento para ser utilizado como instrumento plantilla y de esta forma servir de base para crear otros instrumentos. 15. Enviar invitaciones pendientes: El administrador debe poder enviar las invitaciones por correo electrónico a la población que aún no haya sido invitada a responder el instrumento. 16. Enviar invitaciones a toda la población: El administrador debe poder enviar el correo de invitación a toda la población asociada a ese instrumento un número ilimitado de veces. 17. Exportar resultados: El administrador debe poder descargar un archivo.csv con la información recolectada de la población por el instrumento en un formato crudo.

43 Generar reporte: El administrador debe poder descargar un archivo en formato PDF o HTML con la información recolectada de la población por el instrumento presentada en forma de resumen. Para cumplir con esta historia de administrador se utilizaron las librerías de BIRT para acceder la información dentro de la base de datos y presentarla de forma adecuada. Posteriormente para la realización de reportes mediante un filtrado se utilizó el instrumento de datos demográficos del estudio al que pertenece dicho instrumento. 19. Eliminar instrumento: El administrador debe poder eliminar un instrumento creado por él. Al eliminar un instrumento se eliminan todas las secciones de preguntas pertenecientes al instrumento. 20. Listar población: El administrador debe poder listar todos los usuarios asociados a la población de un instrumento junto al estado en el que se encuentra. Los tres estados posibles son: sin invitar, sin responder y respondido. 21. Crear población: El administrador debe poder agregar un encuestado a la población del instrumento. Este encuestado debe estar previamente registrado en el sistema. 22. Carga masiva de población: El administrador debe poder cargar un archivo de texto bajo un formato preestablecido con los encuestados que desee agregar a la población del instrumento. Cuando el encuestado no esté registrado en el sistema, se registra con los datos suministrados en el archivo de texto. Para realizar esta historia de administrador se estableció un formato para el ingreso de la información. 23. Clonar instrumento: El administrador debe poder crear un instrumento a partir de otro utilizando la acción de clonar, esto significa que el nuevo instrumento estará compuesto por las secciones y preguntas que se encontraban en el instrumento que fue clonado. 24. Vista previa de un instrumento: El administrador debe poder ver como será presentado el instrumento al encuestado al momento de contestarlo.

44 Listar secciones: Un administrador debe poder listar las secciones de preguntas pertenecientes a un instrumento. 26. Ordenar secciones: Un administrador debe poder elegir en que orden desea que las secciones de preguntas se muestren en el instrumento. 27. Crear sección: Un administrador debe poder crear una sección de preguntas dentro de un instrumento. 28. Modificar sección: Un administrador debe poder modificar el nombre de una sección. 29. Eliminar sección: Un administrador debe poder eliminar una sección. Al eliminar una sección, se eliminan todas las preguntas pertenecientes a la sección. 30. Listar preguntas: Un administrador debe poder listar las preguntas pertenecientes a una sección de preguntas. 31. Ordenar preguntas: Un administrador debe poder elegir en que orden desea que las preguntas se muestren en el instrumento dentro de la sección a la que pertenecen. 32. Crear pregunta: Un administrador debe poder crear una pregunta dentro de una sección de preguntas. 33. Modificar pregunta: Un administrador debe poder modificar el enunciado y tipo de una pregunta. 34. Eliminar pregunta: Un administrador debe poder eliminar una pregunta. 35. Listar preguntas de datos personales disponibles: Un administrador debe poder listar las preguntas de datos personales que han sido creadas en el sistema. 36. Crear pregunta de datos personales: Un administrador debe poder crear una pregunta de datos personales en el sistema. Esta pregunta estará disponible para todos los administradores del sistema.

45 Seleccionar preguntas de datos personales: Un administrador debe poder elegir cuales son las preguntas de datos personales que desea solicitar a los encuestados que pertenezcan a alguna de las poblaciones de los instrumentos que él ha creado. 38. Ordenar preguntas de datos personales: Un administrador debe poder elegir en que orden desea que se muestren las preguntas de datos personales a los encuestados. 39. Listar encuestados: Un administrador debe poder listar los encuestados registrados en el sistema. Es importante resaltar que el conjunto de encuestados es común para toda la aplicación. 40. Crear encuestado: Un administrador debe poder crear un nuevo encuestado en el sistema utilizando como entrada la cédula, el correo electrónico y el nombre de la persona. 41. Buscar encuestado: Un administrador debe poder buscar un usuario dentro del conjunto de usuarios registrados utilizando como parámetro parte de la cédula. 42. Modificar perfil encuestado: Un administrador debe poder modificar los datos asociados a un encuestado, estos son: la cédula, el correo electrónico y el nombre. 43. Listar población a la que pertenece un encuestado: Un administrador debe poder listar en cuales poblaciones se encuentra un usuario, y cual es el estado en el que se encuentra en cada una de ellas. 44. Listar datos personales de un encuestado: Un administrador debe poder ver las respuestas a las preguntas de datos personales que han sido respondidas por el encuestado. 45. Eliminar encuestado: Un administrador debe poder eliminar un encuestado del sistema. Si se elimina un encuestado, automáticamente es removido de las poblaciones a las que pertenece.

46 Encuestado El encuestado puede ser la cuenta de un empleado, estudiante, obrero, egresado, trabajador o cualquier persona que desee participar en el sistema de encuestas. El encuestado tiene la posibilidad de responder de manera anónima los instrumentos cuyas poblaciones lo incluyan. También debe poder modificar su perfil y responder las preguntas de datos personales asociadas a su cuenta. Historias de usuario del encuestado 1. Recuperar contraseña: El Encuestado previamente registrado debe poder recuperar su contraseña en caso de olvido suministrando su dirección de correo electrónico. 2. Iniciar sesión: El Encuestado previamente registrado, ingresa su nombre de usuario y contraseña para hacer uso del sistema y de las funcionalidades asociadas a su rol. 3. Finalizar sesión: El Encuestado finaliza la sesión de trabajo y abandona el sistema. 4. Responder preguntas de datos personales: El Encuestado debe poder responder las preguntas de datos personales seleccionadas por los administradores que hayan incluido al encuestado en las poblaciones de sus instrumentos. Estas preguntas están relacionadas al encuestado por lo que no son anónimas. 5. Modificar perfil: El encuestado debe poder cambiar su nombre, correo electrónico o contraseña. 6. Responder instrumento: Un encuestado debe poder responder los instrumentos que lo hayan incluido en sus poblaciones respectivas. El encuestado sólo debe poder responder cada instrumento una única vez. Las respuestas son guardadas en la base de datos de manera anónima Requerimientos no funcionales En esta sección se presenta una lista con los requerimientos no funcionales solicitados para el sistema de encuestas.

47 Rendimiento El tiempo de respuesta de la aplicación al momento de generar una consulta, crear un instrumento, enviar los correos electrónicos, etc. debe encontrarse en un rango aceptable para los usuarios Alta disponibilidad Al ser una aplicación con interfaz web, es primordial que el acceso a la aplicación este garantizado. El uptime no debe ser menor al 99 %, considerando las interrupciones programadas por labores de mantenimiento y actualización del sistema Seguridad El sistema de encuestas de encuestas trabaja con información personal de los empleados y estudiantes de la Universidad, la cual puede considerarse como confidencial. Es por eso que se solicita tomar medidas de seguridad adicionales para impedir el acceso a la información por parte de personal no autorizado. Además de esto, se debe garantizar una autorización por rol que limite las acciones que pueda realizar un usuario registrado Accesibilidad La interfaz de la aplicación debe cumplir con los estándares web relacionados a la filosofía del diseño. Esto se refiere a que la aplicación debe contar código HTML, CSS y JavaScript válido que permita la visualización correcta de la herramienta en los navegadores web más utilizados (Internet Explorer, Mozilla Firefox, Google Crome y Safari) Usabilidad Este aspecto debe poder subdividirse en los siguientes puntos: Facilidad de aprendizaje: La herramienta debe hacer fácil la interacción de los nuevos usuarios. Esto se relaciona con la predicibilidad, sintetización de información, familiaridad, la generalización de los conocimientos previos acerca de la herramienta y la consistencia. Facilidad de uso: El sistema de encuestas debe facilitar la forma en la que usuario utiliza la herramienta, esto se logra mediante un diseño adecuado de la interfaz web, y una minimización de pasos para lograr una acción.

48 36 Flexibilidad: La herramienta debe brindar distintas formas de interactuar con el usuario para lograr un intercambio de información. Esto abarca la multiplicidad de vías para realizar una tarea, la similitud con tareas anteriores y la optimización entre el usuario y el sistema. Robustez: La herramienta debe brindar la asistencia necesaria al usuario para facilitar el cumplimiento de los objetivos que este desee. Esto incluye la documentación de la herramienta y el módulo de ayuda que se incluye en la interfaz web Estabilidad El sistema debe contar con una solidez que garantice un funcionamiento continuo sin errores inesperados. Esto incluye la posibilidad de que el sistema maneje adecuadamente los posibles errores que puedan presentarse durante la realización de un acción Portabilidad El sistema debe ser portable, siendo compatible las plataformas más comunes. El código fuente debe ser capaz de reutilizarse al momento de trasladar la aplicación de una plataforma a otra. Se debe evitar la dependencia de software con respecto a la plataforma en donde se ejecute la herramienta Escabilidad La herramienta debe permitir realizar actualizaciones o agregar nuevas características sin afectar el funcionamiento actualidades de la aplicación. Para lograr esto, el código fuente de la aplicación debe estar modularizado, tal como lo plantea el Modelo Vista Controlador (MVC) Concurrencia La herramienta debe permitir conexiones paralelas e independientes, en las cuales un usuario no pueda afectar el funcionamiento del sistema para los demás. El sistema además debe soportar conexiones de manera masiva por parte de los usuarios sin presentar inconvenientes que puedan afectar al servicio.

49 Mantenibilidad El esfuerzo requerido para conservar el funcionamiento normal de la herramienta debe ser mínimo, permitiendo restituir el servicio en caso de que el servidor donde se ejecuta la aplicación presente alguna falla que requiera atención.

50 CAPÍTULO 5 DESARROLLO E IMPLEMENTACIÓN En este capítulo se explica el proceso de desarrollo e implementación del sistema de encuestas. El mismo se divide en secciones que detallan las fases de evaluación, análisis, desarrollo y mejoramiento del prototipo del sistema. Cabe destacar que cada una de estas fases se corresponde con una iteración de la metodología Extreme Programming, la cual fue utilizada durante la mayor parte del desarrollo del proyecto de grado. 5.1 Aplicación de la metodología de desarrollo Cada ciclo de desarrollo tenia una duración aproximada de dos a tres semanas, y cada ciclo constaba de cuatro etapas: fase de evaluación, fase de análisis, fase de desarrollo y fase de mejoramiento. Por otra parte, como lo indica la metodología Extreme Programming, se realizaron pruebas funcionales y pruebas piloto para garantizar la calidad del software desarrollado y evitar regresiones Fase de evaluación Durante esta fase se determinaron los requerimientos de los decanatos involucrados (clientes) y se evaluó su viabilidad para el sistema de encuestas. Entre los requerimientos más importantes recolectados inicialmente se encuentran los siguientes: La respuestas suministradas por los encuestados no pueden estar relacionadas con el encuestado, de forma tal que no debe ser posible determinar que respuestas de un instrumento dado pertenecen a un encuestado. Permitir el uso de invitaciones por correo electrónico. Poder visualizar resultados parciales de las encuestas a medida que son respondidos.

51 39 Permitir compartir instrumentos entre los administradores. Durante el desarrollo del proyecto de grado, se realizaron varias reuniones entre los desarrolladores y los clientes, con la finalidad de conocer la opinión de los clientes, aclarar dudas con respecto a la utilización de la herramienta y determinar cuales requerimientos habían surgido o cambiado con respecto a las reuniones anteriores. Durante este tiempo se realizaron las historias de usuario para recolectar los diversos propósitos que el sistema debía cumplir y para determinar los tiempos de entrega de las nuevas versiones de la aplicación. En el cuadro 5.1 se encuentran las reuniones que tuvieron lugar durante la elaboración del proyecto de grado. Cuadro 5.1: Resumen de las reuniones realizadas durante el desarrollo de la aplicación Reuniones Reuniones con Decanato de Estudios Profesionales y Decanato de Estudios Generales Reuniones con el personal del Decanato de Estudios Profesionales y Decanato de Estudios Generales interesados en la utilización del sistema Reuniones con el personal del Decanato de Estudios Generales para la discusión de la presentación de resultados parciales y totales del sistema Reuniones con la profesora Aurora Olivieri para el adiestramiento del personal encargado de utilizar la aplicación Reunión con el Decanato de Estudios Tecnológicos En esta etapa del proyecto se realizó el modelado de la base de datos y una descripción general del funcionamiento de la aplicación utilizando como herramienta de trabajo cohesión para la generación del código base del sistema de encuestas. Durante esta etapa se definieron los conceptos relacionados a la aplicación y cual debía ser el ciclo de vida de un instrumento. En el cuadro 5.2 se muestra un resumen de las distintas etapas que debían ser contempladas en la realización de una encuesta utilizando la aplicación.

52 40 Cuadro 5.2: Etapas para la realización de un instrumento Nombre Creación de instrumento Invitación de la población Llenado del instrumento Conteo y totalización de resultados Descripción Se refiere la creación del instrumento con sus respetivas secciones y preguntas Engloba todo lo relacionado al manejo de los encuestados y al envio de correos para invitarlos a responder el instrumento Fase en la cual los encuestados acceden a la aplicación para responder las preguntas de los instrumentos a los que fueron invitados Luego de concluido el tiempo de llenado, se procede a generar los reportes en los que se realiza una totalización de los resultados para un posterior análisis Fase de análisis A lo largo del desarrollo del sistema de encuestas se realizaron reuniones semanales con el profesor Ascánder Suárez con la finalidad de establecer nuevos objetivos y priorizar aquellos que debían ser realizados en el menor tiempo posible al ser de gran importancia para los clientes. Además de esto, era importante analizar las nuevas propuestas para la aplicación y evaluar el desarrollo del sistema. Otro punto tratado durante las reuniones semanales fue la inclusión de nuevos clientes, analizando los requerimientos de dichos clientes y determinando si la herramienta cumplía los mismos o si era factible adaptar el funcionamiento del sistema para cumplirlos Fase de desarrollo Siguiendo el proceso iterativo que caracteriza a la metodología utilizada, el desarrollo de la aplicación se fundamentó en dividir el tiempo disponible en un gran número de iteraciones, con duración de dos semanas cada una. Al inicio de cada iteración se planteaban cuales eran los objetivos que debían ser cumplidos o los problemas reportados por los usuarios que debían ser solucionados. Para el planteamiento de los objetivos se utilizó como referencia el listado de historias del usuario por rol, fraccionando la aplicación en tres grandes módulos, para luego ser divididos en pequeñas acciones utilizando el paradigma divide y vencerás. Mediante esta forma de trabajo se logró adaptar de manera efectiva el desarrollo de la aplicación a nuevos cambios que surgían en los requerimientos por parte de los clientes. Es importante

53 41 mencionar que durante el transcurso de cada semana se trabajaba únicamente en los objetivos establecidos para ese momento, evitando así el desarrollo de nuevos objetivos que no estuviesen contemplados para la próxima entrega de la aplicación. La planificación de nuevas entregas del sistema se realizó con la participación de los decanatos involucrados para de esta manera determinar cuales eran los objetivos primordiales que debía cumplir la aplicación. De esta manera se priorizó el módulo del administrador y se retrasaron los módulos del super administrador y encuestado, dado que los clientes deseaban comenzar a utilizar la aplicación aprendiendo a diseñar los instrumentos. Las primeras versiones de la aplicación fueron presentadas a los clientes mediante reuniones en las cuales se discutieron los objetivos que habían sido cumplidos hasta el momento y los cambios que consideraron pertinentes tanto en el funcionamiento de la aplicación como en la interfaz y la navegación. A partir de ese momento los usuarios podían acceder a la aplicación que se encontraba corriendo en el servidor cerf.lal.labf.usb.ve (con la última versión estable) para familiarizarse con la herramienta y realizar algunas pruebas como la creación de instrumentos ficticios. Si el usuario conseguía un error en la aplicación o consideraba pertinente un cambio en la interfaz, este creaba un reporte dentro de la aplicación MantisBT, en el que describía detalladamente la situación mediante el uso de texto o imágenes Fase de mejoramiento Al momento que los clientes se mostraron satisfechos con el diseño base de la aplicación que permitía a los administradores crear y modificar los instrumentos, se enfocó el tiempo de desarrollo en cumplir con los demás objetivos que habían sido pospuestos, mejorar la interfaz de la aplicación, realizar nuevas pruebas unitarias y corregir los errores que se habían encontrado hasta el momento. Entre los problemas encontrados y posteriormente solucionados se encuentran: Vista Previa: Dado que el sistema inicialmente contaba solamente con el módulo de Administrador, surgió la necesidad de tener la opción de ver la apariencia del instrumento que se esta diseñando y como este es presentado a los encuestados. Para solucionar este problema, se tomo en consideración la apariencia de los modelos en físico provisto por los decanatos y se implementó el módulo de Vista Previa, el cual se fue refinando

54 42 continuamente con la ayuda de los clientes. La apariencia del módulo de responder instrumento desarrollado posteriormente utilizó la apariencia mostrada en la vista previa para lograr la funcionalidad esperada. Filtros para generar reportes: Al momento de estudiar las respuestas obtenidas de los instrumentos, inicialmente se contaba con el vaciado de los datos en crudo sin tener controles detallados sobre ciertos datos demográficos que puedan ser de interés para el administrador. Para solucionar este problema, se implemento el instrumento de datos demográficos, el cual luego es utilizado como filtro por la herramienta BIRT al momento de generar reportes. BIRT toma el total de respuestas almacenadas y relaciona las respuestas de cada encuestado con sus respuestas de datos demográficos, permitiendo al administrador obtener solo las respuestas de aquellos encuestados que hayan respondido con los datos demográficos que le interesen. Envío masivo de correos: En las primeras versiones el sistema utilizó los servicios de Google para el envío de correos, funcionando de forma correcta con las pruebas iniciales con algunas decenas de usuarios, durante esta etapa cada correo tomaba en promedio 4 segundos en ser enviado. En la primera prueba a gran escala se utilizó una población de cerca de 5000 usuarios, lo que rebasaba el límite de correos diarios permitidos por Google para cuentas de correo no corporativas, además de que el tiempo que tomaba enviar todos los correos era inaceptable. Por esta razón, se procedió a utilizar el servidor de correos del Laboratorio Docente de Computación para poder enviar correos de forma masiva, dado que no cuenta con la restricción de correos diarios y los tiempos de entrega de correos se redujeron drásticamente (en la segunda prueba a gran escala 2000 correos fueron enviados en 2 minutos, aproximadamente 0.06 segundos por correo en comparación con los 4 segundos utilizando el servidor de correos de Google). Apariencia del sistema en plataformas Windows: El sistema de encuestas en sus versiones preliminares se presentaba de forma correcta en navegadores como Google Chrome o Mozilla Firefox, pero presentaba problemas con algunas versiones del navegador Internet Explorer, específicamente en las versiones anteriores a la 7.0. Este navegador

55 43 es notoriamente conocido por no respetar estándares HTML y por tener valores por defecto en cuanto a presentación distintos a otros navegadores del mercado, por lo que se requiere trabajo adicional por parte de los desarrolladores para lograr tener una apariencia consistente bajo cualquier navegador. Para solucionar este problema, se modificó el estilo de la aplicación mediante la utilización de CSS, logrando así una apariencia similar en todas las plataformas. Compartir modelos de instrumentos entre administradores: Inicialmente el sistema de encuestas planteaba que cada administrador era un ente totalmente independiente y aislado de otros administradores salvo en el caso de los usuarios, los cuales eran comunes para todos los administradores al momento de generar las poblaciones asociadas a los instrumentos. Luego de las pruebas iniciales del sistema por parte de los preparadores del decanato de Estudios Generales, se volvió evidente la necesidad de poder compartir algunos instrumentos entre los distintos administradores, dado que en muchos casos los administradores utilizaban instrumentos estructuralmente similares. Para solucionar este problema, se implementó un sistema de plantillas que permite a un administrador crear un instrumento que luego puede ser utilizado por cualquier administrador como base de diseño al momento de crear un nuevo instrumento. Uso concurrente de la aplicación: Al momento de realizar pruebas unitarias que involucraban el uso concurrente de la aplicación, la sesión de los usuarios era interrumpida de manera inesperada. Esto ocurría debido a que todas acciones que se ejecutaban de manera concurrente utilizaban la misma sesión de Hibernate para la interacción con la base de datos. Para solucionar el problema se modificó el manejo de sesiones de la aplicación para que cada acción utilizara una sesión distinta. Además de esto, con el objetivo de mejorar la escabilidad y desempeño de la aplicación en la conexión con la base de datos, se utilizó la librería BoneCP como pool de conexiones. Interfaz web mejorada: Las primeras versiones de la aplicación seguían la apariencia visual por defecto generada por Cohesión, la cual a medida que se fue desarrollando el sistema presentó una serie de deficiencias que debieron ser solucionadas por los de-

56 44 sarrolladores. El primer cambio importante de presentación fue la ampliación del área de trabajo, dado que la presentación original dejaba mucho espacio sin utilizarse en los extremos de la ventana del navegador. Para solucionar este problema, se editaron las imágenes y las proporciones utilizadas por el estilo CSS original de forma tal de tener una mayor área útil de trabajo. Posteriormente se eliminó el uso de imágenes y se rediseñó la apariencia general de la aplicación por el estilo actual, el cual resulta mas fácil de mantener y modificar. En la figura 5.1 se muestra la apariencia generada por la herramienta cohesión, mientras que en la figura 5.2 se muestra la apariencia final de la aplicación. Figura 5.1: Interfaz web original

57 45 Figura 5.2: Interfaz web final Pruebas unitarias Durante el desarrollo de la aplicación se realizaron constantemente pruebas unitarias para garantizar el correcto funcionamiento del sistema a medida que nuevas funcionalidades eran añadidas a los módulos del sistema. De esta manera se garantizaba que los cambios hechos en las nuevas versiones de la aplicación no afectaban el funcionamiento de acciones previamente desarrolladas. Además de esto, las pruebas unitarias fueron utilizadas para realizar pruebas de estrés a la aplicación. Pruebas funcionales A medida que cada funcionalidad era creada en la aplicación, se creaba de manera conjunta una prueba funcional que evaluara su correcto funcionamiento. De esta manera se garantizaba el funcionamiento de cada una de las funcionalidades de la aplicación. Las pruebas funcionales fueron implementadas con la herramienta SimpleTest.

58 46 Figura 5.3: Configuración de las pruebas de estrés Pruebas de estrés Se utilizaron 25 máquinas pertenecientes al Laboratorio Docente de Computación para garantizar la solidez de la aplicación en los momentos de carga extrema, en la figura 5.3 se aprecia la configuración de las pruebas de estrés. Las pruebas consistieron en ejecutar concurrentemente en cada máquina un número N de procesos, donde cada uno de estos procesos se encargaba de realizar una prueba funcional con un usuario diferente. En el cuadro 5.3 se muestran los tiempos promedios de respuesta dependiendo del manejador de conexiones utilizado. Para la realización de las pruebas fue utilizada la herramienta Cluster SSH y la interfaz de linea de comando de php PHP CLI. Cuadro 5.3: Tiempos de respuesta (en segundos) entre los manejadores de conexiones. Nro de procesos por máquina BoneCP C3P0 Sin manejador

59 47 Pruebas piloto Al momento de contar con una versión estable de la aplicación, el Decanato de Estudios Generales procedió a realizar distintas pruebas del funcionamiento del sistema mediante la creación de instrumentos experimentales que tenían como objetivo instruir a los preparadores encargados del diseño de los instrumentos. La población invitada a responder estos instrumentos estaba conformada por varios profesores de la Universidad Simón Bolívar, los cuales compartieron su opinión respecto a la interfaz del sistema y realizaron algunas sugerencias para facilitar el proceso de responder los instrumentos. Luego de solventar algunas dificultades que surgieron luego de estas pruebas iniciales, el Decanato de Estudios Generales utilizó la aplicación para la realización de la Encuesta para validar el perfil del egresado del Ciclo de Iniciación Universitaria (CIU), bajo el enfoque por competencias. La invitación a responder la encuesta la recibieron por correo electrónico los bachilleres o profesionales que finalizaron exitosamente el CIU entre Julio de 2006 y Julio 2011, así como los profesores que dictan clases o han dictado clases en este programa. [14] 5.2 Consideraciones del sistema Administración del sistema Al momento de comenzar el desarrollo de la aplicación se pensó que cada decanato o departamento dentro de la Universidad Simón Bolívar que necesitase realizar encuestas mediante la aplicación debía mantener y/o administrar una instancia de la misma, pero esta idea fue rechazada al momento de levantar los requerimientos debido a que generaba las siguientes dificultades: Los departamentos de la Universidad no contaban con el personal necesario para administrar este tipo de aplicaciones. Los decanatos deseaban compartir entre ellos las encuestas diseñadas en la aplicación para facilitar la creación de nuevas encuestas. Los encuestados necesitaban un usuario (y su respectiva contraseña) por cada instancia de la aplicación en la que desearan participar.

60 48 Es por esto que se cambia el enfoque de la aplicación para permitir el trabajo independiente de los distintos administradores bajo una misma instancia de la aplicación, manteniendo una única base de datos con los encuestados y permitiendo compartir las encuestas directamente desde la aplicación Mantenimiento Durante el desarrollo de la aplicación bajo la modalidad de proyecto de grado, la misma se instaló en el servidor de pruebas cerf.lal.labf.usb.ve perteneciente al Laboratorio de Lenguajes ubicado en el edificio de Matemática y Sistemas. En un futuro se tiene planeada una migración del sistema a los servidores de La Dirección de Ingeniería de Información (DII) de la Universidad Simón Bolívar Usuarios El sistema esta dirigido al personal administrativo de los decanatos de Estudios Generales, Estudios Profesionales y Estudios Tecnológicos, con el fin de diseñar encuestas que puedan ser respondidas por el personal obrero, profesional, egresados y estudiantes de la Universidad Simón Bolívar. Cabe destacar que el sistema puede ser utilizado en un futuro por la Universidad para realizar otros tipos de encuestas.

61 CONCLUSIONES Y RECOMENDACIONES En este proyecto de grado se desarrolló una aplicación web denominada Sistema de Encuestas que permite diseñar encuestas, repartirlas en una población en formato digital para que esta exprese su opinión y obtener la totalización de la información recolectada. Se utilizaron los beneficios del lenguaje Java en conjunto con sus librerías para crear una herramienta estable, segura y eficiente que facilita el proceso actual de creación de encuestas dentro y fuera de la Universidad Simón Bolívar. Esta herramienta cumple con los requerimientos iniciales al eliminar la necesidad de utilizar papel en el proceso, agilizar la recolección de datos en la población, realizar la totalización de la información de manera automática, estandarizar el formato de presentación de las encuestas bajo el enfoque por competencias creadas por el Decanato de Estudios Generales, el Decanato de Estudios Profesionales y el Decanato de Estudios Tecnológicos, eliminar los costos del trabajo de campo necesario para la realización de una encuesta, etc. Durante el desarrollo de la aplicación se mantuvo una continua comunicación entre las partes involucradas en el sistema, con el fin de cumplir con todas las necesidades que aparecieron en el camino, mediante soluciones tanto robustas como efectivas. También se brindó la asistencia necesaria al personal administrativo de los decanatos mientras estos se adaptaban al uso de la herramienta. Es importante mencionar que el sistema de encuestas fue desarrollado utilizando como base cohesión, herramienta desarrollada por un grupo coordinado por el profesor Ascánder Suárez dentro de la Universidad. Esta plataforma ofrece una interfaz gráfica para la creación del modelo de datos y diseño del sistema. Debe tenerse en cuenta que a pesar de que el diseño de la aplicación fue enfocado para cumplir los requisitos planteados por los decanatos involucrados, la herramienta puede ser utilizada para la realización de encuestas fuera de la Universidad a cualquier tipo de población 49

62 50 con acceso a Internet, gracias a la abstracción que se realizó en el modelo de datos al no diferenciar el tipo de encuestado dependiendo de su labor en la Universidad. En definitiva, este proyecto de grado no solo se creó una herramienta que cumple con los objetivos planteados, sino que además es altamente escalable y adaptable a requerimientos futuros. Actualmente la herramienta realiza la recolección de la información solicitada mediante la encuesta y realiza una totalización de la data con la cual puede generar un documento donde se muestra un resumen de las respuestas a cada pregunta de la encuesta. El próximo paso que se plantea al proceso de mejorar la aplicación, es el de crear un módulo de análisis que utilice la información recolectada por la encuesta para realizar un análisis detallado de los datos, que incluya información relacionada a las tendencias presentes en la encuesta y predicciones para las próximas ediciones, mediante el uso de tablas y gráficos. Otra funcionalidad que puede considerarse como útil, es la de poder descargar toda la información de las encuestas en un formato predefinido permitiendo realizar respaldos de manera manual, que luego puedan ser subidos a la herramienta en caso de querer restaurar la encuesta al estado en el que se encontraba al momento de realizar el respaldo. Se recomienda continuar con el desarrollo de la aplicación con el fin de que pueda ser utilizada por cualquier decanato, coordinación o institución dentro de la Universidad para la realización de encuestas. Esto ayudaría a fomentar el desarrollo de aplicaciones de calidad por parte de estudiantes de ingeniería en computación, preparándolos para su futuro como profesionales de la república.

63 REFERENCIAS [1] C.G. Ruíz. Internet y la investigación científica: El uso de los medios y las nuevas tecnologías en la educación. Alma Mater. Cooperativa Editorial Magisterio, página 28, [2] Dirección de Ingeniería de la Información. quiénes somos?, disponible en internet: consultado el 10 de julio de [3] Trygve Reenskaug. The model-view-controller (mvc) its past and present. disponible en internet: consultado el 15 de julio de [4] Trygve Reenskaug and James O. Coplien. The dci architecture: A new vision of objectoriented programming. disponible en internet: dci_vision.html, consultado el 23 de agosto de [5] Oracle Corporation. Java language and virtual machine specifications, disponible en internet: consultado el 22 de julio de [6] H. Bergsten. JavaServer Pages. Oreilly Series. O Reilly Media, página 12, [7] Jason Brittain and Ian F. Darwin. Tomcat: the definitive guide, 2nd edition. O Reilly, página 35, [8] James Turner and Kevin Bedell. Struts kick start. Sams, página 7, Indianapolis, IN, USA, [9] Hirondelle Systems. Criticisms of spring, struts, php, and rails. disponible en internet: jsp, consultado el 26 de octubre de Hirondelle Systems. 51

64 52 [10] J. Linwood and D. Minter. Beginning Hibernate, Second Edition. Apresspod Series. Apress, página 2, [11] Diana Peh, Alethea Hannemann, and Nola Hague. BIRT: A Field Guide to Reporting (The Eclipse Series). Addison-Wesley Professional, página 18, [12] J. Ward. Practical Data Analysis and Reporting with Birt. From technologies to solutions. Packt Publishing Limited, página 6, [13] Jason Weathersby, Tom Bondur, Iana Chatalbasheva, and Don French. Integrating and Extending BIRT. Addison-Wesley Professional, página 4, 2 edition, [14] Departamento de información y medios. Usb noticias, disponible en internet: http: //usbnoticias.info/post/17364, consultado el 30 de abril de [15] R. Elmasri, S.B. Navathe, V.C. Castillo, B.G. Espiga, and G.Z. Pérez. Fundamentos de sistemas de bases de datos. Materia Informática. Addison Wesley, páginas ,2002.

65 APÉNDICE A ACTORES INVOLUCRADOS Y USUARIOS A.1 Actores Involucrados En el cuadro A.1 se ofrece un breve resumen de los entes y/o personas que participaron en el desarrollo de este proyecto. Cuadro A.1: Resumen de los actores involucrados en el desarrollo del sistema Nombre Descripción Responsabilidades Decanato de Estudios Profesionales Decanato de Estudios Generales Decanato de Estudios Tecnológicos Ascánder Suárez Pedro Rincón Edward Zambrano Órgano académico encargado de diseñar, coordinar y evaluar todo lo relativo a programas de enseñanza durante el ciclo profesional de carreras largas. Órgano académico responsable de la orientación y actualización de las asignaturas de estudios generales. Órgano académico encargado del diseño, planificación, evaluación y ejecución de los programas de enseñanza de carreras cortas. Tutor académico. Presta asesoría en cuanto a la determinación de los requerimientos del sistema y de las características de su comportamiento. Desarrollador. Encargado del diseño e implementación del sistema. -Proponer los requerimientos. -Utilizar la herramienta. -Reportar fallas relacionadas a la aplicación -Proponer los requerimientos. -Utilizar la herramienta. -Reportar fallas relacionadas a la aplicación -Proponer los requerimientos. -Utilizar la herramienta. -Reportar fallas relacionadas a la aplicación -Prestar asesoría en la determinación de los requerimientos y características del sistema. -Monitoreo del progreso del sistema. -Desarrollar la aplicación -Brindar soporte a los usuarios de la aplicación 53

66 54 A.2 Roles de usuario En el cuadro A.2 se hace referencia a los roles de usuario de la aplicación, incluyendo una breve descripción del mismo y de las responsabilidades asociadas. Cuadro A.2: Resumen de los roles de usuario del sistema Nombre Descripción Responsabilidades SuperAdministrador Administrador Encuestado Encargado exclusivamente del manejo de los administradores. Encargado de todo lo relacionado a la creación y manejo de instrumentos con sus respectivas poblaciones, además de la gestión de los encuestados. Usuario que responde los instrumentos y las preguntas de datos personales. - Agregar nuevos administradores -Deshabilitar a los administradores que ya no son necesarios. -Modificar el perfil de los administradores. - Crear, modificar y/o eliminar estudios con sus respectivos instrumentos y sus poblaciones. -Gestionar las preguntas de datos personales asociadas a sus poblaciones. -Responder los instrumentos a lo que haya sido invitado. -Responder las preguntas de datos personales asociadas a los instrumentos a los que ha sido invitado.

67 APÉNDICE B MODELO ENTIDAD-RELACIÓN EXTENDIDO Descripción del minimundo El sistema de encuestas tiene tres distintos tipos de usuario: super administrador, administrador y encuestado. Cada usuario posee un único login, un password, un y un nombre. Un administrador puede seleccionar un subconjunto de preguntas de datos personales (preguntas dp). Un administrador posee un conjunto de estudios asociados a él. Un estudio es un conjunto de instrumentos y esta asociado a un administrador. Tiene un nombre, una descripción y posee un instrumento concreto denominado instrumento de datos demográficos utilizado para el filtrado de los resultados de aquellos instrumentos que pertenezcan al estudio. Una instrumento es un conjunto de secciones y esta asociado a un estudio. Cada instrumento posee un nombre, una descripción, la fecha de apertura y clausura, una invitación, un estado y un atributo booleano que determina si el instrumento es una plantilla. Cada instrumento invita a un subconjunto de encuestados mediante el envío de correos electrónicos. Una sección es un conjunto de preguntas y esta asociado a un instrumento. Cada sección posee un nombre, una plantilla, una posición y un atributo booleano denominado paginar. Una pregunta puede estar asociada a una sección (pregunta ins) o ser una pregunta de datos personales (pregunta dp). Cada pregunta tiene un enunciado, un tipo, una plantilla, una posición y un atributo booleano denominado paginar. 55

68 56 Un encuestado puede responder responder las preguntas de aquellos instrumentos a los que ha sido invitado y puede contestar las preguntas de datos personales. En la figura B.1 se muestra el modelo entidad relación utilizado para el desarrollo de la aplicación. Se utilizó como referencia la notación diagramática que se encuentra en el libro Fundamentos de Sistemas de Bases de Datos [15].

69 Figura B.1: Modelo Entidad-Relación Extendido 57

70 APÉNDICE C MANUAL DE IMPLANTACIÓN C.1 Requerimientos mínimos Aplicación Servidor Apache Tomcat/ JDK v6 o superior BIRT Acceso por Shell / pgadmin para el manejo de la base de datos Base de datos PostgreSQL o superior Cliente Navegador web con soporte de CSS y compatible con la librería de JQuery (Javascript). Se recomienda el uso de Google Chrome v20, Firefox 13 o Internet Explorer 9. La presentación de la vistas se basa en el uso de capas (divs) por lo que se pueden presentar problemas con navegadores que no realicen la visualización de CSS3 de manera correcta. C.2 Instalación Requisitos Se deben instalar y configurar correctamente las siguientes aplicaciones: Java Development Kit (JDK) Apache Tomcat 58

71 59 PostgreSQL Configuración de la aplicación La instalación de la aplicación se realiza mediante el archivo de aplicación web (.war), para ello es necesario copiar el archivo en el directorio de aplicaciones del servidor Tomcat, que generalmente se encuentra en /var/lib/tomcat6. Además de esto, es necesario copiar los archivos del BIRT Runtime en el directorio especificado en las propiedades de la aplicación (por defecto es /var/lib/birt RUNTIME). Debido a las nuevas restricciones de la versión 6 de Tomcat, se deben agregar las siguientes lineas al archivo catalina.properties que generalmente se encuentra en /etc/tomcat6. org.apache.jasper.compiler.parser.strict QUOTE ESCAPING=false org.apache.jasper.compiler.generator.strict GET PROPERTY=false Configuración de la base de datos La construcción de la base de datos se realiza con el archivo bd.sql que se encuentra en el mismo directorio que la aplicación (.war). Para crear la base de datos con sus respectivas tablas ejecute los siguientes comandos (con el usuario postgres): 1. createuser carreras -P (se crea el rol carreras) 2. createdb -O carreras -E UTF-8 -W carreras2 (se crea la Base de datos asociada al nuevo rol) 3. psql carreras -f bd.sql (se crean las tablas en la base de datos) Al iniciar por primera vez la aplicación podrá entrar al sistema bajo el rol de SuperAdministrador utilizando el usuario root con la contraseña password. Se recomienda como paso siguiente cambiar la contraseña en la pestaña de Modificar Perfil.

72 APÉNDICE D CASOS DE USO A continuación se hace un resumen de los casos de uso de la aplicación. La división de los casos se realizo utilizando como criterio los posibles roles que puede tomar un usuario del sistema de encuestas. La descripción de cada una de las acciones mencionadas se encuentra en la sección D.1 Caso de uso del super administrador Se refiere a todas las acciones que puede realizar un usuario bajo el rol de super administrador, estas se refieren casi en su totalidad a la creación, modificación y eliminación de los administradores que se encuentran registrados en la aplicación. Lista de historias de usuario que desarrolla 1. Recuperar contraseña 2. Iniciar sesión 3. Finalizar sesión 4. Crear administrador 5. Buscar administrador 6. Modificar perfil 7. Modificar perfil de los administradores 8. Deshabilitar administrador 60

73 61 D.2 Caso de uso del administrador Abarca las acciones que puede realizar un usuario bajo el rol de administrador, las cuales se refieren al manejo de los estudios con sus respectivos instrumentos y administración de los encuestados registrados en la aplicación. Lista de historias de usuario que desarrolla 1. Recuperar contraseña 2. Iniciar sesión 3. Finalizar sesión 4. Modificar perfil 5. Listar estudios 6. Crear estudios 7. Buscar estudio 8. Modificar estudio 9. Eliminar estudio 10. Listar instrumentos 11. Crear instrumento 12. Crear instrumento desde plantilla 13. Buscar instrumento 14. Modificar instrumento 15. Enviar invitaciones pendientes 16. Reenviar invitaciones a toda la población 17. Exportar resultados 18. Generar reporte

74 Eliminar instrumento 20. Listar población 21. Crear población 22. Carga masiva de población 23. Clonar instrumento 24. Vista previa de un instrumento 25. Listar secciones 26. Ordenar secciones 27. Crear sección 28. Modificar sección 29. Eliminar sección 30. Listar preguntas 31. Ordenar preguntas 32. Crear pregunta 33. Modificar pregunta 34. Eliminar pregunta 35. Listar preguntas de datos personales disponibles 36. Crear pregunta de datos personales 37. Seleccionar preguntas de datos personales 38. Ordenar preguntas de datos personales 39. Listar encuestados 40. Crear encuestado

75 Buscar encuestado 42. Modificar perfil encuestado 43. Listar población a la que pertenece un encuestado 44. Listar datos personales de un encuestado 45. Eliminar encuestado D.3 Caso de uso del encuestado Este caso de uso engloba todas las acciones que puede realizar un usuario bajo el rol de encuestado. Lista de historias de usuario que desarrolla 1. Recuperar contraseña 2. Iniciar sesión 3. Finalizar sesión 4. Responder preguntas de datos personales 5. Modificar perfil 6. Responder instrumento

76 APÉNDICE F: Cuaderno de Arquitectura Proyecto: Sistema de Encuestas Versión: 1.0

77 Cuaderno de Arquitectura Sistema de Encuestas Fecha: 15/8/ Introducción En este documento se describen los elementos relacionados con el diseño e implementación del sistema de encuestas. En este anexo se utiliza la terminología ya explicada en el capítulo 2 del libro. 2 Resumen Arquitectónico El sistema de encuestas es una herramienta diseñada con la finalidad de permitir reemplazar las metodologías manuales de elaboración de encuestas mediante la utilización de un software que permita el diseño, despliegue y captura de resultados de forma fácil, rápida y efectiva. La aplicación desarrollada es una aplicación web utilizando el patrón MVC que será utilizada tanto por las personas que desarrollan los instrumentos como por aquellos que responden los mismos. Entre los objetivos planteados para este proyecto se encuentran Cumplir con los objetivos generales y específicos planteados en el Capítulo 1 del libro La arquitectura debe estar compuesta por los elementos necesarios para cumplir los objetivos anteriormente planteados, pero al mismo tiempo dar cabida a futuras mejoras y nuevas funcionalidades.

78 Cuaderno de Arquitectura Sistema de Encuestas Fecha: 15/8/ Componentes Significativos de la Arquitectura del Sistema La arquitectura del sistema esta basada en el patrón MVC, por lo tanto existen tres capas claramente definidas las cuales son la capa Modelo, la capa Vista y la capa Controlador. Esta división permite desarrollar sistemas modulares y de fácil mantenimiento que permitan desarrollar distintos niveles de la aplicación de forma independiente. La capa modelo esta representada por el modelo Entidad Relación (Anexo B) y por el diccionario de datos (Anexo F) y se encuentra implementada bajo los archivos.hbm.xml de Hibernate. La capa vista esta implementada por las páginas JSP del proyecto, las cuales se encuentran bajo la carpeta web del código fuente. La capa controlador esta implementada por las clases de Java del proyecto, las cuales se encuentran bajo la carpeta src del código fuente. El manejador de bases de datos utilizado durante el desarrollo del sistema fue PostgreSQL, pero considerando que el sistema utiliza el ORM Hibernate, es posible migrar a otros manejadores de bases de datos realizando pocos cambios en la aplicación. El sistema utiliza el Framework Apache Struts versión 1.3. El desarrollo del sistema puede ser continuado de forma independiente, pero es recomendable el continuar utilizando cohesión en caso de tener familiaridad con la herramienta. Adicionalmente se utilizó BIRT para la elaboración de reportes, los cuales permiten visualizar con facilidad los resultados asociados a las poblaciones de cada instrumento. Requerimientos de la arquitectura. Durante el desarrollo del sistema se asume que se utiliza PosgreSQL como manejador de base de datos, aunque como se mencionó anteriormente este puede ser cambiado a otro haciendo los cambios pertinentes en los archivos de configuración. El servidor web utilizado es Apache Tomcat. El Framework utilizado es Struts en la versión La heramienta BIRT en la versión 4.2.0

79 Cuaderno de Arquitectura Sistema de Encuestas Fecha: 15/8/ Decisiones, restricciones y justificaciones Existen tres clases de usuarios o roles dentro del sistema. Se planteó esta división por diversos requerimientos. En primer lugar se necesitaba un usuario global que permita administrar a los demás sin tener que intervenir de forma directa en la elaboración de los instrumentos. Este es el Super Administrador. El administrador es aquel usuario que se encarga de diseñar, ejecutar y recopilar los resultados de los instrumentos diseñados, mientras que los encuestados son aquellos usuarios que pueden responder los instrumentos diseñados con la herramienta. Los estudios son abstracciones que permiten agrupar los instrumentos del sistema bajo algún criterio genérico. En un principio se planteó utilizar un sistema rígido de estudios por competencias, ya sea de estudios generales o estudios específicos, pero considerando que el sistema se pensó para otros usos se descartó esta idea y se implementaron los estudios como agrupaciones a discreción del administrador. Los encuestados del sistema son globales para todos los administradores, pero cada instrumento tiene poblaciones independientes que toman a un subconjunto de los encuestados. Se creó esta distinción entre encuestados y poblaciones con la finalidad de evitar que los encuestados tengan que registrarse de forma separada para los distintos instrumentos diseñados en la aplicación. Las preguntas de datos personales son visibles para todos los administradores, pero estos pueden decidir cuales quieren mostrar a sus poblaciones. Si un encuestado es miembro a poblaciones de distintos administradores, se muestra la unión de las preguntas de ambos administradores. Los usuarios del sistema son propios del sistema de encuestas y no se encuentran asociados a un sistema externo de autenticación como el CAS, debido a que el sistema puede ser usado por personas que no forman parte de la universidad (por ejemplo empleadores) y permite además el uso a futuro de la herramienta fuera del contexto de la universidad. Cada estudio cuenta con un estudio de datos demográficos, el cual se supone contiene preguntas de interés general sobre la población que luego permite filtrar los resultados de acuerdo a las preguntas de dicho instrumento. 5 Abstracciones Clave

80 Cuaderno de Arquitectura Sistema de Encuestas Fecha: 15/8/2012 La principal abstracción que existe en el sistema de encuestas es el instrumento. Un instrumento es la representación en el sistema del conjunto de preguntas mostradas en un papel, como por ejemplo la encuesta estudiantil. Cada instrumento esta compuesto por secciones, las cuales a su vez están compuestas por preguntas que son diseñadas por un administrador. Cada instrumento es parte de un estudio, el cual es una agrupación de instrumentos bajo algún criterio del administrador. Otra abstracción importante es el estudio. A nivel de la aplicación, un estudio es una agrupación de instrumentos, pero es importante que el administrador le de un significado a tales agrupaciones de instrumentos, ya sea por periodos de tiempo, por las poblaciones a las cuales se va a dirigir los instrumentos o por alguna relación del tópico o los tópicos a tratar. 6 Mecanismos de la arquitectura La información sobre los mecanismos de la arquitectura como entidades o clases, los atributos y las relaciones, incluyendo las restricciones fue presentada en el Apéndice E: Diccionario de datos.

81 Cuaderno de Arquitectura Sistema de Encuestas Fecha: 15/8/ Integración Bajo el Framework de Struts, los usuarios ven páginas JSP que son generadas de forma dinámica por el servidor JSP (Apache Tomcat, por ejemplo). Al momento de interactuar con la aplicación, se realizan acciones (llamadas también ActionForwards), las cuales están implementadas en el lenguaje Java y son interpretadas por Apache Tomcat, realizando la acción correspondiente ya sea en cuanto a navegación o cambios de estado dentro de la aplicación. Al momento de realizar cambios en el modelo de datos (por ejemplo al registrar un nuevo usuario) el controlador en java utiliza Hibernate para comunicarse con el manejador de base de datos y de esta forma realizar los cambios sin realizar consultas SQL directamente. En cuanto a la navegación, se sigue la estructura de acciones con el nombre APre_NOMBRE, con la finalidad de distinguir acciones que preparan las vistas de las acciones que ocurren dentro de las vistas como tal. Como se había mencionado anteriormente, los usuarios están divididos en tres roles distintos y cada uno posee acceso a partes diferentes del sistema. El manejo de dichos privilegios se maneja mediante Actores, los cuales son implementados por la clase cohesiónactor de Java. Bajo esta clase se verifica que cada usuario solo acceda a las páginas que debe al comparar la información almacenada en la sesión con respecto a los privilegios establecidos para la acción que desea realizar. 8 Vistas Arquitectónicas Los casos de uso se encuentran explicados de forma detallada en el Anexo D, por lo que serán omitidos de este documento.

82 Manual de usuario 22 de octubre de

83 ÍNDICE ÍNDICE Índice 1. Navegación Básica del Sistema Opciones comunes Roles de usuarios Restricciones sobre los usuarios Funcionalidades del super administrador Creación de administradores Perfil Gestionar administradores Modificar perfil de los administradores Deshabilitar administrador: Funcionalidades del administrador Perfil Estudios Restricciones sobre los estudios Instrumentos Estados de un instrumento Gestión de invitaciones por correo Exportar resultados y Generar reporte Clonación de un instrumento Vista previa de un instrumento Restricciones sobre los instrumentos Instrumento de datos demográficos Secciones Restricciones sobre las secciones Reordenamiento de las secciones Preguntas Tipos de pregunta Reordenamiento de las preguntas Restricciones sobre las preguntas Poblaciones Carga Masiva Preguntas de datos personales Visibilidad de preguntas de preguntas de datos personales Restricciones sobre las preguntas de datos personales Orden de las preguntas de datos personales Encuestados Creación de encuestados Gestión de encuestados Funcionalidades del encuestado Perfil Datos personales Responder instrumento

84 1. Navegación Básica del Sistema Para utilizar navegar el sistema se utilizan botones de navegación ubicados de forma conveniente en la parte superior de todas las páginas de la aplicación Opciones comunes Regresar: Permite al usuario devolverse un nivel en la navegación de la aplicación. Por ejemplo si se esta desde la vista principal de una pregunta, al pulsar Regresar se retorna a la Sección a la cual pertenece dicha pregunta. Figura 1: Botón Regresar Logout: Permite al usuario salir de manera segura de la aplicación. Figura 2: Botón Logout + Elemento: El símbolo + se utiliza para representar la creación de un nuevo elemento, presentando al usuario la vista de creación asociada al elemento. Por ejemplo en la imagen [S0.03] se aprecia el botón para crear un nuevo instrumento. Figura 3: Botón +Elemento Crear: Inserta un nuevo elemento a la aplicación. En la imagen [S0.04] se ve el botón crear para el caso de la creación de un encuestado. 3

85 Figura 4: Botón Crear Actualizar: Almacena los cambios realizados en la vista actual en la aplicación, por ejemplo al momento de cambiar el enunciado de una pregunta. Figura 5: Botón Actualizar Eliminar: Suprime el elemento que se esta visualizando. Al momento de eliminar un elemento se pregunta al usuario si esta seguro de continuar. En la imagen [S0.06] se muestra por ejemplo la eliminación de una sección. 4

86 Figura 6: Botón Eliminar Ayuda en linea: En todas las páginas del lado derecho se encuentra un botón de ayuda que despliega una ventana emergente con información asociada a la vista actual. Figura 7: Botón Ayuda 2. Roles de usuarios En el sistema de encuestas existen tres roles de usuarios definidos. Encuestados: Son los usuarios comunes que responden a los instrumentos diseñados mediante el sistema de encuestas. Administradores: Son los usuarios que diseñan los instrumentos con sus respectivas poblaciones y evalúan la información recolectada a través de ellos. 5

87 Super Administradores: Es un usuario único que se encarga de gestionar los administradores en el sistema de encuestas. El Super Administrador esta definido internamente en el sistema, y el login por defecto del mismo es root. Para ingresar al sistema debe abrir su explorador de Internet y dirigirse a la dirección en la que se encuentra la aplicación. Figura 8: Página de Ingreso al sistema En caso de olvido de contraseña, se puede utilizar la opción de Olvidó contraseña?, permitiendo el envío de una nueva clave de acceso al correo asociado al usuario. Figura 9: Botón Olvidó contraseña 6

88 Figura 10: Formulario de recuperar contraseña 2.1. Restricciones sobre los usuarios Los usuarios sólo pueden ser de un solo rol. Todos los usuarios poseen un identificador único para ingresar en el sistema. Los administradores y super administradores pueden tener logins con caracteres alfanuméricos. Los encuestados tienen como identificador su cédula que en teoría son solo números, aunque por razones de formato esta puede ser también alfanumérica. No pueden existir dos usuarios con el mismo correo electrónico. Fortaleza de la clave de acceso: el sistema requiere de un nivel mínimo para las claves de acceso para evitar ingresos mediante la utilización de claves comunes. Al momento de escribir una contraseña aparecerá una barra indicando la fortaleza de la misma. 7

89 Figura 11: Medidor de Fortaleza de la clave de acceso 3. Funcionalidades del super administrador 3.1. Creación de administradores Los administradores pueden ser creados de forma manual por el Super Administrador. Para crear un Administrador se debe rellenar el formulario Crear Administrador [S2.02] que aparece al pulsar el botón + Administrador. Figura 12: Formulario de creación de administradores 3.2. Perfil El super administrador puede modificar los datos de su cuenta mediante el formulario de Modificar mi perfil. El administrador unicamente puede cambiar su nombre completo, su correo electrónico y su contraseña. 8

90 Figura 13: Botón Modificar el perfil Figura 14: Formulario de modificación de perfil 3.3. Gestionar administradores Modificar perfil de los administradores El super administrador desde la vista principal puede modificar el perfil de los administradores, seleccionado alguno de los usuarios de la lista. El super administrador puede modificar los campos de nombre de usuario, nombre y correo electrónico. 9

91 Figura 15: Formulario de modificación de perfil Deshabilitar administrador: El super administrador debe poder deshabilitar a un administrador. Si un administrador es deshabilitado, este no podrá entrar al sistema, sin embargo las encuestas asociadas a él no son eliminadas. Figura 16: Botón Deshabilitar Administrador 4. Funcionalidades del administrador 4.1. Perfil El administrador puede modificar los datos de su cuenta mediante el formulario de Modificar mi perfil. El administrador unicamente puede cambiar su nombre completo, su correo electrónico y su contraseña. 10

92 Figura 17: Botón Modificar Perfil Figura 18: Formulario de Modificación de Perfil 4.2. Estudios Un estudio es una agrupación de instrumentos bajo algún criterio del administrador, por ejemplo un periodo de tiempo o tópico. Para crear un se debe rellenar el formulario Crear Estudio que aparece al pulsar el botón + Estudio desde la vista principal del administrador. 11

93 Figura 19: Formulario de creación de Estudios Restricciones sobre los estudios Todo estudio debe tener un nombre y descripción. Todo estudio debe tener un instrumento de datos demográficos definido. Un instrumento de datos demográficos es un instrumento diseñado con la finalidad de presentar un conjunto de preguntas comunes a todos los instrumentos de un estudio en particular. Este instrumento puede ser vacío, pero debe ser creado y designado como instrumento de datos demográficos antes de cambiar el estado a abierto de un instrumento de ese estudio. Para seleccionar un instrumento como instrumento de datos demográficos, se selecciona el instrumento deseado desde el dropdown de la vista del estudio y se pulsa el botón Actualizar. [S3.02] Figura 20: Selección de Instrumento de Datos Demográficos 12

94 Los instrumentos de datos demográficos deben permanecer en estado Diseño Instrumentos Un instrumento es un conjunto de secciones con un orden, el cual es presentado a los encuestados de forma análoga a las encuestas en papel. Para crear un instrumento, se utiliza el botón + Instrumento desde la vista del Estudio [S4.01]. Al momento de crear un instrumento, se puede utilizar alguno de los instrumentos establecidos como plantilla o crear un instrumento vacío. Figura 21: Botón Plantillas Figura 22: Formulario de creación de un instrumento a partir de una plantilla 13

95 Las plantillas son instrumentos diseñados por un administrador que pueden ser utilizados como base por los demás administradores para crear un nuevo instrumento, facilitando el proceso de creación de instrumentos que posean un formato similar Estados de un instrumento Los posibles estados de un instrumento son: Diseño: El instrumento esta en construcción y puede ser modificado de cualquier forma, como agregar nuevas secciones, agregar poblaciones, etc. Abierto: El instrumento se considera completo en cuanto a diseño y puede ser presentado a los encuestados para ser respondido. Cerrado: El instrumento ha cumplido su periodo de validez y ya no puede ser respondido por los encuestados. El estado inicial de todos los instrumentos es Diseño. Para cambiar el estado de un instrumento, se selecciona la opción deseada desde el dropdown en la vista del instrumento y se pulsa el botón Actualizar para almacenar los cambios. Figura 23: Cambio de estado de un Instrumento Gestión de invitaciones por correo Las invitaciones por correo pueden ser enviadas a la totalidad de la población ( Reenviar invitaciones ) o a aquellos encuestados que aún no hayan sido invitados ( Enviar pendientes ). [S4.09] 14

96 Figura 24: Botones de Gestión de Invitaciones Exportar resultados y Generar reporte La aplicación permite generar un archivo CSV que contiene las respuestas suministradas por los encuestados mediante la opción Exportar desde la vista del instrumento. Figura 25: Botón Exportar La aplicación permite además generar reportes en formato HTML o PDF con un resumen de las respuestas suministradas por los encuestados aplicando un filtro de búsqueda mediante las preguntas del instrumento de datos demográficos del estudio al que pertenece el instrumento. Figura 26: Botón Generar Reporte Figura 27: Vista de generación de Reportes Clonación de un instrumento Un administrador puede clonar un instrumento creado por él para utilizarlo como base para el diseño de un nuevo instrumento. [S4.06][S4.07] 15

97 Figura 28: Botón Clonar Figura 29: Vista de clonación de un instrumento Vista previa de un instrumento Un administrador puede ver como será presentado el instrumento al encuestado al momento de contestarlo pulsando el botón Vista Previa. Figura 30: Botón Vista Previa Restricciones sobre los instrumentos Un instrumento creado por un administrador no es visible para otros administradores, a menos que este sea establecido como una plantilla. Un instrumento en estado Diseño no es visible por los encuestados. Durante este estado un instrumento puede ser clonado o previsualizado. Un instrumento en estado Diseño solo puede cambiar a estado Abierto si existe un instrumento de datos demográficos definido para el estudio al que pertenece. Un instrumento en estado Abierto permite además la generación de reportes, exportar resultados parciales y gestionar las invitaciones por correo. 16

98 Un instrumento en estado Abierto no puede ser modificado en cuanto a secciones o preguntas salvo en el orden en que son presentados. Un instrumento en estado Abierto solo puede cambiar a estado Cerrado. Un instrumento en estado Cerrado no puede respondido por los encuestados. Un instrumento en estado Cerrado no puede ser cambiado de estado. Un instrumento en estado Cerrado no permite la gestión de invitaciones por correo. Las poblaciones y el orden de las preguntas pueden ser modificados en cualquier estado del instrumento. En caso de invitar encuestados luego de ser abierto un instrumento se provee la facilidad de enviar las invitaciones restantes o reenviar las invitaciones a todos los miembros de la población Instrumento de datos demográficos Para este instrumento especial no hace falta agregar poblaciones, dado que este se va a presentar a todos los encuestados que respondan a un instrumento del estudio al cual pertenece dicho instrumento de datos demográficos. La descripción e invitación del instrumento de datos demográficos no son presentadas al encuestado, solo se muestra la descripción e invitación del instrumento al cual fue invitado Secciones Una sección es una agrupación de preguntas. Para crear una sección se utiliza el botón + Sección desde la vista del Instrumento. Figura 31: Formulario de creación de Sección 17

99 Restricciones sobre las secciones Una sección no puede ser modificada si el instrumento a la cual pertenece esta en un estado distinto a Diseño Reordenamiento de las secciones El orden de las secciones de un instrumento se muestra desde la vista del instrumento bajo la pestaña Secciones. El orden de las secciones puede ser modificado en cualquier momento. Para cambiar el orden de las secciones, se arrastra la sección a la posición deseada y se pulsa el botón Reordenar para almacenar los cambios. Figura 32: Botón Reordenar 4.5. Preguntas Una pregunta es el elemento básico de un instrumento. Contiene un enunciado y las opciones pertinentes dependiendo del tipo de pregunta. Para crear una pregunta se utiliza el botón + Pregunta desde la vista de la sección. Figura 33: Formulario de creación de preguntas Tipos de pregunta Las preguntas pueden ser de uno de los siguientes tipos: 18

100 Competencias: Es un tipo de pregunta que tiene dos respuestas asociadas, la importancia y el dominio. Cada una de estas preguntas tiene como posibles respuestas una escala del 1 al 5 y una opción de No Aplica. Selección Simple: Es un tipo de pregunta que tiene una sola respuesta. Las opciones disponibles son establecidas por el administrador al momento de elaborar la pregunta. Selección Múltiple: Es un tipo de pregunta que tiene múltiples opciones como respuesta. Las opciones disponibles son establecidas por el administrador al momento de elaborar la pregunta. Texto Corto: Es un tipo de pregunta que tiene como respuesta un texto introducido por el usuario. Estas respuestas por su naturaleza no pueden ser totalizadas en los reportes. Texto Largo: Es un tipo de pregunta que tiene como respuesta un texto largo introducido por el usuario. Estas respuestas por su naturaleza no pueden ser totalizadas en los reportes. El tipo de la pregunta puede ser modificado siempre y cuando el instrumento se encuentre en fase de diseño Reordenamiento de las preguntas El orden de las preguntas de una sección se muestra desde la vista de la sección bajo la pestaña Preguntas. El orden de las preguntas de la sección puede ser modificado en cualquier momento. Para cambiar el orden de las preguntas, se arrastra la pregunta a la posición deseada y se pulsa el botón Reordenar para almacenar los cambios Restricciones sobre las preguntas Todas las preguntas deben tener un enunciado. Una pregunta no puede ser modificada si el instrumento a la cual pertenece esta en un estado distinto a Diseño Poblaciones Una población es una relación entre un encuestado y un instrumento particular. Para crear una población, se utiliza el botón + Población desde la vista del instrumento o desde la vista del encuestado. 19

101 Figura 34: Formulario de creación de poblaciones desde un instrumento Figura 35: Formulario de creación de poblaciones desde encuestados Carga Masiva En el caso de tener muchos usuarios a los cuales se desea agregar a una población, es posible utilizar la opción de carga masiva para utilizar un archivo de texto con el formato Cédula, Correo, Nombre. Bajo esta modalidad si no existe un usuario con la cédula especificada se crea un nuevo usuario del tipo encuestado en el sistema y se envía un correo con la información necesaria para ingresar al sistema. En caso de existir un usuario con la cédula especificada se agrega a dicho usuario a la población del instrumento. En caso de detectar un error al momento de cargar los usuarios el sistema alerta al administrador y especifica en que parte del archivo se encontró el error. 20

102 Figura 36: Botón de carga masiva Figura 37: Formulario de carga masiva 4.7. Preguntas de datos personales Las preguntas de datos personales son preguntas adicionales que pueden ser de interés del administrador al momento de saber las características de los encuestados independientemente de un estudio, como la empresa donde trabaja o números telefónicos entre otros. Para crear una pregunta de datos personales, se utiliza la opción Administrar datos personales desde la vista de Encuestados pulsando la opción +Pregunta. 21

103 Figura 38: Botón Regresar Figura 39: Vista de preguntas de datos personales 22

104 Figura 40: Formulario de creación de preguntas de datos personales Visibilidad de preguntas de preguntas de datos personales Las preguntas de datos personales son compartidas por todos los administradores del sistema, y cada administrador puede seleccionar cuales preguntas desea realizar a las poblaciones de sus instrumentos. A los encuestados se les presenta el conjunto total de preguntas que han sido seleccionadas como visibles por todos los administradores que han invitado al encuestado a algún instrumento. Figura 41: Visibilidad de preguntas de datos personales Restricciones sobre las preguntas de datos personales Las preguntas de datos personales no pueden ser modificadas o eliminadas luego de ser creadas. El tipo de pregunta de competencias no esta disponible para las preguntas de datos personales. 23

105 Orden de las preguntas de datos personales Para ver o cambiar el orden de presentación al encuestado de las preguntas se utiliza la opción orden.... Para modificar el orden de las preguntas, se arrastra la pregunta a la posición deseada y se pulsa el botón Reordenar para guardar los cambios. Figura 42: Botón Orden... Figura 43: Reordenamiento de preguntas de datos personales 4.8. Encuestados Creación de encuestados Los Encuestados pueden ser creados de forma manual desde la vista de Encuestados utilizando el formulario de Crear encuestado [S2.01] utilizando el botón + Encuestado o al ser ingresados por primera vez mediante la funcionalidad de Carga Masiva explicada en la sección

106 Figura 44: Formulario de creación de encuestados Gestión de encuestados El administrador puede modificar los datos de un encuestado, estos son la cédula de identidad, el correo electrónico y el nombre completo. También tiene la posibilidad de eliminar un encuestado o asociar el encuestado a la población de un instrumento como se explicó en la sección 4.6. Figura 45: Gestión de un encuestado 5. Funcionalidades del encuestado 5.1. Perfil El encuestado puede modificar los datos de su cuenta mediante el formulario de Modificar mi perfil. El administrador unicamente puede cambiar su nombre completo, su correo electrónico y su contraseña. 25