GuiaMeUVa: D desarrollo de una aplicación web que localiza y guíe a lugares en la Escuela de Ingeniería Informática

Universidad de Valladolid E. Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática Mención Tecnologías de la Información GuiaMeUVa: Desarrollo de una aplicación web que localiza y guíe a lugares en la Escuela de ingeniería informática. Autor: Juan Carlos Aparicio Domínguez Tutora: Margarita Gonzalo Tasis Resumen En la actualidad el número de estudiantes universitarios en escuelas o facultades ubicadas en ciudades distintas a las de los alumnos es mayor con respecto a años anteriores. Las asignaturas de estas titulaciones pueden ser impartidas en escuelas cuyos docentes tienen su despacho ubicado en un centro distinto con lo cual supone un inconveniente al alumno por tener que desplazarse hacia otro centro y localizar el despacho del docente. Por otro lado, las construcciones de las facultades no son iguales lo cual hace necesario un plano del edificio a modo de leyenda con sus correspondientes plantas y despachos. Este trabajo pretende analizar, comprender y desarrollar una aplicación móvil para Android para facilitar la solicitud de tutorías por parte del alumno y la de guiar al alumno a llegar a su ubicación. La aplicación desarrollada, GuiaMeUVa, consiste fundamentalmente en una herramienta que cumple las funcionalidades anteriormente mencionadas y también la disponibilidad de enviar un correo al docente si así lo necesitara. El método y proceso de software seguido es RUP y la notación de diagramas utilizada es UML. Por último, en este documento se encuentra todo el material obtenido como consecuencia de la licitación de requisitos, análisis, diseño, implementación y pruebas, así como los manuales necesarios para su uso. Abstract At present, the number of university students in schools or faculties located in cities other than those of students is greater than in previous years. The subjects of these degrees can be taught in schools whose teachers have their office located in a different center with which it is inconvenient for the student to have to move to another center and locate the teacher's office. On the other hand, the constructions of the faculties are not the same, which makes necessary a plan of the building as a legend with its corresponding floors and offices. This work aims to analyze, understand and develop a mobile application for Android to facilitate the request for tutorials by the student and to guide the student to reach their location. The application developed, GuiaMeUVa, consists essentially of a tool that fulfills the above-mentioned functionalities and also the availability of sending an email to the teacher if needed. The software method and process followed is RUP and the diagram notation used is UML. Finally, this document contains all the material obtained as a result of the bidding process for requirements, analysis, design, implementation and testing, as well as the manuals necessary for its use. Tabla de contenidos 7 Tabla de contenidos Capítulo 1 - Introducción .................................................................................................................................... 15 1.1. Motivación .................................................................................................................................................. 17 1.2. Objetivos..................................................................................................................................................... 17 1.3. Estructura de la memoria ............................................................................................................................ 17 Capítulo 2 - Contexto .......................................................................................................................................... 19 2.1. Apps existentes destinadas a alumnos ........................................................................................................ 22 2.1.1. Aplicaciones de comunicación Alumno Profesor. ............................................................................... 22 2.1.2. Aplicaciones de localización de espacios. ........................................................................................... 24 2.2. Propuesta de solución ................................................................................................................................. 25 2.2.1. Alcance ................................................................................................................................................ 26 Capítulo 3 – Plan de desarrollo de Software ..................................................................................................... 27 3.1. Introducción ................................................................................................................................................ 29 3.1.1. Propósito .............................................................................................................................................. 29 3.1.2. Ámbito ................................................................................................................................................. 29 3.1.3. Visión global ....................................................................................................................................... 29 3.2. Visión general del proyecto ........................................................................................................................ 29 3.2.1. Objetivos y ámbito del proyecto .......................................................................................................... 29 3.2.2. Suposiciones y restricciones ................................................................................................................ 30 3.2.3. Entregables. Proceso Unificado ........................................................................................................... 30 3.2.4. Evolución del plan de Desarrollo de Software .................................................................................... 31 3.3. Organización del proyecto .......................................................................................................................... 32 3.3.1 Interfaces externas ................................................................................................................................ 32 3.3.2 Estructura interna de la organización ................................................................................................... 32 3.3.2 Método de trabajo ................................................................................................................................. 33 3.4. Plan de gestión de procesos ........................................................................................................................ 33 3.4.1 Plan de inicio ........................................................................................................................................ 33 3.5. Plan de trabajo ............................................................................................................................................ 34 3.5.1 Actividades del proyecto ...................................................................................................................... 34 3.5.2. Recursos humanos del proyecto .......................................................................................................... 36 3.5.3 Duración real del proyecto ................................................................................................................... 37 3.6. Costes del proyecto. .................................................................................................................................... 38 Capítulo 4 – Plan de gestión de riesgos .............................................................................................................. 39 4.1 Gestión de riesgos ........................................................................................................................................ 42 Capítulo 5 – Análisis ............................................................................................................................................ 47 5.1. Análisis de requisitos .................................................................................................................................. 49 5.2 Restricciones ................................................................................................................................................ 51 Tabla de contenidos 8 5.3 Casos de uso ................................................................................................................................................51 5.3.1. Actores primarios.................................................................................................................................51 5.3.2. Actores secundarios. ............................................................................................................................51 5.3.3. Diagrama de Casos de Uso. .................................................................................................................52 5.3.4 Especificación de casos de uso .............................................................................................................54 5.4 Realización de Casos de Uso .......................................................................................................................74 5.4.1. Modelo de dominio ..............................................................................................................................74 5.4.2. Diagramas de actividad........................................................................................................................76 Capítulo 6 – Arquitectura y Diseño ...................................................................................................................97 6.1 Arquitectura Propuesta. MVP ......................................................................................................................99 6.2 Ciclo de vida de Activities y Fragments ....................................................................................................100 6.3. Diseño de la arquitectura ..........................................................................................................................101 6.3.1. Gestión de la persistencia ..................................................................................................................101 6.3.2. Modelo de despliegue ........................................................................................................................103 6.4.3. Diagramas de secuencia .....................................................................................................................104 6.4.4. Diagramas de clase de diseño ............................................................................................................105 Capítulo 7 – Prototipo .......................................................................................................................................111 7.1. Propuesta de prototipo ..............................................................................................................................113 7.1.1. Guías de diseño ..................................................................................................................................113 7.1.2. Navegación ........................................................................................................................................113 7.1.3. Interfaz ...............................................................................................................................................113 7.1.4. Tipografía ..........................................................................................................................................114 7.2. Descripción general del personaje principal “Alumno” ...........................................................................115 7.3. Diseño de los subsistemas ........................................................................................................................116 7.3.1. Vista de casos de uso. Diseño de la interfaz de usuario.....................................................................116 7.4. Evaluación del prototipo ...........................................................................................................................127 7.4.1. Introducción .......................................................................................................................................127 7.4.2. Elección de cuatro tareas significativas .............................................................................................128 7.4.3. Test de usabilidad con usuarios reales ...............................................................................................129 7.4.4 Resultados obtenidos en el test de usabilidad .....................................................................................130 Capítulo 8 – Implementación y Pruebas ..........................................................................................................133 8.1. Herramientas utilizadas ............................................................................................................................135 8.2. Entorno de desarrollo ................................................................................................................................135 8.3. Implementación ........................................................................................................................................136 8.3.1. Decisiones de la implementación ......................................................................................................136 8.4. Alcance de las pruebas .............................................................................................................................141 8.5. Listado de las pruebas ...............................................................................................................................141 8.5.1. Listado para el Usuario (Alumno): ....................................................................................................141 Tabla de contenidos 9 8.5.1. Listado para el Administrador: .......................................................................................................... 141 8.6 Tipos de pruebas ........................................................................................................................................ 142 8.6.1 Pruebas de funcionalidad .................................................................................................................... 142 8.6.2. Pruebas de interfaz de usuario ........................................................................................................... 142 8.6.3. Pruebas de datos e integridad de la base de datos ............................................................................. 142 8.6.3. Pruebas en diferentes versiones ......................................................................................................... 142 8.7 Metodología de las pruebas ....................................................................................................................... 142 8.8 Resultados.................................................................................................................................................. 142 8.9.1. Pruebas para el Usuario “Alumno”.................................................................................................... 143 8.9.2. Pruebas para el Administrador .......................................................................................................... 146 Capítulo 9 - Conclusiones ................................................................................................................................. 153 Capítulo 10 – Líneas Futuras ........................................................................................................................... 157 Capítulo 11 – Bibliografía ................................................................................................................................. 161 Anexos ................................................................................................................................................................. 167 APÉNDICE A: Manual de Instalación ............................................................................................................ 169 A.1. Instalación de la aplicación GuiaMeUVa App .................................................................................... 169 A.2. Código fuente Web .............................................................................................................................. 170 A.3. Android Studio .................................................................................................................................... 171 APÉNDICE B: Material test usabilidad .......................................................................................................... 172 B.1. Introducción y bienvenida .................................................................................................................... 172 B.2. Realización de las tareas ...................................................................................................................... 172 B.3. Preguntas, cuestiones y despedida ....................................................................................................... 173 B.4. Hoja de observaciones ......................................................................................................................... 173 APÉNDICE C: Manual de usuario - Administrador ....................................................................................... 175 C.1. Introducción ......................................................................................................................................... 175 C.2. Funcionalidades para el Administrador ............................................................................................... 175 APÉNDICE D: Manual de usuario - Alumno ................................................................................................. 189 D.1. Introducción ......................................................................................................................................... 189 D.2. Funcionalidades para el Alumno ......................................................................................................... 189 APÉNDICE E: Contenido del CD ................................................................................................................... 199 16 Capítulo 1. Introducción 17 1.1. Motivación En la actualidad, los docentes procedentes de las escuelas o facultades universitarias pueden impartir materias propias de su departamento y escuela en planes de estudios de Grado o de Master universitario en otros centros con la consiguiente dispersión de dichos docentes. Esto conlleva a que los estudiantes tienen que consultar en qué centro se encuentra su despacho, como su ubicación y el horario de tutoría de un profesor dado. Este documento es la propuesta elaborada como respuesta a la asignatura Trabajo Fin de Grado del Grado en Ingeniería Informática mención Tecnologías de la Información de la Escuela de Ingeniería Informática [1] de la Universidad de Valladolid [2]. Este Trabajo de Fin de Grado (TFG en adelante) consiste en el desarrollo de una aplicación móvil Android [3] para guiar y ayudar a los alumnos universitarios para poder aprovechar el recurso de las tutorías con los docentes. A esta aplicación se la ha denominado GuiaMeUVa. 1.2. Objetivos El objetivo es la realización de una App que guía y ayuda al alumno a acudir al despacho del profesor o tutor en cuestión para tener una tutoría. La aplicación muestra la información y ubicación del despacho a la vez que indica a tiempo real la ruta a seguir del alumno para llegar al destino. La aplicación será accedida a través de una app móvil en Android y se supone que las guías empleadas serán usadas por los alumnos de la universidad que quieran acudir a la tutoría concertada. El TFG consistirá en la elaboración de un proyecto como trabajo de síntesis de competencias que tendrá como finalidad la elaboración por el estudiante de un trabajo personal en el que se apliquen e integren los conocimientos, habilidades y actitudes desarrolladas durante los años de estudio en la titulación mencionada anteriormente. Los objetivos que persigue este TFG se mencionan a continuación: • Desarrollar una App que guie a los alumnos para encontrar el despacho de un profesor. • Utilizar los datos de los profesores que están en la web de la UVa. • Utilizar mapas y planos de la Escuela de Ingeniería Informática y Google Maps para llegar. • Desarrollar la App mencionada anteriormente empleando como patrón de diseño Modelo Vista Presentador (MVP). 1.3. Estructura de la memoria A continuación, se proporciona un pequeño esquema de los temas principales que van a ser tratados en los siguientes capítulos, así como una breve descripción de cada uno de ellos • Contexto: descripción y análisis de algunas de las aplicaciones similares que hay disponibles, incluyendo aspectos deseables y no deseables como una pequeña conclusión de ellos. • Entorno tecnológico: Descripción de los equipos y herramientas utilizados durante la realización del proyecto. • Plan de desarrollo de Software: Visión global del enfoque de desarrollo propuesto del TFG • Requisitos: Especificación de los requisitos funcionales y no funcionales del sistema. • Planificación y seguimiento: Desglose del tiempo y esfuerzo que se estiman necesarios para llevar a cabo cada una de las fases de las que se compone el proyecto. Incluye la gestión de riesgos. • Análisis: Detalle de los aspectos más relevantes de la arquitectura y diseño. • Arquitectura y diseño: detalle de los aspectos más relevantes de la arquitectura y diseño. Capítulo 1. Introducción 18 • Implementación y pruebas: Detalle de los aspectos correspondientes a la fase de construcción y pruebas de la ingeniería de software seguidas en las fases anteriores. • Conclusiones y líneas futuras: Se comentan las conclusiones obtenidas a lo largo del desarrollo del proyecto y las posibles líneas futuras de trabajo. • Referencias: Fuentes consultadas a lo largo de la realización de proyecto • Anexos: Información complementaria relativa al proyecto que puede resultar de interés para el lector y en ocasiones provee una visión más extensa de algunos temas tratados. Se incluyen los manuales de instalación y usuario. 19 Capítulo 2 - Contexto 20 Capítulo 2. Contexto 21 La tutoría con los profesores en el ámbito de la universidad consiste en una actividad de carácter formativo que se ocupa de la formación personal, social y profesional de los estudiantes como elementos relevantes de la formación universitaria. La tutoría universitaria tiene que entenderse como un elemento dinamizador para que todos los subsistemas de la organización educativa de la Universidad apoyen al estudiante para conseguir que este sea el agente activo de su aprendizaje. Deberíamos destacar que la disponibilidad de los profesores viene marcada por la guía docente de cada una de las materias que éstos imparten, con lo cual podemos obtener información acerca de la ubicación de los docentes en el horario determinado por esta guía. Esto puede ser fácil desde el punto de vista informativo pero puesto en práctica puede llevar a algunas dificultades como por ejemplo que en un mismo campus puede haber diferentes facultades con lo cual debemos estar seguros de que nos encontraremos en el lugar correcto. Por otro lado, la movilidad del profesorado puesto que los distintos profesores pueden impartir materias distintas en diferentes centros con lo cual el despacho para las tutorías puede variar. También tenemos que darnos cuenta de que varios profesores pueden compartir despacho en un horario determinado. Figura 1: Campus Universitario Miguel Delibes, Valladolid Figura 2: Campus Universitario La Yutera, Palencia Capítulo 2. Contexto 22 Otro aspecto importante es la distribución de las distintas facultades. Hay que tener en cuenta que no siguen un diseño en común con lo cual la distribución de las aulas, despachos y salas requiere un mayor esfuerzo por parte del alumnado en localizar una ubicación determinada. Figura 3: Plano Escuela Ingeniería Informática de Valladolid Los alumnos por su parte, no conocen en su totalidad los espacios disponibles de las facultades tales como salas de estudio o despachos de orientación los cuales pueden ser importantes para Los profesores que imparten clases en diferentes centros o facultades, tienen a su disposición un despacho para poder atender a los alumnos que soliciten una tutoría de la materia en cuestión. El horario de disponibilidad viene determinado en la guía docente de cada asignatura que el profesor imparte siempre respetando que se cumpla, y no se produzca solapamiento entre éstos para que los alumnos de diferentes materias puedan acudir a cada uno de los despachos que tiene asignados el profesor. 2.1. Apps existentes destinadas a alumnos En este apartado, lo primero que hacemos es ponernos en situación. Antes de poder desarrollar nuestra aplicación, se llevará a cabo un breve análisis sobre las diferentes aplicaciones existentes que pretenden proporcionar una solución similar. Para cada una de ellas, se expondrán las ventajas y desventajas observadas y una pequeña conclusión. Abordaremos este análisis orientando a dos puntos de vista: el de comunicación entre alumnos y profesores y el de localización de interiores. 2.1.1. Aplicaciones de comunicación Alumno Profesor. 2.1.1.1. Pizarra Uva Pizarra Uva es una aplicación que favorece la comunicación entre alumnos y profesores gracias a un sistema de mensajería útil y sencillo. Con el perfil de profesor se pueden enviar mensajes de forma masiva a todas las asignaturas o solamente a algunas según la necesidad. Por otro lado, con el perfil de alumno se podrán añadir comentarios, ver los mensajes u anotaciones previamente escritos por otros usuarios, consiguiendo así la creación de un hilo de conversación sobre un tema añadiendo comentarios sobre el mensaje principal. Capítulo 2. Contexto 23 Figura 4: Pizzarra UVa Ventajas: • Permite la comunicación directa con un profesor Desventajas: • Resulta útil si es complementario al entorno Moodle. • Demasiados pasos para marcar como leídos los mensajes. • Algunas de las tipografías no son agradables. Conclusión: Facilita la comunicación entre profesor y alumno fuera de las clases siendo un complemento más junto con el entorno Moodle del Campus Virtual y el correo electrónico, pero no satisface la necesidad descrita anteriormente, no guía a los alumnos a acudir a los despachos de los profesores de otros centros. 2.1.1.2. TokApp School TokApp School [4] es una app móvil disponible tanto en iOS como en Android destinado a la comunicación entre centros educativos, profesores, alumnos y padres. Dependiendo del rol desde el que se use la aplicación ésta propondrá unas funcionalidades u otras. Entre estas funcionalidades podemos destacar que permite organizar a los alumnos de manera sencilla, envío instantáneo de cualquier información, servicio de mensajería instantánea e ilimitada, difusión masiva de noticias y novedades con un solo botón, organización de grupos de interés y especialidades. Capítulo 2. Contexto 24 Figura 5: TokApp School Ventajas: • Servicio de puesta en marcha rápida • Mensajería ilimitada y con la posibilidad de adjuntar archivos como imágenes y documentos. • Confirmación de lectura de los mensajes. • Privacidad y cumplimiento de la Ley de Protección de Datos. • Su API permite ser integrada con cualquier sistema de comunicación e intranet. Desventajas: • No se han encontrado Conclusión: Al igual que Pizarra Uva, facilita la comunicación entre profesor, padres y alumno fuera de las clases siendo un complemento más, pero tampoco satisface la necesidad descrita anteriormente, no guía a los alumnos a acudir a los despachos de los profesores de otros centros. 2.1.2. Aplicaciones de localización de espacios. 2.1.2.1. iBeacon iBeacon es una app móvil disponible tanto para iOS como para Android encargada de detectar presencia por proximidad y localización en interiores. Se basa en Bluetooth Low Energy, también conocido como Bluetooth Smart. El funcionamiento, como en toda comunicación, consiste en disponer de un emisor que transmite un identificador único universal, que será recogido por una aplicación compatible o sistema operativo que puede convertirlo en una localización física o dar información, por ejemplo. Entre las aplicaciones de uso que se pueden emplear destacamos: • Proporcionar información extra mediante imágenes, vídeos, animaciones, cualquier elemento multimedia. • Solicitar ayuda. • Recibir notificaciones. • Guía de espacios de interior. Capítulo 2. Contexto 25 Ventajas: • Geolocalización en espacios de interior más precisas que el GPS • Permite interactuar con otras personas. • El alcance que se puede conseguir es de 50 metros desde el emisor. • Múltiples propósitos, comerciales, informativos, etc. Desventajas: • Necesaria la instalación de dispositivos emisores en espacios de interior. • Un mal uso puede llevar a un abuso de notificaciones a los usuarios. Conclusión: Una solución muy completa que admite varios propósitos u objetivos según las necesidades que se persigan, ofrece un posicionamiento muy preciso con la contraposición de que puede ser intrusivo y su mal uso puede hacer que este sistema pierda el carácter informativo predominante y adquiera un punto de vista abusivo. 2.2. Propuesta de solución La propuesta que se propone para este proyecto se basa fundamentalmente en unificar en una aplicación de carácter móvil necesidades que desde un primer punto de vista pueden aparecer en aplicaciones móviles separadas. Consideramos como necesidades las siguientes: • Consultar la información de los docentes de las diferentes escuelas/facultades. • Solicitar tutorías con los docentes. • Enviar correos electrónicos. • Mostrar ruta de camino desde la ubicación del alumno hasta el despacho del docente. • Interfaz simple y sencilla de usar. En este apartado describiremos al grupo de personas a las que estará destinada la aplicación a desarrollar en este TFG. Para ello, tendremos que elaborar una descripción precisa de nuestro usuario, creando usuarios ficticios (personajes). Los personajes son arquetipos hipotéticos de usuarios reales que surgen del análisis de las características de los usuarios durante el análisis de requisitos. La idea que se persigue es que no hay que diseñar la solución para todos los usuarios, sino para una persona específica y concreta. Es importante destacar que habrá dos tipos de usuarios: • Alumnos: Usuarios finales que interactuaran con el sistema. Éste será el personaje primario. • Administrador: Persona encargada de cargar datos representativos de los docentes como sus despachos y ubicación de éstos. Por tanto, nuestro personaje primario/usuario final posee las siguientes características o propiedades: Es una persona relacionada con la universidad en el papel de “alumno”, ya sea de 1º, 2º ciclo o de estudios de postgrado. Es una persona familiarizada con el uso y manejo de dispositivos móviles. Actualmente se encuentra cursando alguna asignatura y para la resolución de dudas que pueda tener con dicha asignatura solicita tutoría o tutorías necesarias para ello. El proceso de solicitud de una tutoría es el siguiente: Capítulo 3. Plan de desarrollo de Software 32 3.3. Organización del proyecto 3.3.1 Interfaces externas Para este proyecto tanto la tutora del Trabajo de Fin de Grado el único cliente que interactuará con ello estableciendo así las interfaces externas como los medios que hay entre la relación de dicha interacción (proyectocliente). El rol de Alumno (Usuario) y de Administrador de nuestro sistema, ha sido desarrollado por diferentes personas haciendo hincapié la figura del personaje descrita en el apartado 2.2. 3.3.2 Estructura interna de la organización El proyecto estará designado a una sola persona (Juan Carlos Aparicio Domínguez) que será el responsable de desempeñar los diferentes roles a lo largo del transcurso del proyecto. De esta forma, se pondrá en el papel de responsable de proyecto y como miembro de equipo. La figura de un responsable de proyecto implica: • Asignación del trabajo al resto de los miembros del equipo. • Control del aspecto y los contenidos del documento del plan de proyecto y del resto de documentos generados. • Normalización de la estructura de los diferentes documentos a presentar al final de la práctica. • Realización de las tareas de seguimiento y control del proyecto. Al final se cotejará el plan de proyecto con el informe de seguimiento del mismo. Dentro de un grupo o equipo en un proyecto identificamos los siguientes roles y sus responsabilidades. ROL RESPONSABILIDAD Jefe de proyecto Tiene la responsabilidad del planteamiento, asignación de roles, ejecución y control del desarrollo del proyecto. Analista Encargado de la especificación de requisitos y restricciones del software para su posterior diseño. Diseñador Encargado de realizar el diseño software a partir de los resultados es obtenidos en la fase de análisis. Programador Encargado de desarrollo de software final en función de los resultados obtenidos en las fases de diseño y análisis. Probador Encargado de realizar pruebas de las diferentes versiones del software para comprobar su correcto funcionamiento. *Voluntarios Tabla 1: Definición de roles. *Voluntarios: personas externas que en las últimas versiones realizaran pruebas para últimas modificaciones. Los roles descritos en la tabla anterior estarán desempeñados por mi (Juan Carlos Aparicio Domínguez) salvo la parte de voluntarios que estarán desempeñados por terceras personas con el fin de valorar aspectos a tener en cuenta durante el desarrollo del proyecto. Capítulo 3. Plan de desarrollo de Software 33 3.3.2 Método de trabajo Para el desarrollo de este proyecto, el método de trabajo será interpretando el papel de cada miembro del equipo en las tareas a desempeñar en cada momento. El soporte para el proyecto será un servidor remoto donde se almacenará toda la información relevante para poder obtener los datos necesarios para preparar la guía a cada usuario. 3.4. Plan de gestión de procesos 3.4.1 Plan de inicio Como se mencionó anteriormente, el modelo a seguir es el de Proceso Unificado. con lo cual en la fase de inicio se presenta un modelo, visión, metas, deseos del usuario, plazos, costos y viabilidad. Al tratarse de un proyecto de índole académico los costes referentes al hardware y software tanto como los costes de esfuerzo de cada papel desempeñado en el proyecto serán estimados. Capítulo 3. Plan de desarrollo de Software 34 3.5. Plan de trabajo 3.5.1 Actividades del proyecto Nombre de tarea Duración Comienzo Fin Predecesoras Recursos Fase de Inicio 13 días mar 05/12/17 lun 18/12/17 Ámbito y límites del proyecto 2 horas mar 05/12/17 mar 05/12/17 Jefe de Proyecto Especificación de requisitos 3 horas jue 07/12/17 jue 07/12/17 2 Analista Casos de uso principales 3 horas lun 11/12/17 mar 12/12/17 3 Analista Estimación de los riesgos 3 horas mié 13/12/17 mié 13/12/17 3 Jefe de Proyecto Realización plan de fases 1 hora jue 14/12/17 jue 14/12/17 3;5 Jefe de Proyecto Redacción plan de desarrollo 10 horas vie 15/12/17 lun 18/12/17 5;6 Jefe de Proyecto Fase de Elaboración 43 días mar 19/12/17 mié 31/01/18 Elicitación de requisitos 1 hora mar 19/12/17 mar 19/12/17 Analista Especificación de requisitos 2 horas mar 19/12/17 mié 20/12/17 9 Analista Diagrama Casos de Uso 3 horas mié 20/12/17 mié 20/12/17 10 Analista Realización Casos de uso 6 horas mié 20/12/17 jue 21/12/17 11 Diseñador Modelado de dominio 21 horas jue 21/12/17 mar 26/12/17 12 Analista Elaboración de diagramas de secuencia, actividad, E-R 36 horas mar 26/12/17 mar 02/01/18 12;13 Analista Evaluación de Prototipo 20 horas lun 22/01/18 jue 25/01/18 Analista Fase de construcción 50 días lun 29/01/18 lun 19/03/18 Construcción Base de datos 4 horas lun 29/01/18 mar 30/01/18 Programador Diseño Plataforma web 40 horas mar 30/01/18 mar 06/02/18 Programador Construcción Funcionalidad 180 horas mié 07/02/18 lun 12/03/18 Programador Revisión arquitectura 4 horas mar 13/03/18 mié 14/03/18 Diseñador Documentación funcionalidad 15 horas jue 15/03/18 lun 19/03/18 Programador Fase de Transición 9 días mié 21/03/18 jue 29/03/18 Realización de pruebas 43 horas mié 21/03/18 jue 29/03/18 Probador Tabla 2: Actividades y duración estimada. Capítulo 3. Plan de desarrollo de Software 35 Figura 6: Diagrama de Gantt A continuación, se describen cada una de las fases mencionadas en la tabla anterior: 1. Fase de inicio • Ámbito y límites del proyecto: Definición del propósito del proyecto con las limitaciones, restricciones y suposiciones adoptadas. • Especificación de requisitos: Definición de los objetivos principales del proyecto tras haber entendido la necesidad del problema. • Casos de uso principales: Enunciado de las funcionalidades que se obtienen a partir de los requisitos especificados. • Estimación de los riesgos: Identificación de los riesgos que pueden surgir a lo largo de la vida del proyecto. • Realización plan de fases: Estructuración de las distintas fases que sigue el método de trabajo seleccionado para el desarrollo del proyecto. • Redacción plan de desarrollo: 2. Fase de elaboración • Elicitación de requisitos: Acuerdo de los requisitos funcionales como no funcionales anteriormente mencionados con el cliente (en este caso la tutora del Trabajo de Fin de Grado) • Especificación de requisitos: Exposición de los requisitos ya acordados por el cliente como por el responsable del proyecto. • Diagrama casos de uso: Diagrama UML con los requisitos obtenidos anteriormente y estableciendo los actores que realizan cada caso de uso. • Realización casos de uso: Exposición detallada de cada caso de uso mencionado el nombre, descripción, actor, precondiciones, secuencia, excepciones y postcondiciones de cada caso de uso. Capítulo 3. Plan de desarrollo de Software 36 • Modelado de dominio: representación del vocabulario y conceptos clave del dominio del problema en UML • Elaboración de diagramas de secuencia, actividad, E-R: Elaboración de cada uno de los distintos tipos de diagramas UML que representan la lógica y modelo de datos del negocio del proyecto. • Evaluación de prototipo: Diseño, documentación de un prototipo (representación limitada) del sistema en papel para su evaluación en usabilidad frente a usuarios para explorar sus posibilidades e interacciones. 3. Fase de construcción • Construcción base de datos: implementación de la base de datos a partir del modelo Entidad – Relación obtenido anteriormente. • Diseño plataforma web: construcción de plataforma web que permitirá ser la interfaz entre el administrador y los datos de la aplicación del proyecto. • Construcción funcionalidad: Construcción de aplicación Android que guiará a los alumnos a llegar a los despachos de los tutores. • Revisión arquitectura: revisión de la arquitectura software del proyecto para comprobar que sigue el diseño anteriormente elaborado. • Documentación funcionalidad: Creación de manual de funcionamiento de la aplicación para su posterior uso. 4. Fase de pruebas • Realización de pruebas: procesos que permiten verificar y revelar la calidad de la aplicación centrándose en fallos de implementación, calidad (estabilidad, escalabilidad, eficiencia y seguridad) o usabilidad. 3.5.2. Recursos humanos del proyecto Los recursos humanos disponibles a lo largo del proyecto son, Juan Carlos Aparicio Domínguez, alumno que cursa actualmente los estudios de Grado en Ingeniería Informática mención Tecnologías de la Información; y por otro lado, la tutora Margarita Gonzalo Tasis, encargada de la supervisión y guía del proyecto. La duración de este proyecto está estimado y planificado en una cantidad total de 397 horas. Capítulo 3. Plan de desarrollo de Software 37 3.5.3 Duración real del proyecto La siguiente tabla muestra las distintas actividades que componen el proyecto y su duración real. Tabla 3: Actividades y duración real. Nombre de tarea Duración Comienzo Fin Predecesoras Recursos Fase de Inicio 13 días mar 05/12/17 lun 18/12/17 Ámbito y límites del proyecto 2 horas mar 05/12/17 mar 05/12/17 Jefe de Proyecto Especificación de requisitos 3 horas jue 07/12/17 jue 07/12/17 2 Analista Casos de uso principales 3 horas lun 11/12/17 mar 12/12/17 3 Analista Estimación de los riesgos 3 horas mié 13/12/17 mié 13/12/17 3 Jefe de Proyecto Realización plan de fases 1 hora jue 14/12/17 jue 14/12/17 3;5 Jefe de Proyecto Redacción plan de desarrollo 10 horas vie 15/12/17 lun 18/12/17 5;6 Jefe de Proyecto Fase de Elaboración 70 días mar 19/12/17 lun 26/02/18 Elicitación de requisitos 1 hora mar 19/12/17 mar 19/12/17 Analista Especificación de requisitos 2 horas mar 19/12/17 mié 20/12/17 9 Analista Diagrama Casos de Uso 3 horas mié 20/12/17 mié 20/12/17 10 Analista Realización Casos de uso 6 horas mié 20/12/17 jue 21/12/17 11 Diseñador Modelado de dominio 21 horas lun 29/01/18 vie 02/02/18 12 Analista Elaboración de diagramas de secuencia, actividad, E-R 80 horas lun 05/02/18 lun 19/02/18 12;13 Analista Evaluación de Prototipo 40 horas mar 20/02/18 lun 26/02/18 Analista Fase de construcción 132 días jue 01/03/18 mar 10/07/18 Construcción Base de datos 4 horas jue 01/03/18 lun 05/03/18 Programador Diseño Plataforma web 150 horas lun 05/03/18 lun 26/03/18 Programador Construcción Funcionalidad 280 horas mar 27/03/18 lun 04/06/18 Programador Revisión arquitectura 4 horas mar 05/06/18 mar 05/06/18 Diseñador Documentación funcionalidad 30 horas lun 18/06/18 mar 10/07/18 Programador Fase de Transición 16 días lun 24/09/18 mié 10/10/18 Realización de pruebas 43 horas lun 24/09/18 mié 10/03/18 Probador Capítulo 3. Plan de desarrollo de Software 38 Como se puede comprobar en la tabla de duración real del proyecto el tiempo ha sido considerablemente mayor de lo planificado. Entre las causas que se deben a la llegada de este punto han sido el cumplimiento de los riesgos R001 (incumplimiento del calendario de planificación), R002 (problemas asociados al carácter distribuido del calendario), R003(ausencia de familiaridad de las herramientas y tecnologías a usar en el desarrollo del proyecto) y R004 (baja del responsable del proyecto por causas de salud, familiares, etc.). Estos riesgos, junto con la situación laboral del responsable del proyecto han determinado que la duración de este sea mayor de lo planificado. También cabe destacar que la duración del proyecto ha tenido una duración de 686 horas. Los riesgos mencionados anteriormente vienen descritos en el Capítulo 4, Plan de gestión de riesgos. 3.6. Costes del proyecto. Un aspecto o punto de vista muy interesante es traducir todas estas horas de duración del proyecto en un coste de producto final de cara a la venta comercial. Tratándose de un proyecto de fin de carrera y que el costo hora/programacion se sitúa entre un intervalo de 20-90 € más IVA he estimado que el costo hora programacion de este proyecto es de unos 30€ más IVA. También hay que tener en cuenta los gastos de gestión del servidor y contemplar la opción de que el primer año tenga un mantenimiento para asegurar la funcionalidad del producto con lo que el precio de venta de éste es el siguiente: PRODUCTO N.º UNIDADES COSTE UNIDAD Desarrollo Software (horas) 397 horas 30€/hora Instalación y gestión de servidor 1 Ud. 1500€/Ud. Mantenimiento 1 año 1 año 640€/año Total, sin IVA 14.050€ Total, con IVA (21%) 17.000€ Tabla 4: Costes 39 Capítulo 4 – Plan de gestión de riesgos 40 Capítulo 4. Plan de gestión de riesgos 41 Se llama gestión de riesgos a la práctica de valorar y controlar los riesgos que afecta a un producto, proceso o proyecto software. El propósito de la gestión de riesgos es identificar, controlar y eliminar los problemas potenciales antes de que ocurran para que de esta forma no afecten a la consecución de los objetivos del proyecto. Según el PM-BOK [7], “Un riesgo es un evento o una condición inciertos que, si ocurren, tienen un efecto positivo o negativo sobre los objetivos del proyecto.” Está caracterizado por la probabilidad de que ocurra y el tamaño de la perdida que generaría en el caso de que ocurriera. Los riesgos se pueden clasificar según diferentes criterios, se muestran a continuación • Riesgos del proyecto: afectan a la planificación temporal, al coste y a la calidad del proyecto. Identifican problemas potenciales de presupuesto, calendario, coordinación del equipo, recursos… • Riesgos técnicos: amenazan la calidad y la planificación temporal del producto software a desarrollar. Identifican posibles problemas de ambigüedad en la especificación, diseño, implementación, etc. • Riesgos de negocio: amenazan la viabilidad del sistema a construir. Se distinguen varios tipos: o Riesgo de mercado: desarrollar un producto que no tiene salidas o nadie lo considera como solución a su necesidad. o Riesgo de ventas: construir un producto del que no se sabe cómo vender. o Riesgo estratégico: desarrollar un producto que no encaje en la estrategia comercial de la empresa. o Riesgo de presupuesto: no se mantienen los recursos asignados tanto en presupuesto como en personal. También se pueden clasificar según su grado de conocimiento y predictibilidad: • Riesgos conocidos: son aquellos que se pueden predecir después de una evaluación de plan de proyecto, entorno y otras fuentes de información. • Riesgos predecibles: son aquellos que se pueden extrapolar a raíz de la experiencia en proyectos anteriores. • Riesgos impredecibles: pueden ocurrir, pero es extremadamente difícil identificarlos por adelantado aun teniendo una evaluación de plan de proyecto, entorno, experiencia en proyectos similares. Por otro lado, podemos clasificar los riesgos en función de su impacto en un proyecto • Catastrófico: si se da lugar, el proyecto fracasaría. • Crítico: el rendimiento del proyecto como de su desarrollo se verían seriamente afectados. • Marginal: afecta a problemas secundarios de un proyecto • Despreciable: son problemas menores que no causan un retraso considerable en el proyecto. El proceso de gestión de riesgo está formado por las siguientes etapas: • Identificación • Análisis • Control • Monitorización Un jefe de proyecto debe ser capaz de anticiparse a los riesgos que puedan surgir teniendo presente su posible impacto, y en el caso de que ocurran, disponer de un plan de acción. 48 Capítulo 5. Análisis 49 5.1. Análisis de requisitos Los requisitos del sistema son especificados en detalle a continuación ID NOMBRE DESCRIPCION RF-001 Registrar Usuario El sistema debe permitir registrar nuevos usuarios. RF-002 Iniciar Sesión El sistema debe permitir iniciar sesión. RF-003 Buscar Profesor El sistema debe permitir buscar un tutor. RF-004 Solicitar Tutoría El sistema debe permitir solicitar una tutoría. RF-005 Cancelar Tutoría El sistema debe permitir cancelar una tutoría. RF-006 Enviar Correo El sistema debe permitir enviar correos electrónicos. RF-007 Mostrar Ubicación El sistema debe permitir mostrar la ubicación de un despacho. RF-008 Mostrar Ruta El sistema mostrará la ruta al usuario a seguir. RF-009 Consultar Ayuda El sistema podrá mostrar información de ayuda al usuario. RF-010 Inicia Sesión en la web El sistema debe permitir iniciar sesión al administrador en la plataforma web. RF-011 Insertar Profesor El sistema debe permitir insertar datos sobre los tutores. RF-012 Modificar Profesor El sistema debe permitir modificar datos sobre los tutores. RF-013 Eliminar Profesor El sistema debe permitir eliminar información sobre los tutores. RF-014 Insertar Despacho El sistema debe permitir insertar datos sobre los despachos. RF-015 Modificar Despacho El sistema debe permitir modificar datos sobre los despachos. RF-016 Eliminar Despacho El sistema debe permitir eliminar datos sobre los despachos. RF-017 Insertar Centro El sistema debe permitir insertar datos sobre los centros. RF-018 Modificar Centro El sistema debe permitir modificar datos sobre los centros. RF-019 Eliminar Centro El sistema debe permitir eliminar datos sobre los centros. RF-020 Asignar Despachos El sistema debe permitir asignar despachos a los docentes. Tabla 14: Requisitos funcionales del sistema. Capítulo 5. Análisis 50 ID NOMBRE DESCRIPCION Propiedades del sistema RNF-001 Versión Android El sistema será ejecutado por cualquier dispositivo móvil con sistema operativo Android con versión mínima API 19 (Kit Kat, 4.4). RNF-002 Servidor Web El sistema estará alojado en un servidor web HTTP Apache2 RNF-003 Entorno Sistema Operativo El sistema estará soportado en un servidor con Linux RNF-004 Protocolo de Transferencia de texto El acceso a la base de datos de la aplicación será mediante protocolo HTTPS RNF-005 Sistema Gestor de Bases de Datos Relacional La base de datos de la aplicación estará gestionada por MySQL RNF-006 Lenguaje de Programación Las páginas web de la aplicación serán dinámicas implementadas con el lenguaje de programación PHP Rendimiento RNF-007 Capacidad de la base de datos La base de datos deberá ser capaz de almacenar y tratar correctamente la información correspondiente de los profesores. Seguridad RNF-008 Encriptación de datos sensibles El sistema empleara un algoritmo de encriptación para proteger datos sensibles como contraseñas. Interfaces RNF-009 Iconos de gran tamaño El sistema empleará iconos de gran tamaño en representación de los botones que intervienen en la funcionalidad de la misma. Documentación RNF-010 Disponibilidad de manual de instalación. El sistema deberá contar con un manual de instalación. RNF-011 Disponibilidad de manual de Usuario El sistema deberá contar con un manual de usuario. RNF-012 Referencias al manual de Usuario. El sistema proporcionara una sección de ayuda en la aplicación móvil. Tabla 15: Requisitos no funcionales del sistema. Capítulo 5. Análisis 51 5.2 Restricciones Las siguientes restricciones son impuestas por las reglas de negocio, por el cliente o por la tecnología utilizada. ID NOMBRE DESCRIPCION RIN-001 Tipos de usuarios Alumno (usuario): usuarios que utilizan la aplicación móvil. Administrador: usuario encargado de las operaciones CRUD de la base de datos del sistema. RIN-002 Perfil de alumno Email y contraseña desde donde se enviarán correos electrónicos. RIN-003 Perfil de administrador Nombre de usuario y contraseña para acceder a la aplicación web para el tratamiento de datos. RIN-004 Composición de una tutoría DNI del alumno, DNI del profesor y fecha de la tutoría. Tabla 16: Restricciones del sistema. 5.3 Casos de uso 5.3.1. Actores primarios. Se destacan los siguientes actores principales del proyecto: • Usuario: rol que desempeña el cliente cuando hace uso de la aplicación. Es el alumno que solicita tutorías con los profesores, visualiza información de éstos y visualiza las rutas a seguir. • Administrador: rol que desempeña un usuario encargado de tratar la base de datos de la aplicación web. 5.3.2. Actores secundarios. Se han encontrado los siguientes actores: • Profesor: encargado de aceptar o rechazar una tutoría con un alumno a través de un correo. Capítulo 5. Análisis 52 5.3.3. Diagrama de Casos de Uso. Figura 7:Diagrama de casos de uso de Usuario. . Capítulo 5. Análisis 53 Figura 8: Diagrama de casos de uso de Administrador. Capítulo 5. Análisis 54 5.3.4 Especificación de casos de uso Detallamos cada uno de los casos de uso encontrados. UC-001 Registro de usuario Versión 1.0 Dependencias RF-001 Descripción Un alumno quiere registrarse en el sistema a través de la app movil. Actor Primario Usuario Precondiciones La aplicación ha de estar instalada en el dispositivo móvil y en ejecución. Flujo básico 1. El Usuario pulsa en el botón "Registrarse". 2. El Usuario rellena todos los campos necesarios para el registro. 3. El Usuario pulsa "Aceptar". 4. El caso de uso finaliza. Postcondición El Usuario queda registrado en el sistema. Flujo alternativo FA01 El Usuario pulsa el botón “Cancelar”. 1. Se avanza hacia el punto 4 del flujo básico y el caso de uso UC-001 no se completa y queda sin efecto. Excepciones 3.1. Si el Usuario ha dejado un campo vacío el sistema le notificará del error y se procede al paso 2 Frecuencia Alta. Tabla 17: Descripción del UC-001. Capítulo 5. Análisis 55 UC-002 Iniciar sesión versión 1.0 Dependencias RF-002 Descripción Un usuario quiere iniciar sesión en el sistema a través de la aplicación. Actor Primario Usuario Precondiciones El usuario tiene que estar registrado en el sistema (UC-001). Flujo básico 1. El Usuario introduce su cuenta de correo electrónico y su contraseña. 2. El Usuario pulsa "Iniciar Sesión". 3. El caso de uso finaliza. Postcondición El Usuario tiene iniciada una sesión en el sistema. Flujo alternativo FA01 El Usuario pulsa el botón retroceso del dispositivo. 1. Se avanza hacia el punto 3 del flujo básico y el caso de uso UC-002 no se completa y queda sin efecto. Excepciones 2.1. Si el usuario ha introducido mal los datos el sistema le notificará del error y se procede al paso 1. Frecuencia Alta. Tabla 18: Descripción del UC-002. Capítulo 5. Análisis 56 UC-003 Buscar profesor Versión 1.0 Dependencias RF-003 Descripción Un Usuario quiere buscar un profesor en el sistema para poder solicitar una tutoría. Actor Primario Usuario Precondiciones El usuario tiene que haber iniciado sesión en el sistema (UC-002). Flujo básico 1. El actor elige "Buscar Profesor". 2. El sistema ofrece dos vías. 3. El actor elige una opción de búsqueda Usuario pulsa "Aceptar". 4. El sistema muestra los datos del profesor y el caso de uso finaliza. Postcondición El Usuario ha encontrado el profesor deseado para poder solicitar una tutoría. Flujo alternativo 3a El Usuario busca el profesor por listado. 1. Si el actor elige “por nombre” Se realiza el caso de uso “Buscar por nombre” y el caso de uso continua por el paso 4. 3b El Usuario busca el profesor por nombre. 1. Si el actor elige “por listado” se realiza el caso de uso buscar “por listado” y el caso de uso continua por el paso 4. FA01 El Usuario pulsa el botón retroceso del dispositivo 1. El Usuario pulsa el botón retroceso del dispositivo y el caso de uso queda sin efecto. Excepciones Ninguna. Frecuencia Alta. Tabla 19: Descripción del UC-003. Capítulo 5. Análisis 57 UC-004 Solicitar tutoría versión 1.0 Dependencias RF-004 Descripción Un usuario solicita una tutoría con un profesor deseado. Actor Primario Usuario Precondiciones El usuario tiene que haber seleccionado un profesor (UC-003). Flujo básico 1. El Usuario pulsa "Solicitar Tutoría". 2. El Usuario selecciona la fecha y hora disponibles". 3. El Usuario pulsa "Solicitar". 4. El caso de uso finaliza. Postcondición El Usuario ha solicitado una tutoría con el profesor correspondiente. El profesor es notificado de la solicitud enviada por el Usuario. Flujo alternativo FA01 El Usuario pulsa el botón retroceso del dispositivo. 1. Se avanza hacia el punto 4 del flujo básico y el caso de uso UC-004 no se completa y queda sin efecto. Excepciones Ninguna. Frecuencia Tabla 20: Descripción del UC-004. Capítulo 5. Análisis 64 UC-011 Agregar profesor Versión 1.0 Dependencias RF-011 Descripción El Administrador inserta un profesor en la base de datos del sistema. Actor Primario Administrador Precondiciones El Administrador tiene que haber iniciado sesión (UC-010). Flujo básico 1. El Administrador pulsa "Agregar Profesor". 2. El Administrador introduce los datos necesarios para insertar el profesor a la base de datos del sistema. 3. El Usuario pulsa "Aceptar". 4. El caso de uso finaliza. Postcondición Los datos de un profesor están insertados en la base de datos del sistema. Flujo alternativo FA01 El Administrador pulsa el botón "Cancelar". 1. Se avanza hacia el punto 4 del flujo básico y el caso de uso UC-010 no se completa y queda sin efecto. Excepciones 3.1. Si el Administrador ha dejado algún campo vacío el sistema le notificará del error y se procede al paso 2. Frecuencia Alta. Tabla 27: Descripción del UC-011. Capítulo 5. Análisis 65 UC-012 Modificar profesor Versión 1.0 Dependencias RF-012 Descripción El Administrador modifica los datos de un determinado profesor. Actor Primario Administrador Precondiciones El Administrador tiene que haber iniciado sesión (UC-010). Flujo básico 1. El Administrador pulsa "Modificar Profesor". 2. El Administrador selecciona el profesor correspondiente e introduce los datos nuevos para actualizar el profesor en la base de datos del sistema. 3. El Usuario pulsa "Aceptar". 4. El caso de uso finaliza. Postcondición Los datos de un profesor están actualizados en la base de datos del sistema. Flujo alternativo Excepciones Ninguna. Frecuencia Alta. Tabla 28: Descripción del UC-012. Capítulo 5. Análisis 66 UC-013 Eliminar profesor Versión 1.0 Dependencias RF-013 Descripción El Administrador elimina un profesor de la base de datos del sistema. Actor Primario Administrador Precondiciones El Administrador tiene que haber iniciado sesión (UC-010). Flujo básico 1. El Administrador pulsa "Eliminar Profesor". 2. El Administrador selecciona el profesor correspondiente y pulsa "Eliminar". 3. El caso de uso finaliza. Postcondición Los datos de un profesor ya no pertenecen a la base de datos del sistema. Flujo alternativo Excepciones Ninguna. Frecuencia Alta. Tabla 29: Descripción del UC-013. Capítulo 5. Análisis 67 UC-014 Agregar Centro Versión 1.0 Dependencias RF-014 Descripción El Administrador inserta un centro en la base de datos del sistema. Actor Primario Administrador Precondiciones El Administrador tiene que haber iniciado sesión(UC-010). Flujo básico 1. El Administrador pulsa "Agregar Centro". 2. El Administrador introduce los datos necesarios para insertar el centro a la base de datos del sistema. 3. El Usuario pulsa "Aceptar". 4. El caso de uso finaliza. Postcondición Los datos de un centro están insertados en la base de datos del sistema. Flujo alternativo FA01 El Administrador pulsa el botón "Cancelar". 1. Se avanza hacia el punto 4 del flujo básico y el caso de uso UC-010 no se completa y queda sin efecto. Excepciones 3.1. Si el Administrador ha dejado algún campo vacío el sistema le notificará del error y se procede al paso 2. Frecuencia Alta. Tabla 30: Descripción del UC-014. Capítulo 5. Análisis 68 UC-015 Modificar Centro Versión 1.0 Dependencias RF-015 Descripción El Administrador modifica los datos de un determinado centro. Actor Primario Administrador Precondiciones El Administrador tiene que haber iniciado sesión (UC-010). Flujo básico 1. El Administrador pulsa "Modificar Centro". 2. El Administrador selecciona el profesor correspondiente e introduce los datos nuevos para actualizar el centro en la base de datos del sistema. 3. El Usuario pulsa "Aceptar". 4. El caso de uso finaliza. Postcondición Los datos de un profesor están actualizados en la base de datos del sistema. Flujo alternativo Excepciones Ninguna. Frecuencia Alta. Tabla 31: Descripción del UC-015. Capítulo 5. Análisis 69 UC-016 Eliminar centro Versión 1.0 Dependencias RF-016 Descripción El Administrador elimina un centro de la base de datos del sistema. Actor Primario Administrador Precondiciones El Administrador tiene que haber iniciado sesión (UC-010). Flujo básico 1. El Administrador pulsa "Eliminar Centro". 2. El Administrador selecciona el profesor correspondiente y pulsa "Eliminar". 3. El caso de uso finaliza. Postcondición Los datos de un centro ya no pertenecen a la base de datos del sistema. Flujo alternativo Excepciones Ninguna. Frecuencia Alta. Tabla 32: Descripción del UC-016. Capítulo 5. Análisis 70 UC-017 Agregar despacho Versión 1.0 Dependencias RF-017 Descripción El Administrador inserta un despacho en la base de datos del sistema. Actor Primario Administrador Precondiciones El Administrador tiene que haber iniciado sesión (UC-010). Flujo básico 1. El Administrador pulsa "Agregar Profesor". 2. El Administrador introduce los datos necesarios para insertar el despacho a la base de datos del sistema. 3. El Usuario pulsa "Aceptar". 4. El caso de uso finaliza. Postcondición Los datos de un despacho están insertados en la base de datos del sistema. Flujo alternativo FA01 El Administrador pulsa el botón "Cancelar". 1. Se avanza hacia el punto 4 del flujo básico y el caso de uso UC-017 no se completa y queda sin efecto. Excepciones 3.1. Si el Administrador ha dejado algún campo vacío el sistema le notificará del error y se procede al paso 2. Frecuencia Alta. Tabla 33: Descripción del UC-017. Capítulo 5. Análisis 71 UC-018 Modificar despacho Versión 1.0 Dependencias RF-018 Descripción El Administrador modifica los datos de un determinado despacho. Actor Primario Administrador Precondiciones El Administrador tiene que haber iniciado sesión (UC-010). Flujo básico 1. El Administrador pulsa "Modificar Despacho". 2. El Administrador selecciona el profesor correspondiente e introduce los datos nuevos para actualizar el despacho en la base de datos del sistema. 3. El Usuario pulsa "Aceptar". 4. El caso de uso finaliza. Postcondición Los datos de un despacho están actualizados en la base de datos del sistema. Flujo alternativo Excepciones Ninguna. Frecuencia Alta. Tabla 34: Descripción del UC-018. Capítulo 5. Análisis 72 UC-019 Eliminar profesor Versión 1.0 Dependencias RF-019 Descripción El Administrador elimina un despacho de la base de datos del sistema. Actor Primario Administrador Precondiciones El Administrador tiene que haber iniciado sesión (UC-010). Flujo básico 1. El Administrador pulsa "Eliminar Despacho". 2. El Administrador selecciona el profesor correspondiente y pulsa "Eliminar". 3. El caso de uso finaliza. Postcondición Los datos de un despacho ya no pertenecen a la base de datos del sistema. Flujo alternativo Excepciones Ninguna. Frecuencia Alta. Tabla 35: Descripción del UC-019. Capítulo 5. Análisis 73 UC-020 Asignar despacho a profesor Versión 1.0 Dependencias RF-020 Descripción El Administrador asigna un despacho a un profesor y lo añade a la base de datos del sistema. Actor Primario Administrador Precondiciones El Administrador tiene que haber iniciado sesión (UC-010). Flujo básico 1. El Administrador pulsa "Añadir Ubicacion". 2. El Administrador selecciona el profesor correspondiente y el despacho correspondiente y pulsa “Asignar”. 3. El caso de uso finaliza. Postcondición Un profesor tendrá asignado un despacho y quedará insertado en la base de datos del sistema. Flujo alternativo FA01 El Administrador pulsa el botón "Cancelar". 1. Se avanza hacia el punto 3 del flujo básico y el caso de uso UC-020 no se completa y queda sin efecto. Excepciones Ninguna. Frecuencia Alta. Tabla 36: Descripción del UC-020. Capítulo 5. Análisis 80 Figura 14: Diagrama de activdad UC-005 Capítulo 5. Análisis 81 Figura 15:Diagrama de actividad UC-006 Capítulo 5. Análisis 82 Figura 16: Diagrama de actividad UC-007 Capítulo 5. Análisis 83 Figura 17: Diagrama de actividad UC-008 Capítulo 5. Análisis 84 Figura 18: Diagrama de actividad UC-009 Capítulo 5. Análisis 85 Figura 19: Diagrama de actividad UC-010 Capítulo 5. Análisis 86 Figura 20: Diagrama de actividad UC-011 Capítulo 5. Análisis 87 Figura 21: Diagrama de actividad UC-012. Capítulo 5. Análisis 88 Figura 22: Diagrama de actividad UC-013. Capítulo 5. Análisis 89 Figura 23: Diagrama de actividad UC-014 Capítulo 5. Análisis 96 97 Capítulo 6 – Arquitectura y Diseño 98 Capítulo 6. Arquitectura y Diseño 99 El objetivo de este apartado es dar una visión de la arquitectura final del sistema, así como también presentar los bocetos de la interfaz gráfica de la aplicación. También se describe en profundidad en las estructuras y comportamientos descritos en el apartado Capítulo 5 Análisis para acercarlos a la implementación real del sistema. 6.1 Arquitectura Propuesta. MVP El patrón de diseño para llevar a cabo este proyecto es el Patrón Modelo Vista Presentador [7]. Este modelo es una derivación del ya conocido Modelo Vista Controlador. Este patrón es muy utilizado para proyectos de aplicaciones en Android. Recordamos que el patrón Modelo Vista Controlador es un patrón de arquitectura software que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. Este patrón propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, por un lado, define componentes para la representación de la información y por otro lado para la interacción del usuario. La reutilización de código y la separación de conceptos son ideas en las que se basa este patrón de arquitectura de software, ideas que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento. El patrón Modelo Vista Presentador parece bastante similar, pero presenta diferencias frente al MVC notables: 1. En el MVC, el modelo notifica a la vista cualquier cambio que sufra el estado del modelo. La información puede pasarse en la propia notificación, o después de la notificación, la vista puede consultar el modelo directamente para obtener los datos actualizados. Por el contrario, en el MVP, la vista no sabe nada sobre el modelo y la función del presentador es la de mediar entre ambos, enlazando los datos con la vista. 2. En el modelo MVC, la vista tiende a tener más lógica porque es responsable de manejar las notificaciones del modelo y de procesar datos. En el modelo MVP, esa lógica se encuentra en el presentador, haciendo que la vista carezca de funcionalidad. Su única función es representar la información que el presentador le ha proporcionado. 3. En MVC, el modelo tiene lógica extra para interactuar con la vista. En el MVP, esta lógica se encontraría en el presentador. Figura 30: Esquema Patrón MVC vs Patrón MVP Como hemos mencionado antes, en este patrón de diseño podemos separar la lógica del negocio en tres capas fundamentales: • Modelo: Esta capa gestiona los datos. Son las clases que denominaríamos de lógica de negocio. Capítulo 6. Arquitectura y Diseño 100 • Vista: Se encarga de mostrar los datos. Aquí se encontrarían los Fragmentos y Vistas. • Presentador: Se sitúa entre la vista y el modelo, permitiendo conectar la interfaz gráfica con los datos. Entre las ventajas que encontramos en el patrón MVP en el desarrollo de aplicaciones Android es que nos permite que la aplicación sea expandible fácilmente, mantenida fácilmente al estar basado en un modelo por capas. Otra ventaja es que nos permite escribir un código de manera muy limpia y aparte nos permite hacer test unitarios de una manera muy sencilla. 6.2 Ciclo de vida de Activities y Fragments Cabe añadir que hay otro tipo de eventos producidos por el sistema como consecuencia de las interacciones del usuario con la aplicación de manera indirecta, como por ejemplo cuando éste pulsa los botones “home” o “atrás”. Estos eventos componen los ciclos de vida de los Activities y Fragments presentes en la aplicación. Figura 31: Ciclo de vida de una Activity. Figura 32:Ciclo de vida de un Fragment Capítulo 6. Arquitectura y Diseño 101 6.3. Diseño de la arquitectura 6.3.1. Gestión de la persistencia Los tipos de persistencia en Android, por lo general, puede dividirse en tres grupos: • Preferencias compartidas: conjunto de pares clave-valor. Pueden ser privadas (solamente accesibles desde la propia aplicación donde se generan) o compartidas con otras aplicaciones. • Ficheros: una aplicación Android puede almacenar y consultar datos tanto de la carpeta privada de la aplicación como fuera o en una tarjeta de memoria externa. • Base de datos: cada aplicación puede disponer de una base de datos local en la que realizar operaciones SQL, un ejemplo es SQLite para Android. En la aplicación se presentan los 3 tipos de persistencia de datos: 1. Preferencias compartidas: accesibles mediante la clase SharedPreferents [8]. Se alojan los datos propios del alumno, usuario de la aplicación, para evitar el proceso de inicio de sesión. El modo de acceso es privado (MODE_PRIVATE), es decir, solo la aplicación puede acceder al archivo de preferencias. 2. Base de datos: El sistema cuenta con una base de datos común tanto para la aplicación como para la WebApp que gestiona dicha base de datos. Esta base de datos se encuentra alojada en un servidor MySQL externo. La estructura con las tablas necesarias para el almacenamiento de los datos se describe a continuación. 3. Fichero: para la recogida y muestreo de puntos de localización de los distintos despachos (ubicaciones) en el caso de uso de mostrar ruta para el usuario Alumno. Figura 33: Modelo Entidad-Relación base de datos GuiaMeUVa. Capítulo 6. Arquitectura y Diseño 102 ALUMNOS {dni, correo, nombre, apellidos, password} PROFESORES {dni, nombre, apellidos, correo} PROFESORES_ALUMNOS {alumno, profesor, estado, fecha, hora} CENTROS {cod_centro, nombre, direccion, longitud, latitud} DESPACHOS {cod_centro, cod_despacho, extension, planta, longitud, latitud, altitud} EXTENSIONES {extension} PROFESORES_EXTENSIONES_DESPACHOS {centro, despacho, profesor, extension, semana, hora_inicio, hora_fin, cuatrimestre} Capítulo 6. Arquitectura y Diseño 103 6.3.2. Modelo de despliegue A través del modelo de despliegue del sistema podemos observar un ejemplo de la arquitectura en tiempo de ejecución. Se puede distinguir tres niveles en los que se encuentran ubicados los distintos nodos que intervienen según la lógica a la que pertenecen. Figura 34: Modelo de despliegue. Capítulo 6. Arquitectura y Diseño 104 6.4.3. Diagramas de secuencia A continuación, se muestran dos ejemplos de los diagramas de secuencia de diseño de alguno de los casos de uso implementados. Con el fin de no sobrecargar el documento, se muestran dos casos de uso de la aplicación. Los diagramas de secuencia de los casos de uso del usuario Alumno se encuentran en el CD en el directorio Diagramas -> Diagramas de secuencia. Figura 35: Diagrama de secuencia: UC-002. Capítulo 6. Arquitectura y Diseño 105 Figura 36: Diagrama de secuencia: UC-009. 6.4.4. Diagramas de clase de diseño A continuación, se muestra el diagrama de clases de Diseño. Debido al amplio número de clases se ha decidido dividirlo en las diferentes capas (Modelo, Vista y Presentador), omitiendo, en ocasiones, operaciones y atributos que sólo complicarían la comprensión del mismo. En la siguiente figura, se muestra el diagrama correspondiente a las vistas de la aplicación. Cabe recordar que las vistas son encargadas de transmitir los eventos del usuario al “Presentador” y recibir los datos del mismo, con el propósito de mostrarlos al usuario a transmitir los eventos de la interfaz. El modelo contiene todas las clases del dominio y se ocupa de la lógica de negocio de la aplicación. Por otro lado, se muestra una figura las clases catalogadas como “utils” o clases que actúan de intermediaras para la obtención de datos de la base de datos “remoto”. 112 Capítulo 7. Prototipo 113 7.1. Propuesta de prototipo Como se ha mencionado en la propuesta de solución, se busca adaptar la aplicación móvil de este proyecto con una interfaz lo más sencilla posible con una navegación intuitiva y que implemente los casos de uso analizados para lograr así un grado alto de usabilidad del producto. Cabe recordar que la usabilidad es el grado en el que un producto puede ser usado por unos usuarios especificados para conseguir unos fines especificados con • Eficacia • Efectividad • Satisfacción en un contexto de uso especificado. 7.1.1. Guías de diseño Las guías de diseño son documentos que ofrecen a los desarrolladores un conjunto de recomendaciones destinadas a mejorar la experiencia de los usuarios, haciendo que las interfaces sean más intuitivas. Estas guías enumeran políticas específicas basadas en estudios de Interacción Persona-Computadora [9], así como en estudios de usabilidad. Se persigue cumplir los siguientes criterios de usabilidad • Eficaz: este criterio a la completitud y precisión con que los usuarios logran sus metas- • Eficiente: este criterio está relacionado con la velocidad y precisión con que los usuarios realizan las tareas. • Estimulante: grado en que la apariencia y el tono del interfaz hacen que el producto sea agradable y satisfactorio para los usuarios. • Tolerancia a errores: este criterio hace referencia a como ayuda el diseño a prevenir errores o ayuda a recuperarlos cuando se producen. • Facilidad de aprendizaje: este criterio se refiere a la bondad con la que el sistema soporta tanto la orientación inicial como la profundización en el uso del mismo. Para este proyecto se han seleccionado unas guías de diseño específicas para personas (descripción de la persona) comprendidas entre 18 y 40 años, aunque se persigue un diseño sencillo para que resulte intuitivo y genere una interacción 100% satisfactoria para el usuario final. Se ha seleccionado los colores pertenecientes a la Universidad de Valladolid para estimular el uso de la aplicación. 7.1.2. Navegación La navegación por parte del usuario con el sistema debe conseguir los siguientes objetivos: • Captar la atención de los usuarios: los iconos y diferentes objetos deben llamar la atención de los usuarios para conseguir la realización de acciones de manera correcta y satisfactoria. • Ubicación de elementos importantes: en la pantalla inicial de la aplicación del sistema tiene que aparecer los elementos que persiguen satisfacer las necesidades planteadas anteriormente. • Evitar sobrecargas: Se debe de evitar la sobrecarga de información irrelevante para no producir por parte del usuario cualquier tipo de confusión. 7.1.3. Interfaz Objetos de tamaño normal: los tamaños de los objetos como texto deberán ser normal que por defecto en los dispositivos móviles el tamaño de la fuente es “pequeño”. Colores adecuados: el color principal de la aplicación es el corporativo de la Universidad de Valladolid. Capítulo 7. Prototipo 114 Inicialmente, la pantalla principal de la aplicación tendrá un aspecto similar a la que se muestra a continuación: Figura 41: Prototipo de Interfaz. Como se puede apreciar en la figura observamos dos partes importantes de la pantalla de la aplicación: • La parte superior contiene el logo de la Universidad de Valladolid y un menú Burger o tres puntos que refuerza las opciones mostradas en la parte inferior de la pantalla para ofrecer otra alternativa para que el usuario pueda realizar las tareas que considere oportunas. • La parte inferior contiene los iconos referentes a las tareas principales de la aplicación. Estos tienen un tamaño considerable para que pueda captar la atención de los usuarios y puedan relacionar de manera rápida dicha imagen con la acción que acompaña. 7.1.4. Tipografía La tipografía seleccionada es la “Nexa”. Es una tipografía de tipo “sans-serif” o de “palo seco”, y se caracteriza por ser un tipo de tipografía que presenta un estilo limpio, funcional y aséptico con lo cual hace de ésta ser una excelente opción para la lectura. Dentro de esta categoría la tipografía “Nexa” pertenece al subconjunto de tipografía de palo seco “Geométricas”. Este subconjunto presenta un trazo absolutamente homogéneo y los caracteres acaban teniendo una concepción geométrica; esto origina un Ductus más sintético, más redondo y más cuadrado. Capítulo 7. Prototipo 115 7.2. Descripción general del personaje principal “Alumno” En este apartado describiremos al grupo de personas a las que estará destinada la aplicación a desarrollar en este TFG. Para ello, tendremos que elaborar una descripción precisa de nuestro usuario, creando usuarios ficticios (personajes). Los personajes son arquetipos hipotéticos de usuarios reales que surgen del análisis de las características de los usuarios durante el análisis de requisitos. La idea que se persigue es que no hay que diseñar la solución para todos los usuarios, sino para una persona específica y concreta. Para la elaboración del personaje se han seguido los pasos que se detallan a continuación: • Fase de análisis: se recopila la información mediante la observación los distintos alumnos en una escuela, encuestas… • Fase de segmentación: eliminar los extremos y elaborar clases de usuarios que contengan las cualidades principales de los futuros arquetipos. El resultado son perfiles. • Fase de modelado: usando los perfiles o arquetipos en la etapa anterior, se elaboran las descripciones de los personajes. Esto da lugar a las fichas de personajes. Un ejemplo se muestra en la figura siguiente. Figura 42: Ficha de personaje. Se distingue un tipo de personaje: • Primarios/usuarios finales: usuarios para los que va a ser diseñada la aplicación y cuyo diseño debe ser satisfactorio al 100%. Por tanto, nuestro personaje primario/usuario final posee las siguientes características o propiedades: • Es una persona relacionada con la universidad en el papel de “alumno”, ya sea de 1º, 2º ciclo o de estudios de postgrado. Es una persona comprendido en un intervalo de edad de entre unos 18 y 40 años. Es una persona familiarizada con el uso y manejo de dispositivos móviles. Actualmente se encuentra cursando Capítulo 7. Prototipo 116 alguna asignatura y para la resolución de dudas que pueda tener con dicha asignatura solicita tutoría o tutorías necesarias para ello. 7.3. Diseño de los subsistemas 7.3.1. Vista de casos de uso. Diseño de la interfaz de usuario. Los bocetos de la interfaz de usuario han sido realizados con la herramienta GNU Image Manipulation Program, GIMP 2. Para el desarrollo de los bocetos se han utilizado diseños propios. Una vez implementada la aplicación, se han incluido iconos totalmente personalizados siguiendo el estilo en la medida de lo posible a los bocetos. 7.3.1.1. Especificación de casos de uso de diseño En este apartado se especifican los casos de uso que respecta a la interfaz de usuario en la aplicación móvil. Para la interfaz de la aplicación web se ha realizado un diseño libre sin bocetaje persiguiendo una interfaz sencilla , intuitiva y fácil de aprender. 7.3.1.1.1. UC-001 Registrar Usuario Figura 43: Boceto de usuario. Capítulo 7. Prototipo 117 7.3.1.1.2. UC-002 Iniciar Sesión Figura 44: Boceto de usuario, inicio de sesión. Capítulo 7. Prototipo 118 7.3.1.1.3. UC-003 Buscar Profesor Figura 45: Boceto de usuario, buscar profesor. Capítulo 7. Prototipo 119 7.3.1.1.4 Solicitar Tutoría Figura 46: Boceto de usuario, solicitar tutoría. 7.3.1.1.5 Cancelar Tutoría Figura 47: Boceto de usuario, cancelar tutoría. Capítulo 7. Prototipo 120 7.3.1.1.6 Enviar Correo Figura 48: Boceto de usuario, Enviar correo. Capítulo 7. Prototipo 121 7.3.1.1.7. UC-007 Mostrar Ubicación Figura 49: Boceto de usuario, mostrar ubicación. Capítulo 7. Prototipo 128 localizar despachos de los profesores dentro de las facultades, y a su vez la de poder también encontrar información con respecto a los profesores y solicitar una tutoría para posteriormente acudir a ella con la aplicación. A continuación, se mostrará como los usuarios interactúan con nuestra aplicación y realizan los correspondientes test de usabilidad con el prototipo desarrollado. Se analizarán los resultados del test para así incluir posibles mejoras en versiones posteriores. Se dividirá el trabajo en tres fases: • Elección de cuatro tareas significativas • Diseño de un prototipo de bajo coste para simular las tareas seleccionadas. • Test de usabilidad de prototipo con usuarios reales. Finalmente, se analizarán los resultados obtenidos en los test de usabilidad y se expondrán unas breves conclusiones sobre el trabajo realizado. 7.4.2. Elección de cuatro tareas significativas En esta fase, se indicarán las tareas seleccionadas para ser simuladas con el prototipo. Se ha decidido centrar la elección de las cuatro tareas entre las que encontramos en la propia aplicación. 7.4.2.1 Mostrar ubicación de un docente. La tarea de mostrar ubicación de un docente, consistirá en: • Acceder a la aplicación. • Seleccionar el icono de búsqueda de profesores. Se mostrará una ventana con un listado de los profesores insertados en el sistema. • Seleccionar un docente. Se mostrará una ventana con un resumen de la información del profesor seleccionado. • Pulsar el botón “Mostrar ubicación”. Esta tarea es una de las fundamentales de la aplicación ya que supone la base para luego poder realizar otras que dependen de ésta. 7.4.2.2 Solicitar tutoría. La tarea de solicitar tutoría, consistirá en: • Acceder a la aplicación. • Seleccionar el icono de búsqueda de profesores. Se mostrará una ventana con un listado de los profesores insertados en el sistema. • Seleccionar un docente. Se mostrará una ventana con un resumen de la información del profesor seleccionado. • Pulsar el botón “Solicitar tutoría”. Se mostrará una ventana para poder seleccionar los datos de la tutoría de fecha y hora. • Seleccionar fecha y hora y pulsar “Solicitar”. Capítulo 7. Prototipo 129 Esta tarea es una de las fundamentales de la aplicación ya que supone que le usuario pueda luego localizar el despacho una vez que ha solicitado la tutoría. 7.4.2.3 Mostrar ruta. La tarea de mostrar ruta, consistirá en: • Acceder a la aplicación. • Seleccionar el icono de “Mis tutorías”. Se mostrará una ventana con un listado de las tutorías del alumno insertadas en el sistema. • Seleccionar una tutoría. Se mostrará una ventana con un resumen de la información de la tutoría seleccionada. • Pulsar el botón “Mostrar ruta”. • Visualizar y seguir la ruta. Esta tarea es la que tiene en su fundamento este TFG por lo que constituye un pilar en la aplicación. 7.4.2.4 Cancelar tutoría. La tarea de cancelar tutoría, consistirá en: • Acceder a la aplicación. • Seleccionar el icono de “Mis tutorías”. Se mostrará una ventana con un listado de las tutorías del alumno insertadas en el sistema. • Seleccionar una tutoría. Se mostrará una ventana con un resumen de la información de la tutoría seleccionada. • Pulsar el botón “Cancelar tutoria”. 7.4.3. Test de usabilidad con usuarios reales En esta fase llevaremos a cabo las pruebas con nuestro prototipo con usuarios reales. Es un paso imprescindible para poder realizar una interfaz que pueda cumplir con los requisitos impuestos y que permita realizar las tareas de una forma rápida y eficaz. 7.4.3.1. Asignación de roles A la hora de realizar un test de usabilidad es necesario conocer qué personas se encargará de desempeñar los papeles de ordenador, facilitador y observador. • Facilitador: persona que guía al usuario para que realice los escenarios. Es el único que interactúa con el usuario. El facilitador le presenta el prototipo y las tareas a realizar, describe cómo se llevará a cabo la evaluación y le resolverá las dudas en caso de que éste sea incapaz de conseguir los objetivos que persiguen las tareas. • Ordenador: es la persona encargada de manejar el prototipo de forma que responda a las acciones del usuario. • Observador: persona que mira, observa el comportamiento del usuario y toma notas de todo lo que sucede. Capítulo 7. Prototipo 130 En cuanto a la asignación de roles, todos ellos serán realizados por la misma persona, el propio alumno del TFG. Se ha llevado a cabo de esta forma debido a que no existía la posibilidad de reunir a tres personas al haberse realizado en un entorno distinto al de la escuela. 7.4.3.2. Participantes en el test de usabilidad El número recomendado de usuarios para realizar el test de usabilidad es de tres, con lo cual se ha realizado esta prueba con tal número. Siguiendo esto, nos hemos puesto en contacto con dos usuarios finales (alumnos) y un exalumno y que es diseñador gráfico. 7.4.3.3. Material para la evaluación Además del prototipo, //marvelapp, se ha elaborado el material necesario para llevar a cabo la evaluación: los guiones seguidos y las hojas de observación. Este material se incluye en el APENDICE B: Material test de usabilidad. 7.4.3.4. Descripción del procedimiento Como se ha indicado anteriormente, nos reunimos con los tres usuarios de forma independiente en un ambiente tranquilo para que el usuario se encontrase cómodo durante las pruebas. Los pasos a seguir han sido iguales para cada uno de los usuarios: • El facilitador presenta el sistema al usuario. • A continuación, se pone en situación en los correspondientes e hipotéticos escenarios al usuario y se solicita que realice cada una de las tareas descritas anteriormente. El ordenador va cambiando los estados de la aplicación según los paso y tareas que el usuario vaya desempeñando. • El observador toma nota de todo cuanto sea relevante del comportamiento de cada uno de los usuarios al realizar cada una de las tareas. Una vez realizado los test, los resultados obtenidos en la evaluación del prototipo se encuentran descritos en el siguiente apartado. 7.4.4 Resultados obtenidos en el test de usabilidad En primer lugar, al término de cada uno de los test se pidió a los usuarios una opinión en general sobre el prototipo en cuanto a aspecto visual y éstos indicaron que sigue un diseño fácil de manejar e intuitivo. Uno de los problemas que ha observado alguno de los usuarios es el botón de “mostrar ruta” que no entendía por qué estaba disponible dentro de una tutoría solicitada. Una vez explicado la lógica que persigue la aplicación entendió el punto de vista y lo vio como algo lógico. Al tratarse de un caso aislado se ha decidido seguir con el diseño del prototipo en cuanto a la función de “mostrar ruta”. Otro aspecto mencionado por algunos de los usuarios es el botón de “atrás” haciendo referencia al propio botón físico (o no) de los propios smartphones con lo que se podría resolver la función de retroceso a la anterior pantalla o cancelar una acción. Capítulo 7. Prototipo 131 Los comentarios recibidos una vez finalizadas las pruebas, resaltan la claridad y el tamaño de algunos iconos representando a las tareas principales de la aplicación. La mayoría de los usuarios han realizado cada una de las tareas de forma correcta, habiendo alguna confusión en cuanto a la tarea de mostrar ruta comentada anteriormente, con lo cual se traduce a unos cuantos segundos de más a la hora de desempeñar esta tarea. 132 133 Capítulo 8 – Implementación y Pruebas 134 Capítulo 8 Implementación y Pruebas 135 8.1. Herramientas utilizadas Durante el desarrollo del proyecto se han utilizado las siguientes herramientas o aplicaciones informáticas. • Android Studio: Entorno de desarrollo utilizado para la implementación de la aplicación. • IndoorAtlas: Plataforma de posicionamiento de interior y diseño de rutas utilizado para crear las rutas necesarias y crear los mapas de cada planta del edificio para su posterior integración a la aplicación Android. 8.2. Entorno de desarrollo El entorno de trabajo durante todo el TFG se describe a continuación Hardware Procesador AMD A10-9600P RADEON R5 Placa base HP Memoria 12 GB DDR4-2133 SDRAM (1 x 4 GB, 1 x 8 GB) HDD HDD 1TB Tarjeta Gráfica Gráficos AMD Radeon™ R7 M440 (2 GB DDR3 dedicado) Audio DTS Studio Sound Pantalla 1366 x 768 x 60 Hercios Software OS Windows 10 Home 64 Sistema de Ficheros NTFS Tabla 37: Entorno de desarrollo. Capítulo 8. Implementación y Pruebas 136 8.3. Implementación La implementación de la parte de la plataforma Web encargada del tratamiento de datos de la base de datos se ha realizado en una fase o versión: • Versión 1.0: Toda la funcionalidad implementada, con datos persistentes de la base de datos. Interfaz definitiva. Para la implementación de la plataforma web del sistema se ha empleado el lenguaje de programación PHP para la parte del servidor Web junto con JavaScript y Ajax. Para el empleo del diseño de la interfaz se ha empleado Bootstrap para obtener una interfaz de usuario sencilla a la vez que agradable para el usuario. La lógica que sigue la plataforma web es la de realizar operaciones CRUD de las tablas existentes en la base de datos. La base de datos está implementada en MySQL siguiendo los requisitos no funcionales mencionados en el Capítulo 5 Análisis. La implementación de la aplicación GuiaMeUVa, tras el análisis y diseños previos, se ha realizado en tres fases o versiones: • Versión 1.0: Implementación de la aplicación sin datos persistentes, solo la interfaz con las distintas pantallas y mostrando datos constantes. Algunas partes se han implementado sin aplicar el patrón Modelo Vista Presentador. • Versión 2.0: Implementación de la aplicación con datos persistentes procedente de la base de datos, fichero y preferencias almacenadas del usuario en el móvil. Aún hay partes de la aplicación sin aplicar el patrón Modelo Vista Presentador. • Versión 3.0: Implementación de toda la funcionalidad con la totalidad de los datos persistentes de la base de datos, interfaz definitiva. Como hemos mencionado anteriormente. El sistema se compone de una plataforma web para el tratamiento de datos y de una aplicación Android. Se han implementado 83 clases y 18 activities y fragments (contenidos en las 83 clases). En cuanto al plan de pruebas de GuiaMeUVa, se busca conseguir una serie de objetivos que ayuden en la verificación de las pruebas y en la toma de decisiones. Se enumeran a continuación: • Enumerar y analizar los requisitos más importantes que deben probarse para el correcto funcionamiento de la aplicación. • Identificar los diferentes elementos y clases del proyecto que se deben probar y la información que tenemos que obtener de ellos. • Describir las estrategias de prueba que van a ser utilizadas para un correcto funcionamiento de la aplicación. 8.3.1. Decisiones de la implementación 8.3.1.1 Versiones de Android soportadas En el RFN-001, se especificaba el nivel de API mínimo que va a soportar la aplicación, para la cual se ha tenido en cuenta los datos de fragmentación de Android actuales. En la siguiente figura se puede observar como la mayoría de los usuarios cuentan con versiones de API oscilando entre la 21 y la 26 (Android 5.0 Lollipop y Android 7.0 Nougat). Capítulo 8 Implementación y Pruebas 137 Figura 62: Grafica y tabla de versiones Android y su uso en %. Aunque la versión JellyBean cuenta todavía con un 90.1% de soporte en la mayoría de los dispositivos Android de los usuarios, es por eso por lo que se decide que el nivel mínimo de API es el 16, Android 4.1 Jelly Bean y el Target API es el 26, es decir Android 8.0 Oreo. 8.3.1.2. Recursos y bibliotecas externas utilizadas En este apartado, se detallan los recursos y bibliotecas externas que se han utilizado en el desarrollo de la aplicación. 8.3.1.2.1. JavaMail JavaMail es una API que permite realizar el envío de correos electrónicos en segundo plano sin necesidad de lanzar aplicaciones de gestión de correos. Para poder obtener esta funcionalidad se han acoplado al Gradle de la aplicación tres ficheros .jar para su correcto funcionamiento. • activation.jar • additional.jar • mail.jar Una vez añadidos, en el desarrollo de la aplicación se define una sesión con las conexiones al servidor de salida en función de una cuenta de correo existente que se ha de proporcionar para que se pueda utilizar este servicio. Se ha empleado la cuenta de correo [email protected] para el envío de correos. Capítulo 8. Implementación y Pruebas 144 CP_U_04 El usuario Alumno puede solicitar varias tutorías el mismo día con el mismo profesor Versión 1.0 Descripción Un usuario Alumno selecciona una tutoría con el mismo profesor el mismo día. Resultado esperado La aplicación informa al usuario de que no puede realizar más de una solicitud el mismo día con el mismo profesor. Aplicación Aplicación móvil, versión final. Resultado Primera ejecución: Incorrecto Causa: no está controlado la respuesta que el sistema envía al realizar la “insert” en la base de datos. Acciones realizadas: controlar la respuesta que el sistema devuelve para comprobar si no es correcto debido a que ya está insertado en la base de datos y a continuación informar al usuario. Segunda ejecución: Correcto Tabla 41: Descripción del CP_U_04. CP_U_05 El usuario Alumno puede solicitar una tutoría fuera de las horas disponibles por el profesor Versión 1.0 Descripción Un usuario Alumno selecciona la hora de tutoría fuera de las disponibles. Resultado esperado La aplicación debe de informar al usuario que no puede seleccionar una hora que no sea las disponibles. Aplicación Aplicación móvil, versión final. Resultado Incorrecto Tabla 42: Descripción del CP_U_05. CP_U_06 El usuario Alumno puede cancelar una tutoría Versión 1.0 Descripción Un usuario Alumno cancela una tutoría solicitada con profesor y ésta cambia de estado de “Pendiente” o “Aceptada” a “Cancelada”. Resultado esperado La aplicación informa de que la tutoría ha sido cancelada y se envía un correo al profesor. Aplicación Aplicación móvil, versión final. Resultado Incorrecto Tabla 43: Descripción del CP_U_06. Capítulo 8 Implementación y Pruebas 145 CP_U_07 El usuario Alumno puede visualizar la ubicación de un profesor Versión 1.0 Descripción Un usuario Alumno selecciona un profesor de la lista y pulsa “Mostrar Ubicación”. Resultado esperado La aplicación muestra al usuario Alumno la información con la ubicación del profesor. Aplicación Aplicación móvil, versión final. Resultado Correcto Tabla 44: Descripción del CP_U_07. CP_U_08 El usuario Alumno puede visualizar la ruta de un despacho Versión 1.0 Descripción Un usuario Alumno visualiza la ruta que le guía hacia el despacho del profesor. Resultado esperado La aplicación le muestra la ruta actualizada al usuario Alumno de la ruta a seguir. Aplicación Aplicación móvil, versión final. Resultado Correcto Tabla 45: Descripción del CP_U_08. CP_U_09 El usuario Alumno puede visualizar la ruta de un despacho Versión 1.0 Descripción Un usuario Alumno visualiza la ruta que le guía hacia el despacho del profesor. Resultado esperado La aplicación le muestra la ruta actualizada al usuario Alumno de la ruta a seguir. Aplicación Aplicación móvil, versión final. Resultado Correcto Tabla 46: Descripción del CP_U_09. Capítulo 8. Implementación y Pruebas 146 CP_U_10 El usuario Alumno puede visualizar la ruta de un centro Versión 1.0 Descripción Un usuario Alumno visualiza la ruta que le guía hacia el centro donde está el despacho del profesor. Resultado esperado La aplicación le muestra la ruta actualizada al usuario Alumno de la ruta a seguir. Aplicación Aplicación móvil, versión final. Resultado Correcto Tabla 47: Descripción del CP_U_10. CP_U_11 El usuario Alumno puede consultar un listado de los temas de ayuda Versión 1.0 Descripción Un usuario Alumno visualiza una lista de los temas de ayuda de la aplicación. Resultado esperado La aplicación le muestra una lista de preguntas de ayuda del uso de la misma. Aplicación Aplicación móvil, versión final. Resultado Correcto Tabla 48: Descripción del CP_U_11. 8.9.2. Pruebas para el Administrador CP_A_01 El administrador puede iniciar sesión Versión 1.0 Descripción El Administrador introduce el nombre de usuario y la contraseña y pulsa “Iniciar Sesión”, a continuación, accede a la pantalla de inicio de la web. Resultado esperado La plataforma web le muestra la pantalla de inicio Aplicación Sitio web. Versión final. Resultado Correcto Tabla 49: Descripción del CP_A_01. Capítulo 8 Implementación y Pruebas 147 CP_A_02 El Administrador puede visualizar los centros Versión 1.0 Descripción El Administrador hace clic en la pestaña centros y visualiza accede a la ventana donde se muestra una tabla con los centros que hay en la base de datos. Resultado esperado La aplicación le muestra una lista de centros procedente de la base de datos Aplicación Sitio web, versión final. Resultado Correcto Tabla 50: Descripción del CP_A_02. CP_A_03 El Administrador puede visualizar los despachos Versión 1.0 Descripción El Administrador hace clic en la pestaña despachos y visualiza accede a la ventana donde se muestra una tabla con los despachos que hay en la base de datos. Resultado esperado La aplicación le muestra una lista de despachos procedente de la base de datos Aplicación Sitio web, versión final. Resultado Correcto Tabla 51: Descripción del CP_A_03. CP_A_04 El Administrador puede visualizar los profesores Versión 1.0 Descripción El Administrador hace clic en la pestaña profesores y visualiza accede a la ventana donde se muestra una tabla con los profesores que hay en la base de datos. Resultado esperado La aplicación le muestra una lista de profesores procedente de la base de datos Aplicación Sitio web, versión final. Resultado Correcto Tabla 52: Descripción del CP_A_04. Capítulo 8. Implementación y Pruebas 148 CP_A_05 El Administrador puede visualizar las extensiones Versión 1.0 Descripción El Administrador hace clic en la pestaña extensiones y visualiza accede a la ventana donde se muestra una tabla con las extensiones que hay en la base de datos. Resultado esperado La aplicación le muestra una lista de extensiones procedente de la base de datos Aplicación Sitio web, versión final. Resultado Correcto Tabla 53: Descripción del CP_A_05. CP_A_06 El Administrador puede añadir centros Versión 1.0 Descripción El Administrador hace clic en “Añadir Centro” y a continuación aparece una ventana modal en la que el Administrador inserta los datos relacionados con el centro. Resultado esperado Los datos del centro quedan insertados en la base de datos. Aplicación Sitio web, versión final. Resultado Correcto Tabla 54: Descripción del CP_A_06. CP_A_07 El Administrador puede añadir despachos Versión 1.0 Descripción El Administrador hace clic en “Añadir Despacho” y a continuación aparece una ventana modal en la que el Administrador inserta los datos relacionados con el despacho. Resultado esperado Los datos del despacho quedan insertados en la base de datos. Aplicación Sitio web, versión final. Resultado Correcto Tabla 55: Descripción del CP_A_07. Capítulo 8 Implementación y Pruebas 149 CP_A_08 El Administrador puede añadir profesores Versión 1.0 Descripción El Administrador hace clic en “Añadir Profesor” y a continuación aparece una ventana modal en la que el Administrador inserta los datos relacionados con el profesor. Resultado esperado Los datos del profesor quedan insertados en la base de datos. Aplicación Sitio web, versión final. Resultado Correcto Tabla 56: Descripción del CP_A_08. CP_A_09 El Administrador puede añadir extensiones Versión 1.0 Descripción El Administrador hace clic en “Añadir Extensión” y a continuación aparece una ventana modal en la que el Administrador inserta los datos relacionados con la extensión. Resultado esperado Los datos de la extensión quedan insertados en la base de datos. Aplicación Sitio web, versión final. Resultado Correcto Tabla 57: Descripción del CP_A_09. CP_A_10 El Administrador puede modificar centros Versión 1.0 Descripción El Administrador hace clic en “Editar” en la fila del centro correspondiente y a continuación los campos son editables para modificarlos. Resultado esperado Los datos del centro quedan actualizados en la base de datos. Aplicación Sitio web, versión final. Resultado Correcto Tabla 58: Descripción del CP_A_10. Capítulo 8. Implementación y Pruebas 150 CP_A_11 El Administrador puede modificar despachos Versión 1.0 Descripción El Administrador hace clic en “Editar” en la fila del despacho correspondiente y a continuación los campos son editables para modificarlos. Resultado esperado Los datos del despacho quedan actualizados en la base de datos. Aplicación Sitio web, versión final. Resultado Correcto Tabla 59: Descripción del CP_A_11. CP_A_12 El Administrador puede modificar profesores Versión 1.0 Descripción El Administrador hace clic en “Editar” en la fila del profesor correspondiente y a continuación los campos son editables para modificarlos. Resultado esperado Los datos del profesor quedan actualizados en la base de datos. Aplicación Sitio web, versión final. Resultado Correcto Tabla 60: Descripción del CP_A_12. CP_A_13 El Administrador puede modificar extensiones Versión 1.0 Descripción El Administrador hace clic en “Editar” en la fila de la extensión correspondiente y a continuación los campos son editables para modificarlos. Resultado esperado Los datos de la extensión quedan actualizados en la base de datos. Aplicación Sitio web, versión final. Resultado Correcto Tabla 61: Descripción del CP_A_13. Capítulo 8 Implementación y Pruebas 151 CP_A_14 El Administrador puede eliminar centros Versión 1.0 Descripción El Administrador hace clic en “Eliminar” en la fila del centro correspondiente y a continuación la fila desaparece de la tabla. Resultado esperado Los datos del centro quedan eliminados en la base de datos. Aplicación Sitio web, versión final. Resultado Correcto Tabla 62: Descripción del CP_A_14. CP_A_15 El Administrador puede eliminar despachos Versión 1.0 Descripción El Administrador hace clic en “Eliminar” en la fila del despacho correspondiente y a continuación la fila desaparece de la tabla. Resultado esperado Los datos del despacho quedan eliminados en la base de datos. Aplicación Sitio web, versión final. Resultado Correcto Tabla 63: Descripción del CP_A_15. CP_A_16 El Administrador puede eliminar profesores Versión 1.0 Descripción El Administrador hace clic en “Eliminar” en la fila del profesor correspondiente y a continuación la fila desaparece de la tabla. Resultado esperado Los datos del profesor quedan eliminados en la base de datos. Aplicación Sitio web, versión final. Resultado Correcto Tabla 64: Descripción del CP_A_16. CP_A_17 El Administrador puede eliminar extensiones Versión 1.0 Descripción El Administrador hace clic en “Eliminar” en la fila de la extensión correspondiente y a continuación la fila desaparece de la tabla. Resultado esperado Los datos de la extensión quedan eliminados en la base de datos. Aplicación Sitio web, versión final. Resultado Correcto Tabla 65: Descripción del CP_A_17. Capítulo 8. Implementación y Pruebas 152 CP_A_18 El Administrador puede asignar centro, despacho y extensión a un profesor Versión 1.0 Descripción El Administrador selecciona la pestaña Administración y aparece una ventana con la tabla de los centros, despachos, extensiones y el profesor asignado a ellos. El Administrador hace clic en Añadir Ubicación y a continuación sale una ventana modal para insertar los datos. Resultado esperado Los datos insertados quedarán persistentes en la base de datos y aparecerán en la tabla. Aplicación Sitio web, versión final. Resultado Tabla 66: Descripción del CP_A_18. 153 Capítulo 9 - Conclusiones