UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA GRADO EN INGENIERÍA INFORMÁTICA TRABAJO FIN DE GRADO

Transcripción

1 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA GRADO EN INGENIERÍA INFORMÁTICA TECNOLOGÍAS DE LA INFORMACIÓN TRABAJO FIN DE GRADO Un Juego para Desarrollar Habilidades Convenientes en Desarrollo Global del Software David Valencia Delgado-Corredor Septiembre, 2015

2

3 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA GRADO EN INGENIERÍA INFORMÁTICA TECNOLOGÍAS DE LA INFORMACIÓN TRABAJO FIN DE GRADO Un Juego para Desarrollar Habilidades Convenientes en Desarrollo Global del Software Autor: David Valencia Delgado-Corredor Director: Aurora Vizcaíno Barceló Septiembre, 2015

4

5 TRIBUNAL: Presidente: Vocal: Secretario: FECHA DE DEFENSA: CALIFICACIÓN: PRESIDENTE VOCAL SECRETARIO Fdo.: Fdo.: Fdo.:

6

7 Resumen En los últimos años, las empresas se han visto afectadas por la globalización, lo que ha cambiado su modelo de negocio. Las empresas de desarrollo software no son una excepción, e intentan unirse al mercado global con el fin de poder contratar mano de obra en otros países, buscando reducir los costes, aumentar la productividad y ganar ventaja competitiva. Esto es lo que se conoce como Desarrollo Global del Software (Global Software Development GSD, por sus siglas en ingles). Con esta práctica las empresas tratan de encontrar desarrolladores que posean conocimientos y habilidades para solventar los problemas que surgen a causa del GSD. Sin embargo, los métodos tradicionales para enseñar a los estudiantes o empleados cómo trabajar en entornos GSD suelen ser costosos, además de requerir un gran esfuerzo. Es aquí donde los serious games tienen un papel importante, ya que se trata de juegos educativos que permiten adquirir conocimientos y habilidades con un bajo coste. En este TFG se propone desarrollar un serious game con el cual se puedan adquirir algunas de las competencias necesarias en el GSD. El juego simulará el desarrollo global de un proyecto software, de manera que el usuario pueda tomar conciencia de los problemas referentes al GSD y adquirir una cierta experiencia a la hora de solventar estos problemas. VII

8

9 Abstract In the last years, companies has been affected by globalization, which has changed its business model. Software development companies are not an exception, and try to expand to globalization, looking for labor in other countries, seeking to reduce costs, increase productivity and gain competitive advantage. This is known as Global Software Development (GSD). Thus, companies try to find developers who possess knowledge and skills to solve GSD problems. However, traditional learning methods are often costly, and require much effort. Serious games play and important role, allowing to acquire knowledge and skills at a low cost. We propose to develop a serious game to acquire some of the skills needed in the GSD. The game will simulate the global development of a software project, so the user may become aware of the problems concerning GSD, and gain some experience to solve these problems. IX

10

11 Agradecimientos Quisiera que estas líneas sirviesen para expresar todo mi agradecimiento a aquellas personas que han hecho posible que haya llegado hasta aquí, porque sin ellos no habría sido igual. En el plano académico, me gustaría dar las gracias a Aurora Vizcaíno Barceló, directora de este trabajo, por guiarme a lo largo de todo este proyecto; por su tiempo, apoyo y confianza. En el plano personal, me gustaría en primer lugar, dar las gracias a mi familia por su apoyo a lo largo de todos estos años. En segundo lugar, a mis amigos por los buenos momentos que hemos pasado juntos, porque siempre han estado a mi lado cuando lo he necesitado. Para terminar, a mis compañeros de universidad, por su ayuda durante esta etapa. XI

12

13 XIII A Sergio López-Romero

14

15 Índice General Índice de figuras Índice de tablas Índice de listados xvii xxi xxiii 1 Introducción 1 2 Objetivos 5 3 Antecedentes Desarrollo Global de Software Tipos de Desarrollo Global de Software Beneficios del Desarrollo Global del Software Desafíos del Desarrollo Global de Software Serious Games Serious games como herramienta de aprendizaje Método de trabajo Proceso Unificado de Desarrollo Fases del PUD Flujo de trabajo del PUD Marco tecnológico de trabajo Herramientas de gestión de proyectos Herramientas para el modelado Herramientas y tecnologías para el desarrollo del proyecto Herramientas para la documentación Resultados Fase de Inicio Captura e identificación de requisitos Modelo de Casos de Uso Gestión del riesgo Plan de iteraciones Fase de Elaboración Iteración Iteración Fase de Construcción XV

16 5.3.1 Iteración Iteración Iteración Iteración Fase de Transición Iteración Conclusiones y propuestas Conclusiones Consecución de objetivos Propuestas futuras Bibliografía 87 A Desafíos del GSD B Serious games en diversas áreas C Manual de instalación C.1 Requisitos del sistema C.2 Instalación de las tecnologías y sistema D Manual de usuario D.1 Funciones comunes a todos los usuarios D.2 Estudiante D.3 Profesor XVI

17 Índice de figuras 3.1 Incremento de las actividades de offshoring y del ahorro que conlleva [10] Cono de aprendizaje de Dale [13], que muestra el grado o nivel de aprendizaje que se produce cuando los alumnos se dedican a cada estilo de aprendizaje Ejemplo se serious games para el aprendizaje Interfaz de Visual Paradigm Interfaz de la herramienta Día Interfaz de Balsamiq Mockups Interfaz de Microsoft Project Diagrama de casos de uso del cliente Diagrama de casos de uso del cliente Diagrama de caso de uso Registro (Cliente) Diagrama de caso de uso Registro (Servidor) Diagrama de caso de uso Acceso (Cliente) Diagrama de caso de uso Acceso (Servidor) Diagrama de caso de uso Gestión del Perfil (Cliente) Diagrama de caso de uso Gestión del Perfil (Servidor) Diagrama de caso de uso Gestión de Escenarios (Cliente) Diagrama de caso de uso Gestión de Escenarios (Servidor) Diagrama de caso de uso Jugar Escenario (Cliente) Diagrama de caso de uso Jugar Escenario (Servidor) Diagrama de caso de uso Consultar Resultado (Cliente) Diagrama de caso de uso Consultar Resultado (Servidor) Diagrama de Gantt del plan del proyecto Arquitectura del sistema Esquema entidad-relación de la base de datos Boceto de la interfaz de registro Diagrama de secuencia del Grupo funcional F1 (Cliente) XVII

18 5.20 Diagrama de secuencia del Grupo funcional F1 (Servidor) Boceto pantalla de acceso Diagrama de secuencia del Grupo funcional F2 (Cliente) Diagrama de secuencia del Grupo funcional F2 (Servidor) Diagrama de secuencia del Grupo funcional F3 (Cliente) Diagrama de secuencia del Grupo funcional F3 (Servidor) Boceto de la interfaz de editor de proyecto Diagrama de secuencia para crear un proyecto (Cliente) Diagrama de secuencia para crear un proyecto (Servidor) Boceto de la interfaz del juego Diagrama de secuencia para simular una llamada (Cliente) Diagrama de secuencia para simular una llamada (Servidor) Diagrama de secuencia para la obtención de un resultado (Cliente) Diagrama de secuencia para la obtención de un resultado (Servidor) D.1 Página de acceso D.2 Formulario de registro D.3 Página de edición del perfil D.4 Formulario para cambiar la contraseña D.5 Página principal (Estudiante) D.6 Página Requests D.7 Página con los resultados del usuario D.8 Página con el resultado del usuario D.9 Pantalla de juego D.10 Pantalla de configuración de un módulo D.11 Bandeja de entrada D.12 Pantalla de una llamada D.13 Página principal (Profesor) D.14 Página para crear una solución D.15 Página para crear un problema XVIII

19 D.16 Página para crear una llamada D.17: Página para crear un chat D.18 Página para crear un proyecto D.19 Página para enviar una solicitud a un alumno D.20 Página con los estudiantes asociados D.21 Página con los datos de un estudiante D.22 Página con el resultado de una partida XIX

20

21 Índice de tablas 3.1 Procesos de desarrollo afectados por las distancias en GSD [4] Grupos funcionales del sistema Plan de iteraciones Grupos funcionales del sistema XXI

22

23 Índice de listados 5.1 Función signup que permite el registro de un usuario (Cliente) Pruebas unitarias para el correcto registro de usuarios Función signin que permite el acceso de un usuario (Cliente) Función signin que permite el acceso de un usuario (Servidor) Pruebas unitarias para el correcto acceso a sistema Función changeuserpassword Pruebas unitarias para cambiar el password Fragmento de código para la creación un proyecto Pruebas unitarias para el modelo Projects Funciones start_recording y stop_recording Función createcallresponse para almacenar una respuesta de audio Prueba unitaria de la función $scope.hire() Función createresult para almacenar el resultado de una partida Función getmodulesdata : Pruebas unitarias del grupo funcional F6: Consultar Resultados XXIII

24

25 CAPÍTULO 1 INTRODUCCIÓN En muchas áreas como la defensa, sanidad, educación, política, ingeniería, etc. se necesitan personas con una formación adecuada, que posean los conocimientos, capacidades y habilidades adecuados para llevar a cabo su trabajo. Generalmente, los métodos de enseñanza tradicionales son costosos y necesitan de mucho tiempo de preparación. Es aquí donde entra el concepto de Serious Game. Un Serious game es un juego que está diseñado de tal forma que su objetivo principal no es el entretenimiento del usuario, sino su formación en un área determinada [12]. En 2012, Graafland et al Graafland, Schraagen [8], llevaron a cabo una revisión sistemática de los serious games para la enseñanza de habilidades quirúrgicas y conocimientos médicos. En su trabajo presentaron 30 serious games, en los que 17 tenían un propósito educativo y 13 el de desarrollar habilidades necesarias para el personal médico. La conclusión de su trabajo fue que se pueden utilizar los juegos serios tanto para desarrollar habilidades técnicas como no técnicas en el ámbito quirúrgico. La principal ventaja de los serious games es su bajo coste y solo requieren de un DVD o un CD-ROM, a diferencia de simuladores que normalmente requieren de un hardware especializado. Por otro lado, en el área del desarrollo de software, la globalización ha llevado a muchas empresas a realizar el desarrollo de sus productos de una manera distribuida, llevándose a cabo por diferentes equipos, e incluso desde diferentes países. Esto se conoce con el término de Desarrollo global de software (GSD, por sus siglas en inglés Global Software Development) [14]. Los principales motivos que llevan a las empresas al GSD es que permite aumentar la productividad, ya que el hecho de que los equipos se encuentren en distintos usos horarios, permite dedicar más horas al desarrollo de un proyecto. Además, los costes se ven reducidos debido a la expansión hacia otros países donde la mano de obra es más barata [15]. Sin embargo, el desarrollo global de software también tiene una serie de desventajas. Además de los problemas tradicionales del desarrollo de software, la deslocalización de los 1

26 CAPÍTULO 1. INTRODUCCIÓN equipos conlleva problemas de comunicación, coordinación y control, además de otros problemas derivados de las diferencias culturales de los distintos equipos [7]. Por todo ello es necesario que las personas que trabajan en el GSD posean unas competencias adicionales a las requeridas en el desarrollo tradicional. Generalmente, es difícil encontrar un método adecuado para la enseñanza de estas habilidades, ya que las clases teóricas resultan insuficientes. Otros métodos, como el descrito en [6], en el que estudiantes localizados en diferentes países llevan a cabo el desarrollo de un software, resultan costosos y complejos de coordinar. Para dar una solución a los problemas anteriormente mencionados, se pretende, mediante este Trabajo de Fin de Grado, desarrollar un serious game con el que el usuario pueda adquirir las competencias necesarias en el Desarrollo Global del Software. De esta manera, se simulará el desarrollo global de un proyecto software, de manera que el alumno pueda tomar conciencia de los problemas referentes al GSD y adquirir una cierta experiencia a la hora de solventar estos problemas. El presente documento se compone de 6 capítulos y 4 anexos, que se describen a continuación. El capítulo actual corresponde al Capítulo 1 del documento, en el cual se introduce al lector en el tema del Desarrollo Global del Software y los serious games, resumiendo algunas de sus principales ventajas y desafíos. En el Capítulo 2 se expone el objetivo principal de este TFG y se describen los objetivos que se derivan del objetivo principal. El Capítulo 3 corresponde al estado del arte, y se centra en los temas que sirven como fundamentos teóricos para este trabajo, como son el Desarrollo Global del Software y los serious games. En el Capítulo 4 se explica la metodología de trabajo que se ha utilizado para el desarrollo del proyecto y que, en este caso, se trata del Proceso Unificado de Desarrollo. Además, se exponen los entornos y herramientas utilizadas. En el Capítulo 5 se recogen los resultados y artefactos que se han obtenido a lo largo del ciclo de vida del desarrollo del presente trabajo y que hacen posible la ejecución del 2

27 CAPÍTULO 1. INTRODUCCIÓN sistema. Estos resultados se han obtenido siguiendo la metodología de trabajo propuesta en el Capítulo 4. En el Capítulo 6 se exponen las conclusiones obtenidas tras realizar el trabajo, además de las propuestas futuras para incorporar al sistema. Tras los capítulos anteriormente mencionados, se muestra la bibliografía consultada durante el desarrollo de este TFG. Por último, se presentan una serie de anexos, donde se muestra información importante a tener en cuenta, pero que no se ha introducido en los capítulos anteriores para evitar sobrecargarlos. Estos anexos son: Anexo A. Desafíos del GSD. Anexo B. Serious games en diversas áreas. Anexo C. Manual de instalación. Anexo D. Manual de usuario. 3

28

29 CAPÍTULO 2 OBJETIVOS El objetivo principal del TFG consiste en el desarrollo de un serious game que permita al usuario adquirir algunas de las habilidades y competencias necesarias para trabajar en el Desarrollo Global del Software. En concreto, el usuario jugará desempeñando el papel de un jefe de proyecto. El juego se basará en la planificación de un software, donde se simula trabajar con personas de distintas partes del mundo, donde el jugador tendrá que hacer frente a problemas que podrían darse en el GSD. Además de ser una herramienta que permite adquirir una serie de conocimientos, combina los aspectos esenciales de un juego, lo que resulta en un aprendizaje más entretenido y llevadero para el estudiante. Para alcanzar nuestro propósito habrá que realizar los siguientes objetivos que se describen como requisitos del sistema a construir: El usuario debe poder modificar los datos de su perfil si así lo desea. La aplicación simulará un chat, correo electrónico y teléfono para que el alumno tenga que trabajar con comunicación síncrona y asíncrona, por lo que la aplicación simulará la llegada de s, llamadas telefónicas y chat, en un orden aleatorio. La aplicación debe estar basada en distintos escenarios, que tendrán distintos niveles de dificultad. El jugador comenzará por el más sencillo e irá ascendiendo en el nivel de dificultad. De esta forma se pretende que el estudiante adquiera conocimientos de una forma gradual. La aplicación debe permitir al usuario crear escenarios personalizados, por si quiere practicar en un escenario concreto. La aplicación debe simular una serie de eventos o problemas inesperados que podrían darse en la realidad en un proyecto GSD, como que un trabajador tenga vacaciones, que sea fiesta en alguno de los países de los que un equipo de desarrollo forma parte, una caída del servidor, etc. Estos eventos se producirán de manera aleatoria. El usuario podrá consultar una ayuda cuando no sepa cómo seguir. El usuario podrá consultar su historial de puntuación. 5

30

31 CAPÍTULO 3 ANTECEDENTES 3.1 Desarrollo Global de Software En los últimos años, las organizaciones e industrias han sufrido una tendencia hacía la globalización, y la industria del software, no es una excepción. Por lo tanto, muchas compañías han cambiado la forma en la que trabajan, pasando de tener a los equipos de desarrollo en un mismo edificio, a tenerlos localizados en distintos edificios, ciudades o, incluso en distintos países. Al modelo de desarrollo de software en el que los equipos se encuentran en distintos países se le llama Desarrollo Global del Software (DGS, o GSD por sus siglas en inglés: Global Software Development)[14]. Entre las principales ventajas de este tipo de desarrollo se encuentran la mejora de productividad y la reducción de costes. Este aumento de la productividad se puede conseguir mediante el enfoque follow-the-sun, que consiste en aprovechar la diferencia horaria entre los distintos equipos de desarrollo, de modo que un equipo puede estar trabajando mientras el otro está durmiendo. De esta forma, el proyecto mantiene un desarrollo constante [3]. En cuanto a la reducción de costes, entre los métodos que se suelen emplear destacan la subcontratación de empresas o la creación de una filial de la misma organización en países donde los sueldos son más reducidos. No obstante, hay que tener en cuenta que la coordinación de un equipo remoto conlleva un coste extra, por lo que deben crearse puestos para los gerentes en dicho país, o asumir el costo de los viajes de los gerentes [3]. Podemos concluir diciendo que el Desarrollo Global del Software es una tendencia que está creciendo, tanto por motivos económicos, como por motivos de calidad y de mercado. Este crecimiento y la globalización de las empresas hacen que cada vez se interesen más ingenieros en este tipo de modelo de desarrollo [7]. 7

32 3.1 DESARROLLO GLOBAL DE SOFTWARE Tipos de Desarrollo Global de Software Existen diversas variaciones dentro del GSD. A continuación se resumen las distintas variantes. Outsourcing: También conocido como subcontratación, es el proceso mediante el cual, una empresa delega los recursos orientados a cumplir algunas tareas en una empresa externa, la cual se dedica a prestar servicios sobre los que está especializada. Offshoring: Este concepto está relacionado con el anterior, y se refiere a la relocalización de procesos de negocio, a través de empresas filiales en otros países Nearshoring: Es el nombre que recibe el concepto de offshoring cuando los países implicados en las actividades se encuentran a una distancia relativamente cercana del país origen Estas prácticas son cada vez más utilizadas en el Desarrollo Global del Software, debido a la rentabilidad que proporcionan a la compañía. En la Figura 3.1 se puede observar el crecimiento del offshoring hasta el año 2010 y la reducción de costes que conlleva. Figura 3.1: Incremento de las actividades de offshoring y del ahorro que conlleva [10] 8

33 CAPÍTULO 3. ANTECEDENTES Como se puede apreciar, el desarrollo global del software y sus prácticas conllevan una serie de beneficios o ventajas, pero también dificultades o inconvenientes que hay que tener en cuenta. En los siguientes apartados se explican tanto los beneficios como los inconvenientes que conlleva el GSD Beneficios del Desarrollo Global del Software A continuación se explican los principales beneficios que aporta el GSD, según [1]. Ahorro de costes Quizás el beneficio más importante que proporciona el GSD es la reducción de costes durante el desarrollo. Las empresas están globalizando sus actividades de desarrollo para aprovechar los salarios más bajos de otros países. Aumenta la competitividad La competitividad entre las empresas aumenta ante la posibilidad de estas de encontrar mano de obra más cualificada y experimentada en otros países. Por lo tanto, las empresas tienen la oportunidad de ampliar su actividad para incluir la aportación de miles de trabajadores, donde quiera que se encuentren. Reducción del tiempo de lanzamiento al mercado Gracias al enfoque follow-the-sun, una empresa puede aumentar la efectividad con la que maneja sus recursos, maximizando la productividad, ya que se pueden aprovechar las diferencias horarias que existen entre los distintos equipos de desarrollo. De este modo, la empresa puede estar desarrollando el software las 24 horas del día, permitiendo así reducir el tiempo de salida al mercado del producto. 9

34 3.1 DESARROLLO GLOBAL DE SOFTWARE Proximidad al mercado y al cliente Al establecer filiales en los países donde se encuentran sus potenciales clientes, el Desarrollo Global de Software permite a las empresas desarrollar el software de una manera más cercana a los clientes y aumentar el conocimiento del mercado local. Innovación y compartición de mejores prácticas Las organizaciones pueden aprovechar las ventajas que tiene la colaboración entre miembros de equipos localizados en distintos países y con distintas formas de organización, ya que se producen mayores innovaciones y se comparten mejores prácticas Desafíos del Desarrollo Global de Software Hemos podido ver que el Desarrollo Global de Software proporciona a las organizaciones unos beneficios muy prometedores. Sin embargo, el GSD también conlleva una serie de inconvenientes que las organizaciones deben superar. Según [5] los principales desafíos del GSD son: Desafíos de comunicación, entendiendo la comunicación como el intercambio de información y conocimientos. Desafíos de coordinación, es decir, desafíos relacionados con la realización de tareas para lograr los objetivos e intereses comunes. Desafíos de control, que están centrados en la gestión del proyecto, es decir, en cumplir el calendario de entregas, presupuestos, calidad, estándares, etc, con éxito. Estos desafíos no solo se producen en el Desarrollo Global de Software, sino también en método tradicional de desarrollo. Sin embargo, en GSD, los ingenieros deben enfrentarse a una serie de obstáculos y dificultades que aparecen debido a lo que se conoce como las tres distancias. Los tres tipos de distancia según [2] son: Distancia geográfica. En GSD, se define como la medida de esfuerzo que un individuo necesita realizar para visitar otro punto, alejado del primero [4]. Por 10

35 CAPÍTULO 3. ANTECEDENTES ejemplo, dos lugares que se encuentren dentro del mismo país, separados por una gran distancia, que tengan un enlace aéreo directo con vuelos regulares, se pueden considerar relativamente cercanos. En cambio, dos lugares que se encuentren separados por pocos kilómetros, pero con poca infraestructura de transporte, se considera que tienen una distancia geográfica elevada. Distancia temporal. En GSD, se define como la medida de la deslocalización en tiempo, experimentada por dos individuos que desean interactuar [4]. Normalmente, esta distancia está relacionada con la anterior, ya que cuando existe distancia geográfica, suele implicar diferentes husos horarios, lo que limita la comunicación síncrona cuando no hay solapamiento horario entre dos equipos que están geográficamente distribuidos. Distancia socio-cultural. Se define como la medida en que un individuo comprende las costumbres (símbolos, normas y valores sociales) y cultura de otro individuo [4]. Debido a que cada miembro del equipo puede tener una nacionalidad y cultura diferente, esta distancia se da con frecuencia en GSD. Esta distancia provoca malentendidos y conflictos entre los miembros de los equipos de desarrollo, generando retrasos en la entrega de los productos. En la Tabla 3.1 podemos observar cómo afecta cada una de las distancias a los procesos de comunicación, coordinación y control. Proceso Distancia Geográfica Temporal Socio-Cultural Comunicación Depende de la tecnología Comunicación asíncrona Malentendidos Coordinación Control Falta de conciencia, aumenta el esfuerzo de coordinación Aumenta la dificultad de gestión y control Modificación de las horas de trabajo Control asíncrono sobre recursos remotos Falta de confianza en los demás Variaciones culturales en los mecanismos de control Tabla 3.1 Procesos de desarrollo afectados por las distancias en GSD [4] 11

36 3.2 SERIOUS GAMES En el Anexo A se descubren los principales desafíos del GSD según [4]: 3.2 Serious Games Actualmente el paradigma educativo se está viendo inmerso en un importante cambio, pasando de la enseñanza centrada en la transmisión de conocimientos, a una nueva concepción que se centra en el estudiante y que se basa en que el alumno adquiera y desarrolle unas competencias clave. En los últimos años, las competencias se están incorporando tanto a la educación obligatoria como a la superior [9]. Es entonces cuando surge el concepto de serious games como una nueva forma de adquirir estas competencias. Un serious game es un juego que está diseñado de tal forma que su objetivo principal no es el entretenimiento del usuario, sino su formación en un área determinada [12]. La principal ventaja de los serious games es su bajo coste, ya que a diferencia de otros métodos de enseñanza tradicional, como los simuladores, que requieren de un hardware costoso, los serious games solo necesitan de un CD o un DVD. El número de juegos educativos va en aumento. El potencial de los juegos digitales como herramientas de aprendizaje se incrementará debido a la mejora de la tecnología, el aumento de las técnicas de interacción, la capacidad del software para procesar datos y el aumento de los jugadores Serious games como herramienta de aprendizaje Los serious games se pueden aplicar a todos los niveles de la educación, dentro y fuera de la escuela, desde niños hasta personas mayores y también se pueden aplicar a una amplia variedad de áreas. El potencial de los juegos serios como una herramienta para el aprendizaje ha sido reconocido por la capacidad de equilibrar el entretenimiento, la interactividad y la rejugabilidad de los juegos típicos, con el objetivo del aprendizaje de un objetivo educativo dado. Por otra parte, los juegos serios enfocan el aprendizaje como un reto, difícil y gratificante, con la finalidad de aumentar el compromiso de los jugadores [29]. 12

37 CAPÍTULO 3. ANTECEDENTES Figura 3.2: Cono de aprendizaje de Dale [13], que muestra el grado o nivel de aprendizaje que se produce cuando los alumnos se dedican a cada estilo de aprendizaje De acuerdo al Cono de aprendizaje de Dale (Figura 3.2), los resultados del aprendizaje aumentan de arriba abajo. El aprendizaje mediante la simulación de una experiencia real (parte más baja del Cono de Dale), puede ayudar a la comprensión de lo que se está aprendiendo más de lo que ayuda leer o escuchar (parte más elevada del Cono de Dale). Dale afirma que los usuarios podrían recordad un 90 por ciento de lo que aprenden mediante la simulación. Así, con el fin de crear una herramienta de aprendizaje de alta eficiencia, con control del riesgo y presupuesto en la práctica real, la simulación con juegos serios es la más interesante [13]. La Figura 3.3 muestra algunos ejemplos de juegos serios en varias áreas. De arriba a abajo y de izquierda a derecha: The Virtual Dental Implant Training Simulation, un juego serio diseñado para ayudar a los estudiantes de odontología en el diagnóstico, la toma de decisiones y los protocolos de tratamiento. Quest for oil, un serious game para la exploración de petróleo. Cruise ship, un juego serio para que la tripulación de cruceros se entrene para diferentes desastres. RescueSim, para preparar a los profesionales de la seguridad para los accidentes de la vida real, en un entorno virtual. 3D Networks, un juego serio con el objetivo de entrenar a estudiantes de ingeniería civil sobre los riesgos de las obras públicas cerca de redes subterráneas. NanoMission, un juego serio con el objetivo de enseñar a los jugadores los conceptos de la nanociencia a través de aplicaciones prácticas del mundo real. 13

38 3.2 SERIOUS GAMES Figura 3.3: Ejemplo se serious games para el aprendizaje En el Anexo B se muestran las aplicaciones de los serious games en diversas áreas. 14

39 CAPÍTULO 4 MÉTODO DE TRABAJO Para el desarrollo de este software se ha utilizado la metodología genérica descrita por el Proceso Unificado de Desarrollo (PUD), propuesta por Jacobson, Booch y Rumbaugh [11]. 4.1 Proceso Unificado de Desarrollo El PUD es una evolución del Proceso Unificado de Rational, que define un conjunto de actividades necesarias para transformar los requisitos de usuario en un sistema software. Es más que un simple proceso; se trata de un marco de trabajo genérico que se puede especializar para una gran variedad de sistemas software, diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto [11]. Las principales características del PUD según [11] son: Dirigido por casos de uso. Un caso de uso es una funcionalidad que el sistema proporciona al usuario un resultado que tiene un valor para este. Los casos de uso representan los requisitos funcionales, y todos ellos forman el modelo de casos de uso. Los casos de uso guían el proceso de desarrollo, es decir, no solo sirven para especificar los requisitos, sino que también guían el diseño, la implementación y las pruebas. Centrado en la arquitectura. La arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura se ve reflejada en los casos de uso, aunque intervienen otros factores, como la plataforma sobre la que el software debe funcionar (arquitectura hardware, sistema operativo, sistema de gestión de la base de datos, protocolos para la comunicación red). La arquitectura es una vista completa del diseño, teniendo en cuenta las cosas más importantes, y debe diseñarse para permitir que el sistema evolucione, tanto en su desarrollo, como a lo largo de futuras generaciones. 15

40 4.1 PROCESO UNIFICADO DE DESARROLLO Iterativo e incremental. Desarrollar un producto software supone un gran trabajo, que puede durar varios meses o incluso años. Por lo tanto, resulta muy conveniente reducir el trabajo en partes más pequeñas o miniproyectos. Cada miniproyecto es una iteración, compuesta por una serie de casos de uso, que tiene como resultado un incremento en el proyecto. En cada iteración, los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseño utilizando la arquitectura seleccionada como guía, implementan el diseño mediante componentes y verifican que los componentes satisfacen los casos de uso. Si la iteración cumple con sus objetivos, se continúa con la siguiente. Para que la efectividad en el desarrollo del proyecto sea máxima, las iteraciones deben estar controladas, es decir, hay que seleccionarlas y ejecutarlas de una forma planificada Fases del PUD El Proceso Unificado de Desarrollo tiene una serie de ciclos que constituyen la vida del sistema. Cada ciclo constituye una versión del producto, y consta de cuatro fases: inicio, elaboración, construcción y transición, y cada fase, se divide a su vez en iteraciones. Fase de inicio En esta fase se determina el alcance del proyecto y se procede a la identificación de los riesgos principales. Los artefactos más relevantes que se obtienen en esta fase son [11]: Modelo de casos de uso. Una vez hecha la captura de requisitos, se obtiene el primer modelo de casos de uso, que representará estos requisitos. Gestión del riesgo. Un documento que contiene los riesgos principales a tener en cuenta durante el desarrollo del proyecto. Glosario de términos. Un glosario que contiene los términos más relevantes del dominio sobre el que se trabaja. Plan de proyecto. Se elabora el plan de iteraciones que se seguirá durante el desarrollo del proyecto. 16

41 CAPÍTULO 4. MÉTODO DE TRABAJO Fase de elaboración Durante esta fase, se especifican más en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura del sistema. Como resultado de esta fase se obtiene la línea base de la arquitectura. Durante esta fase se obtienen los siguientes artefactos [11]: Arquitectura. Se diseña la arquitectura del sistema. Modelo de casos de uso. A partir del modelo de casos de uso obtenido en la fase de inicio, se obtiene un modelo de casos de uso con más detalle, reuniendo todos los requisitos funcionales. Modelo de análisis. Es un modelo más detallado que el de casos de uso, pero sin llegar al nivel de detalle del modelo de diseño. Se compone de los diagramas de clases de análisis y los diagramas de secuencia. Modelo de diseño. Es un modelo compuesto por diagramas de clases de diseño y diagramas de secuencia e interacción Fase de construcción El propósito de esta fase es el desarrollo del producto software en su versión operativa inicial, también conocida como versión beta. Durante esta fase se implementa cada una de las iteraciones en las que se ha dividido el producto software. En esta fase también se diseñan y ejecutan las pruebas para las distintas funcionalidades. Durante esta fase se obtienen los siguientes artefactos [11]: Modelo de diseño. Se obtiene otro modelo más refinado a partir del modelo obtenido en la fase de elaboración. Modelo de implementación. Este modelo se compone de los diagramas de componentes, como se relacionan y las dependencias entre ellos Modelo de pruebas. Modelo que consta de los casos de pruebas unitarias y funcionales. 17

42 4.1 PROCESO UNIFICADO DE DESARROLLO Fase de transición Esta fase consiste en implantar el producto en su entorno de operación. Durante esta fase se continúa probando el producto y posiblemente, también se va incrementando su funcionalidad. Al finalizar esta fase el producto está disponible para ser entregado, al igual que los manuales y documentos legales, como los contratos, licencias, renuncias de derechos y garantías [11] Flujo de trabajo del PUD Como y se ha comentado cada una de las fases anteriores se divide en una o varias iteraciones. Cada una de estas iteraciones constituye un conjunto de casos de uso y tiene como resultado un incremento en la funcionalidad del producto software. Cada iteración sigue un flujo completo de trabajo, que se compone de cinco disciplinas: captura de requisitos, análisis, diseño, implementación y pruebas [11]. Captura de requisitos Esta disciplina tiene un mayor grado de participación en las fases de inicio y elaboración y se centra en la captura e identificación de los requisitos. El objetivo principal es desarrollar un modelo del sistema que se va a construir y para ello, se utilizan los casos de uso. Esto se debe a que los requisitos funcionales se estructuran de forma natural en los casos de uso y a que los requisitos no funcionales pueden especificarse en un solo caso de uso Análisis Tiene su mayor relevancia en la fase de elaboración. Durante el análisis, se analizan los requisitos que se describieron en la captura de requisitos, refinándolos y estructurándolos. El objetivo es lograr comprender mejor los requisitos y logar una descripción de los mismos que sea fácil de mantener y que ayude a estructurar el sistema. Se elabora el modelo de análisis, que ofrece una visión más específica del sistema, sin llegar al nivel de detalle del modelo de diseño. Diseño Esta disciplina tiene más relevancia en las fases de elaboración y construcción. En esta fase se modela el sistema para que se soporten todos los requisitos, incluyendo los requisitos no 18

43 CAPÍTULO 4. MÉTODO DE TRABAJO funcionales y otras restricciones. Se elabora el modelo de diseño, que tiene un mayor nivel de detalle que se acerca a la implementación. Implementación Esta disciplina tiene mayor relevancia en la fase de construcción. Durante esta fase se implementa el sistema en términos de componentes, es decir, los ficheros de código fuente, scripts, ficheros de código binario, ejecutables, etc. Ya que la mayor parte de la arquitectura se ha capturado en la fase de diseño, el propósito principal de esta fase es desarrollar la arquitectura y el sistema como un todo. Pruebas Esta disciplina es relevante en todas aquellas fases en las que se haya llevado a cabo una implementación, pues se deben probar todos los componentes a medida que se van implementando. El objetivo principal es el diseño e implementación de las pruebas unitarias y funcionales del sistema. Se crean casos de prueba para cada iteración y se automatiza su ejecución siempre que sea posible. 4.2 Marco tecnológico de trabajo En esta sección se exponen las herramientas, tecnologías y librerías utilizadas para el desarrollo de este proyecto Herramientas de gestión de proyectos Git Git [24] es el sistema de control de versiones que se ha utilizado a lo largo del desarrollo de este proyecto. Está diseñado para manejar proyectos muy grandes con velocidad y eficiencia, pero también es útil para proyectos pequeños. Durante este proyecto, se utiliza un repositorio Git para la gestión de sus versiones. Este repositiorio está alojado en Bitbucket, un sistema de alojamiento basado en web, para proyectos que usan los sistemas de control de versiones Mercurial y Git. 19

44 4.2 MARCO TECNOLÓGICO DE TRABAJO Herramientas para el modelado Visual Paradigm Visual Paradigm [25] es una herramienta CASE (Computer Aided Software Engineering o Ingeniería de Software Asistida por Computador) profesional para el modelado UML (Unified Modeling Language o Lenguaje Unificado de Modelado). Visual Paradigm ha sido realizada con el propósito de soportar el ciclo de vida completo del proceso de desarrollo del software, a través de la realización de una gran variedad de tipos de diagramas. En este proyecto se utilizará esta herramienta para realizar los diagramas UML que sean necesarios. En la Figura 4.1 se puede observar la interfaz de esta herramienta. Figura 4.1: Interfaz de Visual Paradigm Día Día es un programa para la generación de diagramas. Está desarrollado en módulos, con diferentes paquetes según las necesidades. Actualmente permite la creación de diagramas entidad-relación, diagramas UML, diagramas de flujo, diagramas de redes, etc. En la Figura 4.2 se muestra la interfaz de esta herramienta. 20

45 CAPÍTULO 4. MÉTODO DE TRABAJO Figura 4.2: Interfaz de la herramienta Día Balsamiq Mockups Balsamiq Mockups [22] es una aplicación que se utiliza para el diseño de borradores y bocetos de las interfaces de usuario. Permite hacer representaciones de todos los elementos utilizados para construir una web, como las pantallas de los navegadores, los títulos, menús, imágenes, vídeos, etc, de modo que nos permite tener una rápida aproximación de la solución que se quiere desarrollar. En la Figura 4.3 podemos ver la interfaz de esta herramienta. Figura 4.3: Interfaz de Balsamiq Mockups 21

46 4.2 MARCO TECNOLÓGICO DE TRABAJO Microsoft Project Microsoft Project es un software para la administración de proyectos que está diseñado, desarrollado y comercializado por Microsoft, para asistir a administradores de proyectos. Este software ayuda en el desarrollo de planes, la asignación de recursos a tareas, el seguimiento del progreso, la administración de presupuestos y el análisis de las cargas de trabajo. En la Figura 4.4 podemos ver la interfaz de Microsoft Project. Figura 4.4: Interfaz de Microsoft Project Herramientas y tecnologías para el desarrollo del proyecto Sublime text Sublime text es un editor de texto y de código multiplataforma, escrito en C++ y Phyton para el soporte de plugins. Entre sus características principales destacan: soporte nativo para varios lenguajes, soporte de snippets y plugins, configuración total de keybindings, paleta de comandos y búsqueda dinámica. Javascript Javascript (abreviado como JS) es un lenguaje ligero e interpretado, orientado a objetos. Se trata de un lenguaje script multi-paradigma, basado en prototipos, dinámico, con soporte para estilos de programación funcional, orientada a objetos e imperativa. Se utiliza 22

47 CAPÍTULO 4. MÉTODO DE TRABAJO principalmente en el lado del cliente, implementado como parte de un navegador web para la creación de páginas web dinámicas, aunque existen formas de javascript para el lado del servidor, como Node.js. Node.js Node.js [19] es una plataforma construida en tiempo de ejecución para desarrollar fácilmente aplicaciones de red rápidas y escalables. Node.js utiliza un modelo orientado a eventos de entrada/salida, no bloqueante, que resulta ideal para aplicaciones en tiempo real que utilizan datos de manera intensiva que se ejecutan a través de dispositivos distribuidos. Node.js es de código abierto, para el lado del servidor (aunque no solo se limita a ello), basado en el lenguaje de programación ECMAScript. En este proyecto se utiliza Node.js en el lado del servidor, recibiendo peticiones del cliente, consultando la base de datos y devolviendo la respuesta al cliente. MongoDB MongoDB [18] es un sistema de base de datos NoSQL orientado a documentos, desarrollado como código abierto. Este tipo de sistemas de base de datos, al contrario que los sistemas que usan bases de datos relacionales, no guarda los datos en tablas, si no que guarda estructuras de datos en documentos de tipo JSON (llamado BSON en MongoDB), lo que hace que la integración de datos en ciertas aplicaciones sea más fácil y rápida. Express.js Express.js [16] es un framework para Node.js, diseñado para construir aplicaciones de página única (SPA por sus siglas en ingles), aplicaciones de página múltiple y aplicaciones web híbridas. Express.js es el framework de servidor estándar de facto para Node.js. AngularJS AngularJS [21] es un framework MVC (model-view-controller) de JavaScript de código abierto para desarrollar aplicaciones SPA (Single-Page Applications o aplicaciones de página única) en el lado del cliente. 23

48 4.2 MARCO TECNOLÓGICO DE TRABAJO HTML HTML (HyperText Markup Language) es un lenguaje de marcas que se utiliza para el desarrollo de páginas en Internet. Es de formato abierto y permite ordenar y etiquetar diversos documentos dentro de una lista. HTML es un estándar a cargo de la World Wide Web Consortium (W3C) [17], organización que se dedica a la estandarización de casi todas las tecnologías ligadas a la web. Para este proyecto, se utiliza concretamente la quinta revisión de este lenguaje: HTML5 CSS CSS, o hoja de estilo en cascada, es un lenguaje para definir y crear la presentación de documentos estructurados en HTML o XML. La idea del desarrollo de CSS surgió de separar la estructura de los documentos de su presentación. Al igual que con HTML, la W3C [17] se encarga de la especificación de las hojas de estilo, entre las que se encuentra CSS, y que sirven de estándar para los navegadores. RecordRTC RecordRTC [20] es una librería de medios de grabación basada en JavaScript para navegadores web modernos. Está optimizada para diferentes dispositivos y navegadores para permitir la grabación en el lado del cliente Herramientas para la documentación EndNote EndNote [23] es una herramienta de búsqueda online que proporciona un método simple de búsqueda en bases de datos bibliográficos en la red. Se utiliza para la gestión de referencias y el manejo de listados bibliográficos y citas a la hora de escribir artículos y ensayos. Además, permite la organización de imágenes, asignando a cada imagen su propia leyenda y palabras clave. 24

49 CAPÍTULO 4. MÉTODO DE TRABAJO Gimp Gimp es una aplicación diseñada para la edición de imágenes digitales, libre y gratuita. Tiene muchas de las herramientas y filtros que se pueden encontrar en programas comerciales similares, además de algunos extras. Esta herramienta se ha utilizado para la edición de imágenes, tanto en la documentación, como en el software que se ha desarrollado. 25

50

51 CAPÍTULO 5 RESULTADOS En este capítulo se expondrán los resultados obtenidos de aplicar la metodología descrita en el capítulo 4 para el desarrollo del presente TFG. Se mostrará todo el proceso de desarrollo que se ha seguido para la obtención del sistema, desde la fase de inicio hasta su finalización, mostrando su evolución incremental y la evolución de requisitos que ha sufrido. Siguiendo la metodología que propone el Proceso Unificado de Desarrollo, se ha dividido el ciclo de vida del sistema en cuatro fases: Inicio, Elaboración, Construcción y Transición. A su vez, estas fases de han dividido en una o más iteraciones, donde intervienen la Captura de Requisitos, Análisis, Diseño, Implementación y Pruebas, en mayor o menor medida, según la fase e iteración donde se encuentre. 5.1 Fase de Inicio Debido a que esta fase no está estructurada en base a iteraciones y a que no produce resultados funcionales, la fase de inicio presenta ciertas diferencias con el resto. De este modo, se centra en la captura e identificación de requisitos, el estudio de la viabilidad del sistema y la elaboración del plan de iteraciones Captura e identificación de requisitos Para la identificación de los requisitos del sistema, se estudió la literatura existente relacionada con el tema y se extrajeron algunos requisitos funcionales que pudieran resolver o mitigar algunos de los desafíos encontrados en la literatura. 27

52 5.1 FASE DE INICIO Además de los requisitos obtenidos del estudio de la literatura, se realizaron una serie de reuniones con expertos en el tema. Se llevaron a cabo reuniones con Mario Piattini Velthuis, uno de los investigadores más importantes en ingeniería del software y profesor de la UCLM. En dichas reuniones se pudo obtener una visión sobre cómo enfocar este proyecto y se obtuvieron algunos requisitos funcionales. Requisitos funcionales La funcionalidad que la herramienta proporciona dependerá del rol que el usuario desempeñe a la hora de hacer uso de ella. Por lo tanto, en primer lugar, se identificarán los roles que los usuarios pueden desempeñar a la hora de utilizar el sistema: Alumno. Es el usuario que utilizará la herramienta para adquirir conocimientos y habilidades sobre GSD por medio de escenarios simulados, teniendo la posibilidad de consultar la puntuación obtenida, lo que le permitirá conocer su progreso. Profesor. Es el usuario que se encarga de la supervisión de los alumnos. Podrá utilizar el sistema para crear nuevos escenarios y podrá acceder a los resultados de los alumnos. A continuación se muestran los requisitos funcionales que debe cumplir el sistema: La aplicación debe permitir el registro de usuarios en el sistema. El usuario debe poder modificar los datos de su perfil si así lo desea. La aplicación simulará un chat, correo electrónico y teléfono para que el alumno tenga que trabajar con comunicación síncrona y asíncrona, por lo que la aplicación simulará la llegada de s, llamadas telefónicas y chat, en un orden aleatorio. La aplicación debe estar basada en distintos escenarios, que tendrán distintas dificultades. El jugador comenzará por el más sencillo e irá ascendiendo en el 28

53 CAPÍTULO 5. RESULTADOS nivel de dificultad. De esta forma se pretende que el estudiante adquiera conocimientos de una forma gradual. El usuario podrá repetir los escenarios. La aplicación debe permitir al profesor crear escenarios personalizados, por si quiere que el alumno practique un escenario concreto. La aplicación debe simular una serie de eventos o problemas inesperados que podrían darse en la realidad en un proyecto GSD, como que un trabajador tenga vacaciones, que sea fiesta en alguno de los países de los que un equipo de desarrollo forma parte, una caída del servidor, un malentendido por distintos niveles de inglés, etc. Estos eventos se producirán de manera aleatoria. El usuario debe poder elegir entre una lista de soluciones cada vez que ocurra un evento inesperado, las cuales tienen una mayor o menor puntuación dependiendo de lo apropiadas que sean para resolver ese problema concreto. La aplicación dispondrá de un sistema de puntos, basado en los días restantes para la entrega del software y el presupuesto disponible, de modo que una mala decisión por parte del usuario a la hora de enfrentar un evento inesperado resultará en una mayor pérdida del presupuesto y los días restantes que si la decisión seleccionada hubiese sido más apropiada. El usuario podrá consultar una ayuda cuando no sepa cómo seguir. El usuario podrá consultar su historial de puntuación. Una vez identificados los requisitos del sistema, se agruparon en diferentes grupos funcionales del sistema. En la Tabla 5.1 se muestra dicha agrupación, así como los roles que pueden hacer uso de cada uno de los requisitos. 29

54 5.1 FASE DE INICIO Grupo Funcional Requisito Funcional Rol F1: Registro Registrarse Alumno y Profesor F2: Acceso Login Logout Alumno y Profesor Alumno y Profesor F3: Gestión del Perfil Modificar Perfil Alumno y Profesor F4: Gestión de Escenarios Crear Escenario Modificar Escenario Borrar Escenario Profesor Profesor Profesor F5: Jugar Escenario Jugar Escenario Alumno F6: Leer información que manda el sistema Leer Correo Usar Chat Coger Teléfono Alumno Alumno Alumno F7: Consultar Puntuación Consultar Puntuación Alumno y Profesor F8: Repetir Escenario Repetir Escenario Alumno F9 Consultar Ayuda Consultar Ayuda Alumno Tabla 5.1: Grupos funcionales del sistema Requisitos no funcionales El sistema debe estar basado en la tecnología JavaScript. El sistema podrá ser accesible a través de la web y por lo tanto, usará una arquitectura cliente-servidor, donde el subsistema servidor procesará las peticiones enviadas por el subsistema cliente que usa el usuario. 30

55 CAPÍTULO 5. RESULTADOS El sistema dispondrá de una base de datos, en la que se almacenarán los distintos escenarios, la puntuación y la información de los distintos usuarios Modelo de Casos de Uso Una vez que se han identificado los requisitos funcionales del sistema, se modelan los diagramas de casos de uso. Al encontrarnos en la fase de inicio, los diagramas de casos de uso se han modelado con un nivel alto de abstracción. Por lo tanto, solo se muestran los grupos funcionales del sistema que se detallaron en la Tabla 5.1. En la siguiente fase de modelarán los diagramas de los casos de uso de una forma más detallada, mostrando los diferentes casos de uso que componen cada uno de estos grupos funcionales. Figura 5.1: Diagrama de casos de uso del cliente 31

56 5.1 FASE DE INICIO En la Figura 5.1 se muestra el diagrama de casos de uso del sistema cliente. Se pueden observar las funcionalidades a las que tiene acceso cada usuario dependiendo del rol que tengan (alumno o profesor) Gestión del riesgo La gestión del riesgo es un aspecto importante en el desarrollo de un proyecto. Uno de los aspectos más importantes que hubo que tener en cuenta, fue el desconocimiento de algunas de las tecnologías utilizadas para el desarrollo del proyecto, por lo que se tuvo que aprender a utilizarlas. Sin embargo, su curva de aprendizaje era rápida, por lo que no supuso un gran problema. Por otro lado, se llevó a cabo una estimación de la duración del proyecto y se comprobó que podía terminase dentro de los plazos, teniendo en cuenta los posibles retrasos Plan de iteraciones Dado que el PUD es centrado y dirigido por casos de uso, se utiliza el diagrama de casos que representa los grupos funcionales de alto nivel para poder crear una primera versión del plan de proyecto (o plan de iteraciones) y llevar a cabo el desarrollo de dichos grupos funcionales en las iteraciones de las fases posteriores. De este modo, se obtienen las iteraciones mostradas en la Tabla 5.2. Fase Iteración Objetivos Inicio Elaboración Preliminar 1 2 Realizar un estudio del sistema a desarrollar, capturando e identificando sus requisitos funcionales Validar el estudio del sistema e identificar posibles nuevos requisitos, modelando los requisitos del sistema con mayor detalle y realizando la definición de su arquitectura. Analizar e identificar los objetos de dominio y de persistencia que forman parte del sistema 32

57 CAPÍTULO 5. RESULTADOS Fase Iteración Objetivos Construcción Análisis, diseño, implementación y pruebas de los casos de uso del grupo funcional F1 y F2 Análisis, diseño, implementación y pruebas de los casos de uso del grupo funcional F3 Análisis, diseño, implementación y pruebas de los casos de uso del grupo funcional F4 y F5 Análisis, diseño, implementación y pruebas de los casos de uso del grupo funcional F6 y F7 Análisis, diseño, implementación y pruebas de los casos de uso del grupo funcional F8 y F9 Transición 8 Obtener el entregable del sistema, así como su documentación y manuales de usuario. Tabla 5.2: Plan de iteraciones 5.2 Fase de Elaboración La fase de elaboración consta de dos iteraciones que se centran principalmente en el análisis y el modelado del sistema. La primera iteración se centra en la revisión de los requisitos identificados y en realizar un análisis para comprobar si existen nuevos requisitos que no fueron identificados en la fase de inicio. También se centra en el modelado de los requisitos a través de la elaboración de casos de uso de una manera más detallada que los realizados en la fase anterior. En la segunda iteración, se analizan e identifican los objetos de dominio que forman parte del sistema, a partir de los casos de uso elaborados en la primera iteración. En esta fase también se abordan cuestiones de implementación, aunque la mayor parte se verá en la fase de construcción. 33

58 5.2 FASE DE ELABORACIÓN Iteración 1 En esta iteración nos centraremos en la identificación de nuevos requisitos, en la elaboración de un modelo de casos de uso más detallado, revisar y mejorar el plan de iteraciones y definir y diseñar la arquitectura del proyecto. Identificación de requisitos Tras terminar la fase de inicio y haber obtenido un primer modelo de casos de uso con una serie de requisitos, se llevó a cabo una serie de reuniones, para revisar la planificación del proyecto e identificar nuevos requisitos funcionales, si fuese necesario. En estas reuniones, se determinó que se debía especificar más concretamente en qué consistía la creación y edición de escenarios y se obtuvieron un conjunto de requisitos funcionales que se exponen a continuación: Editar las propiedades del escenario. Se debe permitir la modificación de los atributos del escenario, como lo son el título, el presupuesto y los países involucrados. Añadir módulo. Un módulo es cada una de las partes en las que se divide un proyecto dentro del escenario. Se debe permitir la creación y adición de los módulos que componen el escenario. Los módulos se componen de su nombre y del porcentaje que ocupan dentro del escenario. Añadir problema. Se debe permitir la adición de problemas en el escenario por parte del profesor. Se trata de problemas que podrían suceder en el Desarrollo Global del Software y que tiene una serie de soluciones entre las que el alumno deberá elegir durante la simulación del escenario. Añadir llamada. El profesor debe tener la oportunidad de crear llamadas mediante la grabación de audio a través de un micrófono conectado al equipo. Estás podrán ser reproducidas por el alumno durante la simulación del escenario. Añadir chat. El profesor podrá añadir chats simulados a un proyecto. 34

59 CAPÍTULO 5. RESULTADOS En cuanto al grupo funcional F6, conviene especificar de una mejor forma en qué consisten cada uno de sus requisitos. A continuación se explican de una forma más detallada los requisitos funcionales de dicho grupo funcional: Leer correo. El alumno debe poder acceder al contenido de los correos electrónicos que llegan de forma simulada y que contienen información sobre el estado de la partida o los problemas que van surgiendo. Debido a que los correos se almacenarán en una bandeja de entrada, habría que añadir dos nuevos requisitos funcionales: Acceder a la bandeja de entrada y Eliminar correo. Usar chat. El alumno podrá escribir a través del sistema de chat, el cual mantendrá una conversación simulada con el alumno. Coger teléfono. El alumno podrá reproducir las llamadas que se producen de manera aleatoria. Del mismo modo, el alumno debe poder grabar una contestación por medio de un micrófono en su dispositivo. Dado que además de reproducir la llamada, el alumno puede grabar una contestación, un nombre más apropiado para este requisito funcional sería Usar teléfono. Dado que este grupo funcional se lleva a cabo al jugar en un escenario, los casos de uso de este grupo funcional han sido incluidos dentro del grupo funcional Jugar escenario y el nombre del caso de uso Jugar escenario se ha cambiado por Interactuar con el escenario. Además, es necesario que se guarde el resultado del escenario al terminarlo. Se ha cambiado el nombre del grupo funcional Consultar Puntuación por Consultar Resultado, ya que los datos obtenidos por este grupo funcional contienen otra información además de la puntuación. Con respecto al grupo funcional F9: Consultar ayuda, hay que tener en cuenta que la ayuda se podrá consultar al jugar un escenario, por lo que este caso de uso se introduce en el grupo funcional Jugar escenario. Del mismo modo, el grupo funcional F8: Repetir escenario, también ha sido incluido en el grupo funcional F5. Una vez obtenidos estos nuevos requisitos, se han actualizado los grupos funcionales obtenidos durante la fase de inicio (Véase Tabla 5.3). 35

60 5.2 FASE DE ELABORACIÓN Grupo Funcional Requisito Funcional Rol F1: Registro Registrarse Alumno y Profesor F2: Acceso Login Logout Alumno y Profesor Alumno y Profesor F3: Gestión del Perfil Modificar Perfil Alumno y Profesor F4: Gestión de Escenarios F5: Jugar Escenario Crear Escenario Modificar Escenario Borrar Escenario Añadir módulo Añadir problema Añadir llamada Añadir chat Interactuar con el escenario Acceder a la bandeja de entrada Leer Correo Eliminar correo Usar Chat Usar Teléfono Obtener Problema Consultar Ayuda Guardar Resultado Repetir Escenario Profesor Profesor Profesor Profesor Profesor Profesor Profesor Alumno Alumno Alumno Alumno Alumno Alumno Alumno Alumno Alumno Alumno F6: Consultar Resultado Consultar Resultado Alumno y Profesor Tabla 5.3: Grupos funcionales del sistema 36

61 CAPÍTULO 5. RESULTADOS Modelo de casos de uso Una vez identificados y modelados los nuevos requisitos, obteniendo los diagramas de casos de uso de alto nivel actualizados, se profundiza y aumenta el detalle en los diagramas de casos de uso, representando, para cada grupo funcional del sistema, el conjunto de casos de uso que modelan los requisitos que se engloban en dicho grupo, como se ha detallado en la Tabla 5.3. En la Figura 5.2 se observa el diagrama de casos de uso para el subsistema cliente. Figura 5.2: Diagrama de casos de uso del cliente Grupo funcional F1: Registro En la Figura 5.3 se muestran los casos de uso que forman parte del grupo funcional F1: Registro del subsistema cliente. 37

62 5.2 FASE DE ELABORACIÓN Figura 5.3: Diagrama de caso de uso Registro (Cliente) En la Figura 5.4 se pueden observar los casos de uso del servidor que están relacionados con el grupo funcional F1: Registro. Como se puede ver, se encarga de almacenar la información del usuario en la base de datos. Figura 5.4: Diagrama de caso de uso Registro (Servidor) Grupo funcional F2: Acceso La Figura 5.5 se muestran los casos de uso que forman parte del grupo funcional F2: Acceso del subsistema cliente. 38

63 CAPÍTULO 5. RESULTADOS Figura 5.5: Diagrama de caso de uso Acceso (Cliente) En la Figura 5.6 se muestran los casos de uso que forman parte del grupo funcional F2: Acceso del subsistema servidor. Figura 5.6: Diagrama de caso de uso Acceso (Servidor) Grupo funcional F3: Gestión del Perfil En la Figura 5.7 se muestran los casos de uso que forman parte del grupo funcional F3: Gestión del Perfil del subsistema cliente. 39

64 5.2 FASE DE ELABORACIÓN Figura 5.7: Diagrama de caso de uso Gestión del Perfil (Cliente) En la Figura 5.8 se muestran los casos de uso que forman parte del grupo funcional F3: Gestión del Perfil del subsistema servidor. Como se puede observar, se encarga de guardar los cambios realizados en el perfil del usuario en la base de datos. Figura 5.8: Diagrama de caso de uso Gestión del Perfil (Servidor) 40

65 CAPÍTULO 5. RESULTADOS Grupo funcional F4: Gestión de Escenarios En la Figura 5.9 se muestran los casos de uso que forman parte del grupo funcional F4: Gestión de Escenarios del subsistema cliente. Figura 5.9: Diagrama de caso de uso Gestión de Escenarios (Cliente) En la Figura 5.10 se muestran los casos de uso que forman parte del grupo funcional F4: Gestión de Escenarios del subsistema servidor. Como se puede observar, los casos de uso se centran en almacenar o eliminar datos de la base de datos, según las peticiones del cliente. 41

66 5.2 FASE DE ELABORACIÓN Figura 5.10: Diagrama de caso de uso Gestión de Escenarios (Servidor) Grupo funcional F5: Jugar Escenario En la Figura 5.11 se muestran los casos de uso que forman parte del grupo funcional F5: Jugar Escenario del subsistema cliente. En la Figura 5.12 se muestran los casos de uso que forman parte del grupo funcional F5: Jugar Escenario del subsistema servidor. Este diagrama está formado por cuatro casos de uso que realizan una consulta en la base de datos, Cargar escenario, Cargar llamadas, Cargar Problemas y Cargar Chats, y de un caso de uso que almacena información en la base de datos, Almacenar resultado. 42

67 CAPÍTULO 5. RESULTADOS Figura 5.11: Diagrama de caso de uso Jugar Escenario (Cliente) 43

68 5.2 FASE DE ELABORACIÓN Figura 5.12: Diagrama de caso de uso Jugar Escenario (Servidor) Grupo funcional F6: Consultar resultado En la Figura 5.13 se muestran los casos de uso que forman parte del grupo funcional F6: Consultar resultado del subsistema cliente. Figura 5.13: Diagrama de caso de uso Consultar Resultado (Cliente) 44

69 CAPÍTULO 5. RESULTADOS La Figura 5.14 se muestran los casos de uso que forman parte del grupo funcional F6: Consultar resultado del subsistema servidor. Figura 5.14: Diagrama de caso de uso Consultar Resultado (Servidor) Plan de iteraciones Después de identificar los nuevos requisitos, se lleva a cabo una revisión del plan de iteraciones elaborado en la fase anterior. Se ha realizado una planificación más detallada en la cual se muestra el desglose del proyecto. Este desglose ha sido exportado MS Project 2013 y se ha generado el diagrama de Gantt que se muestra en la Figura Fase de Inicio Captura e identificación de requisitos Modelo de casos de uso Gestión del riesgo Plan de iteraciones Fase de elaboración o Iteración 1 Identificación de requisitos Modelado de casos de uso 45

70 5.2 FASE DE ELABORACIÓN Diseño de la arquitectura o Iteración 2 Diseño del diagrama de clases de dominio Diseño de la base de datos Fase de construcción o Iteración 3 Se realiza el análisis, diseño, implementación y pruebas de los siguientes casos de uso: Registrarse Iniciar sesión Cerrar sesión Almacenar usuario o Iteración 4 Se realiza el análisis, diseño, implementación y pruebas de los siguientes casos de uso: Modificar perfil Crear escenario Modificar escenario Borrar escenario Añadir módulo Añadir problema (cliente) Añadir llamada (cliente) Añadir chat (cliente) Actualizar perfil Almacenar escenario Eliminar escenario Añadir problema Añadir llamada Añadir chat o Iteración 5 Se realiza el análisis, diseño, implementación y pruebas de los siguientes casos de uso: Acceder a la bandeja de entrada 46

71 CAPÍTULO 5. RESULTADOS Leer correo Eliminar correo Usar chat Usar teléfono Obtener problema Consultar ayuda Interactuar con el escenario Guardar resultado Cargar escenario Cargar llamadas Cargar chats Almacenar resultado o Iteración 6 Se realiza el análisis, diseño, implementación y pruebas de los siguientes casos de uso: Consultar resultado Obtener resultado Fase de transición o Iteración 7 Pruebas finales Manual de usuario 47

72 5.2 FASE DE ELABORACIÓN Figura 5.15: Diagrama de Gantt del plan del proyecto 48

73 CAPÍTULO 5. RESULTADOS Arquitectura del sistema Al finalizar esta primera iteración de la fase de elaboración se define la arquitectura del sistema. -Arquitectura cliente-servidor Como se comentó en la identificación de los requisitos no funcionales en la fase de inicio, el sistema será accesible a través de la web y por lo tanto, seguirá una arquitectura clienteservidor, donde el subsistema servidor procesará las peticiones enviadas por el subsistema cliente que el usuario esté utilizando y mandará la respuesta a este. Utilizando este enfoque de sistema distribuido siguiendo la arquitectura cliente servidor obtenemos algunos beneficios. Uno de ellos es la centralización del control, ya que la lógica de dominio y control se encuentra en el servidor, haciendo que el sistema cliente sea independiente del servidor. Al tener la aplicación separada en dos partes, proporciona una forma de crear una aplicación escalable y además, permite que sea fácil de mantener, pudiendo realizar modificaciones en el servidor sin que los clientes se vean afectados por ello. En cuanto a la comunicación entre el cliente y el servidor, el sistema utiliza una REST (Representational State Transfer), un estilo de arquitectura para sistemas hipermedia distribuidos como la Word Wide Web. El sistema se comunica a través del Protocolo de Transferencia de Hipertexto con los métodos HTTP (GET, POST, PUT, DELETE, etc.), utilizados por los navegadores web para recuperar páginas web y enviar datos al servidor. -Arquitectura multicapa Se utiliza una arquitectura multicapa para la implementación de los sistemas cliente y servidor, permitiendo aislar la capa de presentación de la lógica del dominio y esta última de la capa de persistencia. A continuación se describen estas tres capas: Presentación. En esta capa se hace una presentación de los datos del modelo, proporcionando la interfaz con la que el usuario se comunica con la aplicación. Dominio. Actúa como intermediario entre la capa de presentación y de persistencia. Se encarga del procesamiento de los datos, recibiendo peticiones y 49

74 5.2 FASE DE ELABORACIÓN devolviendo resultados a la capa de presentación, y accediendo y modificando los datos almacenados en la capa de persistencia. Persistencia. Esta capa contiene una representación de los datos que maneja el sistema. Los datos que se representan en el modelo de dominio se almacenan en la base de datos. Utilizando este enfoque multicapa, se sigue el principio de mínimo acoplamiento y máxima cohesión, desacoplando los elementos de una capa a otra. De esta forma, se facilita el mantenimiento y la extensibilidad del sistema, de modo que si se realiza algún cambio en una de las capas, las demás no se verán afectadas. En la Figura 5.16 se muestra la representación de la arquitectura del sistema. Figura 5.16: Arquitectura del sistema Iteración 2 Tras finalizar la iteración anterior, se realizó otra reunión de seguimiento para revisar y validar los artefactos obtenidos. En esta reunión ya no se identificaron más requisitos y se validó el plan de iteraciones definitivo y el resto de artefactos obtenidos, por lo que en posteriores iteraciones se comienza a desarrollar los casos de uso identificados, utilizando como entrada el modelo de casos de uso y la arquitectura que se definió en la iteración anterior. 50

75 CAPÍTULO 5. RESULTADOS Por lo tanto, esta iteración se centrará en: Análisis e identificación de los objetos de dominio que forman parte del sistema. Diseño de la base de datos. Modelo de dominio Se realiza un análisis de los modelos de dominio del sistema y las relaciones que hay entre ellos. Estos modelos se irán detallando y refinando en las posteriores iteraciones que forman parte de la fase de construcción. De este modo, según los requisitos que se obtuvieron en la fase de inicio, se obtienen los siguientes modelos: Proyecto (Project). Modela el proyecto o escenario que se va a simular. Los atributos que contiene son el nombre, la duración, el presupuesto, los módulos que lo componen y los países que intervienen. Usuario (User). Representa al usuario alumno, que simulará los escenarios, o al usuario profesor, que puede gestionarlos y ver los resultados de un alumno. Un usuario está definido por su nombre, país, , su nombre de usuario y el rol que desempeña (alumno o profesor). Empleado (Employee). Modela las características de los empleados virtuales. Los empleados se caracterizan por nombre, país, rol, salario, dirección , eficiencia, experiencia y una foto que lo representa. País (Country). Representa las características de los países. Un país se define por su nombre, hora de comienzo de la jornada laboral y hora de finalización y su diferencia horaria con el meridiano de Greenwich. Problema (Problem). Representa los problemas que se dan durante la simulación de un proyecto o escenario. Un problema se tiene de una descripción y de un conjunto de posibles soluciones. 51

76 5.2 FASE DE ELABORACIÓN Solución (Solution). Modela las posibles soluciones de un problema. Una solución se compone de una descripción y la puntuación y presupuesto que se obtiene si se elige dicha solución. Sonido (Sound). Modela el audio utilizado en la simulación de las llamadas. Un sonido contiene una descripción, una referencia al usuario que ha realizado la grabación, una referencia a otro sonido, que simularía la respuesta (si la hubiese) y un buffer que contiene los datos del propio sonido. Chat. Modela las conversaciones de chat que se simulan durante una partida. Un chat contiene un nombre, una descripción, el nombre de la persona con la que se simulará el chat, un ID que referencia al usuario que creó el chat y el conjunto de fases en las que se divide. Resultado (Result). Almacena la información de los resultados obtenidos durante la simulación del escenario. Contiene el ID del alumno que ha realizado la simulación y los datos de una partida. Por lo tanto, se ha modelado y diseñado una base de datos para que los objetos de dominio puedan ser persistentes. En la Figura 5.17 se puede observar el esquema entidadrelación que representa la base de datos. 52

77 CAPÍTULO 5. RESULTADOS Figura 5.17: Esquema entidad-relación de la base de datos 53

78 5.3 FASE DE CONSTRUCCIÓN 5.3 Fase de Construcción Durante esta fase, las etapas que toman mayor relevancia son las de diseño, implementación y pruebas, aunque también se realizan tareas de análisis en cada iteración. Para las iteraciones de esta fase, se realizará el análisis, diseño, implementación y pruebas de los grupos funcionales que se planificaron y que pueden ser consultados en la Tabla Iteración 3 En esta iteración se abordan los casos de uso de los grupos funcionales F1: Registro y F2: Acceso. Hay que tener en cuenta que para desarrollar la aplicación se ha usado Yeoman generator, un generador que proporciona una pila de desarrollo de código abierto, con herramientas y frameworks destinados a que los desarrolladores puedan construir las aplicaciones web de una forma más rápida. Este generador, además de generar una estructura de directorios fácil de mantener, también nos proporciona el registro y el acceso de usuarios de una forma sencilla. A continuación se explica cómo se lleva a cabo el registro y el acceso de usuarios en el sistema. Grupo funcional F1: Registro En esta sección se llevará a cabo el análisis de casos de uso del grupo funcional F1, el diseño de la funcionalidad relativa al registro en el sistema, la implementación de dicha funcionalidad y el diseño e implementación de pruebas Análisis de casos de uso Al principio de esta iteración, se llevó a cabo una reunión con expertos para diseñar la interfaz del formulario que permitiese el registro de usuarios. En dicha reunión se presentó un boceto sobre cómo sería dicha interfaz (véase Figura 5.18). 54

79 CAPÍTULO 5. RESULTADOS Figura 5.18: Boceto de la interfaz de registro Diseño Una vez que se ha realizado el análisis de los casos de uso de este grupo funcional, se modelan los diagramas de secuencia para mostrar cómo funciona. En el primero, se muestra el proceso en el sistema cliente (Figura 5.19). Una vez que el usuario ha modificado los datos y hecho click en el botón Sign up, se manda un evento al controlador authenticationcontroller, el cual envía una petición de inserción al servidor. 55

80 5.3 FASE DE CONSTRUCCIÓN Figura 5.19: Diagrama de secuencia del Grupo funcional F1 (Cliente) La Figura 5.20 muestra como el servidor trata la petición de crear un usuario. Se puede ver que el controlador AuthenticationController recibe una petición de inserción con los datos del usuario y se encarga de su almacenamiento en la base de datos. Figura 5.20: Diagrama de secuencia del Grupo funcional F1 (Servidor) 56

81 CAPÍTULO 5. RESULTADOS Implementación Como se comentó en el diseño de la arquitectura del sistema durante la fase de elaboración, el cliente y el servidor se comunican mediante el Protocolo de Transferencia de Hipertexto, utilizando los métodos HTTP (GET, POST, PUT, DELETE, etc.). En el Listado 5.1 se muestra la función del sistema cliente que permite el registro de un nuevo usuario y donde se puede ver un ejemplo de cómo el sistema cliente se comunica con el servidor a través de un método POST. $scope.signup = function() { if ($scope.credentials.password!== $scope.credentials.confirmpassword){ $scope.error = 'Passwords must match'; } else { $scope.error = ''; $http.post('/auth/signup',$scope.credentials).success(function(response){ // If successful we assign the response to the global user model $scope.authentication.user = response; }; } // And redirect to the index page $location.path('/'); }).error(function(response) { $scope.error = response.message; }); Listado 5.1: Función signup que permite el registro de un usuario (Cliente) En primer lugar, se comprueba que la contraseña y la confirmación de la contraseña coinciden, en cuyo caso, el sistema cliente realiza una petición POST al servidor, enviando los datos del nuevo usuario (variable $scope.credentials). Pruebas Para realizar las pruebas se ha utilizado Jasmine, un framework para el testing de código JavaScript. Las pruebas que se han realizado se centran en garantizar que los nuevos usuarios se registran correctamente. A continuación se muestra el código para comprobar que se produce un error al intentar almacenar un usuario por segunda vez y también si a un usuario le falta el campo firstname. 57

82 5.3 FASE DE CONSTRUCCIÓN it('will fail to save an existing user again', function(done) { user.save(); return user2.save(function(err) { should.exist(err); done(); }); }); it('will show an error when try to save without first name', function(done) { user.firstname = ''; return user.save(function(err) { should.exist(err); done(); }); }); Listado 5.2: Pruebas unitarias para el correcto registro de usuarios Grupo funcional F2: Acceso En esta sección se llevará a cabo el análisis de casos de uso del grupo funcional F2, el diseño de la funcionalidad relativa al acceso al sistema, la implementación de dicha funcionalidad y el diseño e implementación de pruebas Análisis de casos de uso Al igual que en la fase de análisis del anterior grupo funcional, se llevó a cabo una reunión para diseñar la interfaz que permitiese el acceso al sistema. En la reunión se presentó un boceto sobre cómo sería dicha interfaz (véase Figura 5.21). Figura 5.21: Boceto pantalla de acceso 58

83 CAPÍTULO 5. RESULTADOS Como se puede ver, para acceder al sistema es necesario el Username y el Password. Además, se decide incorporar un link a la página de registro. Diseño Una vez que se ha realizado el análisis de los casos de uso de este grupo funcional, se modelan los diagramas de secuencia para mostrar cómo funciona. En el primer diagrama (Figura 5.22), se muestra el proceso en el sistema cliente. Cuando el usuario ha introducido sus datos de acceso y ha hecho click en el botón Sign in, se manda un evento al controlador authenticationcontroller, que envía una petición al servidor. Tras recibir la respuesta del servidor, se asigna el usuario devuelto por este y se produce una redirección a la página de proyectos. Figura 5.22: Diagrama de secuencia del Grupo funcional F2 (Cliente) La Figura 5.23 muestra el flujo que sigue la parte del servidor para realizar el login. Como muestra la imagen, la petición es manejada por el controlador 59

84 5.3 FASE DE CONSTRUCCIÓN UsersAuthenticationController. A continuación se carga el usuario y se comprueba que el password introducido es correcto, en cuyo caso se devuelve el usuario al sistema cliente. Figura 5.23: Diagrama de secuencia del Grupo funcional F2 (Servidor) Implementación A continuación se muestra el código que permite llevar a cabo el login de un usuario. En el Listado 5.3 se muestra cómo el sistema cliente lleva a cabo esta funcionalidad. Como puede verse, la función sigin del controlador authenticationcontroller, realiza una petición POST al servidor, enviando el nombre de usuario y la contraseña, que se encuentran en la variable $scope.credentials. $scope.signin = function() { $http.post('/auth/signin', $scope.credentials).success(function(response) { // If successful we assign the response to the global user model $scope.authentication.user = response; }; // And redirect to the index page $location.path('/projects'); }).error(function(response) { $scope.error = response.message; }); Listado 5.3: Función signin que permite el acceso de un usuario (Cliente) 60

85 CAPÍTULO 5. RESULTADOS El Listado 5.4 muestra cómo el servidor maneja esta petición. Para comprobar el acceso, el sistema hace uso de passport.js, un middleware de autenticación para Nodejs. En este caso, passport utiliza una estrategia local, que permite la autenticación de usuarios mediante los datos de la base de datos de la aplicación. Si el usuario se autentifica correctamente, se realiza una llamada a req.login, que establece una sesión y manda el usuario como respuesta. exports.signin = function(req, res, next) { passport.authenticate('local', function(err, user, info) { if (err!user) { res.status(400).send(info); } else { // Remove sensitive data before login user.password = undefined; user.salt = undefined; }; req.login(user, function(err) { if (err) { res.status(400).send(err); } else { res.json(user); } }); } })(req, res, next); Listado 5.4: Función signin que permite el acceso de un usuario (Servidor) Pruebas Para este grupo funcional, se han realizado pruebas para comprobar que los usuarios acceden al sistema de manera correcta. A continuación se muestran dos casos de prueba: uno en la que un usuario accede al sistema de manera correcta y otro en el que se produce un error porque el usuario no existe. 61

86 5.3 FASE DE CONSTRUCCIÓN it('$scope.signin() should fail to log in with wrong credentials', function() { // Foo/Bar combo assumed to not exist scope.authentication.user = 'Foo'; scope.credentials = 'Bar'; // Test expected POST request $httpbackend.expectpost('/auth/signin').respond(400, { 'message': 'Unknown user' }); scope.signin(); $httpbackend.flush(); }); // Test scope value expect(scope.error).toequal('unknown user'); it('$scope.signup() should register with correct data', function() { // Test expected POST request scope.authentication.user = 'Fred'; $httpbackend.when('post', '/auth/signup').respond(200, 'Fred'); scope.signup(); $httpbackend.flush(); }); // test scope value expect(scope.authentication.user).tobe('fred'); expect(scope.error).toequal(undefined); expect($location.url()).tobe('/'); Listado 5.5: Pruebas unitarias para el correcto acceso a sistema Iteración 4 En esta iteración se abordan los casos de uso de los grupos funcionales F3: Gestión del Perfil y F4: Gestión de Escenarios. Grupo funcional F3: Gestión del Perfil En esta sección se llevará a cabo el análisis de casos de uso del grupo funcional F3, el diseño de la funcionalidad relativa a la modificación del perfil de usuario, la implementación de dicha funcionalidad y el diseño e implementación de pruebas. 62

87 CAPÍTULO 5. RESULTADOS Análisis de casos de uso Al principio de esta iteración, se llevó a cabo una reunión con expertos para determinar qué características de usuario sería necesario que tuviesen la posibilidad de modificarse. Como resultado de la reunión se estableció que los atributos que podrían modificarse serían: el nombre, el nombre de usuario, y la contraseña. Este grupo funcional se compone de dos casos de uso: Modificar perfil en el subsistema cliente y Actualizar perfil en el subsistema servidor. Diseño Una vez que se ha realizado el análisis de los casos de uso de este grupo funcional, se modelan los diagramas de secuencia para mostrar cómo funciona este grupo funcional. En la Figura 5.24 se muestra el diagrama de secuencia del grupo funcional F3: Gestión del Perfil para del lado del cliente. Una vez que el usuario ha modificado los datos y hecho click en el botón update, se manda un evento al controlador SettingsController, el cual envía una petición de actualización al servidor. Figura 5.24: Diagrama de secuencia del Grupo funcional F3 (Cliente) 63

88 5.3 FASE DE CONSTRUCCIÓN En la Figura 5.25 se muestra el proceso en el lado del servidor. Como se puede ver, el servidor trata la petición de actualizar un usuario. El controlador UserProfileController recibe una petición de actualización con los datos del usuario y se encarga de almacenarlo en la base de datos. Figura 5.25: Diagrama de secuencia del Grupo funcional F3 (Servidor) Implementación A continuación se muestra el fragmento de código que permite enviar una petición al servidor para actualizar la contraseña del usuario. // Change user password $scope.changeuserpassword = function() { $scope.success = $scope.error = null; }; $http.post('/users/password', $scope.passworddetails).success(function(response) { // If successful show success message and clear form $scope.success = true; $scope.passworddetails = null; }).error(function(response) { $scope.error = response.message; }); Listado 5.6: Función changeuserpassword Se puede observar cómo se hace uso del método post para mandar una petición de actualización al servidor. 64

89 CAPÍTULO 5. RESULTADOS Pruebas Las pruebas realizadas para este grupo funcional se centran en la correcta actualización de los datos de un usuario. El siguiente listado de código muestra los casos de prueba para testear el correcto comportamiento de la función $scope.changeuserpassword(). En el primer caso de prueba, el usuario cambia su password correctamente y en el segundo, se obtiene un error en la respuesta. it('$scope.changeuserpassword() should update a correct user without errors', function() { $httpbackend.when('post', '/users/password').respond(200, { 'message': 'Password changed successfully' }); scope.changeuserpassword(); $httpbackend.flush(); // Test scope value expect(scope.success).tobe(true); }); it('$scope.changeuserpassword() should fail when passwords do not match', function() { $httpbackend.when('post', '/users/password').respond(400, { 'message': 'Passwords do not match' }); scope.changeuserpassword(); $httpbackend.flush(); // Test scope value expect(scope.error).toequal('passwords do not match'); }); Listado 5.7: Pruebas unitarias para cambiar el password Grupo funcional F4: Gestión de Escenarios En esta sección se llevará a cabo el análisis de casos de uso del grupo funcional F4, el diseño de las funcionalidades relativas a la creación, modificación, eliminación de proyectos (escenarios), así como las relativas a la creación y adición de módulos, 65

90 5.3 FASE DE CONSTRUCCIÓN problemas, llamadas y chats, la implementación de dichas funcionalidades y el diseño e implementación de pruebas. Análisis de casos de uso Durante el análisis de este grupo funcional, se produce un cambio en los requisitos de la aplicación, ya que el alumno, en lugar de ir superando niveles que van aumentando de dificultad, este podrá jugar en los escenarios definidos por el profesor, dependiendo la dificultad de estos escenarios de las características que el profesor les haya añadido al crearlos. Al principio de esta iteración, se llevó a cabo una reunión con el cliente para determinar cómo sería la interfaz del editor de proyectos. Se presentó un boceto sobre cómo sería dicha interfaz (véase Figura 5.26). Figura 5.26: Boceto de la interfaz de editor de proyecto 66

91 CAPÍTULO 5. RESULTADOS Diseño Al igual que en los casos anteriores, se han modelado los diagramas de secuencia para mostrar cómo funciona el sistema. Se ha elegido mostrar el proceso en el cual se guarda un proyecto. En el primer diagrama (Figura 5.27), se muestra el proceso en el sistema cliente. Una vez que el usuario ha creado el proyecto y hecho click en el botón create, se manda un evento al controlador ProjectsController, el cual envía una petición de inserción al servidor. Figura 5.27: Diagrama de secuencia para crear un proyecto (Cliente) La Figura 5.28 muestra cómo el servidor trata la petición de actualización de un usuario. Como puede verse, el controlador UserProfileController recibe una petición de actualización con los datos del usuario y se encarga de almacenarlo en la base de datos. 67

92 5.3 FASE DE CONSTRUCCIÓN Figura 5.28: Diagrama de secuencia para crear un proyecto (Servidor) Implementación A continuación se explican algunos aspectos relevantes a la hora de realizar la implementación de la funcionalidad asociada con la creación de un proyecto. A la hora de crear y añadir un módulo para el proyecto, hay que tener en cuenta que un módulo no es un modelo persistente, sino que se ha implementado como un objeto que contiene los atributos name y percentage, que representa el porcentaje que ocupa ese módulo en el proyecto. Por tanto, un proyecto contiene un array con estos objetos. El Listado 5.8 muestra el fragmento de código que permite la creación de un proyecto. Como se puede observar, en primer lugar se crea un nuevo objeto Projects, asignando a cada uno de sus atributos los datos obtenidos mediante un formulario, a excepción de los atributos problems, calls, chats, modules y numbermodules. Los atributos problems, calls y chats son arrays que almacenan los IDs de los problemas, llamadas y chats asociados, respectivamente. El atributo modules contiene un array con los objetos que representan los módulos del proyecto y numbermodules es el número de módulos. A continuación, se ejecuta $save(), que realiza una petición de inserción al servidor y se limpian los campos del formulario. 68

93 CAPÍTULO 5. RESULTADOS // Create new Project object var project = new Projects ({ name: this.name, countries: this.countries, budget: this.budget, delivery: projectdelivery, time: this.time, problems: this.addedproblemsid, calls: this.addedcallsid, chats: this.addedchatsid, numbermodules: modulenumber, modules: this.modulelist }); // Redirect after save project.$save(function(response) { $location.path('projects/' + response._id); } // Clear form fields $scope.name = ''; $scope.countries = []; $scope.budget = ''; $scope.delivery = ''; $scope.addedproblems = []; $scope.addedproblemsid = []; $scope.addedcalls = []; $scope.addedcallsid = []; $scope.addedchats = []; $scope.addedchatsid = []; $scope.modulelist = []; Listado 5.8: Fragmento de código para la creación un proyecto Pruebas Las pruebas que se han realizado se han centrado en comprobar la correcta creación, actualización y eliminación de escenarios. El siguiente listado de código contiene pruebas unitarias para testear el funcionamiento del modelo Project de la base de datos. En el primer caso, se comprueba que es posible almacenar un proyecto siempre que contenga todos los atributos necesarios del modelo. En el segundo caso, se comprueba que se produce un error al intentar almacenar un proyecto sin un nombre. 69

94 5.3 FASE DE CONSTRUCCIÓN it('should be able to save without problems', function(done){ return project.save(function(err) { should.not.exist(err); done(); }); }); it('should be able to show an error when try to save without name', function(done) { project.name = ''; return project.save(function(err) { should.exist(err); done(); }); }); Listado 5.9: Pruebas unitarias para el modelo Projects Iteración 5 En esta iteración se abordan los casos de uso del grupo funcional F5: Jugar Escenario. Grupo funcional F5: Jugar Escenario En esta sección se llevará a cabo el análisis de casos de uso del grupo funcional F5, el diseño de las funcionalidades relativas a la carga de un escenario, la carga y creación de llamadas telefónicas simuladas, la gestión del correo electrónico, el uso del chat, la carga de problemas, la consulta de ayuda y el almacenamiento de los resultados, la implementación de dichas funcionalidades y el diseño e implementación de pruebas. Análisis de casos de uso Al principio de esta iteración, se llevó a cabo una reunión para determinar cómo sería la interfaz al jugar un determinado escenario (proyecto). En dicha reunión se presentó un boceto sobre cómo sería dicha interfaz (véase Figura 5.29). 70

95 CAPÍTULO 5. RESULTADOS Figura 5.29: Boceto de la interfaz del juego Como se puede ver en la imagen, la interfaz se divide en tres columnas. Las columnas laterales contienen información y posibles acciones para interactuar con el juego. En la columna central se mostrará la información y acciones que se estén ejecutando en cada momento. Además esta columna cuenta con los botones de teléfono, chat y correo. Durante una partida, la mayor parte de la funcionalidad se llevará a cabo en la parte del cliente, a excepción de la carga de escenarios, llamadas, problemas, chats, la creación de llamadas y el almacenamiento de resultados. Diseño Tras realizar el análisis de los casos de uso de este grupo funcional, se modelan algunos diagramas de secuencia para mostrar cómo funciona. Uno de los aspectos más importantes en este grupo funcional es la obtención de una llamada y la grabación de una respuesta, por lo que se ha elegido este caso para mostrar su funcionamiento. A continuación se muestran los diagramas de secuencia que representan esta funcionalidad. En el primer diagrama (Figura 5.30), se muestra el proceso del sistema cliente. En primer lugar, se manda una petición al servidor para obtener las llamadas que se incluyen en el proyecto. A continuación, el sistema obtiene una llamada aleatoria, que el usuario puede reproducir. El 71

96 5.3 FASE DE CONSTRUCCIÓN usuario puede grabar una llamada mediante los botones Start y Stop, para comenzar y parar la grabación, respectivamente. Por último, al hacer click en el botón Accept, se realiza una petición al servidor para guardar la respuesta en la base de datos. Figura 5.30: Diagrama de secuencia para simular una llamada (Cliente) En el lado del servidor (Figura 5.31), se muestra como este maneja las distintas peticiones recibidas por el cliente. El controlador SoundsServerController es el que se encarga de dichas peticiones. En primer lugar, devuelve la lista de llamadas de un proyecto y, cuando el usuario graba una respuesta, se encarga de realizar una petición a la base de datos para almacenarla. 72

97 CAPÍTULO 5. RESULTADOS Figura 5.31: Diagrama de secuencia para simular una llamada (Servidor) Implementación Para permitir la grabación de audio por medio de un micrófono se ha usado la librería RecordRTC, que facilita el proceso tanto para la grabación de video, como para la grabación de audio. En el caso de la simulación de llamadas, solo es necesaria la grabación de audio. El Listado 5.10 muestra las funciones para comenzar y parar la grabación de audio. En la función start_recording se realiza una llamada a getusermedia(), de forma que se pedirá permiso al usuario para usar el micrófono. Si el usuario concede permiso, se crea un objeto RecordRTC y la grabación comienza. Cuando se ejecuta la función stop_recording(), se termina la grabación y se obtiene la URL del audio, la cual se usará para mostrar el resultado mediante un elemento de tipo audio en la interfaz de usuario. A la hora de almacenar el audio en la base de datos, es necesario almacenar los datos en un buffer. El Listado 5.11 muestra este proceso. 73

98 5.3 FASE DE CONSTRUCCIÓN $scope.start_recording = function(){ navigator.getusermedia({audio: true}, function (MediaStream) { recordrtc = RecordRTC(MediaStream); recordrtc.startrecording(); document.getelementbyid('audiostatus').innerhtml = 'Recording'; }, function(error){console.log(error);}); }; $scope.stop_recording = function(){ recordrtc.stoprecording(function(audiourl) { removenodechilds('audio'); var au = document.createelement('audio'); }; }); au.controls = true; au.src = audiourl; document.getelementbyid('audio').appendchild(au); document.getelementbyid('audiostatus').innerhtml = ''; Listado 5.10: Funciones start_recording y stop_recording Como se puede observar en el Listado 5.11, en primer lugar se hace uso de la clase FileReader para leer los datos obtenidos. A continuación, se convierten estos datos a base64 y posteriormente, se almacenan en un buffer. Para finalizar, se crea un nuevo objeto de tipo Sound y se realiza la petición al servidor para almacenar el audio mediante sounds.$save. 74

99 CAPÍTULO 5. RESULTADOS $scope.createcallresponse = function() { if (recordrtc){ var recordedblob = recordrtc.getblob(); recordrtc = null; var reader = new FileReader(); reader.readasbinarystring(recordedblob); $scope.sounddescription = $scope.currentcall.description; var binarystring; reader.onload = function() { binarystring = reader.result; var base64data = btoa(binarystring); var buf = base64tobuffer(base64data); var arr = Array.prototype.slice.call(buf); // Create new Sound object var sounds = new Sounds ({ description: $scope.sounddescription, question: $scope.currentcall._id, audio: { data: arr, contenttype: 'audio/wav' } }); }; // Redirect after save sounds.$save(function(response) { // Clear form fields $scope.sounddescription = ''; $scope.errorsound = ''; removenodechilds('audio'); $scope.currentcall = null; }, function(errorresponse) { $scope.errorsound = errorresponse.data.message; }); }; } else { $scope.errorsound = 'Audio is required'; } Listado 5.11: Función createcallresponse para almacenar una respuesta de audio Pruebas Las pruebas realizadas en este grupo funcional se centran en testear las funcionalidades relacionadas con las distintas acciones que el usuario puede realizar durante la partida. 75

100 5.3 FASE DE CONSTRUCCIÓN El Listado 5.12 muestra un caso de prueba realizado para la función $scope.hire(). Esta función asigna un empleado como coordinador de un módulo. it('$scope.hire() should store a coordinator in a module', inject(function() { scope.currentmodule = { coordinator: '' }; var employeesample = {name: 'Juan'}; scope.staff = [employeesample]; //Run controller functionality scope.hire(employeesample); //Test scope value expect(scope.currentmodule.coordinator).toequaldata(employeesample); expect(scope.staff).toequaldata([]); })); Listado 5.12: Prueba unitaria de la función $scope.hire() Iteración 6 En esta iteración se abordan los casos de uso del grupo funcional F6: Consultar Resultado. Grupo funcional F6: Consultar resultado En esta sección se lleva a cabo el análisis de casos de uso del grupo funcional F6, el diseño de las funcionalidades relativas al almacenamiento y carga de resultados, la implementación de dichas funcionalidades y el diseño e implementación de pruebas. Análisis de casos de uso Al principio de esta iteración, se llevó a cabo una reunión para determinar qué información debía almacenarse en el resultado de una partida. Se estableció que debía guardase la información sobre qué usuario ha realizado la partida, la reproducción de las llamadas realizadas, la información del progreso de cada módulo del proyecto, las conversaciones de chat y las respuestas a los problemas surgidos. 76

101 CAPÍTULO 5. RESULTADOS Diseño Después de realizar el análisis de los casos de uso de este grupo funcional, se modelan los diagramas de secuencia para mostrar cómo funciona. A continuación se muestran los diagramas de secuencia que representan la consulta de un resultado por parte de un usuario. En el primer diagrama (Figura 5.32), se muestra el proceso del sistema cliente. Una vez que la ventana de la interfaz se ha cargado, se ejecuta la función findresult() del controlador, que se encargará de realizar un petición al servidor pasando como parámetro el ID del resultado que se quiere consultar. Si la petición tiene éxito, el servidor devolverá el resultado y se mostrarán los datos en la interfaz. Figura 5.32: Diagrama de secuencia para la obtención de un resultado (Cliente) En la parte del servidor (Figura 5.33), se muestra como este maneja la petición de consulta recibida por el cliente. El controlador ResultsServerController es el que se encarga de dicha petición. En este caso, el servidor realiza una petición de consulta a la base de datos, utilizando el ID del resultado que se quiere obtener y devuelve el resultado al cliente. 77

102 5.3 FASE DE CONSTRUCCIÓN Figura 5.33: Diagrama de secuencia para la obtención de un resultado (Servidor) Implementación A continuación se explican algunas funciones relevantes para guardar los resultados de una partida. El Listado 5.13 muestra la función que permite guardar el resultado de una partida. Como se puede ver, la función se encarga de crear un objeto de tipo Result y de mandar una petición de inserción al servidor. Las variables callsresult, chatsresult y problemsresult contienen los resultados de las llamadas, chats y los problemas que el usuario ha contestado. La función getmodulesdata() se encarga de obtener el porcentaje completado de las fases de cada módulo, tal y como muestra el Listado

103 CAPÍTULO 5. RESULTADOS function createresult(){ var modulesarray = getmodulesdata(); var description = 'Project ' + $scope.project.name; var score = $scope.score; var result = new Results ({ user: $scope.authentication.user._id, content: { description: 'Project '+$scope.project.name, score: score, modules: modulesarray, calls: callsresult, chats: chatsresult, problems: problemsresult } }); }; result.$save(function(response) { console.log(response); }, function(errorresponse) { $scope.errorresult = errorresponse.data.message; }); Listado 5.13: Función createresult para almacenar el resultado de una partida function getmodulesdata() { var modulesdata = []; var i, j; for(i = 0; i < $scope.modules.length; i++) { var moduledata = {}; moduledata.modulename = $scope.modules[i].modulename; moduledata.phase = []; for (j = 0; j < $scope.modules[i].phase.length; j++){ var phasedata = { name: $scope.modules[i].phase[j].phasename, progress: $scope.modules[i].phase[j].progress }; moduledata.phase.push(phasedata); } modulesdata.push(moduledata); } } return modulesdata; Listado 5.14: Función getmodulesdata 79

104 5.3 FASE DE CONSTRUCCIÓN Pruebas Las pruebas que se han realizado en esta iteración se basan en comprobar el correcto guardado de resultados y su correcta obtención. El Listado 5.15 muestra dos casos de prueba. En el primero, se comprueba que tras obtener un resultado mediante un método GET, este se almacena en la variable $scope.result. El segundo caso, muestra que se produce un error si se intenta guardar un resultado sin el ID de un usuario. 80

105 CAPÍTULO 5. RESULTADOS it('$scope.findresult() should create an array with one Result object using a resultid URL parameter', inject(function(results) { //Define a sample module var module = {name: 'Module', percentage: 100}; // Define a sample Project object var sampleresult = new Results({ _id: '525a8422f6d0f87f0e407a33', user: '525a8422f6d0f87f0e407a31', content: { description: 'New Result', score: 200, modules: [module], calls: ['525a8422f6d0f87f0e407a36', '525a8422f6d0f87f0e407a37'] } }); // Set the URL parameter $stateparams.resultid = '525a8422f6d0f87f0e407a33'; // Set GET response $httpbackend.expectget(/result\/([0-9-a-fa-f])/).respond(sampleresult); // Run controller functionality scope.findresult(); $httpbackend.flush(); // Test scope value expect(scope.result).toequaldata(sampleresult); })); it('should be able to show an error when try to save without user', function(done) { result.user = ''; return result.save(function(err) { should.exist(err); done(); }); }); Listado 5.15: Pruebas unitarias del grupo funcional F6: Consultar Resultados 81

106 5.4 FASE DE TRANSICIÓN 5.4 Fase de Transición En esta fase, que se compone de una sola iteración, se prepara el producto para ser probado, instalado y utilizado por el cliente, e incluye los últimos detalles de implementación y pruebas Iteración 7 En la última iteración se han realizado las últimas pruebas globales para comprobar que el sistema funciona correctamente y se han corregido los pequeños bugs que se han detectado. Además, en esta iteración se elabora la documentación del producto software y se redacta el manual de instalación del sistema y el manual de usuario. 82

107 CAPÍTULO 6 CONCLUSIONES Y PROPUESTAS 6.1 Conclusiones Con el desarrollo de este TFG se ha conseguido satisfacer los objetivos y requisitos propuestos. Como resultado se ha obtenido un Serious Game que sirve de apoyo para la adquisición de algunos de los conocimientos y habilidades que son necesarios en el Desarrollo Global del Software. Ya que se trata de un juego, tiene la ventaja de ser mucho más asequible y entretenido que otros medios de formación tradicionales. El juego se basa en la simulación de un escenario en el que se desarrolla un proyecto. El jugador debe conseguir desarrollar todas las fases que componen cada módulo. Durante el desarrollo del juego surgirán una serie de problemas, pudiendo el usuario reducir la probabilidad de que estos aparezcan mediante determinadas acciones. Con respecto a la tecnología utilizada, hay que decir que supuso un reto desde el principio, ya que algunas de las tecnologías utilizadas en este proyecto no se habían usado antes (Node.js, MongoDB, Express.js, Angular.js y JavaScript), por lo que antes de comenzar con el desarrollo, fue necesario aprender a manejarlas. Uno de los principales problemas durante el desarrollo fue la simulación de llamadas, para lo que había que permitir la grabación de audio a través del micrófono del usuario. A continuación se lleva a cabo la consecución de los objetivos y sub-objetivos establecidos en el Capítulo Consecución de objetivos El objetivo principal de este TFG era desarrollar un serious game que permitiese adquirir algunos de los conocimientos y habilidades necesarias en GSD. Se considera que el objetivo ha sido conseguido gracias al diseño y construcción de la aplicación que se ha descrito a lo largo del documento. 83

108 6.2 CONSECUCIÓN DE OBJETIVOS A continuación se evalúa la consecución de los sub-objetivos descritos en el Capítulo 2 de este documento: El usuario debe poder modificar los datos de su perfil si así lo desea. La aplicación permite que un usuario modifique sus datos de perfil más relevantes, así como su contraseña. Este objetivo se ha alcanzado mediante el desarrollo del grupo funcional F3: Gestión del Perfil. La aplicación simulará un chat, correo electrónico y teléfono para que el alumno tenga que trabajar con comunicación síncrona y asíncrona. La aplicación simula conversaciones en chat y recepción de mensajes de correo electrónico y de llamadas telefónicas durante el desarrollo de una partida. Este objetivo se ha alcanzado gracias al desarrollo del grupo funcional F5: Jugar Escenario. La aplicación debe permitir al usuario crear escenarios personalizados, por si quiere practicar en un escenario concreto. La aplicación permite la creación de nuevos proyectos o escenarios mediante un editor de escenarios. Este objetivo se ha alcanzado mediante el desarrollo del grupo funcional F4: Gestión de Escenarios. De este modo, un usuario con rol de profesor puede crear escenarios con distintos módulos, países involucrados, presupuesto, etc. La aplicación debe simular una serie de eventos o problemas inesperados que podrían darse en la realidad en un proyecto GSD. Este objetivo se ha alcanzado gracias al desarrollo del grupo funcional F5: Jugar Escenario. Durante el desarrollo de una partida, el alumno tiene que hacer frente a una serie de problemas que se dan en el GSD, como problemas por malentendidos debido a los distintos niveles de inglés de los participantes, controlar la confianza entre los desarrolladores, etc. El usuario podrá consultar una ayuda cuando no sepa cómo seguir. Durante el desarrollo del juego, el usuario puede acceder a distintos paneles de ayuda que contienen información sobre algún aspecto del juego. El usuario podrá consultar su historial de puntuación. La aplicación permite que un 84

109 CAPÍTULO 6. CONCLUSIONES Y PROPUESTAS usuario consulte los resultados de las partidas que ha realizado. Además, un profesor puede consultar los resultados de sus alumnos. Este objetivo se ha logrado gracias al desarrollo del grupo funcional F6: Consultar resultado. 6.3 Propuestas futuras Debido a que la tendencia del Desarrollo Global del Software está en continuo crecimiento, surgen nuevos conocimientos y capacidades que los desarrolladores del software deben aprender, por lo que en el futuro podría adaptarse la herramienta para desarrollar estas nuevas habilidades. A continuación se describen algunas propuestas de trabajo futuro: Adaptar la herramienta para permitir que varios usuarios con distintos roles jueguen entre ellos, ofreciendo la posibilidad de entrenar habilidades de liderazgo. Desarrollo de una funcionalidad para poder exportar e importar los escenarios utilizando algún lenguaje de marcas, como XML. Mejorar la interfaz para crear una mayor sensación de inmersión en el GSD al usuario. 85

110

111 BIBLIOGRAFÍA 1. Ågerfalk, P., Fitzgerald, B, Holmstrom, H and Ó Conchúir, E, Benefits of Global Software Development: The Known and Unknown p Ågerfalk, P., Fitzgerald, B., Holmström, H., Lings, B., Lundell, B. and Conchúir, E. Ó., A framework for considering opportunities and threats in distributed software development Aranda, G.N., Marco para la Elicitación de Requisitos Software en Procesos de Desarrollo Global, in Tecnologías y Sistemas de Información. 2008, Universidad de Castilla-La Mancha. p Conchúir, E.Ó., Global Software Development: A Multiple-Case Study of the Realisation of the Benefits. 2010, University of Limerick 5. Cho, J., Globalization and software development. Utah State University, 2007: p Deiters, C., et al., GloSE-Lab: Teaching Global Software Engineering, in International Conference on Global Software Engineering p Desarrollo Global de Software, ed. Vizcaíno, A., García, F.O., and Piattini, M. 2014: Ra-Ma. 8. Graafland, M., Schraagen, J.M., and Schijven, M.P., Systematic review of serious games for medical education and surgical skills training Guenaga, M., et al., Serious Games para el Desarrollo de Competencias Orientadas al Empleo p Insight, G., Executive Summary: The Comprehensive Impact of Offshore Software and IT Services Outsourcing on the U.S. Economy and the IT Industry. Information Technology Association of America, Jacobson, I., Booch, G., and Rumbaugh, J., El proceso unificado de desarrollo de software. 2000: Addison Wesley. 87

112 BIBLIOGRAFÍA 12. Micahel, D. and Chen, S., Serious Games: Games That Educate, Train, and Inform. 2006: Thomson Course Technology. 13. Molenda, M., Cone of Experience Monasor, M.J., A framework for interaction training in Global Software Development Tesis doctoral 15. Monasor, M.J., Vizcaíno, A., and Piattini, M., Docencia en Desarrollo Global de Software: Una Revisión Sistemática, in XVII Jornadas de Enseñanza Universitaria de la Informática. 2011: Sevilla. p Sitio Oficial de Express.js. Available from: accedido el 08 de Febrero de Sitio Web de la W3C. Available from: accedido el 03 de Febrero de Sitio Web de MongoDB. Available from: accedido el 20 de Febrero de Sitio Web de Node.js. Available from: accedido el 05 de Febrero de Sitio Web de RecordRTC. Available from: accedido el 02 de Abril de Sitio Web Oficial de AngularJS. Available from: accedido el 08 de Febrero de Sitio Web Oficial de Balsamiq Mockups. Available from: accedido el 17 de Enero de Sitio Web Oficial de EndNote. Available from: accedido el 25 de Enero de Sitio Web Oficial de Git. Available from: accedido el 25 de Enero de Sitio Web Oficial de Visual Paradigm. Available from: accedido el 14 de Abril de

113 BIBLIOGRAFÍA 26. Smith, R.D., Investigating the disruptive effect of computer game technologies on medical education and training Squire, K., Changing the Game: What Happens When Video Games Enter the Classroom? (6). 28. Ulicsak, M., Games in Education: Serious Games WATTANASOONTORN, V., Serious Games for Health and Medicine. A Cardiopulmonary Resuscitation (CPR) Case Study. 2013, Universitat de Girona 89

114

115 ANEXO A DESAFÍOS DEL GSD Desafíos en la comunicación Falta de comunicación Las distancias geográfica y temporal reducen las oportunidades de comunicación informal entre los desarrolladores. Por tanto, la capacidad de los equipos para responder a los cambios puede verse afectada por la falta de capacidad para comunicarse. Dependencia de las tecnologías de información y comunicación. En GSD, la dependencia de las tecnologías de información y comunicación es alta. Dado que esta tecnología se usa para la comunicación, esta tiene un impacto en los procesos más críticos de una organización. Cuando la comunicación de un equipo no es buena, es muy difícil crear y validar las soluciones de diseño y gestionar los entregables del equipo. Malentendidos Las diferencias lingüísticas y socio-culturales causan confusión cuando los miembros del equipo tienen orígenes culturales distintos. En GSD, la distancia geográfica y temporal puede multiplicar este efecto, haciendo que el proceso sea más complejo. Las normas de trabajo pueden tener una gran variación, lo que se traduce en diferencias de opinión acerca de la naturaleza del proceso de desarrollo de software. Desafíos en la coordinación Reducción de la confianza La confianza juega un papel importante en el desarrollo de las relaciones personales. La confianza mutua es importante para que las personas sean capaces de cooperar y trabajar 91

116 ANEXO A. DESAFÍOS DEL GSD entre ellas. Por lo tanto, la falta de confianza resulta en la ruptura de los esfuerzos de coordinación entre los equipos remotos. Reducción de las horas de colaboración Una desventaja de la distancia temporal es que el número de horas superpuestas durante una jornada de trabajo se ve reducida. Por ejemplo, entre un equipo localizado en el Este de los Estados Unidos y un equipo localizado en Irlanda, solo puede haber tres horas superpuestas durante una jornada de trabajo. Dificultad de coordinar reuniones síncronas Los miembros del equipo podrían tener que trabajar horas flexibles con el fin de coordinarse con los miembros remotos a través de teleconferencias en tiempo real, lo que supone un aumento en el coste y el esfuerzo. Las reuniones intercontinentales siempre son difíciles, ya que siempre hay alguien que debe ceder en su horario de trabajo. Falta de conocimiento del dominio Algunas tareas del desarrollo del proyecto pueden requerir conocimientos específicos que los desarrolladores procedentes de otros países no tienen. Las organizaciones pueden tener puntos de vista incompatibles en un dominio, basándose en su propia experiencia. Desafíos en el control Riesgos organizativos En función de los lugares involucrados, la deslocalización puede aumentar el riesgo que implica para la organización. Partes de la organización podrían estar localizadas en países desarrollados o emergentes, que históricamente han sido más volátiles, menos estables, menos predecibles y menos transparentes. Los riesgos políticos incluyen la guerra, el terrorismo, disturbios, insurrección, golpes militares, confiscación, expropiación y crisis 92

117 ANEXO A. DESAFÍOS DEL GSD monetarias. Varios informes han tratado de clasificar a los países de destino para el GSD, de acuerdo a la estabilidad política, entre otros factores. También hay que tener en cuenta el riesgo soberano, donde las regulaciones gubernamentales pueden cambiar. Gestión de los artefactos del proyecto Cuando un proyecto GSD involucra a miembros de diferentes organizaciones, hacer cumplir el procedimiento y los estándares es importante en el mantenimiento de la coherencia y la interoperabilidad entre los artefactos del proyecto. Para mantener la coherencia entre los artefactos del proyecto, se suele utilizar una herramienta de gestión de la configuración con almacenamiento centralizado. Los artefactos incluyen el código fuente y la documentación del proyecto. Incluso cuando se trabaja desde el mismo repositorio central, pueden surgir problemas mediante una nueva versión de un artefacto. Este problema no ocurre exclusivamente en GSD, pero se ve acentuado por la reducción de las comunicaciones formales e informales que ayudarían en este proceso. Diferentes percepciones de la autoridad/jerarquía La naturaleza de la autoridad en el equipo puede variar entre diferentes culturas. Por ejemplo, los desarrolladores irlandeses requieren que sus superiores se ganen el respeto, mientras que los desarrolladores de Estados Unidos son más sumisos a la autoridad. Por lo tanto, pueden surgir problemas en el control de un proyecto GSD si los equipos en diferentes lugares esperan ser controlados de una manera diferente y si estas diferencias no son identificadas desde el principio. 93

118

119 ANEXO B SERIOUS GAMES EN DIVERSAS ÁREAS Como ya hemos podido observar, los serious games están siendo pioneros en varios sectores. A continuación se muestran algunas de las áreas en las que se han usado serious games [28]: Militar Los primeros juegos creados se basaban en el combate y en la lucha. Por ejemplo, juegos de mesa como Chaturanga y Wei Hei, ambos de unos 4000 años de antigüedad, eran juegos diseñados para el desarrollo de estrategias para las batallas No fue hasta 1996, con la aparición del juego Marine Doom, cundo comenzó a apreciarse el potencial de los juegos. Este juego se trata de una variación del juego Doom. En lugar de un juego de disparo primera persona, se introdujeron armas más realistas y se incluyeron tareas que fomentaban el aprendizaje de la secuencia adecuada de ataque, como la conservación de munición, comunicarse con eficacia, dar órdenes y trabajar en equipo. En los últimos años, el ejército de Estados Unidos está explorando el uso de serious games como una manera de tratar el estrés postraumático. Esta tecnología también está siendo investigada para la rehabilitación del ictus y para evaluar las capacidades cognitivas de los adultos con Alzheimer. Salud Los juegos serios relacionados con la salud son un campo en crecimiento. Los juegos de salud para profesionales (como médicos y enfermeras) tienden a estar basados en la simulación y son utilizados para el entrenamiento. Por ejemplo, en 2008, en Birmingham, se permitió que médicos jóvenes experimentaran y entrenaran para una variedad de escenarios médicos mediante el uso de maniquíes computarizados como si fueran pacientes. En su disertación, Smith [26], comparó la enseñanza tradicional y el entrenamiento usando realidad virtual y herramientas basadas en juegos para cirugía laparoscópica. Smith 95

120 ANEXO B. SERIOUS GAMES EN DIVERSAS ÁREAS observó que esta última era menos cara, tardaba menos tiempo y daba lugar a menos errores médicos cuando se realizaba la cirugía en la realidad. Educación formal El uso limitado de los juegos serios en la educación formal puede estar relacionado con las cuestiones en torno a la utilización de juegos de ocio. Por otra parte, los juegos no son eficaces para todos los estudiantes. Esto se debe en parte a la pedagogía. Los jugadores aprenden con la repetición y la exploración, lo que contrasta con el aprendizaje de cantidades discretas de información que se puede encontrar en las escuelas [27]. Además, el sistema de educación formal tiene que adherirse a los conocimientos y procedimientos necesarios para los exámenes externos. Por lo tanto, los juegos también deben abordar estas áreas. 96

121 ANEXO C MANUAL DE INSTALACIÓN En este anexo se detallan los requisitos del sistema, así como los pasos a seguir para instalar la aplicación desarrollada. C.1 Requisitos del sistema Debido a que la aplicación se encuentra alojada en un servidor de internet, tan solo es necesario disponer de un navegador web para acceder a la aplicación. Se puede acceder mediante el siguiente enlace: Sin embargo, si se quiere ejecutar la aplicación en un entorno local, es necesaria la instalación de las tecnologías MongoDB y Node.js, cuya instalación se explica a continuación. C.2 Instalación de las tecnologías y sistema A continuación se explica cómo instalar las tecnologías necesarias para la ejecución de la aplicación en un sistema Debian. Node.js Para la instalación de Node.js hay que introducir los siguientes comandos en la consola: sudo apt-get install curl curl sl sudo bash - sudo apt-get update sudo apt-get install nodejs MongoDB Para instalar MongoDB hay que seguir los siguientes pasos: 97

122 ANEXO C. MANUAL DE USUARIO Importar la clave pública utilizada por el sistema de gestión de paquetes. sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10 Crear el archivo /etc/apt/sources.list.d/mongodb-org-3.0.list. echo "deb wheezy/mongodborg/3.0 main" sudo tee /etc/apt/sources.list.d/mongodb-org-3.0.list Instalar MongoDB. sudo apt-get update sudo apt-get install -y mongodb-org Instalación y ejecución de la aplicación Para la instalación del sistema en local debemos copiarnos la carpeta app que se encuentra en el DVD de este TFG en el directorio deseado. Una vez que hemos copiado la carpeta podemos lanzar el servidor simplemente ejecutando el siguiente comando por la consola desde el directorio raíz: node server.js. Una vez lanzado el servidor podemos acceder a la aplicación desde el navegador mediante la siguiente dirección: 98

123 ANEXO D MANUAL DE USUARIO En el presente anexo se detalla el manual de usuario de la herramienta desarrollada en este TFG. D.1 Funciones comunes a todos los usuarios Registro y acceso al sistema Al acceder a la página web, se muestra la página que se ve en la Figura D.1. Figura D.1: Página de acceso En esta página el usuario dispone de dos opciones. Si el usuario ya se ha registrado previamente, puede acceder al sistema introduciendo su nombre de usuario y contraseña, pulsando a continuación en el botón Sign in. En caso de que el usuario no esté registrado, puede crear un nuevo perfil pulsando en el enlace Sign up y rellenando el formulario que se muestra en la Figura D2. Uno de los 99

124 D1. FUNCIONES COMUNES A TODOS LOS USUARIOS aspectos más importantes del formulario es la elección del rol, ya que dependiendo del rol elegido el usuario podrá realizar unas u otras acciones. Figura D.2: Formulario de registro Una vez completado el formulario, el usuario debe pulsar el botón Sign up para completar el proceso de registro. Una vez que el usuario se haya registrado, o haya introducido su nombre de usuario y contraseña, se accederá al sistema. 100

125 ANEXO D. MANUAL DE USUARIO Editar perfil Para editar el perfil hay que hacer click en la opción de la esquina superior derecha y a continuación en Edit Profile. Simplemente se debe rellenar el formulario de la Figura D.3. Figura D.3: Página de edición del perfil Cambiar contraseña Para cambiar la contraseña, se debe hacer click en la opción de la esquina superior derecha y seleccionar Change Password. En el formulario que muestra la Figura D.4 se debe introducir la contraseña actual en el primer campo y la nueva contraseña en los campos restantes. 101

126 D1. FUNCIONES COMUNES A TODOS LOS USUARIOS Figura D.4: Formulario para cambiar la contraseña Cerrar sesión Para cerrar la sesión y volver a la página de acceso, se debe hacer click en la opción de la esquina superior derecha y seleccionar Sign out. D.2 Estudiante En este apartado se explican las funciones disponibles para los usuarios con rol de estudiante. Página principal Al acceder al sistema, se mostrará la página principal, tal y como se muestra en la Figura D5. 102

127 ANEXO D. MANUAL DE USUARIO Figura D.5: Página principal (Estudiante) En esta página se muestran los proyectos creados por el profesor que el alumno tiene asociado. Al lado de cada proyecto hay dos botones. Con el botón play comenzará la partida para simular el escenario. Con el segundo botón, se puede ver la información del proyecto. En la barra superior se puede navegar para acceder a las distintas funcionalidades del sistema. Las opciones que contiene son: Projects, Requests y My Results. Al hacer click sobre la opción Project se muestra la ventana principal, descrita en este apartado. En los siguientes apartados se explican las funciones para las opciones Request y My Results. Solicitud de un profesor Al pulsar sobre la opción Request, se mostrará la página que se ve en la Figura D.6. En esta página se muestran todos los profesores que nos han enviado una solicitud, pudiendo aceptar o rechazar dicha solicitud con los botones Accept y Refuse, respectivamente. Debido a que solo se puede tener un profesor asociado, todos los profesores desaparecerán de la lista al aceptar una solicitud. 103

128 D2. ESTUDIANTE Figura D.6: Página Requests Ver resultados Un usuario puede ver sus resultados haciendo click en la opción Results. Se mostrará una ventana como la de la Figura D.7. Figura D.7: Página con los resultados del usuario Podemos ver un resultado concreto pulsando en el botón que hay al lado de cada resultado. Se mostrará la página que se ve en la Figura D