Brayan Julian Barbosa Sierra Pablo Andrés Esteban...

Construcción de un entorno virtual enfocado al proceso bidireccional pedagógico Brayan Julian Barbosa Sierra Pablo Andrés Esteban Vargas Universidad Distrital Francisco José de Caldas Ingeniería de Sistemas Bogotá D.C. 2017

i

Contenido Índice de Ilustraciones ....................................................................................................... vi Índice de Tablas ................................................................................................................. ix Índice de ecuaciones ......................................................................................................... xi Capítulo 1. Sobre el problema ........................................................................................... 1 1.1 Introducción Histórica al Problema .............................................................................. 1 1.2 Planteamiento del Problema ......................................................................................... 4 1.3 Objetivos ...................................................................................................................... 5 1.3.1 Objetivo General ................................................................................................... 5 1.3.2 Objetivos específicos ............................................................................................ 5 1.4 Justificación .................................................................................................................. 6 1.5 Limitaciones y delimitaciones ...................................................................................... 7 1.6 Alcance ......................................................................................................................... 8 Capítulo 2. Marco Teórico ................................................................................................ 11 2.1 Metodologías ágiles .................................................................................................... 11 2.1.1 Scrum .................................................................................................................. 12 2.1.2 XP ........................................................................................................................ 13 2.1.3 Uniendo Scrum y XP .......................................................................................... 15 2.2 Entornos virtuales de aprendizaje ............................................................................... 15

ii

2.2.1 Componentes de los entornos virtuales de aprendizaje ....................................... 16 2.2.2 Algunos tipos de entornos virtuales de aprendizaje ............................................ 17 2.2.3 Usos de los entornos virtuales de aprendizaje .................................................... 18 2.2.4 Sobre los entornos virtuales asincrónicos ........................................................... 19 2.3 Trabajos Relacionados ............................................................................................... 20 2.3.1 Monkey Tales ...................................................................................................... 21 2.3.2 Aplicación Pizarra ............................................................................................... 21 2.3.3 Videojuego educativo enfocado al teatro clásico ................................................ 21 2.3.4 Juego Adaptativo para enseñar SQL ................................................................... 22 2.3.5 Blackboard (Clarenc & S. M. Castro, 2013) ....................................................... 22 2.3.6 Dokeos (Universidad Internacional de Valencia, s.f.) ........................................ 22 2.3.7 Ingeniosos (MINTIC, 2015)................................................................................ 23 2.3.8 Edmodo (Clarenc & S. M. Castro, 2013) ............................................................ 23 Capítulo 3. Metodología ................................................................................................... 24 3.1 Implementación de Scrum y XP ................................................................................. 24 3.2) Desarrollo de la metodología. ................................................................................... 26 3.2.1) Definición del Product Backlog ......................................................................... 26 3.2.2) Definiciones de Hecho ....................................................................................... 27 3.3) Definición de los Sprints ........................................................................................... 33

iii

3.3.1) Primer Sprint .......................................................................................................... 34 3.3.1.1) Definición del Primer Sprint ........................................................................... 34 3.3.1.2) Sprint Backlog ................................................................................................ 34 3.3.1.3) Diagrama de Gantt .......................................................................................... 37 3.3.1.4) Ejecución de Sprint ......................................................................................... 37 3.3.1.5) Retrospectiva del Sprint .................................................................................. 41 3.3.1.6) Anexos. ........................................................................................................... 43 3.3.2) Segundo Sprint ....................................................................................................... 45 3.3.2.1) Definición del Segundo Sprint ........................................................................ 45 3.3.2.2) Sprint Backlog ................................................................................................ 45 3.3.2.3) Diagrama de Gantt .......................................................................................... 47 3.3.2.4) Ejecución de Sprint ......................................................................................... 47 3.3.2.5) Retrospectiva del Sprint .................................................................................. 51 3.3.2.6) Anexos. ........................................................................................................... 53 3.3.3) Tercer Sprint .......................................................................................................... 54 3.3.3.1) Definición del Tercer Sprint ........................................................................... 54 3.3.3.2) Sprint Backlog ................................................................................................ 55 3.3.3.3) Diagrama de Gantt .......................................................................................... 59 3.3.3.4) Ejecución de Sprint ......................................................................................... 60

iv

3.3.3.5) Retrospectiva del Sprint .................................................................................. 68 3.3.3.6) Anexos. ........................................................................................................... 69 3.3.4) Cuarto Sprint .......................................................................................................... 71 3.3.4.1) Definición del Cuarto Sprint ........................................................................... 71 3.3.4.2) Sprint Backlog ................................................................................................ 71 3.3.4.3) Diagrama de Gantt .......................................................................................... 73 3.3.4.4) Ejecución de Sprint ......................................................................................... 74 3.3.4.5) Retrospectiva del Sprint .................................................................................. 77 3.3.4.6) Anexos. ........................................................................................................... 78 3.3.4) Quinto Sprint .......................................................................................................... 80 3.3.4.1) Definición del quinto Sprint ........................................................................... 80 3.3.4.2) Sprint Backlog ................................................................................................ 80 3.3.5.3) Diagrama de Gantt .......................................................................................... 83 3.3.5.4) Ejecución de Sprint ......................................................................................... 83 3.3.5.5) Retrospectiva del Sprint .................................................................................. 92 3.3.5.6) Anexos ............................................................................................................ 93 Capítulo 4. Conclusiones ................................................................................................. 95 Glosario ............................................................................................................................... 97 OECD ............................................................................................................................... 97

v

Juegos de rol ..................................................................................................................... 97 Pruebas PISA .................................................................................................................... 98 Shamanimals ................................................................................................................ 98 Sloan Consortium (Sloan-C) ............................................................................................ 98 Ukanbook ..................................................................................................................... 99 WEB 2.0 ........................................................................................................................... 99 Gamificacion .................................................................................................................... 99 Bibliografía ........................................................................................................................ 100

vi

Índice de Ilustraciones Ilustración 1. Ciclo de vida de Scrum .................................................................................. 12 Ilustración 2. Ciclo de vida de XP ....................................................................................... 14 Ilustración 3 Diagrama de Gantt Sprint 1 ............................................................................ 37 Ilustración 4 MVC primer Sprint ......................................................................................... 38 Ilustración 5 inicio Arcadia .................................................................................................. 40 Ilustración 6 Registro estudiantes y profesores .................................................................... 40 Ilustración 7 Página principal estudiantes………………………………………………….41 Ilustración 8 Página principal profesores…………………………………………………..41 Ilustración 9 Creación reinos………………………………………………………………42 Ilustración 10 Perfil profesor………………………………………………………………42 Ilustración 11 Diagrama Entidad-Relación v. 1……………………………………………44 Ilustración 12 Diagrama de clases v. 1……………………………………………………..45 Ilustración 13 Diagrama de Gantt Sprint 2....……………………………………………...48 Ilustración 14 Página principal de un reino………………………………………………...49 Ilustración 15 Incripción a un reino………………………………………………………..49 Ilustración 16 Perfil y lista de estudiantes………………………………………………….49 Ilustración 17 Mapa de profesores ....................................................................................... 50 Ilustración 18 Modelo-Vista-Controlador v. 2 ................................................................... 500 Ilustración 19 Diagrama Entidad-Relación v. 2 ................................................................... 53 Ilustración 20 Diagrama de clases v. 2……………………………………………………..54

vii

Ilustración 21 Diagrama de Gantt Sprint 3 .......................................................................... 59 Ilustración 22 Vista creación actividades tipo archivo…………………………………….60 Ilustración 23 Vista creación actividades en clase…………………………………………61 Ilustración 24 Vista creación actividades desde el mapa…………………………………..61 Ilustración 25 Vista edición actividades…………………………………………………...61 Ilustración 26 Diagrama MVC v. 3…………………………………………………….......62 Ilustración 27 Vista actividades por región para estudiantes………………………………63 Ilustración 28 Actividad en estado activo………………………………………………….64 Ilustración 29 Actividad con el máximo número de intentos……………………………...64 Ilustración 30 Actividad cerrada…………………………………………………………...64 Ilustración 31 Actividades por región profesores………………………………………….65 Ilustración 32 Respuestas de una actividad………………………………………………...66 Ilustración 33 Respuestas de un estudiante………………………………………………...66 Ilustración 34 Lista de estudiantes en el reino……………………………………………..67 Ilustración 35 Notas por región…………………………………………………………….67 Ilustración 36 Notas para un estudiante……………………………………………………68 Ilustración 37 Diagrama Entidad-Relación v. 3……………………………………………69 Ilustración 38 Diagrama de clases v. 3……………………………………………………..70 Ilustración 39 Diagrama de Gantt Sprint 4………………………………………………...73 Ilustración 40 Diagrama MVC v. 4………………………………………………………..74 Ilustración 41 Galeria completa……………………………………………………………75 Ilustración 42 Página principal reinos con galeria y novedades…………………………...76 Ilustración 43 Ventana modal adición de elementos en galeria……………………………77

viii

Ilustración 44 Diagrama Entidad-Relación v. 4……………………………………………78 Ilustración 45 Diagrama de clases v. 4……………………………………………………..79 Ilustración 46 Diagrama de Gantt v. 5……………………………………………………..83 Ilustración 47 Diagrama MVC v. 5………………………………………………………...84 Ilustración 48 Titulo de un estudiante y selección del avatar……………………………...87 Ilustración 49 Registro del estudiante y las clases…………………………………………87 Ilustración 50 Nota y nivel del estudiante …………………………………………………87 Ilustración 51 Creación preguntas……………………………………………………….…89 Ilustración 52 Listado preguntas…………………………………………………………...89 Ilustración 53 Creación actividad tipo cuestionario……………………………………….90 Ilustración 54 Ventana modal resolver cuestionarios……………………………………..90 Ilustración 55 Vista inicial cuestionarios……………………………………………….…91 Ilustración 56 Ejemplo de una pregunta en un cuestionario………………………….……91 Ilustración 57 Resultado cuestionario……………………………………………….……..91 Ilustración 58 Diagrama Entidad-Relación v. 5……………………………………………93 Ilustración 59 Diagrama de clases v. 5……………………………………………………..94

ix

Índice de Tablas Tabla 1 Miembros del equipo de desarrollo………………………………………………..26 Tabla 2 Product Backlog…………………………………………………………………...26 Tabla 3 Definiciones de hecho H.U. 1000 ........................................................................... 28 Tabla 4 Definiciones de hecho H.U. 1001 ......................................................................... 298 Tabla 5 Definiciones de hecho H.U. 1002 ........................................................................... 29 Tabla 6 Definiciones de hecho H.U. 1003 ........................................................................... 29 Tabla 7 Definiciones de hecho H.U. 1004 ........................................................................... 30 Tabla 8 Definiciones de hecho H.U. 1005 ........................................................................... 30 Tabla 9 Definiciones de hecho H.U. 1006 ........................................................................... 30 Tabla 10 Definiciones de hecho H.U. 1007 ......................................................................... 31 Tabla 11 Definiciones de hecho H.U. 1008 ......................................................................... 31 Tabla 12 Definiciones de hecho H.U. 1009 ......................................................................... 32 Tabla 13 Definiciones de hecho H.U. 1010 ......................................................................... 32 Tabla 14 Definiciones de hecho H.U. 1011 ......................................................................... 33 Tabla 15 Sprint Backlog 1.................................................................................................... 36 Tabla 16 Funcionalidades Sprint 1 ....................................................................................... 36 Tabla 17 Prefijos nombramiento Tablas .............................................................................. 37 Tabla 18 Sprint Backlog 2.................................................................................................... 46 Tabla 19 Funcionalidades Sprint 2 ....................................................................................... 47 Tabla 20 Sprint Backlog 3.................................................................................................... 57 Tabla 21 Funcionalidades Sprint 1 ....................................................................................... 58

x

Tabla 22 Funcionalidades Sprint 4 ....................................................................................... 73 Tabla 25 Clases y niveles en Arcadia. ................................................................................. 85

xi

Índice de ecuaciones Ecuación 1 Duración de un Sprint en semanas….………………………………………...36 Ecuación 2 Sumatoria porcentaje actividades en reino……………………………………87 Ecuación 3 Nota en reino, caso 1………………………………………………………….87 Ecuación 4 Nota en reino, caso 2………………………………………………………….87

1

Capítulo 1. Sobre el problema Este capítulo ilustra las generalidades del proyecto, iniciando con una introducción histórica que tiene como función enmarcar la problemática proyecto y dar unas primeras ideas sobre la temática del documento, si mismo se encuentra el planteamiento del problema en el cual se halla ubicada la pregunta de investigación y los últimos tres apartados, los cuales son los objetivos, la justificación y las limitaciones y delimitaciones. 1.1 Introducción Histórica al Problema Las herramientas tecnológicas que utilizan páginas web y comunicación con Internet han permeado los diferentes aspectos y espacios de los seres humanos, desde instrumentos usados en el hogar como neveras, hasta la forma de hacer deporte haciendo rastreo y seguimiento en tiempo real, con esta gran invasión no es extraño el hecho de que esta misma ola inunde la aulas de clases; de esta misma manera, estas tecnologías han comenzado a abrirse camino a la educación básica apoyando los procesos de enseñanza y ofreciendo soluciones a los problemas del día a día de los docentes. Los procesos por los cuales los alumnos aprenden y los maestros enseñan van cambiando a medida que el tiempo va avanzando en sí mismo, “los educadores procuran buscar métodos y herramientas que permitan llegar a los educandos con efectividad y eficiencia” (Sharma, Agada, & Ruggin, 2013) de esta manera, han encontrado en Internet la forma de acercar al aula de clase novedades en este campo, sistemas y elementos que permiten acceder al conocimiento sin implicar trasladarse o contar con nutridos presupuestos. Esta fuente de inagotables servicios ha sido abrazada por algunos educadores como un recurso para la enseñanza, y por algunas instituciones educativas, como el sistema que les permite ampliar sus aulas sin tener que levantar nuevas paredes. Sin embargo la diversidad de contenidos que se encuentran en la red sobre un tema en específico y la creación de sitios web como lo son Wikipedia, Monografías, y muchos blogs entre otros, en donde cualquier usuario puede agregar su conocimiento o ideas, genera el temor de encontrar contenido sin fundamentos, muchas veces falaz y basado solo en las ideas de un usuario, esto puede llegar a distorsionar el gran potencial que ofrecen los sitios web. Así surgieron espacios y sitios en internet pensados para la enseñanza y con la idea de hacer uso educativo

2

de la red. Estos espacios creados con un plan y organización de recursos adecuados se denominaron “aulas virtuales”. Las aulas virtuales han sido uno de los avances más significativos para la educación en línea permitiendo el aprendizaje a través de la comunicación sin requerir la interacción “cara a cara”, los cursos en línea han incrementado en la última década en credibilidad y popularidad. En el año 2008, el SLOAN CONSORTIUM reporto que 3.9 millones (cerca del 20%) de estudiantes, en Estados Unidos estaban tomando al menos un curso en línea. En solo un año, 2006-2007, hubo un incremento del 12.9% en la inscripción en línea, este incremento de 400000 estudiantes se debe al crecimiento de oferta de cursos en cualquier momento, en cualquier lugar y proporciona flexibilidad y comodidad para el aprendizaje para los estudiantes e instructores, “sin embargo uno de los mayores retos que los educadores a distancia enfrentan hoy, es el diseño de cursos que provean interactividad” (Martin F., 2010, p.1). “En Colombia, se piensa que educación consiste en ir a la escuela y sentarse a recibir datos, concepto limitado y no pertinente porque desconoce que cada acción es una oportunidad de aprendizaje” (Herrera, 2005, p.57), esta es una de las razones del bajo rendimiento de los jóvenes en las pruebas PISA, “los jóvenes deben ser equipados con habilidades que les permita desarrollar todo su potencial y participar activamente en la economía y política, estas habilidades le permiten a las personas afrontar los retos diarios, resolver problemas y tomar decisiones” (Gurria, 2012, p.2), según la OECD (Organisation for Economic Co-operation and Development) que es el organismo encargado de administrar las pruebas PISA, las aptitudes que deben poseer los jóvenes a nivel mundial están dividas en tres grupos, matemáticas, lectura y ciencias, a partir de esto se puede evidenciar la necesidad de hacer cambios en la educación y utilizar todas la herramientas al alcance como la tecnología y las páginas web. El rendimiento de Colombia en las pruebas PISA del año 2012 es muy bajo, quedando en el puesto 62 de 65 países que son evaluados, la mejor área para Colombia fue el área de lectura en el cual quedo en el puesto 55, adicionalmente las pruebas PISA evalúan la capacidad de resolución de problemas de los estudiantes en este tema Colombia fue el último con 399 puntos, quedando 101 puntos por debajo del promedio mundial que es 500 puntos, en estas pruebas se evalúa la capacidad de adquirir conocimiento y luego aplicarlo en una situación definida, muchos de los problemas son de comprensión de lectura y abstracción de ideas principales de un texto, con la información recopilada se proponían nuevos problemas y los estudiantes debían afrontar estos interrogantes con el conocimiento previamente adquirido, esto es una parte del modelo bidireccional en el cual el

3

alumno recibe información, la procesa y retorna resultados o inquietudes a su emisor. “La bidireccionalidad requiere alejarse de teorías del aprendizaje donde el maestro sea el centro del proceso y maneje un sistema emisor, mensaje y receptor de una sola vía” (Beltrán, 2014, p.102), la clase como forma básica de organización de la enseñanza debe plantearse como un espacio donde el alumno se desarrolle integralmente protagonizando un verdadero papel activo en ella. Una vía para lograrlo es la utilización de métodos que pongan en marcha procesos creativos y propicien una enseñanza en la cual los alumnos van resolviendo problemas, organizando ideas, etc. Logrando así un aprendizaje agradable y profundo. El juego no es sólo juego infantil. “Jugar, para el niño y para el adulto es una forma de utilizar la mente e incluso mejor, una actitud sobre cómo utilizar la mente. Es un marco en el que poner a prueba las cosas, un invernadero en el que poder combinar pensamiento, lenguaje y fantasía” (Bruner, 1984, p.989), Beltrán (2014) en su trabajo sobre los juegos de roll y la web 2.0 aplicados en la educación colombiana propone algunas herramientas con las cuales los procesos de aprendizaje pueden ser enriquecidos, la idea es que el estudiante obtenga medios y herramientas con las cuales pueda expresarse, se realizaron pruebas con una web denominada Arcadia (http://www.mundoarcadia.co) en la cual los estudiantes podían interactuar con el profesor y sumergirse en un juego de roll, “lo tecnológico en Arcadia está mediado por la web 2.0 principalmente, tecnología que demostró ser efectiva como herramienta de comunicación en un proyecto pedagógico con las características de Arcadia” (Beltrán, 2014, p.95). Se pueden proponer muchas herramientas utilizando Internet y la web para abordar las falencias de la educación colombiana, según Peña (2014) si la población no tiene acceso a internet o dispositivos que le permitan utilizar estas herramientas seria como arar en el desierto, para aclarar este tema se han realizado encuestas como las hechas por Ipsos – Napoleón Franco en las cuales se realiza un sondeo sobre el uso del Internet y las diferentes formas de acceder a este, la conclusión más destacada del trabajo realizado por esta empresa fue que está creciendo la intensidad horaria del uso de Internet y la cantidad de personas que utilizan este en Colombia, la encuesta muestra que 59% de los colombianos acceden a internet diariamente mientras que en el 2013 un 53,3%, los diferentes tipos de dispositivos como los teléfonos inteligentes se han popularizado y el 34% de los encuestados ingresa a internet desde este medio, para el 2013 solo un 15% utilizaba el teléfono inteligente, al mismo tiempo que las tabletas crecieron del 3% al 16%, el 70% de las personas utilizan el computador de su casa para entrar a internet.

4

1.2 Planteamiento del Problema Arcadia surge como herramienta para fortalecer el proceso pedagógico bidireccional, desde su inicio el objetivo de Arcadia nunca fue el administrar la información de las notas de los estudiantes o el permitir compartir información, por eso mismo muchas de las funcionalidades y de los requisitos para ser un aula virtual se omitieron, de esa manera Arcadia se presenta como una valiosa oportunidad para la ingeniería de sistemas y la teoría general de sistemas, en primera medida para analizar las falencias se debe tener en cuenta que no cumple a cabalidad con los componentes propuestos por Scagnoli (2005) ni tampoco soporta todas las fases del aprendizaje definidas por Kolb (Marters & Achten, 2008) definidos en la sección 2.2, uno de los problemas más grandes es la falta de persistencia de la información en el sitio web Arcadia, ya que no se pueden almacenar las notas de los estudiantes, documentos, archivos multimedia o cualquier otro tipo de elemento que facilite el trabajo del docente y de los estudiantes. Siguiendo con el recuento de las falencias que presenta Arcadia está la necesidad de la administración de los usuarios, en este momento Arcadia no cuenta con ninguna forma de autenticación de usuarios, por lo tanto no existen perfiles ni roles de estos mismos, esto es importante para el seguimiento del avance de los estudiantes, el control de notas y cualquier otro aspecto que sea personal de acuerdo a cada usuario. Otro punto que vale la pena recalcar es el hecho de que Arcadia carece de aspectos visuales atractivos y llamativos para los estudiantes lo cual es esencial para poder envolver al estudiante en el contenido y la historia, carece de herramientas que le permitan al docente moldear el sitio a sus necesidades y al contenido programático de sus asignaturas. La idea es analizar a Arcadia de tal manera que sus falencias se puedan abordar y fortalecer, utilizando a Arcadia como un puente y retomando la idea inicial de Beltrán de diseñar un juego de rol online para apoyar los procesos pedagógicos, se abre la ventana para rescatar los valiosos aspectos pedagógicos de Arcadia, identificando, rediseñando y rehaciendo los puntos débiles, de esta manera cumplir con las expectativas de Beltrán apoyándose en el marco conceptual, teórico y práctico que le ofrece la ingeniería de sistemas. De este mismo modo se genera la inquietud de saber qué contribuciones puede llegar a realizar la teoría general de sistemas y el enfoque sistémico al sistema diseñado por Beltrán, hay que tener en cuenta que el sistema conocido como Arcadia es una herramienta web 2.0 con el fin de permitir mejoras en el proceso bidireccional pedagógico por tanto se requiere tener sustento en la ingeniería de software con el objetivo de llegar a describir a Arcadia, proponer mejoras, diseñar nuevos componentes y llevar a cabo estas mismas.

5

No se desea criticar el sitio web Arcadia, se busca analizar el proceso de creación que realizó el responsable de este proyecto para así mismo descubrir los posibles campos de trabajo en los cuales se puedan hacer aportes utilizando las herramientas que ofrecen la ingeniería de software y la ingeniería de sistemas, vale la pena resaltar que el proyecto Arcadia tiene fines pedagógicos lo cual está muy alejado de las ramas del conocimiento de los autores de este proyecto de investigación, por lo tanto se propone utilizar el enfoque sistémico como puente entre la ingeniería y la pedagogía, esta idea la expone Rosnay en la siguiente frase “la base del pensamiento sistémico consiste en reconocer la existencia de una serie de conceptos genéricos aplicables y aplicarlos en diversos estudios” (Rosnay, 1977, p.105), tales conceptos genéricos como la cibernética y las demás disciplinas en las que se basa la teoría general de sistemas deben poder formar el marco conceptual y teórico lo suficientemente firme para llevar a cabo la empresa de resolver problemas planteados en la pedagogía desde la ingeniería. Para plantear la pregunta de investigación se debe tener presente que se buscan aplicar los procesos y las metodologías que se utilizan en la ingeniería para realizar aportes en la pedagogía, la pregunta de investigación es la siguiente: ¿La metodología Scrum ofrece las suficientes herramientas para culminar satisfactoriamente la construcción de un entorno virtual de aprendizaje? 1.3 Objetivos 1.3.1 Objetivo General Construir un entorno virtual de aprendizaje a partir del sitio web www.mundoarcadia.co con el fin de fortalecer el proceso el proceso pedagógico bidireccional en la materia de español (lectura y escritura) de los estudiantes del colegio Alejandro Obregón I.E.D. de los cursos décimo y undécimo. 1.3.2 Objetivos específicos 1. Identificar las falencias a nivel tecnológico en el proyecto Arcadia. 2. Proponer nuevos cambios y una serie de mejoras que aporten positivamente al proyecto Arcadia para ser aplicadas y examinar su funcionamiento.

6

3. Documentar el proceso de creación del sistema y del producto de software. 4. Establecer los componentes necesarios para que Arcadia pueda ser un entorno virtual de aprendizaje. 5. Implementar y desarrollar un conjunto de cambios previamente establecidos al proyecto Arcadia. 6. Entregar un producto finalizado al docente Luis Carlos Beltrán que cumpla con las definiciones de hecho. 1.4 Justificación El número de horas que los estudiantes usan internet diariamente, las políticas para fomentar la ciencia, la tecnología y la educación promovidas por el gobierno colombiano, la baja preparación que muestran los estudiantes en las pruebas a nivel internacional y el poco interés que los estudiantes muestran en las clases tradicionales son las principales razones que motivan este proyecto. Ya que el sitio web Arcadia se encuentra en funcionamiento y su creador es el licenciado Luis Carlos Beltrán, este sitio presenta problemas para aportar a la formación integral de los usuarios ya que su creador no posee los conocimientos suficientes para poder implementar los cinco componentes esenciales que todo entorno virtual debe tener ya sea como herramienta para apoyar las clases o para la educación virtual, esto es sólo un ejemplo de los inconvenientes y el vacío que se presenta al proponer ideas para atacar las complicaciones de las comunidades educativas sin poseer el conocimiento para materializarlas. Este proyecto busca atacar ese vacío que existe articulando un proyecto pedagógico como Arcadia y las metodologías de la ingeniería de sistemas, con el objetivo de que las necesidades y los planteamientos que han surgido en la pedagogía puedan ser resuelto desde la ingeniería, de esta manera beneficiando a la comunidad académica, en este caso específico a los colegios públicos de Bogotá, que es la población a la cual se dirige esta iniciativa.

7

El proyecto espera obtener resultados directamente en el rendimiento académico en el área de compresión y elaboración de textos de los estudiantes de decimo y onceavo grado del IED Alejandro Obregón la cual es la población piloto, se espera que la iniciativa logre extenderse a más colegios de Bogotá. Se busca que el proyecto refuerce las actividades extracurriculares, extra clase y dentro del salón de clases, ya que el nuevo entorno virtual ofrecerá una ayuda al profesor en sus labores de la clase, ya sea el registro de notas, base de datos para actividades, etc. Adicionalmente, apoye la comunicación de los alumnos y los maestros fuera de la clase permitiendo compartir archivos, resolver dudas y realizar seguimiento de las actividades, todo esto enfocado en fortalecer las capacidades y la competitividad de los estudiantes, de esta misma manera se verá beneficiado el profesor agilizando y sistematizando muchas de sus labores. En la ingeniería, el proyecto toma importancia desde el mismo sentido de ser de la ingeniería y del ingeniero, ya que este último “siempre ha estado orientado a la resolución de problemas, y aun lo está” (Krick, 2004, p.56), el simple hecho de que exista una necesidad en la sociedad y esta se pueda atacar utilizando las herramientas que aporta la ingeniería es razón suficiente para tomarse el tiempo y el trabajo de abordar el problema, no se busca en este trabajo decidir si la mejor manera de diseñar una solución es utilizando la base de conocimientos de la ingeniería, se procura plantear el diseño y llevar a cabo una solución que satisfaga las expectativas de las partes implicadas y traiga beneficios a estas mismas. Para Krick (2004) todo ingeniero debe ser especialista en resolución de problemas y este problema traza un reto para los autores de este documento, es importante resaltar que el sitio web que se desea desarrollar no tiene antecedentes en Sudamérica y ponerlo en marcha es aporte importante a los procesos pedagógicos en Colombia. 1.5 Limitaciones y delimitaciones Dentro de las limitaciones de este proyecto, se encuentran variables como las leyes que rigen a Colombia, más específicamente las que tratan temas como las TICs en la educación. Para enmarcar este límite (en este caso positivo para el proyecto), se debe tener en cuenta la ley 1341 del 2009, artículo dos; en el cual se habla del fomento e incentivación de TICs que contribuyan a varios ámbitos, para el caso, el de la educación en Colombia. Las fronteras en los conocimientos de los investigadores, proponen una brecha a romper, debido a que se hace necesario de tiempo extra para llenar los vacíos que se presenten a lo largo de la investigación. Sumado a esta, se encuentran las limitaciones económicas, teniendo en cuenta que los integrantes del grupo de

8

investigación, se encuentran en estratos sociales del uno al dos y dependen económicamente de terceros, lo cual sugiere que a nivel económico el ingreso para el proyecto se verá afectado. De esta forma se procederá a analizar el proyecto pedagógico Arcadia, el cual fue propuesto por Beltrán en su trabajo sobre los juegos de rol y la web 2.0 y puesto en marcha en jóvenes del grado décimo y undécimo en el Colegio Alejandro Obregón. A pesar de que este es un problema que afecta a todos los estudiantes en general, se ha optado por realizar este sistema, en base y como objetivo, los jóvenes entre 14 y 17 años de edad que estén cursando actualmente grado décimo o undécimo de un colegio público de Bogotá, por lo tanto no pretende solucionar el problema con personas mayores o niños para los cuales sería un proceso totalmente diferente. La delimitación geográfica del proyecto estaría dado por lo diferentes colegios públicos de la ciudad. Pero, debido a la extensión territorial de la capital, algunas instituciones presentan particularidades que los alejarían de los límites de la investigación. Por ejemplo, algunas localidades de Ciudad Bolívar en donde se presenta bajo acceso a la tecnología y dinámicas especiales debido a los pocos maestros que pueden llegar a estas zonas. Así la investigación está limitada a las instituciones que compartan contextos similares en sus dinámicas, como en la población que es atendida. Por esta razón y para obtener mejores resultados y valores de comparación significativos para la investigación se trabajará con la misma muestra de estudiantes con el cual el proyecto de Beltrán fue puesto en marcha, esto nos da otra limitante como lo es la disponibilidad del grupo de estudiantes a su cargo para la recolección de datos. 1.6 Alcance El principal propósito de este proyecto es determinar la medida en la cual un entorno virtual de aprendizaje desarrollado bajo una metodología ágil (Scrum) y aplicando un modelo de diseño de Software (MVC) se puede llegar a afectar el proceso pedagógico bidireccional en la Institución Educativa Distrital Alejandro Obregón en la localidad de Rafael Uribe Uribe, esto va directamente relacionado con la pregunta

9

de investigación que se postuló en planteamiento del problema (sección 1.3), debido a que la naturaleza de este proyecto es multidisciplinar y está ligado con el trabajo en el campo de la pedagogía realizado por Beltrán (2015), necesariamente el propósito final tiene una estrecha relación entre la visión ingenieril que procuran aportar los autores de este documento y la parte pedagógica en la cual no se desea profundizar ya que esta parte fue estudiada previamente por Beltrán (2015); el fin de esta investigación es apoyar los procesos pedagógicos para mejorar la educación colombiana y brindar a los jóvenes colombianos más herramientas para poder competir en un mundo globalizado y los actuales ambientes laborales, desde ese objetivo se plantea la población a la cual va dirigido este proyecto, los cuales son estudiantes de grados décimo y once que están bajo la tutoría del docente Luis Carlos Beltrán, esta población cobra importancia ya que son los jóvenes los cuales en un futuro inmediato se van a enfrentar al reto universitario y requieren poseer la mayor cantidad de competencias, resulta de vital importancia poseer muy buenas capacidades de comprensión y creación de textos. Como se puede ver el proceso de mejoras que se va a realizar a Arcadia no es el fin de este proyecto, ya que Arcadia solo es una herramienta que se utiliza tanto para apoyar a los procesos educativos como a la recolección de datos, con la información captada se realiza un análisis a profundidad en el rendimiento académico de los miembros participantes y en la experiencia vivida por Beltrán durante este proceso, lo cual convierte a Arcadia en un medio para conseguir y apoyar el objetivo principal de la investigación de Beltrán que radica en mejorar los procesos pedagógicos bidireccionales en la I.E.D. Alejandro Obregón, por lo tanto el alcance está definido en dos etapas, la primera etapa está en el proceso de análisis y desarrollo de Arcadia, seguido por la segunda etapa que busca desplegar a Arcadia, utilizarla en un ambiente controlado bajo la supervisión de Beltrán y una fase final de análisis de todos los datos captados durante esta etapa, es importante definir el tiempo que va a durar la segunda etapa ya que puede llegar a ser tan larga como se desee y los creadores de este documento no cuentan con el conocimiento suficiente para tomar decisiones de ese tipo, por lo tanto se consulta con Beltrán y él define que un tiempo prudente para la segunda etapa son 2 meses que equivalen a un bimestre en el proceso educativo Colombiano. A partir de este proyecto se pueden desprender muchas oportunidades como la integración de otros miembros muy importantes de la comunidad académica como son los padres de familia, este punto específico no se desea abordar dentro de esta investigación pero si se pretende dejar unas bases suficientemente sólidas para planificar una futura extensión a Arcadia desarrollando un módulo para padres en el cual estos puedan seguir el trabajo de sus hijos y hacer parte activa del aprendizaje de sus hijos; así mismo nace la inquietud del porqué no incluir otras materias de vital importancia como historia o matemáticas, el punto de vista es similar al anterior ya que la idea es dejar el terreno listo para la inclusión de más contenido referente

10

a otras asignaturas sin embargo en este momento se desea solo trabajar el área de español (lectura y escritura) debido a que se posee un fuerte apoyo de Beltrán el cual es profesional y especialista en esa área del conocimiento, por otro lado la inserción de más contenido de diferentes materias se tendría que desarrollar de la mano de especialistas, debido a que los requerimientos y las necesidades pueden variar de una materia a otra.

11

Capítulo 2. Marco Teórico El segundo capítulo trata el sustento teórico en el cual está basado este documento, se centra en dos metodologías de desarrollo ágil y la idea de cómo algunos autores han logrado implementar una unificación de prácticas entre estas dos metodologías, en segundo lugar se describe que es un entorno virtual de aprendizaje profundizando en los tipos que existen y sus usos, finalmente se aborda el tema de desarrollo web con una tecnología específica y un modelo que se desea implementar. 2.1 Metodologías ágiles Un proceso ágil de software debe adaptarse de forma incremental (Pressman, 2010), para una metodología ágil es importante que el avance sea continuo y visible para el cliente, al referirse a visible desde el punto de vista del cliente se quiere decir que el cliente pueda palpar el progreso, para los ojos del cliente que el proyecto posea diagramas o calendarios definidos no es siempre un avance significativo, pero un producto que se pueda probar y se pueda utilizar siempre es un avance, esta una de las características más notables de una metodología ágil que es la entrega continua de resultados al cliente, esto toma importancia desde dos ángulos, el primero es que el cliente siente la evolución de su producto con una alta frecuencia y así mismo él puede realizar observaciones sobre sus impresiones del producto para generar retroalimentación de tal manera que el cliente genera un aporte continuo en la realización del producto y este mismo se adapta más a las expectativas iniciales. Para las metodologías ágiles se emplean los procesos de desarrollo y diseño al tiempo, esto va desde su misma filosofía en la cual no se planea todo desde un inicio, es decir se diseña la solución y luego se aplica, para una metodología ágil se planea sobre la marcha y se aplica inmediatamente (Pressman, 2010), igualmente cada vez que se obtiene una retroalimentación por parte del cliente o por parte del medio externo estas se aplican con la mayor prontitud posible, cuando se habla de ágil se hace referencia a la capacidad de adaptación por lo tanto estas metodologías deben tomar el cambio como algo natural y aprovechar las ventajas que ofrece el cambio continuo como lo es la retroalimentación.

12

2.1.1 Scrum Scrum es una metodología ágil que aporta un marco de trabajo en el cual se le brinda especial énfasis a las relaciones entre los roles, eventos y artefactos (Schwaber & Sutherland, 2013). Los proyectos dirigidos bajo Scrum poseen como núcleo a los equipos Scrum que están compuestos por el dueño del producto, el master Scrum y el equipo de desarrollo, el equipo Scrum se auto dirige y auto controla de tal manera que se pueda fomentar la creatividad y la productividad, los equipos de Scrum deben ser flexibles para poderse adaptar a los tres pilares de Scrum que son la transparencia, la inspección y la adaptación. El primer componente del equipo Scrum es el Dueño del Producto el cual tiene como función administrar la lista del producto, desde incluir los contenidos en la lista hasta asegurarse que todos los miembros del equipo de desarrollo entienden la lista del producto, las decisiones que tome el dueño del producto deben dar valor al trabajo del equipo de desarrollo y estas mismas se deben acatar por parte del equipo de Ilustración 1. Ciclo de vida de Scrum. Tomado de Jared Erickson en el sitio web http://calvinx.com/wp-content/uploads/2014/05/scrum-overview-mark-hoogveld.jpg (Fecha de actualización 25/04/2015).

http://jarederickson.com/

13

desarrollo, del cumplimiento de esta relación Dueño del Producto – Equipo de Desarrollo depende en gran medida el éxito del proyecto. El último miembro es el Scrum Master el cual hace el símil al “coach” en XP, su principal función es cerciorarse que todos los demás miembros estén trabajando bajo el marco de Scrum, entre sus responsabilidades se encuentran mantener la agilidad al interior del equipo Scrum, asegurarse que el equipo de desarrollo siga estando organizado y ayudar en los problemas internos. Scrum posee un ciclo de vida al igual que todas las metodologías de software, en la Ilustración 1 se muestra el resumen del ciclo de vida, adicionalmente se gráfican los elementos que componen el equipo de Scrum, los principales componentes que utiliza Scrum como la lista de producto y muestra el término “Sprint” que se va a revisar a continuación. El trabajo dentro de Scrum se divide en Sprints que por definición en el manifiesto ágil tienden a durar entre dos semanas y un mes, cada Sprint tiene una serie de objetivos claros y al final de este se debe entregar una mejora o incremento del producto, un Sprint contiene eventos los cuales tienen duraciones definidas y objetivos que deben aportar a conseguir el objetivo final del Sprint, una parte vital del Sprint es la reunión de planificación en la cual se reúnen los tres integrantes del equipo Scrum y definen cuál es el incremento (el objetivo del Sprint) y cómo lograr el incremento. 2.1.2 XP La aplicación de la metodología XP se da cuando los grupos de trabajo son pequeños o medianos y los requerimientos del usuario no son claros, por lo tanto pueden cambiar en el tiempo, esto es una problema en las metodologías prescriptivas (como cascada) ya que desde un principio se definen arquitecturas y marcos bajo los cuales ese lleva a cabo todo el trabajo siguiente, mientras que XP asume los cambios con naturalidad (Calabria & Piriz, 2003), como es un ambiente de trabajo cambiante se requieren fuertes y fiables canales de comunicación entre las diferentes partes, en esta comunicación se requiere que el cliente intervenga continuamente ya sea para aclarar ideas o para realizar pruebas.

14

En XP el cliente debe estar al corriente del estado actual del trabajo, por ello se debe encontrar la manera de mantener al cliente siempre informado evitando lenguaje técnico que se le dificulte entender y usando metáforas u otras técnicas para lograr este fin (Kniberg, 2015), la retroalimentación que proporciona el cliente es vital, esta tiene una gran prioridad al momento de realizar cambios ya que el cliente es el encargado de aclarar la finalidad del sistema. Otra parte del grupo de trabajo de XP es el Coach el cual se responsabiliza de que las prácticas de XP se realicen de manera correcta, por sus hombros pasa que el proyecto sea en realidad un proyecto XP y que los programadores, el manager, los encargados de pruebas, los clientes y el consultor externo trabajen bajo la misma sintonía. El ciclo de vida de XP es de manera iterativa, esto se puede apreciar en la Ilustración2, inicia en la fase de exploración que es donde el cliente registra sus requerimientos y las funcionalidades que desea que tenga el sistema en story cards, al mismo tiempo el equipo de trabajo tiene que plantear la tecnología y la mejor manera de manejar XP en el proyecto, el siguiente paso es la fase de planificación en donde se recolectan, organizan y clasifican las story cards del cliente para darles prioridades y poder planificar el trabajo en un cronograma, las entregas no pueden superar los dos meses u ocho semanas. Ilustración 2. Ciclo de vida de XP. Tomada de Software Engineering A Practitioner`s Approach (7ma ed.), Roger Pressman, New York: McGraw Hill. pag. 74.

15

La tercera fase es la primera fase iterativa y su mismo nombre la define así, iteración por entregas, cada iteración dura entre una y dos semanas, de tal manera que cada entrega se divide en iteraciones, al inicio del proyecto cada iteración toca temas genéricos y a medida que el tiempo pasa se abarcan temas más específicos, la idea es que el cliente bajo sus prioridades define en que story cards se debe trabajar primero. Antes de que se realice una entrega se entra en fase de producción en donde se realizan pruebas con el objetivo de entregar el mejor trabajo al cliente, una vez se realiza la primera entrega el cliente realiza sus pruebas y entrega una retroalimentación para tener en cuenta en las siguientes iteraciones, por eso en cada ciclo posterior se tiene una fase de mantenimiento y por último se tiene una fase de muerte ya sea porque el trabajo llegó a su fin de manera exitosa o de manera catastrófica. 2.1.3 Uniendo Scrum y XP Scrum se enfoca en las prácticas de organización y gestión, mientras que XP se centra más en las prácticas de programación (Kniberg, 2015), Scrum y XP al ser dos metodologías con diferentes enfoques de profundización se pueden unir ciertas prácticas destacadas de cada una para complementar los diferentes procesos, los más destacado de Scrum son su capacidad organizativa de los grupos de trabajo y la gestión de los Sprints, por otro lado XP utiliza prácticas como la programación en parejas que tienen tantas ventajas como desventajas dependiendo de los recursos humanos y de la manera como se realice (Kniberg, 2015). Una práctica realmente importante de XP que tiene cabida dentro de la estructura organizada de Scrum es el desarrollo guiado por pruebas, la actividad que sustenta el desarrollo guiado por pruebas es el diseñar pruebas automatizadas antes de crear código de tal manera que apenas esté implementado el código, este deba pasar las pruebas diseñadas anteriormente, no es una práctica sencilla ya que requiere más tiempo y no siempre es fácil diseñar casos de prueba pero es fructífera ya que se puede tomar como un primer filtro de errores, esto debe estar a la par del código abierto para todos los desarrolladores, Scrum busca la transparencia en muchos niveles del desarrollo (Kniberg, 2015), incluyendo la transparencia en el código y que todo el equipo de trabajo pueda ver y aportar al código, estas prácticas pueden funcionar como otro filtro disminuyendo posibles problemas futuros. 2.2 Entornos virtuales de aprendizaje Un entorno virtual de aprendizaje es un término muy amplio debido a que abarca una gran gama de herramientas que se utilizan en la educación a distancia o que no es presencial, Marters los define como la solución técnica a los problemas de

16

educación a distancia (Marters & Achten, 2008), los parámetros para usar en entorno virtual de aprendizaje dependen completamente de lo que requiera el profesor o educador, debido a esto existen 2 tipos de entornos, los asincrónicos y los sincrónicos, los dos están enfocados a solucionar el problema ubicación espacial de estudiantes y profesores, la diferencia marcada está en la variable temporal, los sincrónicos buscan reunir las partes en un entorno virtual al mismo mientras que el asincrónico no requiere que los interesados dispongan de los mismos horarios para poder trabajar. Kolb define cuatro fases de aprendizaje, las experiencias concretas, las observaciones y reflexión, la formación de conceptos y generalizaciones abstractas, y los conceptos de prueba en situaciones nuevas, un entorno virtual de aprendizaje es un tipo de sistema informático que soporta un alumno en las cuatro etapas del ciclo de aprendizaje de Kolb (Marters & Achten, 2008), la implicación de esto es sumamente profunda ya que no cualquier sitio web puede cumplir con estas características, el entorno virtual de aprendizaje debe servir al docente como puente para un ciclo de enseñanza completo en el que los dos puedan participar de manera activa y compartir toda clase de información. 2.2.1 Componentes de los entornos virtuales de aprendizaje Scagnoli (2005) define cinco componentes esenciales que todo entorno virtual debe tener ya sea como herramienta para apoyar las clases o para la educación virtual, en primera medida se debe tener una forma correcta de distribuir la información, con esto se refiere a que el entorno virtual tiene que estar en la capacidad de servir como plataforma para que el docente pueda publicar contenido en diferentes formatos, ya sean documentos, imágenes, videos, audios, etc. pero no solo basta con publicar información, se requiere que la información se pueda encontrar fácilmente, que el docente pueda evaluar a los alumnos y que todos puedan compartir ideas, contenido, gustos o lo que la persona desee mientras no infrinja ninguna ley o regla definida por los participantes, esto va de la mano del segundo elemento que es tener una plataforma para el intercambio de ideas y experiencias, por lo tanto los dos primero elementos son complementarios desde herramientas como foros y chats. El tercer elemento que no puede faltar en ningún entorno virtual de aprendizaje es la aplicación y la experimentación de lo aprendido, esto es una implicación profunda y va de la mano de la afirmación de Kolb (Marters & Achten, 2008) en el que el entorno virtual tiene que estar en la capacidad de cubrir todas las fases del

17

aprendizaje, por lo tanto se deben tener las herramientas que permitan al estudiante hacer simulaciones, comparar resultados y demostrar sus conocimientos; el cuarto elemento es la evaluación, como en la misma educación y según Kolb la evaluación debe ser natural y hacer parte de manera innata en los entornos virtuales de aprendizaje, el alumno podrá realizar evaluaciones y estas deben ser corregidas dándole retroalimentación al estudiante. El último elemento, el cual según Scagnoli (2008) es el más importante ya que todos y cada uno de los elementos del entorno virtual requieren tenerlo, este elemento es la seguridad y confianza del sistema, la seguridad de la información es parte fundamental, los miembros tienen información personal como teléfonos, nombres, fechas y direcciones físicas, de aquí nace la necesidad de que esta información solo pueda ser consultada por quienes tienen permiso y que esta información no sea usada con otro fin que no sea el educativo, de esta misma manera el entorno virtual es un ambiente académico y por lo tanto el contenido debe ser cuidado de manera rigurosa. 2.2.2 Algunos tipos de entornos virtuales de aprendizaje Una herramienta que se utiliza como entorno virtual de aprendizaje son las aulas virtuales, un aula virtual es un instrumento para llevar a cabo una sesión de clase por internet (Schlusmans, Giesbertz, Rusman, & Spoelstra, 2009), para este tipo de entorno virtual se requieren herramientas que permitan la interacción en tiempo real ya que trata de emular una clase presencial, por lo tanto es de tipo sincrónico debido a que soluciona únicamente el problema de la distancia, algunas herramientas usadas en las aulas virtuales son los pizarrones virtuales en los cuales el profesor puede dibujar o escribir y los alumnos pueden ver el pizarrón, las cámaras web para ver al profesor y este a los alumnos o salas de videoconferencia en las cuales se reúnen los alumnos y se proyecta la clase que imparte el profesor. Los Moodle (Modular Object-Oriented Dynamic Learning Environment) son plataformas de aprendizaje para interacción asincrónica entre estudiantes y profesores, en este entorno los profesores pueden colocar documentos, tareas o cualquier tipo de información a disposición de los estudiantes los cuales siguen unas pautas establecidas para trabajar con el material que aporta el profesor, luego el estudiante demuestra resultados al profesor utilizando el mismo moodle de una manera similar a la cual utilizó el profesor para publicar la información, entre las herramientas que utiliza un Moodle se encuentran los foros en los cuales se pueden

18

enTablar discusiones y es común encontrar un repositorio de archivos con el cual se realiza la transferencia de información entre alumnos y docentes. Estos dos tipos de aulas anteriormente mencionadas son una forma de clasificar los entornos virtuales de aprendizaje, otra clasificación diferente son los sitios síncronos y asíncronos, esta clasificación se basa en la concurrencia de los participantes, para Bonilla (2010) un entorno virtual asíncrono es “un entorno virtual en el que existirá una separación tanto espacial como temporal entre el docente y los alumnos, por el contrario los sistemas asíncronos son aquellos en los que existe únicamente una separación espacial”, los sistemas síncronos son muy utilizados en la educación virtual debido a que permiten hacer comunicación en vivo teniendo mucha semejanza con las clases presenciales. 2.2.3 Usos de los entornos virtuales de aprendizaje Los usos de los entornos virtuales de aprendizaje se pueden agrupar en dos clasificaciones, el primero es como apoyo directo a las aulas de clases y como elemento para la educación a distancia, en el segundo tipo de uso en entornos virtuales toman un papel completamente protagónico ya que es único medio de comunicación y este debe suplir absolutamente todas las necesidades de los miembros participantes, así mismo todos los servicios están centralizados y se vuelcan sobre este, sin importar si el tipo de clases son síncronas o asíncronas toda la responsabilidad de mantener el contenido del curso (notas, tareas, discusiones, etc.) recae sobro el entorno virtual por lo tanto debe poseer una alta disponibilidad. Por otro lado el primer uso son los entornos virtuales como acompañantes o apoyo para las aulas de clases, es un caso completamente diferente ya que las exigencias en cuanto a disponibilidad son menores, el papel protagónico que ocupan en la educación a distancia se ve drásticamente reducido en comparación con los entornos virtuales como acompañantes de clase, ya que el entorno virtual no va a ser el único punto de reunión entre los participantes y la experiencia de las clases no recae totalmente sobre este, el entorno virtual puede llegar a tener los mismos servicios que se implementan en la educación a distancia o solo algunas funcionalidades o fragmentos de estas funcionalidades, por ejemplo se puede utilizar como pizarra para novedades, compartir archivos, etc. Como en este caso el entorno virtual apoya los procesos y las actividades desarrolladas en clase, tiende a ser muy común que los alumnos pierdan interés y no visiten el sitio, para Scagnoli (2005, p.1) el uso del hipertexto es esencial para atraer a los alumnos al entorno

19

virtual, en el siguiente apartado se profundiza en los entornos virtuales asíncronos debido a que Arcadia pertenece a esta clasificación. 2.2.4 Sobre los entornos virtuales asincrónicos Los entornos virtuales asincrónicos pueden ser usados para mejorar el aprendizaje, esto puede ser logrado a través de la combinación de aprendizaje activo y construcción de conocimiento (Kumar & Kandasamy, 2011), esta afirmación es sustentable desde las posibilidades que se forman en los entornos asincrónicos, la primera característica destacable es la opción de discutir y debatir a través de mensajes en los que todos los participantes pueden intervenir, esto incrementa el trabajo colaborativo, permite el uso de habilidades colaborativas y promueve la construcción de conocimiento de una manera social (Kumar & Kandasamy, 2011). Un factor realmente importante es el tiempo, el cual ya no se restringe a unas horas establecidas como en la educación presencial, el ciclo virtual tiene la ventaja de estar disponible las 24 horas del día dando flexibilidad a la combinación de deberes ya sean familiares o personales con el tiempo empleado en educación. Es importante reconocer que un entorno virtual asincrónico está abierto a las críticas por los medios que utiliza, pero en el momento en que se utiliza como una herramienta complementaria a la clase presencial es capaz de servir como fuente de retroalimentación para el profesor y una vía de comunicación alterna de los estudiantes, la característica más destacada es la capacidad de comunicación que ofrece un entorno virtual asincrónico. Dillenbourg define un entorno virtual como un espacio social, “un libro no es un entorno virtual, pero leer el mismo libro en un seminario, discutirlo con otros estudiantes, escribir un resumen para el tutor… constituye un entorno virtual de aprendizaje” (Dillenbourg, 2000), el entorno virtual permite la libre expresión y el libre trabajo de los miembros participantes, convierte la comunicación en algo completamente natural y obligatorio para poder participar en el entorno virtual, en muchas ocasiones este mismo sirve como escudo para que la persona pueda dar a conocer sus ideas de una manera más franca que si estuviera hablando frente a sus compañeros de manera presencial, da la oportunidad al profesor de analizar más a fondo a sus alumnos y encontrar mejores maneras de acercarse y mejorar el proceso de enseñanza bidireccional. Bonilla (2010, p.3) define una serie de ventajas que poseen los entornos virtuales síncronos, entre las ventajas más importantes es que sirven para hacer clases en directo, las sesiones son conducidas por el docente, permite una interacción directa entre todos los miembros participantes y facilita la conexión entre alumnos que se

20

encuentran en diferentes zonas geográficas, estas son ventajas que realmente no pueden suplir lo sistemas asíncronos, sin embargo Arcadia no se diseña con el objetivo de ser síncrono, su finalidad es apoyar las clases presenciales, ya que estas si suplen las funcionalidades anteriormente nombradas a excepción de facilitar la conexión entre miembros de diferentes zonas geográficas que para este caso Arcadia si está en la capacidad de suplir esta falencia, se define que Arcadia junto con las clases presenciales están en la capacidad de suplir las cuatro fases del aprendizaje de Kolb (Marters & Achten, 2008) y poseen las mismas ventajas de los sistemas síncronos propuestas por Bonilla (2010), con base en estas teorías se sustenta el diseño asíncrono de Arcadia siendo que los sistemas síncronos presentan mayores ventajas que los asíncronos. 2.3 Trabajos Relacionados El aprendizaje a través de juegos por computadora o de plataformas enfocadas al aprendizaje de los estudiantes de forma didáctica se ha estado estudiando alrededor del mundo en los últimos años, en estos momentos podemos evidenciar una gran cantidad de webs enfocadas al aprendizaje tanto de niños, como jóvenes-adultos. Estas plataformas se dividen según su coste de adquisición en licenciadas y de recurso educativo abierto, permitiendo así que múltiples usuarios puedan acceder a estas tecnologías, unas de las más utilizadas a nivel global son Blackboard, Dokeos, Sakai, Moodle, Almagesto, WizIQ, Edmodo, Pizarra entre otras. Además de juegos educativos utilizados para captar el interés de los más pequeños y de los estudiantes con déficit de atención de estos juegos se pueden nombrar Monkey Tales, Foolish Lady, Proyecto Kokori y juegos diseñados para la programación. En el ámbito Colombiano el Ministerio de Tecnologías de la información y las Comunicaciones ha impulsado la creación de portales web y juegos para la educación de los cuales se destacan Ukanbook, Saberes, Ingeniosos, GAIA, Yo investigador, Tropicapp y Kogui entre otros. A continuación se describirán algunas plataformas y juegos anteriormente mencionados.

21

2.3.1 Monkey Tales Monkey Tales o “cuentos de mono” en su traducción al español, es una serie de juegos matemáticos enfocados al desarrollo de las competencias matemáticas que los niños ven en la escuela primaria. El juego cuenta con diferentes versiones cada una orientada a una habilidad matemática específica, en el que los niños podrán divertirse e ir fortaleciendo las habilidades aprendidas. El objetivo de los juegos de Monkey Tales no es instruir, sino ayudar a los niños a ensayar y mejorar las habilidades que deben tener, estableciendo si un niño se encuentra en la curva de aprendizaje y motivándolos a practicar llevándolos cada vez por ejercicios más complejos (Derboven, Zaman, Vissers, & Geerts, 2015). 2.3.2 Aplicación Pizarra Los entornos virtuales forman parte de las experiencias de aprendizaje de los estudiantes y muchas de estas han abordado el tema de la colaboración, una de las aplicaciones que se ha vuelto común con la introducción de la web 2.0 son las llamadas pizarras interactivas las cuales proporcionan una plataforma alternativa para el aprendizaje (Nyarko & Ventura, 2010). Las aplicaciones con servidores pizarra tienen como objetivo replicar un entorno de tutorial en un grupo pero en una plataforma virtual añadiendo como ventaja el tiempo y el espacio independientes, ya que los usuarios pueden utilizar esta aplicación en cualquier momento y en cualquier lugar con solo una conexión a internet. 2.3.3 Videojuego educativo enfocado al teatro clásico El videojuego presenta una historia clásica de teatro como lo es Foolish Lady “(La Dama Boba)” basada en la homónima obra de teatro clásico de español dramaturgo Lope de Vega. El juego tiene como objetivo ser un dispositivo para aumentar el interés de los jóvenes por el teatro, la historia, conocimientos lingüísticos y el conocimiento de la obra (Manero, Torrente, Serrano, Martinez, & Baltasar, 2015). Un estudio realizado con este videojuego en 754 alumnos de 8 escuelas de Madrid en España divididos en 1 grupo experimental que uso el videojuego y 2 grupos de control que tenían clases tradicionales, lograron mostrar en sus resultados que el

22

juego de video incrementaba el interés de los estudiantes por el teatro y mantenía resultados similares en la mejora de conocimiento sobre la trama de la obra y algunos conceptos lingüísticos, esto permite que se abra un nuevo horizonte a los videojuegos como motivadores en diferentes ámbitos artísticos. 2.3.4 Juego Adaptativo para enseñar SQL El juego desarrollado para enseñar lenguaje SQL (Structured Query Language) de bases de datos, está compuesto por 3 modos los cuales tienen como objetivo mostrar cómo la enseñanza adaptativa basada en juegos es una herramienta que ayuda a los estudiantes a tener mejores resultados en su aprendizaje. Los modos antes mencionados son el modo de no adaptabilidad, un modo que se personaliza mediante el perfil encontrado a través de una encuesta y el modo de adaptabilidad dinámica el cual se personaliza según la interacción que tenga el usuario con el juego (Soflano, Connolly, & Hainey, 2015). 2.3.5 Blackboard (Clarenc & S. M. Castro, 2013) Es un sistema de gestión de aprendizaje en línea, el cual representa un ambiente de integración entre tutor y participante. Esta es una plataforma educativa de tipo comercial o licenciada y ha sido utilizada por diversas instituciones educativas en más de 60 países de todo el mundo. Es la plataforma utilizada por el Servicio Nacional de Aprendizaje de Colombia, la Universidad de Colombia, La Universidad de los Andes y la Universidad Autónoma de Puebla México. Blackboard provee a sus usuarios de construcción de comunidades, manejo y colaboración de contenidos, enseñanza y aprendizaje, experiencias colaborativas y compromiso de mejora continua además de contar con los parámetros de accesibilidad de acuerdo a las normas propuestas por WorldWide Web Consortium (W3C). 2.3.6 Dokeos (Universidad Internacional de Valencia, s.f.) Dokeos, es un creador de soluciones de e-learning y una empresa de servicios con un enfoque de ayuda a las empresas, proveedoras de formación y las

23

multinacionales con sus proyectos de formación en línea. Con 15 años en el mercado, es un software pionero en técnicas y metodologías en línea en el sector de la educación universitaria en lengua francesa. Dokeos ha incorporado los avances tecnológicos y las oportunidades estratégicas en sus soluciones que permiten la virtualización de servicios y prácticas profesionales. En la oferta de servicios, se adapta a las nuevas necesidades y cambios en las prácticas de negocios: el aprendizaje informal, las redes sociales de negocios, el aumento de la movilidad y la reubicación del personal. 2.3.7 Ingeniosos (MINTIC, 2015) 'Ingeniosos' es una plataforma web para niños, padres y docentes que les permite acercarse, aprender, divertirse con la tecnología y construir robots, hacer experimentos con materiales sencillos y comprender de manera lúdica cómo funciona la tecnología, así como compartir con la comunidad sus avances e inventos. A los docentes les ayuda a complementar sus clases con actividades lúdicas y didácticas de manera que sus estudiantes aprendan a diseñar proyectos de aplicación de conceptos difíciles en la parte teórica, pero divertidos en lo práctico; y a los padres de familia, les posibilita afianzar sus lazos de unión con los hijos en los momentos de estudio, y aprender junto a ellos. 2.3.8 Edmodo (Clarenc & S. M. Castro, 2013) Se puede definir como la combinación entre una plataforma educativa y una red social la cual promueve la interacción entre profesores y alumnos de forma segura y privada. En la actualidad Edmodo cuenta con tres millones de usuarios en todo el mundo, permitiendo a sus usuarios establecer claras jerarquías entre profesores y alumnos, crear diferentes grupos y subgrupos para la organización de los alumnos y proporcionar un sistema de evaluación continua formado por tareas que el profesor cuelga en el muro de la plataforma.

24

Capítulo 3. Metodología El crecimiento que ha tenido la tecnología en los últimos años ha impulsado al software a ser una de las tecnologías más importantes en el ámbito mundial (Pressman, 2010). El proyecto Arcadia está diseñado para aprovechar el incremento y aceptación que ha tenido la tecnología y las plataformas educativas en el sector colombiano. La metodología de investigación de este proyecto será llevada a cabo siguiendo los lineamientos propuestos por Sampieri (Sampieri, Collado, & Baptista, 2006) y el proceso de desarrollo seguirá el marco general de la ingeniería de software el cual nos provee actividades genéricas como lo son la comunicación, planeación, modelado, construcción y despliegue. Estas actividades son utilizadas como base en la mayoría de procesos de software, y en el proyecto Arcadia guiarán el desarrollo del entorno virtual para que este cumpla con la calidad y los objetivos anteriormente mencionados. Las actividades de la ingeniería de software son tratadas de diferente manera según el modelo y el ciclo de vida que se use en su desarrollo, la forma en que este proyecto trata estas actividades además de la arquitectura, los lenguajes de programación, la medición y los recursos disponibles para llevar a cabo la investigación será abordada en los siguientes apartados de este capítulo. 3.1 Implementación de Scrum y XP La importancia al momento de escoger la metodología o el conjunto de metodologías bajo las cuales se rige un proyecto de software es vital ya que no todos los proyectos poseen las mismas necesidades, enfoque, prioridades, tiempos o costos, una mala decisión al momento de elegir una metodología puede llevar a mal puerto toda una gran idea (Pressman, 2010). Para este proyecto en específico se escoge la utilización de Scrum como metodología base gracias a que es una metodología ágil que se ajusta a los tiempos y recursos disponibles para este proyecto, en los siguientes párrafos se exponen a fondo las razones por las cuales Scrum cubre con las necesidades básicas de este proyecto y por qué utilizar XP para fortalecer determinados puntos que se consideran realmente importantes para la culminación exitosa de este, adicionalmente se presenta la forma en que se implementan estas metodologías.

25

Scrum se enfoca primordialmente en las prácticas de organización y gestión mientras que XP se centra más en las prácticas de programación (Kniberg, 2015), esta es la razón de que se pueda trabajar con la unión de estas. La organización de Scrum se divide en tres diferentes roles para abarcar las responsabilidades dentro del proyecto, el primero el Dueño del Producto el cual para este caso específico es el docente Luis Carlos Beltrán, este se encargara de ser la voz del cliente además de mantener y priorizar las tareas del backlog las cuales deben estar acompañadas de las historias de usuario especificando el comportamiento del requerimiento planteado, el segundo rol es el Scrum Master que en este proyecto será el Profesor Carlos Montenegro este proporcionara las debidas bases para que el tercer rol como lo es el equipo de desarrollo cumpla el lineamiento que provee Scrum. El equipo de desarrollo es el encargado de escribir y probar el código, en esta parte es donde teniendo en cuenta la cantidad de personas del proyecto que en este caso son dos personas que tienen la responsabilidad de todos los temas relacionados, desde el diseño hasta la liberación final del software, se implementa una articulación con XP y su idea de programación por pares la cual presenta una buena propuesta de cómo una pareja de programadores se coordinan para trabajar como equipo, al tener 2 personas concentradas sobre el mismo código se evitan errores y ahorra tiempo en futuras correcciones (Calabria & Piriz, 2003), como lo sustenta Calabria esta práctica ahorra tiempo a futuro mas no en el presente, en el cual se podría dividir el trabajo y cada persona se encarga de diferentes labores por lo tanto no hay un filtro inmediato y los errores cometidos en el presente se reflejan en el futuro, en contraste con la programación por pares se invierte más tiempo en las tareas tempranas y el hecho de que exista una retroalimentación inmediata evita errores en el futuro. Las funcionalidades principales que se desean en el nuevo diseño de Arcadia son esenciales para cumplir con los componentes de los entornos virtuales por lo tanto la seguridad y el manejo de la información por medio de una base de datos es primordial al momento de implementar el proyecto, la creación de Reinos (cursos) y la vinculación de los estudiantes por medio de Personajes o Avatares que puedan tener una personalización a lo largo que se avance en el curso permiten dar el énfasis de juego de rol que se desea para este proyecto, además de esto la implementación de un módulo de actividades y tareas interactivos que permita a los estudiantes ganar nivel (nota), recompensas y honores que le permitirán personalizar su personaje son partes importantes del desarrollo del entorno virtual propuesto. La definición de cada Sprint se aborda en los siguientes apartados, cada Sprint posee unos determinados componentes y una estructura propia que se desglosa durante el desarrollo.

26

3.2) Desarrollo de la metodología. Con respecto a la medición de esfuerzo en este proyecto se va a implementar la métrica en horas, lo que implica que cada historia de usuario y cada tarea se evalúa basados en horas de trabajo, por tal razón la métrica de esfuerzo se mide en horas. Un aspecto importante es la definición de personas encargadas o responsables de cada tarea durante todo el proceso, para tal fin las personas encargadas se muestran en la Tabla 1, en la definición de cada sprint se hace referencia a esta Tabla al momento de delegan tareas. ID Nombre 1 Brayan Julián Barbosa 2 Pablo Andrés Esteban Tabla 1 Miembros del equipo de desarrollo 3.2.1) Definición del Product Backlog A continuación se muestran las historias de usuarios en la Tabla 2, estas fueron entregadas por el docente Luis Carlos Beltrán, son un total de doce (12) requerimientos los cuales están ordenados y enumerados de acuerdo a la prioridad donde 1 representa la mayor prioridad y 5 la menor prioridad, la columna de esfuerzo se mide en horas de trabajo. Product Backlog ID Historia de Usuario Prioridad 1000 Yo como cliente deseo que los alumnos y profesores se puedan inscribir en la plataforma, para así poder guardar los perfiles y la información de cada uno. 1 1001 Yo como cliente deseo que los profesores puedan crear reinos para de esa manera asociar un reino a una materia o a un curso. 1

27

1002 Yo como cliente deseo que los estudiantes se puedan inscribir en los reinos para así hacer el seguimiento de las actividades académicas del estudiante. 1 1003 Yo como cliente deseo que el reino sea un mapa el cual este divido en 5 regiones para organizar el contenido y la programación del curso. 1 1004 Yo como cliente deseo que el profesor pueda crear actividades, estas deben estar dentro de alguna de las 5 regiones del reino para poder ser asignadas como tareas. 2 1005 Yo como cliente deseo que el profesor pueda calificar las actividades, por lo tanto se debe poder darle un porcentaje a las actividades y una nota para poder medir el rendimiento de los alumnos. 2 1006 Yo como cliente deseo ver las actividades en una lista, con las notas de las actividades de los estudiantes, poder filtrar y ordenar, así mismo deseo poder añadir notas que reflejen actividades en el salón de clase, se deben sacar promedios y notas finales ponderadas por las notas parciales, para poder utilizar la plataforma como administrador de notas. 2 1007 Yo como cliente deseo que los estudiantes puedan ver las actividades y puedan resolverlas, ya sea subiendo una serie de archivos o directamente en la plataforma, para permitir que el estudiante demuestre su progreso en los temas vistos en clase. 3 1008 Yo como cliente deseo que el reino tenga una galería, en la galería se deben poder colocar imanes, documentos y videos de YouTube. 3 1009 Yo como cliente deseo que el sistema ponga recordatorios cuando las actividades estén por vencerse y cuando existan actividades nuevas en los perfiles de los estudiantes y profesores para visualizar novedades y noticias importantes. 4 1010 Yo como cliente deseo poder generar actividades tipo cuestionario, para lo cual se requiere un banco de preguntas, el cuestionario se debe calificar automáticamente. 4 1011 Yo como cliente deseo que los estudiantes puedan tener una clase o una raza, esta debe cambiar el aspecto gráficos dentro del juego, el nivel debe ser con respecto a la clase y a la nota en el reino. 5 Tabla 2 Product Backlog 3.2.2) Definiciones de Hecho En Scrum una vez se ha definido el Product Backlog debe existir un parámetro de medición para cada una de las historias de usuario, Kniberg define un componente llamado “How to Demo” (Kniberg, 2015), este componente busca definir una forma de exponer el trabajo realizado durante el sprint, el Product Onwer define el “How to Demo” de tal manera que pueda ver resultados o tener resultados tangibles al finalizar el Sprint, otra forma de garantizar que el cliente reciba el producto esperado

28

es con la definición de hecho (Álvarez Garcia, de las Heras del Dedo, & Lasa Gómez, 2012), la definición de hecho es un aspecto bajo el cual se va a evaluar el trabajo realizado a una historia de usuario, una historia de usuario esta completada cuando cumple con todos las definiciones de hecho, por lo tanto una historia de usuario debe tener al menos una definición de hecho. Las historias de usuario (H.U.) de la 1000 a la 1011 tienen sus propias definiciones en las Tablas que van desde la Tabla 3 hasta la Tabla 14, como se muestran a continuación, cada definición está numerada con su propio ID con el fin de hacer un mejor seguimiento durante el proceso. H.U. ID Aspectos 1000 0 Al ingresar a la página debe existir una herramienta que me redirija a un formulario en el cual puedo ingresar mis datos y quedar registrado en la base de datos Arcadia. 1 En el formulario de registro se deben poder ingresar los siguientes datos: nombres, apellidos, colegio, curso actual, género, nickname, contraseña, fecha de nacimiento, teléfono de contacto y correo electrónico. 2 En el formulario debe existir la opción de seleccionar un avatar de perfil. 3 Se deben poder registrar tantos estudiantes como profesores. 4 El diseño gráfico queda a la libertad de los diseñadores. 5 La página debe tener una herramienta para identificar si deseo ingresar como estudiante o como profesor. 6 Al ingresar a la página debe existir una herramienta que me permita ingresar mi nombre de usuario y contraseña, esos datos deben ser validados y en caso de sean válidos se me debe redirigir a la página principal de estudiante o profesor según sea el caso. Tabla 1 Definiciones de hecho H.U. 1000 H.U. ID Aspectos 1001 7 Solamente los profesores deben poder crear reinos. 8 En la pantalla de inicio de los profesores debe existir una herramienta que me redirija a un formulario en el cual pueda ingresar los datos necesarios para crear un reino. 9 En el formulario de creación de reinos se deben pedir los siguientes datos: nombre, misión, visión, historia y contraseña. 10 El reino siempre debe permanecer disponible para su uso, los reinos deben estar listos para usarse desde el momento de crearse. 11 Una vez exista el reino, debe existir una página principal para cada reino.

29

12 En la página principal del profesor debe existir una forma en la cual se listen o se visualicen los diferentes reinos que posee un profesor. 13 El diseño gráfico queda libre al gusto de los diseñadores, pero debe mantener el mismo estilo durante toda la página. Tabla 2 Definiciones de hecho H.U. 1001 H.U. ID Aspectos 1002 14 En la página principal de los estudiantes debe existir una forma de ingresar el código de un reino, puede ser un buscador de reinos, de tal manera que el estudiante pueda seleccionar el reino que está buscando y este pueda solicitar acceso al contenido de dicho reino 15 Debe existir una forma de validación para inscribirse al reino, puede ser pidiendo solicitud de inscripción al reino o con una contraseña que el profesor brinde a los estudiantes. 16 Una vez el alumno esté inscrito en el reino, el estudiante debe poder acceder a la página principal del reino, esta debe ser una versión única de los estudiantes y debe tener funcionalidades diferentes a la de los profesores. 17 En la página principal de los estudiantes debe existir un menú o alguna forma de visualizar los reinos a los cuales el estudiante está inscrito. Tabla 3 Definiciones de hecho H.U. 1002 H.U. ID Aspectos 1003 18 El mapa debe ser el centro del contenido del reino. 19 El mapa debe estar ubicado de manera protagónica dentro de la página del reino, ya sea para profesores como para estudiantes. 20 El mapa debe tener subdivisiones, exactamente 5 divisiones. 21 El usuario debe poder ver el mapa, el mapa debe estar en la página principal del reino. 22 El diseño del mapa queda a la libre elección de los diseñadores. Tabla 4 Definiciones de hecho H.U. 1003 H.U. ID Aspectos 1004 23 El profesor debe poder generar actividades la cuales van asociadas a una división del reino. 24 Debe existir una herramienta dentro del mapa que permita crear actividades, para tal fin debe existir un formulario en el cual se puedan ingresar los datos correspondientes para la creación de la actividad. 25 En el formulario de creación de actividad se deben solicitar los siguientes datos: nombre de actividad, descripción, parámetro de calificación, valor o porcentaje de la nota asociada a la actividad, tipo y fecha de vencimiento. 26 Se deben poder asociar documentos a una actividad.

30

27 Debe existir la forma de asociar los documentos en el formulario de creación de la actividad. Los datos de la actividad se deben poder modificar una vez está creada en el mapa. 28 Debe existir una herramienta para seleccionar una actividad de tal manera que visualice los datos de la actividad y los documentos asociados, una vez mostrados estos datos, se deben poder modificar. 29 Debe existir una herramienta para seleccionar una actividad y esta se pueda eliminar. Tabla 5 Definiciones de hecho H.U. 1004 H.U. ID Aspectos 1005 30 Debe existir una herramienta que permita visualizar el estado de una actividad. 31 La herramienta debe permitir ver qué estudiantes realizaron o no realizaron la actividad. 32 La herramienta debe mostrar los documentos adjuntos que envió el estudiante para resolver dicha actividad. 33 La herramienta debe mostrar cuántos estudiantes resolvieron la actividad. 34 La herramienta debe permitir que el profesor asigne una nota a la actividad desarrollada para cada estudiante. 35 La herramienta debe notificar al estudiante que su actividad fue calificada y notificarle su respectiva calificación. Tabla 6 Definiciones de hecho H.U. 1005 H.U. ID Aspectos 1006 36 En cada división del mapa debe existir una herramienta que permita visualizar todas las actividades y debe permitir re direccionar a la sección de creación de actividades. 37 Debe existir una forma de ordenar por estudiantes, por reinos y por actividades. 38 Debe existir una forma de filtrar por nombre de estudiante y por actividad. 39 Se deben poder añadir actividades y sus respectivas notas, estas actividades no se deben poder resolver en Arcadia, solamente se debe visualizar la nota en la página del estudiante, y el profesor debe poder añadirlas, editarlas y eliminarlas. 40 La herramienta debe poder mostrar notas finales por estudiantes, por cada reino y el mapa en general. 41 La herramienta debe poder mostrar estadísticas con respecto a las notas, promedios de notas, alumnos que aprobaron y reprobaron. Tabla 7 Definiciones de hecho H.U. 1006

31

H.U. ID Aspectos 1007 42 En la página del estudiante deben aparecer notificaciones de las actividades que el profesor coloque en el reino, la actividad debe estar ligada a un reino. 43 La página debe tener una herramienta que permita visualizar la información referente a la actividad y los documentos anexos que el profesor definió para dicha actividad. 44 La página debe tener una herramienta que permita al estudiante resolver la actividad. 45 La página debe tener una herramienta que permita al estudiante anexar documentos a la actividad. 46 La página debe marcar el estado de la actividad y la fecha de cierre de dicha actividad. 47 Mientras la actividad esté abierta, el estudiante debe poder enviar una respuesta a la actividad mientras los intentos se lo permitan. 48 Una vez cerrada la actividad, esta solo se mostrará, pero el estudiante no debe poder modificar información referente a la actividad como los documentos y las respuestas. 49 Una vez el profesor califique la actividad, la nota se le debe mostrar al estudiante. Tabla 8 Definiciones de hecho H.U. 1007 H.U. ID Aspectos 1008 50 En la página principal del reino debe existir una sección en la cual se muestren los últimos elementos ingresados en la galería, un video, tres documentos y tres imágenes. 51 La galería no debe tener un tamaño máximo. 52 Tanto profesores como estudiantes deben tener acceso a la galería desde la página principal del reino. 53 La versión ampliada de la galería debe estar ordenada por videos, imágenes y documentos, en ese orden. 54 El único perfil con permiso para añadir elementos a la galería es el profesor, los estudiantes solamente puede ver el contenido de la galería sin editarla. 55 Debe existir una herramienta que permita añadir elementos a la galería, las imágenes se deben mostrar en vista miniatura. 56 Para el ingreso de videos se debe solicitar el enlace a YouTube y el video se debe poder reproducir en la misma página. Tabla 9 Definiciones de hecho H.U. 1008 H.U. ID Aspectos 1009 57 En la página principal de los estudiantes y de los profesores debe existir una herramienta de novedades.

32

58 En dicha herramienta de novedades se le debe notificar al estudiante de todas las actividades que diseñe el profesor y se debe indicar el renio. 59 Se le debe notificar al estudiante cuando las actividades están cercanas a vencerse (12 horas antes). 60 El profesor puede enviar mensajes personalizados o de difusión a los estudiantes y esto se debe mostrar en la herramienta de novedades. 61 Cuando una actividad se cierre se le debe notificar a los estudiantes y a los profesores. 62 En la página de los estudiantes se debe notificar la existencia de actividades sin resolver. 63 Cuando el profesor califique una actividad se le debe notificar la nota y las observaciones al estudiante. Tabla 10 Definiciones de hecho H.U. 1009 H.U. ID Aspectos 1010 64 Debe existir la opción de crear una actividad tipo cuestionario en el formulario de crear actividad. 65 Se deben poder escoger la cantidad de preguntas que posee un cuestionario. 66 Las preguntas que conforman el cuestionario se deben poder escoger. 67 Solo se pueden resolver una cantidad limitada de veces, esto lo define el profesor. 68 Las preguntas se deben mostrar en desorden, es decir que no debe existir un orden específico para mostrar las preguntas. 69 Las opciones no deben mostrarse siempre en el mismo orden. 70 El cuestionario debe calificarse solo y la nota se debe mostrar tanto al profesor como al estudiante. Tabla 11 Definiciones de hecho H.U. 1010 H.U. ID Aspectos 1011 71 El estudiante al momento de inscribirse debe poder escoger una clase. 72 La clase depende del género del estudiante, es decir si es masculino o femenino se le deben mostrar diferentes opciones al estudiante. 73 El título y el avatar del estudiante cambian de acuerdo a la clase del estudiante. 74 El nivel del estudiante es un reflejo de la nota, de la siguiente manera: entre 0 y 2.5 es nivel 0, entre 2.5 y 5 es nivel 1, entre 5 y 7.5 es nivel 2, y el nivel 3 entre 7.5 y 10. 75 Cada vez que se actualicen notas se debe actualizar el nivel del estudiante si es necesario.

33

76 Cuando un estudiante sube de nivel se debe notificar como novedad. 77 Cuando un estudiante sube de nivel debe ganar un título y un avatar dependiendo de la clase a la que pertenezca, el estudiante debe poder escoger entre sus avatares y títulos. Tabla 12 Definiciones de hecho H.U. 1011 3.3) Definición de los Sprints En cada Sprint se toman historias de usuario y se desarrollan de tal manera que al final se pueda entregar el trabajo al cliente, el cual en este caso es el docente Luis Carlos Beltrán, la manera en la cual él mide el trabajo es de acuerdo a las definiciones de hecho. Cada Sprint tiene seis (6) componentes, lo primero es la definición en la cual se plantea el objetivo del Sprint de acuerdo a las historias de usuario que se decidan abordar, las historias de usuario se dividen en tareas dejando claro el alcance del Sprint. El segundo componente es el Sprint Backlog en el cual se les asigna un tiempo de ejecución a cada tarea y estas tareas son asignadas a miembros del equipo, en esta misma fase se hace la plantilla del Sprint en la cual se le da un identificador al Sprint y se describen las funcionalidades que se le van a entregar al cliente al final del Sprint. El tercer componente está basado en los primeros dos (2), este es el diagrama de Gantt, el cuarto componente es la ejecución del Sprint, en esta parte se describe cómo se realizó cada tarea y en qué manera se desarrollaron las historias de usuario, este componente varía completamente de acuerdo a cada Sprint, el quinto componente es la retrospectiva en la se plasman las dificultades que hubieron durante la cuarta fase, es un espacio para reflexionar sobre los procesos llevados a cabo y dar impresiones personales. El ultimo componente es el de anexos, con esto se pueden aclarar ideas y mostrar evidencias del desarrollo. El esfuerzo máximo por persona encargada es de veinte (20) horas semanales, lo que implica que la máxima cantidad de horas asignadas al equipo son cuarenta, esto se debe a que son dos miembros encargados, durante los procesos de asignación de tareas siempre se va a hacer referencia a la Tabla 1 en la cual están definidos los encargados de cada tarea.

34

3.3.1) Primer Sprint 3.3.1.1) Definición del Primer Sprint En el primer Sprint se plantea el desarrollo de actividades bases que son transversales para todos los usuarios, específicamente actividades del Product Backlog que poseen la máxima prioridad, por tal razón en este sprint se abordan las historias de usuario con el ID 1000 y 1001, la historia de usuario 1000 se aborda en su totalidad, mientras que la 1001 se fracciona y se toman únicamente tareas de diseño y de codificación, sin integración con la historia de usuario 1001. La primera tarea que se aborda es la creación de usuarios, ya sea tanto de profesores como de alumnos, esto incluye el modelo de la base de datos que no solamente se define para soportar las tareas definidas en este sprint, se busca que el diseño esté hecho para soportar otras historias de usuario, por tal razón se entrega una primera versión de la base de datos que está hecha para soportar varias de las funcionalidades del producto, este modelo está abierto a cambios en la medida que el Product Owner entregue sus retroalimentaciones, con respecto a la base de datos se diseñan y crean roles de usuarios, vistas y el diagrama entidad relación. Para este sprint se define la primera versión del diagrama de clases que soporte en su totalidad las historias de usuario 1000 y 1001. Como este es el primer Sprint es necesario definir un modelo de arquitectura de Software el cual sirva como estructura para todo el proceso de desarrollo del proyecto, como apoyo para la definición de arquitectura se realiza un diagrama, este se puede ver en cada Sprint. Se aborda el diseño de la parte gráfica para soportar la creación de usuarios y la creación de reinos, se hacen Mockups los cuales sirven como base para el diseño visual de las páginas de inicio, creación de usuarios, página principal de profesores y estudiantes, y la respectiva creación de los reinos por parte de los profesores. Los diseños gráficos siguen un patrón gráfico definido por los creadores de este documento siguiendo los colores respectivos definidos por el Product Owner. 3.3.1.2) Sprint Backlog En el tema de la medición de esfuerzo, en este Sprint el cual tiene una duración de tres semanas debido a que cada miembro del equipo invierte veinte (20) horas semanales, lo que implica que en la semana son cuarenta (40) horas entre los dos miembros del grupo y el esfuerzo son ciento quince (115) horas, la función que permite hallar la cantidad de semanas que dura el Sprint es la siguiente:

35

𝑥 = ∑ 𝑎 𝑎 𝑎 𝑎𝐻 𝑎 𝑎 𝑎 Para hallar las sumatoria del tiempo en las tareas se debe tener en cuenta que las tareas de codificación cuentan como dobles ya que se implementa la técnica de programación por parejas propia de XP, estos datos son extraídos de la Tabla 15 y la suma es la siguiente: ∑ = + + + + + ∗ + ∗ + + + + ∗ = 𝐻 𝑎 Teniendo las dos variables se reemplazan en la Ecuación 1.

𝑥 = = . 𝑎 𝑎 Se redondea hacia arriba lo que da un resultado de tres (3) semanas de duración del Sprint. Sprint Backlog: 1 Backlog ID: 10000 ID Historia de Usuario Tarea Prioridad Esfuerzo 1000 Creación del modelo de la base de datos y respectiva creación de la base de datos. 1 10 Selección de patrón de arquitectura de software 1 6 Definición de clases a usar para abordar el problema y su respectiva diagramación. 1 10 Definición y creación de roles de usuarios en la base de datos. 1 8 Definición y creación de vistas de la base de datos para soportar funcionalidades de historia de usuario 1000. 1 5 Codificación de funcionalidad de creación de usuarios (alumno). 2 14 Codificación de funcionalidad de creación de usuarios (profesor). 2 14 Diseño de Mockups y gráficos para pantallas de inicio, creación de usuarios alumnos y creación de usuarios profesores. 2 2 1001 Diseño de Mockups y gráficos para pantallas principales de usuarios alumnos y profesores. 3 4

Ecuación 1 Duración de un Sprint en semanas

36

Diseño de Mockups y gráficos para pantallas de creación de reinos. 3 4 Codificación de funcionalidad de creación de reinos. 3 5 Tabla 13 Sprint Backlog 1

Sprint ID 1 Backlog ID 10000 Historias de U. 1000 y 1001 Responsables Pablo Esteban y Julián Barbosa Descripción de las funcionalidades. La primera funcionalidad que se aborda en el sprint es la creación de usuarios para profesores y estudiantes, para dicho fin en la página de inicio debe existir la opción de inscribirse, de tal manera que se despliega un formulario en el cual se solicita la información definida en el elemento 2 de la historia de usuario 1000, una vez se llena el formulario la información se almacena en la base de datos. La segunda funcionalidad es la validación para el ingreso a la página de Arcadia, en la página de inicio se solicita el nombre del usuario y la contraseña, una vez ingresada esta información se coteja en la base de datos, de tal manera que si es correcta se le da acceso a la persona a la página principal ya sea del profesor o del estudiante. La tercera funcionalidad es la creación de reinos, el profesor en su página principal posee la opción de creación de reinos, de tal manera que se le muestra un formulario con la información definida en el elemento 9 de la historia de usuario 1001, una vez diligenciado el formulario se guarda la información en la base de datos y se le muestra al profesor que ha creado un reino. Tabla 14 Funcionalidades Sprint 1

37

3.3.1.3) Diagrama de Gantt Ilustración 3 Diagrama de Gantt Sprint 1. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). 3.3.1.4) Ejecución de Sprint Las tareas se abordan en el mismo orden en el que están consignadas en la Tabla15 lo que indica que la primera tarea que se desarrolla es la creación de la base de datos, el motor de base de datos que se usa es PostgreSQL, debido a que es libre, es confiable y posee una gran cantidad de documentación disponible, las Tablas y las relaciones por las cuales está compuesta la base de datos se muestran en el diagrama entidad relación (Ilustración 11), para el nombramiento de los atributos de cada entidad se usa un estándar en el cual cada término se separa por un guion bajo ( _ ) y al inicio de cada uno se especifica el tipo de atributo según la Tabla 17, el diagrama se encuentra en la página 44 en el apartado de anexos del Sprint 1. Prefijo Descripción K Llave Primaria o llave foránea N Cadena de caracteres V Valor decimal O Otros F Fechas I Estados Q Valor entero Tabla 15 Prefijos nombramiento Tablas

38

La segunda tarea es la selección de un patrón de arquitectura de software, se escoge el Modelo-Vista-Controlador (MVC) ya que estructura la construcción de software en tres (3) componentes, Zoblin (2013 ) describe el MVC como un patrón para estructurar la comunicación entre la lógica de negocio y la presentación, MVC en la capa de Modelo se manejan las estructuras de datos y los datos, en la capa controlador opera la lógica de negocio y en la capa de vista se manipulan las interacciones con el usuario, en la Ilustración 4 se muestra la forma se aplica MVC para el caso de Arcadia. Por otro lado para implementar MVC se utiliza el framework “CodeIgniter”, este framework aporta una estructura en la cual se puede aplicar el patrón MVC, está hecho para desarrollar aplicaciones web y está diseñado para PHP. Para la comunicación con la base de datos se escoge el patrón Data Access Object (DAO), de tal manera que se añade una buena práctica al proceso de codificación, el Patrón DAO según (Oracle, 2016) aporta flexibilidad al software ya que se utilizan objetos para el acceso a la capa de datos, con esto se garantiza la independencia de la vista, el patrón DAO se implementa en la capa del modelo del MVC, esto se muestra en la Ilustración 4. Ilustración 4 MVC primer Sprint Las tres capas del MVC se muestran en la Ilustración 4, en la capa controlador se maneja la lógica del estudiante, del profesor y del reino, adicionalmente existe Welcome.php que es el hilo de inicio definido por CodeIgniter. En la capa Modelo están las estructuras de datos del reino, del profesor y del estudiante, también estas se implementan el patrón DAO, siguiendo los lineamientos de DAO se define una interfaz para estructura de datos, es decir para cada objeto, la última capa es la de Vista, esta se divide entre profesor y estudiante, cada uno de los miembros tiene

39

una forma de registrarse y una forma de ingresar a la plataforma, igualmente una vista independiente principal. Con la estructura definida se aborda la tercera tarea, la definición del modelo de clases, es importante anotar que el modelo de clases se debe ajustar y respetar el patrón MVC y el patrón DAO previamente definidos, por tal razón las clases están definidas bajo el mismo esquema que aporta MVC, las relaciones en la capa de modelo son de instanciación, es decir que los modelos instancian a las clases definidas por el patrón DAO, con lo cual se garantiza que los objetos son los únicos que se comunican con la capa de datos. Los controladores instancian a los modelos, por otro lado existe una relación de herencia entre una interfaz imagen y los avatares específicos de cada controlador, por último está una relación de agregación entre profesor y estudiante con la clase reino como se muestra en la Ilustración 12, el diagrama de clases se muestra en el apartado de anexos del primer Sprint. La cuarta tarea es la creación de los roles en la base de datos, la importancia de esto radica en agrupar los diferentes tipos de usuario y controlar el acceso a la base de datos, “Los datos guardados en la base de datos deben estar protegidos contra los accesos no autorizados, de la destrucción o alteración malintencionadas además de la introducción accidental de inconsistencias” (Silberschatz, Korth, & Sudarshan, 2002), basándose en MVC se definen 3 tipos de roles, el primero es el de estudiante, el segundo es el de profesor y el tercer un rol de administrador. Los permisos entre cada rol varían de acuerdo a las necesidades, y de acuerdo al nivel de seguridad, por defecto cada rol no tiene permisos de escritura, consulta, eliminación ni edición a ninguna de las Tablas, los permisos se asignan durante el proceso de codificación. Las vistas generadas para este sprint buscan tener en cuenta las consideraciones de seguridad de la información, de tal manera que las vistas garanticen únicamente la información necesaria para un usuario determinado. Estas vistas se adaptan al modelo lógico definido, la primera vista es la vista de ver el perfil del estudiante que permite traer toda la información relevante para un estudiante, esto mismo ocurre con la vista para ver el perfil del profesor, la tercera y última vista definida en este sprint es una vista para que el profesor pueda acceder a sus reinos creados. Las tareas de parte gráfica se abordan entre las Ilustraciones 5 y 10, la Ilustración 5 muestra el inicio de la página desde el cual se puede ingresar a la página principal de profesores y estudiante, en esta misma vista está el enlace para el registro de profesores y estudiantes, la vista de registro es la misma para profesores y estudiantes por lo tanto se resumen en la Ilustración 6.

40 Ilustración 8 Página principal profesores. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). Ilustración 5 inicio Arcadia. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). La Ilustración 7 y la Ilustración 8 muestran las páginas principales tanto de estudiantes como de profesores, la diferencia radica en la opción de crear un reino por parte de los profesores. Ilustración 7 Página principal estudiantes. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). La vista para la creación de reinos se muestra en la Ilustración 9, es un formulario en el cual se solicita la información necesaria para la creación de un reino, en la Ilustración 10 se ve la vista de perfil del profesor además de los reinos que ha creado el profesor.

Ilustración 6 Registro estudiantes y profesores. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017).

41 Ilustración 9 Creación Reinos. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). Ilustración 10 Perfil Profesor. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). 3.3.1.5) Retrospectiva del Sprint Luego de haber terminado la fase de desarrollo y de culminado todas las tareas planteadas en el tiempo establecido se verifica que el producto cumpla con las definiciones de hecho planteadas por el docente Luis Carlos Beltrán, en el caso de

42

la H. U. 1000 existen siete (7) definiciones de hecho (DH) enumeradas desde el uno (1) hasta el siete (7), todas las DH se cumplen a cabalidad, la DH 1 solicita una herramienta para poder redirigirse hacia el formulario, como se muestra en la Ilustración 5 la plataforma cuenta con un botón que permite ir al formulario de registro, el cual a su vez cuenta con la cantidad de campos solicitados en la DH 2 y en la DH 3, esto se puede verificar en la Ilustración 6 y el diagrama entidad-relación en la Tabla de estudiante cuenta con los campos necesarios para almacenar dicha información, desde la pantalla principal se puede escoger si desea ingresar como profesor o como estudiante y el botón de inscribirse es independiente en cada vista por tal razón desde la vista de inicio de profesor se inscriben los profesores y lo mismo ocurre con los estudiantes, cumpliendo así mismo con las DH 4 y 6. La última DH de la HU 1000 es el poder validarse como usuario en la plataforma una vez la persona se encuentre registrada y redirigirla a la página principal, la funcionalidad de verificar se realiza en las funciones cargarPerfilProfesor y cargarPerfilEstudiante que se muestran en la Ilustración 12. La HU 1001 posee tres (3) DH que están enumeradas desde el 7 hasta el 9, estas al igual que en la HU anterior se cumplen completamente, la DH especifica que solo los profesores pueden crear reinos, esto se garantiza en dos (2) partes, la primera es la imposibilidad por parte del estudiante de crear reinos ya que en su página no existe la opción de crear reinos y la segunda parte es seguridad a nivel de permisos en la base de datos, el único rol con permisos de hacer inserciones en la Tabla de reinos es el rol de profesor, la DH 8 solicita una forma de crear reinos en la página del profesor, la evidencia de esto se muestra en las Ilustraciones 8 y 9, que al mismo tiempo cumplen con la DH 9. El balance una vez finalizado el Sprint 1 es realmente positivo, con todas las definiciones de hecho completas y las tareas culminadas se puede dar por terminado el Sprint 1, algunas de las cosas por ajustar son los tiempos empleados en la parte visual ya que ocuparon más tiempo de los que se había planteado inicialmente, sin embargo las tareas de codificación se agilizaron para suplir el tiempo de demora en el desarrollo visual de la página, la deuda técnica de este Sprint radica en el manejo de errores y excepciones, cuando una persona intenta entrar a la página y su contraseña o nickname no son válidos se captura la excepción pero no se le avisa a la persona que ha ocurrido un error, este punto se aborda en Sprints posteriores.

43

3.3.1.6) Anexos. Ilustración 11 Diagrama Entidad-Relación v. 1

44 Ilustración 12 Diagrama de clases v. 1

45

3.3.2) Segundo Sprint 3.3.2.1) Definición del Segundo Sprint Este segundo Sprint retoma la HU 1001 fraccionada del Sprint 1, siendo este el primer objetivo a abordar en este Sprint, se emprenden dos HU nuevas que son las HU 1002 y 1003, estas se desglosan en tareas y se buscan finalizar completamente. La HU 1001 se debe completar, para lo cual diseña la página principal de los reinos tanto para profesores como para estudiantes ya que esto está inscrito en la HU 1002, esta solicita la inscripción de estudiantes en los diferentes reinos, una vez inscritos los estudiantes deben poder ingresar al reino, es decir a la página principal del reino. La HU 1003 se cambia y redefine, el docente Luis Carlos Beltrán decide que el mapa es una herramienta administrativa para los profesores y los estudiantes van a tener otro tipo de interacción con la plataforma, la cual se aborda en un próximo Sprint, por tal razón el mapa solo tiene funcionalidad en la página del profesor; este Sprint tiene una nueva versión de la base de datos, del diagrama de clases y del diagrama MVC, se diseñan nuevas vistas para cumplir con las funcionalidades y con las DH de cada HU. 3.3.2.2) Sprint Backlog Este Sprint al igual que el primer Sprint tiene una duración de tres (3) semanas, los miembros del equipo continúan con la inversión de veinte (20) horas semanales, cuarenta (40) horas semanales entre los dos miembros del grupo y el esfuerzo son ciento doce (112) horas. Las tareas de codificación se multiplican por dos (2) debido a la práctica de codificación en pares. ∑ = + ∗ + + + ∗ + ∗ + ∗ + + + + ∗ + = 𝐻 𝑎 Teniendo las dos variables se reemplazan en la Ecuación 1.

46

𝑥 = = . 𝑎 𝑎 Se redondea hacia arriba lo que da un resultado de tres (3) semanas de duración del Sprint. Sprint Backlog: 2 Backlog ID: 10001 ID Historia de Usuario Tarea Prioridad Esfuerzo 1001 Creación de los gráficos de la página principal del reino tanto para profesores como para estudiantes. 1 14 Codificación de funcionalidad para redirección desde la página de selección de reino hasta la página principal del reino para profesores. 1 7 1002 Diseño de Mockups y gráficos para la inscripción de un reino por parte de un estudiante 2 6 Diseño de Mockups y gráficos para vista de selección de reinos inscritos de un estudiante. 2 6 Codificación de funcionalidad de inscripción a reinos por parte del estudiante. 2 6 Codificación de listado de reinos para el estudiante 2 5 Codificación de carga de la página principal del reino para el estudiante. 2 6 Integración de funcionalidades de HU 1002 con el proyecto. 3 6 1003 Diseño del mapa para la página principal de profesores. 1 8 Diseño de ventana para visualización del mapa en la página del profesor. 1 8 Codificación para carga de vista del mapa en la página del profesor. 2 6 Integración del mapa con el proyecto. 2 4 Tabla 16 Sprint Backlog 2 Sprint ID 2 Backlog ID 10001 Historias de U. 1001, 1002 y 1003 Responsables Pablo Esteban y Julián Barbosa Descripción de las funcionalidades. Este Sprint aborda seis (6) funcionalidades, la primera funcionalidad es el poder escoger entre los reinos propios y de esa manera el profesor ingresar a determinado reino entre todos sus reinos disponibles, la forma de hacerlo queda de libre elección al grupo de desarrollo.

47 3.3.2.3) Diagrama de Gantt Ilustración 13 Diagrama de Gantt Sprint 2 3.3.2.4) Ejecución de Sprint Como primera medida para afrontar este Sprint se abordan las tareas que tienen que ver con visualización y vistas, esta decisión se toma con base en la experiencia ganada en el Sprint 1, ya que estas tareas presentan una mayor dificultad al equipo

La segunda funcionalidad es listar los reinos en los cuales un estudiante se puede inscribir, esto se debe hacer desde la página principal del estudiante. La tercera funcionalidad es la inscripción a un reino por parte de un estudiante, una vez el estudiante puede ver los reinos disponibles él debe estar en la capacidad de seleccionar un reino e inscribirse utilizando la contraseña que ha escogido el profesor. La cuarta funcionalidad es listar los reinos a los cuales un estudiante está inscrito y darle la opción al estudiante de seleccionar alguno de los reinos para poder ingresar a la página del reino. La quinta funcionalidad es cargar la página principal de un reino en específico para profesores y estudiantes. Por último la sexta funcionalidad es cargar el mapa para la página principal del reino del profesor. Tabla 17 Funcionalidades Sprint 2

48

de desarrollo, se afronta la primera tarea de la HU 1001, las tareas uno (1) y dos (2) de las HU 1002 y 1003. La primera tarea es el diseño de la página principal del reino para estudiantes y profesores, la diferencia entre los dos (2) diseños radica en las opciones que se muestran a la izquierda de la Ilustración 14, se muestra el nombre del reino, el mapa para los profesores, se puede apreciar el espacio para la historia, la misión y la visión, y esta la disposición para una galería de documentos, imágenes y videos. Como lo solicita el docente Luis Carlos Beltrán el mapa tiene una posición protagónica dentro de la página de inicio del reino. Ilustración 14 Página principal de un reino. . Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). De la HU 1002 están dos (2) tareas de diseño, la primera es la vista de inscripción de un reino por parte del estudiante (Ilustración 15) y la segunda se basa en darle

49

la opción al estudiante de acceder a la página principal de alguno de los reinos a los cuales está inscrito como se muestra en la Ilustración 16. Ilustración 15 Inscripción a un reino Ilustración 16 Perfil y lista de reinos del estudiante. . Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). La primera tarea de la HU 1003 se unifica con la vista principal de los profesores y estudiantes en la Ilustración 14, la segunda tarea de diseño de la HU 1003 es el diseño de la ventana para el mapa de los profesores, en este caso se decide tener una vista únicamente para el mapa y sus regiones (Ilustración 17).

50

Ilustración 17 Mapa de profesores. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). Ilustración 18 Modelo-Vista-Controlador v. 2 Las tareas de codificación se realizan posteriormente a las tareas de diseño visual, estas tareas se afrontan siguiendo la estructura definida en el primer Sprint, continuando con el diagrama entidad-relación se actualiza la versión del diagrama a su segunda versión, el docente Luis Carlos Beltrán hace un énfasis en la necesidad de mantener informados a los estudiantes, de esta manera se añade la Tabla de novedades y se añaden los atributos las relaciones de los avatares entre los profesores y los estudiantes, ya que un estudiante debe poder escoger entre una variedad de avatares al igual que los profesores, estos cambios se puede ver en la Ilustración 18, debido a que la base de datos es un tema crítico se decide afrontar con la mayor prioridad, siguiendo con el esquema planteado por el patrón MVC se añaden las vistas creadas a la capa de vistas, en la capa de controlador se agrega el controlador para el manejo de regiones y así mismo en la capa de modelo

51

el modelo de reino con su respectivo DAO, estos cambios se exponen en la Ilustración 17. El diagrama de clases también se modifica y se incrementa su versión siguiendo los cambios hechos en el MVC, se adicionan clases para el manejo de la lógica de las regiones, las nuevas clases se muestran en la Ilustración 20. Se añaden vistas para controlar los reinos creados por parte de los profesores y los estudiantes, son dos vistas diferentes para listar los reinos que poseen los profesores y los reinos a los cuales está inscrito un estudiante, todo esto con el objetivo de mantener la integridad de la base de datos. La integración entre las tareas de codificación y las tareas de diseño se hacen a manera de cascada de acuerdo al orden de las HU, primeramente se hace una integración de la carga de la página principal del reino para los profesores, sobre esta integración se añaden las opciones de poder inscribirse a un reino si se es estudiante, siguiendo con el estudiante se integra la funcionalidad de listar los reinos de un estudiante y la capacidad de ir a la página principal del reino, por último se integra el mapa para los profesores, este Sprint es el primero en sufrir integraciones y manejo de versiones con el código, para tener un control sobre dichas versiones se utiliza un repositorio en gitHub en el cual se hacen las integraciones y los cambios al código, ya sea en la parte lógica como en la parte visual. 3.3.2.5) Retrospectiva del Sprint Las conclusiones que deja este segundo Sprint son satisfactorias, al igual que en el Sprint anterior todas las tareas se concluyen en el tiempo estimado, teniendo mayor holgura con las tareas de diseño gráfico y ajustando tiempos en las tareas de codificación, las nuevas tareas de integración se desarrollan sin inconvenientes ya que la estructura aportada por MVC es flexible y soporta bien las nuevas funcionalidades. Las DH de la HU 1002 consisten en permitir que el estudiante pueda ver los reinos hechos por los profesores e inscribirse, una vez inscrito el estudiante puede listar los reinos a los cuales está inscrito y acceder a alguno de dichos reinos, estas DH están enumeradas desde el 14 hasta el 17, las cuatro (4) definiciones de hecho se cumplen a cabalidad como se evidencia en el desarrollo del Sprint, el mismo caso ocurre con la HU 1003, los aspecto a evaluar son visuales, el mapa está ubicado en el centro de la página de los reinos y llama mucho la atención, para los profesores el mapa tiene una página únicamente para mostrarse. Tanto profesores como estudiantes pueden acceder a la página principal del reino, sin embargo la vista del profesor tiene las condiciones para administrar las actividades, la galería y las novedades. El docente Luis Carlos Beltrán se muestra conforme con el resultado al final del Sprint, el como cliente realiza observaciones a nivel gráfico con respecto a

52

detalles de ubicación de los elementos de las vistas, a nivel de funcionalidad aprueba todas las DH de las tres (3) HU abordadas en este Sprint. Por parte de los desarrolladores no existen inconvenientes, las medidas tomadas en la planeación de los tiempos surgen un efecto positivo en el equipo y en el resultado, con esto se da por finalizado el segundo Sprint.

53


54 Ilustración 20 Diagrama de clases v. 2 3.3.3) Tercer Sprint 3.3.3.1) Definición del Tercer Sprint Este Sprint tiene una importancia crucial para el proyecto Arcadia, se planea afrontar las tareas de creación y resolución de actividades, el docente Luis Carlos Beltrán hace un énfasis en estas funcionalidades, ya que aspectos como el buen manejo de actividades permite un verdadera gamificacion a Arcadia, en el aspecto académico y en la codificación se maneja el término de actividad que va asociado directamente con las tareas realizadas por los estudiantes, sin embargo dentro del entorno de Arcadia se utiliza el término de misión para referirse a una tarea, del buen desempeño en este Sprint depende la buena culminación del proyecto Arcadia, la ser las actividades un tema central se toman y se unen las HU que tratan

55

las actividades, en consecuencia las HU que se abordan en este Sprint son las 1004, 1005, 1006 y 1007, las cuatro (4) HU se atacan en su totalidad. Los objetivos del tercer Sprint son generar una herramienta que permita al profesor crear actividades que estén ligadas a alguna región de un reino en específico, estas actividades deben ser visibles por los estudiantes del reino y los estudiantes deben estar en capacidad de visualizar las actividades, se le debe brindar al estudiante la opción de resolver la actividad, por último el profesor requiere una forma para visualizar las tareas resueltas de los estudiantes y calificarlas, esto implica el proceso completo de creación, resolución y calificación de tareas, el docente Luis Carlos Beltrán define tres (3) tipos de actividades, la primera es formulario, este no se va a resolver durante este Sprint, solo se aborda la posibilidad de crear formularios; el segundo tipo es el archivo, para este caso el docente deja un archivo como tarea y el estudiante responde de la misma manera, el ultimo tipo de actividad es la actividad en clase, la cual es únicamente para el seguimiento de notas, con esto se busca que el docente pueda usar Arcadia como un administrador de notas, de tal manera que el docente crea una actividad que puede ser vista por el alumno mas esta no se puede resolver, el docente puede cambiar la nota de la actividad con respecto a la nota que obtuvo el estudiante en clase y así esta actividad refleje una tarea de la vida real. El modelo de la base de datos se actualiza para soportar todas funcionalidades con respecto a las actividades, los diagramas de clases y MVC sufren sus respectivas alteraciones con el objetivo de solucionar las necesidades que presenta este Sprint, por la parte gráfica se plantean dos (2) opciones para el profesor, la creación de actividades desde el mapa y desde la herramienta de administración de actividades, mientras que el estudiante va a poseer solo la opción de resolver actividades desde la herramienta en la página principal del reino y no desde el mapa. Por la cantidad, la complejidad y la importancia de las HU que se resuelven en este Sprint se espera que la duración sea superior a la de los Sprints anteriores, la cantidad de vistas que se deben diseñar también incrementan y requieren un tiempo prudencial para que el diseño se acople con lo ya realizado. 3.3.3.2) Sprint Backlog Hasta el momento este es el Sprint con mayor duración, incluso mayor que los dos (2) Sprints juntos, el cálculo de duración en semanas se realiza de igual manera que las veces anteriores, dando como resultado un total 10.5 semanas, esto es de esperarse debido a la importancia de las HU que posee este Sprint, además que se incluyen cuatro (4) HU, un total de treinta (30) tareas y cuatro (4) tareas de integración, durante este periodo de tiempo se tiene el apoyo del cliente para evitar

56

desviaciones o malinterpretaciones de algunas tareas y funcionalidades, esto se debe a la longitud del Sprint. ∑ = + + + + ∗ + + ∗ + + + ∗ + + ++ ∗ + ∗ + ∗ + + + + + + ∗+ ∗ + + ∗ + ∗ + + + ∗ + ∗ += 𝐻 𝑎

𝑥 = = . 𝑎 𝑎 Se redondea hacia arriba lo que da un resultado de diez semanas y media (10.5) de duración del Sprint. Sprint Backlog: 3 Backlog ID: 10002 ID Historia de Usuario Tarea Prioridad Esfuerzo 1004 Actualización del modelo de bases de datos para soportar HU 1003, 1004 y 1005. 1 10 Diseño de clases para soportar funcionalidades de HU 1003, 1004 y 1005. 1 10 Diseño de Mockups y gráficos para la creación de actividades en el mapa. 1 8 Diseño de Mockups y gráficos para la creación de actividades en la página del reino. 1 10 Codificación para la creación de una actividad y su respectiva relación con las regiones. 1 9 Investigación para encontrar manera de anexar documentos utilizando php. 2 6 Codificación de anexión de documentos para una actividad, se debe validar el nombre del documento en caso de estar repetido. 2 12 Diseño de Mockups y gráficos para la visualización de actividades creadas por el profesor. 2 11 Diseño de Mockups y gráficos para la edición de actividades. 2 8 Codificación de lógica para la edición actividades. 2 9 Integración de tareas realizadas en HU 1004 con el proyecto. 1 8 1007 Diseño de Mockups y gráficos para visualizar las actividades de los estudiantes. 1 10 Diseño de Mockups y gráficos para ventanas modales para resolución de diferentes tipos de tareas por parte de los estudiantes. 1 20

57

Codificación para la descarga de documentos anexados. 3 7 Codificación para manejo de estados de una actividad de acuerdo a la fecha de cierre. 3 9 Codificación para resolución de actividades por parte de los estudiantes. 3 14 Integración de tareas realizadas en HU 1007 con el proyecto. 1 10 Diseño de Mockups y gráficos para ver actividades por región. 2 10 1005 Diseño de Mockups y gráficos para listar estudiantes en un reino. 2 10 Diseño de Mockups y gráficos para ver las actividades de un estudiante. 2 10 Diseño de Mockups y gráficos para ver una actividad y los estudiantes que la resolvieron. 2 10 Codificación para la actualización de la nota de una actividad y todos los estudiantes que están involucrados en dicha actividad. 4 12 Codificación para la actualización de una actividad con respecto a la nota. 4 14 Integración de tareas realizadas en HU 1005 con el proyecto. 1 12 Codificación para la creación de actividades desde el mapa. 4 2 Codificación para la calificación de actividades hechas en clase. 4 8 1006 Diseño de Mockups y gráficos para la vista de notas finales (profesores). 3 14 Diseño de Mockups y gráficos para la vista de notas finales (estudiantes.). 3 8 Codificación para el cálculo de notas finales para los profesores. 1 15 Codificación de notas finales para un único estudiante. 1 3 Integración de tareas realizadas en HU 1006 con el proyecto. 1 10 Tabla 18 Sprint Backlog 3 Sprint ID 3 Backlog ID 10003 Historias de U. 1004, 1005, 1006 y 1007 Responsables Pablo Esteban y Julián Barbosa Descripción de las funcionalidades. La primera funcionalidad de este tercer Sprint es la creación de actividades por parte del profesor, esto incluye seleccionar la fecha de cierre de la actividad y el documento adjunto en el caso de la actividad tipo archivo, además de información como el porcentaje de la nota, el nombre de la actividad, para el

58 Tabla 19 Funcionalidades Sprint 1

caso de la actividad en clase se solicitan menos campos, se excluye la fecha de cierre y el archivo. Las actividades se deben poder editar, únicamente se puede editar la fecha de cierre, el nombre y el porcentaje de la nota, los demás campos se mantendrán igual, esto cumple con la segunda funcionalidad. Una funcionalidad que se usa dos veces en este Sprint es la anexión de documentos, en primera medida para crear la actividad y en segunda medida para poder resolver la actividad por parte de los estudiantes. La cuarta funcionalidad es la visualización de las actividades creadas para los profesores, esto tiene dos partes, la primera es listar las actividades por región y la segunda una lista de actividades por estudiantes, esto tiene de manera implícita la quinta funcionalidad que es carga la lista de estudiantes inscritos en el reino. La séptima funcionalidad es el cierre automático de actividades, una actividad se debe cerrar en la fecha que el profesor decida que la actividad se vence. Una actividad solo se puede resolver mientras esté activa y solo se puede calificar una vez esta se vence, es decir se cierra. La octava funcionalidad es la opción del estudiante de resolver una actividad, para lo cual debe tener la herramienta de descargar el documento que envió el profesor al momento de crear la actividad y de anexar un documento como respuesta, las actividades tienen un numero límite de intentos, el estudiante no debe poder enviar más respuestas de las permitidas, cuando una actividad es resuelta su nota por defecto es cero (0). La novena funcionalidad es del profesor, el profesor debe poder ver la respuesta de un alumno a una actividad, en caso de que la actividad tenga múltiples intentos, el único intento valido es el último o el más reciente dependiendo de la situación. La décima funcionalidad es darle al profesor la capacidad de poder editar las notas de un estudiante o las notas asociadas a una actividad, los profesores solo deben poder editar notas una vez la actividad está cerrada. El estudiante debe poder ver sus notas en una lista de actividades por región, esta es la undécima funcionalidad. La doceava y penúltima funcionalidad radica en una lista de notas, esta lista de notas debe ser de estudiantes contra actividades, la lista de notas debe tener el valor acumulado de notas en el reino y un promedio de nota por actividad, toda la parte grafica queda a diseño del equipo de desarrollo, esto incluye todas las vistas anteriores. La última funcionalidad para desarrollar es el mostrar al estudiante su nota acumulada en la región de acuerdo con la nota en sus actividades resueltas.

59

3.3.3.3) Diagrama de Gantt Ilustración 21 Diagrama de Gantt Sprint 3

60

3.3.3.4) Ejecución de Sprint Este Sprint se abordó en una manera parecida al primer Sprint en cuanto a que las tareas se desarrollaron de acuerdo a cada HU, pero la diferencia radica en que las primeras tareas que se llevan a cabo son las tareas de diseño gráfico, de tal manera que este apartado está dividido en cuatro (4) partes una para cada HU. Las primeras tareas a desarrollar de la HU 1004 son las 3, 4, 8 y 9, estas abarcan todas las vistas para esta HU, la vista para la creación de actividades está divida en tres (2) partes, una para la creación de actividades tipo archivo (Ilustración 22) y otra para actividades en clase (Ilustración 23), estas pertenecen al profesor y el estudiante no las puede ver, son formularios en los cuales se captura la información requerida para crear una actividad, los campos van de acuerdo a lo planteado por el docente Luis Carlos Beltrán, la creación de actividades también hace parte del mapa, por lo tanto se desarrolla una vista propia para el mapa en la cual el profesor puede acceder a una ventana modal que permite re direccionar al formulario de creación de actividades haciendo clic sobre alguna región en el mapa, como se muestra en la Ilustración 24, estas vistas acogen la funcionalidad de creación de actividades desde el mapa como desde la herramienta de actividades y las tareas 3, 4 y 8; la vista de la tarea 9 se muestra en la Ilustración 25, esta vista es la edición de actividades para los profesores. De este Sprint quedan pendientes las actividades tipo cuestionario las cuales se añaden a estas vistas en futuros Sprints. Ilustración 22 Vista creación de actividades tipo archivo. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017).

61 Ilustración 23 Vista creación actividades en clase. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). Ilustración 24 Vista creación actividades desde el mapa. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). Ilustración 25 Vista editar actividades. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). La base de datos al inicio de cada Sprint se modifica y actualiza para garantizar que puede soportar toda la información que se requiere ingresar durante el desarrollo del Sprint, en la Ilustración 37 en el apartado de anexos de este Sprint se muestran los cambios con respecto las versiones anteriores, se añade la Tabla de soporte, la cual tiene relación con las Tablas actividad_resuelta y estudiante, y se hacen ajustes en los nombramientos de los atributos de la Tabla anexo.

62

El diagrama de clases también sufre cambios al añadírsele las clases necesarias para el desarrollo de todo el Sprint, se adicionan clases para el manejo de actividades, desde la creación, pasando por la edición, la resolución y la respectiva calificación de las actividades, las nuevas clases son Actividad la cual es padre de los tres (3) diferentes tipos de actividades, por lo cual tienen una relación de herencia con la clase Actividad, esta a su vez instancia a la clase Documento, las clases Documento y Actividad tienen su propio DAO y en la capa de modelo cada una tiene su correspondiente clase, sin embargo la clase Actividad posee dos (2) diferentes modelos ya que esta puede tener el estado de resuelta y el estado de actividad del profesor, dependiendo del momento en el que se instancie y se llame la actividad esta va a tener diferentes parámetros, pero esto es independiente del DAO ya que este se encargará de encapsular la información de manera correcta de acuerdo a la situación en que se encuentre la actividad, los cambios se pueden apreciar en la Ilustración 38. El diagrama MVC (Ilustración 26) es modificado a la par del diagrama de clases y sirve para complementar la idea sobre las nuevas clases para el manejo de lógica sobre actividades, en este se muestra cómo se acomodan las nuevas clases en cada capa. Ilustración 26 Diagrama MVC v. 3

63

Las actividades se ajustan a los modelos anteriormente planteados, las funciones diseñadas permiten subir y descargar documentos, el inconveniente radica en documentos mayores a 15 Mb. Por lo tanto este punto se deja como deuda técnica para un futuro Sprint, para bloquear los documentos mayores al tamaño especificado y añadir una barra de estado donde se muestre el estado del documento al momento de cargarse. Las tareas de la HU 1007 tratan sobre el estudiante, el objetivo de esas tareas es darle al estudiante la capacidad de resolver actividades, por lo tanto se deben mostrar las actividades en primera medida, las actividades se muestran agrupadas por región, en la Ilustración 26 se puede ver como se muestran las actividades para los estudiantes, las actividades poseen la opción de ser seleccionadas para ser resueltas, cada actividad se muestra con su nombre, su fecha de vencimiento, su estado, la cantidad de intentos posibles y los hechos, y por último si es una actividad tipo archivo la opción de descargar el documento anexo, como ejemplo se ven un conjunto de actividades bajo la región Kalinov y las demás regiones se encuentran vacías, están dos (2) tipos de actividades en diferentes estados como cerradas y activas con el máximo número de intentos de respuestas. Ilustración 27 Vista Actividades por región para estudiantes. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017).

64

Las ventanas modales en las cuales se pueden resolver las actividades varían de acuerdo al estado en el que se encuentre la actividad, la primera ventana modal es cuando la actividad está activa y todavía hay intentos por realizar (Ilustración 28), la segunda ventana es cuando el estudiante ya realizó todos los intentos posibles para una activad y ya no se pueden hacer más envíos a esa actividad (Ilustración 29) y el ultimo estado es cuando la actividad está cerrada y por lo tanto no se pueden enviar respuestas o resolver (Ilustración 30). Ilustración 28 Actividad en estado activo. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). Ilustración 29 Actividad con el número máximo de intentos. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). Ilustración 30 Actividad cerrada. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). Con las tareas de diseño, más las tareas de codificación y la integración de dichas funcionalidades se completan las tareas a realizar en la HU 1007, se decide resolver primero esta HU antes que las HU 1006 y 1005 ya que es el paso siguiente a la

65

creación de actividades y esa es la resolución de actividades, por su parte la HU 1005 trata sobre la visualización de las respuestas de los estudiantes para el profesor, las vistas para el profesor se dividen en dos (2), una vista en actividades por región y otra vista es una lista de estudiantes los cuales se pueden seleccionar para ver todas las respuestas de un estudiante previamente seleccionado. Para resolver la HU 1005 se le dan dos (2) opciones al profesor, una vista en la cual se listan las actividades agrupadas por región (Ilustración 31), si la actividad se encuentra cerrada aparece la opción de ver la lista de estudiantes y las respuestas que cada estudiante envió, en caso de que un estudiante no envíe ninguna respuesta se le informa al profesor que el estudiante no resolvió la actividad y que la nota es 0, un ejemplo es la Ilustración 32, cuando una actividad aún no está cerrada se le muestra al profesor que la actividad aún está activa por lo tanto no la puede calificar ni ver las respuestas de los estudiantes, desde esta vista se pueden editar y eliminar las actividades, cumpliendo con una funcionalidad más de la HU 1005, estas funcionalidades se manejan en ventanas modales, la eliminación de actividades se basa en el cambio de estado de la actividad pero esta sigue existiendo en la base de datos. Ilustración 31 Actividades por región Profesores. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017).

66 Ilustración 32 Respuestas de una actividad. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). La segunda opción para que un profesor pueda calificar es una lista por estudiantes (Ilustración 34), desde dicha lista el profesor selecciona un estudiante con lo cual se muestran todas las respuestas del estudiante a todas las actividades que existen en el reino, si el estudiante no ha resultó una actividad se le notifica al profesor que la actividad no fue resuelta por el estudiante y que la nota respectiva es 0, la Ilustración 33 es un ejemplo de esta vista. Ilustración 33 Respuesta de un estudiante. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017).

67 Ilustración 34 Lista estudiantes en el reino. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). Las tareas de codificación en la HU 1005 radican en brindarle al profesor la capacidad de actualizar las notas de los estudiantes, con lo cual se garantiza que él puede calificar las actividades que realicen sus estudiantes, las diferentes formas de listar actividades y de listar estudiantes sirven para que el profesor pueda organizar y administrar sus notas de la mejor manera, así mismo para brindarle al estudiante la opción de solicitar notas. La última HU de este Sprint es la 1006, el objetivo de esta HU es el mostrar notas definitivas tanto a profesores como a estudiantes, para los profesores se tiene una vista completamente nueva y diferente ya que por solicitud del docente Luis Carlos Beltrán se desea una Tabla de notas en la cual se contrasten estudiantes y actividades, la vista para el diseño de la Tabla se puede ver en la Ilustración 35, las actividades también están agrupadas por región, en la parte inferior de la Tabla se aprecian el promedio de notas por cada actividad, por último para el manejo de notas para un estudiante se encuentra la Ilustración 36, las notas del estudiante se muestran agrupadas por región y en la parte superior de cada región se le informa al estudiante su nota con respecto al 100% de las actividades cerradas y activas, el acumulado se calcula automáticamente a medida que el profesor actualiza notas, con lo cual el estudiante puede ver su nota al momento de ser calificada y su acumulado sin ningún tipo de retraso. Ilustración 35 Notas por región. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017).

68 Ilustración 36 Notas para un estudiante. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). Con la vista anterior se da por finalizado el resumen de las actividades hechas durante el tercer Sprint. 3.3.3.5) Retrospectiva del Sprint El balance de este tercer Sprint es completamente positivo, el calendario se cumple de manera prácticamente exacta, incluso sobra un día para una revisión general de todas las funcionalidades, el cliente realiza pruebas para verificar las funcionalidades de las cuatro (4) HU y todas pasan los criterios de aceptación, esto no es de extrañarse ya que durante la ejecución del Sprint el cliente presenta un acompañamiento constante validando cada parte del trabajo desarrollado. Es el Sprint con mejor manejo de tiempo y con mejores resultados a pesar de las funcionalidades presentan un nivel de dificultad superior a las de los anteriores Sprint el tiempo se planifica y se maneja con mucho acierto, la deuda técnica del Sprint radica en las actividades tipo formulario las cuales desde la fase de planeación se deciden omitir en este Sprint y dejarse para un Sprint posterior. El equipo de desarrollo se muestra con buena disposición para continuar afrontando las HU restantes.

69


71

3.3.4) Cuarto Sprint 3.3.4.1) Definición del Cuarto Sprint Las HU que hasta el momento están sin desarrollar son las de menor prioridad, quedan las HU 1008, 1009, 1010 y 1011, para lograr un Sprint corto se decide abordar únicamente las primeras dos (2) HU, la primera HU se basa en la galería, la galería es una herramienta que el docente Luis Carlos Beltrán desea para poder compartir material informativo con sus estudiantes, para tal fin desea poder publicar imágenes y documentos, estos se deben poder descargar, la galería debe estar en la capacidad de publicar video de YouTube, y que estos se puedan reproducir desde Arcadia, la única persona autorizada a publicar material es el profesor, los estudiantes son únicamente espectadores de la galería. La segunda HU trata el tema de las novedades, una novedad es una notificación a todas las personas del reino en la cual se les informa de algún evento importante, inicialmente se plantean unos eventos para ser publicados en la Tabla de novedades pero estos son modificados por el cliente, de tal manera que los eventos que se publican como novedad son, cuando un estudiante ingresa al reino, cuando el profesor coloca elementos en la galería, cuando un profesor crea una actividad y cuando el profesor califica una actividad, estos eventos disparan la creación de una novedad en el reino, adicionalmente el profesor debe poder dejar mensajes como novedad, estos mensajes deben tener un máximo de trescientos (300) caracteres. Las novedades se deben ver de la misma manera para todos los integrantes del reino. El objetivo de este Sprint es cumplir con la creación de la galería y el estante de novedades, el diseño gráfico sigue a cargo del equipo de desarrollo y el trabajo se desarrolla sobre la página principal del reino. 3.3.4.2) Sprint Backlog La duración de este Sprint vuelve a ser regular con los dos (2) primeros Sprints, tiene una duración de tres (3) semanas y un día, los miembros del equipo continúan con la inversión de veinte (20) horas semanales, cuarenta (40) horas semanales entre los dos miembros del grupo y el esfuerzo son ciento veinticuatro (124) horas. Las tareas de codificación se multiplican por dos (2) debido a la práctica de codificación en pares.

72

∑ = + + + + ∗ + ∗ + ∗ + ∗ + + + ∗ + ∗+ ∗ + ∗ + = 𝐻 𝑎 Teniendo las dos variables se reemplazan en la Ecuación 1. 𝑥 = = . 𝑎 𝑎 Se redondea hacia arriba lo que da un resultado de tres (3) semanas y un día de duración del Sprint. Sprint Backlog: 4 Backlog ID: 10003 ID Historia de Usuario Tarea Prioridad Esfuerzo 1008 Actualización del modelo de bases de datos para soportar HU 1008 y 1009. 1 5 Diseño de clases para soportar funcionalidades de HU 1008 y 1009. 1 7 Diseño de Mockups para la galería en la página principal del reino. 2 6 Diseño de Mockups para la galería completa tanto para profesores como para estudiantes. 2 10 Diseño de Mockups para la ventana modal para la adición de elementos en la galería. 2 8 Codificación para la funcionalidad de adición de elementos a la galería. 3 9 Codificación para la visualización de elementos en la galería completa. 3 9 Codificación para la visualización de la galería en la página principal del reino. 3 3 Integración de funcionalidades de HU 1002 con el proyecto. 1 6 1009 Diseño de Mockups para la sección de novedades en la página principal del reino. 1 8 Codificación de novedades cuando el profesor califica una actividad. 2 4 Codificación de novedades cuando el profesor crea una actividad. 2 4 Codificación de novedades cuando un estudiante se inscribe en el reino. 2 3 Codificación de novedades cuando el profesor adiciona elementos en la galería. 2 3 Integración de funcionalidades de HU 1009 con el proyecto. 1 4 Tabla 20 Sprint Backlog 4.

73 3.3.4.3) Diagrama de Gantt Ilustración 39 Diagrama de Gantt Sprint 4.

Sprint ID 4 Backlog ID 10003 Historias de U. 1008 y 1009 Responsables Pablo Esteban y Julián Barbosa Descripción de las funcionalidades. La primera funcionalidad para esta Sprint es la creación de una galería en la página principal del reino, se deben mostrar videos, imágenes y documentos. La segunda funcionalidad radica en la adición de elementos a la galería, se deben poder subir imágenes, documentos y videos de YouTube, no debe existir límite en la cantidad de elementos a subir. La tercera funcionalidad es la visualización completa de la galería, ya que en la página principal del reino solo se muestran los últimos elementos añadidos, debe existir una vista en la cual la galería se pueda ver completamente. La cuarta funcionalidad es la publicación de novedades en el reino, las novedades se deben ubicar a la izquierda de la página principal del reino, se deben mostrar las últimas ocho (8) novedades. - Cuando un estudiante se inscriba en el reino. - Cuando el profesor crea una actividad. - Cuando el profesor califica una actividad. - Cuando el profesor añade un elemento a la galería. La última funcionalidad es darle al profesor la posibilidad de colocar un mensaje en la estantería de novedades. Tabla 21 Funcionalidades Sprint 4

74

3.3.4.4) Ejecución de Sprint En el cuarto Sprint se desarrolla primero la HU 1008, siguiendo el esquema utilizado en los Sprints anteriores como primera medida se añaden los campos y las Tablas necesarias a la base de datos para soportar la información que se requiera almacenar durante el desarrollo de las funcionalidades, se añade la Tabla de multimedia y una Tabla para especificar el tipo de multimedia que se desea añadir, la Tabla multimedia posee una relación con el reino con lo cual se garantiza que el material de un reino es únicamente para un reino en específico, esto se muestra en la ilustracion 44, la Tabla de novedades ya estaba presente desde Sprints anteriores por lo tanto en el tema de las novedades no hay cambio en la estructura de la base de datos. Ilustración 40 Diagrama MVC v. 4 El diagrama de clases también sufre modificaciones a nivel de funciones mas no a nivel de clases, se toma la decisión de no añadir clases ya que estas no tienen ningún comportamiento específico, todos los elementos de la galería únicamente se muestran y se crean, no tienen alguna funcionalidad que requiera ser modelada, por tal motivo la clase reino se encarga de la lógica de negocio tanto de novedades como de la galería, la cuarta versión del diagrama de clases es la Ilustración 45, el caso del diagrama MVC no es muy diferente al diagrama de clases, se añaden las

75

vistas respectivas a la galería y los demás cambios son soportados por los miembros ya existentes en el esquema, por lo tanto los cambios los sufre la capa de vista como se puede ver en la Ilustración 40. La galería se puede apreciar en la Ilustración 41, en esta imagen se pueden observar los tres (3) diferentes tipos de archivos elementos que soporta la galería, en la parte superior se pueden observar los videos, en el centro las imágenes, estas se ven en miniatura y se pueden descargar, los documentos tienen un icono de pergamino y se encuentran ubicados en la parte inferior de la imagen. La galería del estudiante es la misma vista, el único cambio es la opción de añadir elementos la cual es exclusiva del profesor. Ilustración 41 Galería completa. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017).

76

La visualización de la galería en la página principal cumple con los requerimientos planteados inicialmente, se muestra un solo video y las últimas tres (3) imágenes y documentos añadidos, en la izquierda de la Ilustración 42 se muestra el espacio que se utiliza para las novedades, estas se crean automáticamente al momento en que las dispara alguno de los eventos definidos en la Tabla 21, el botón azul en la parte inferior de las novedades sirve para enviar la novedad creada por el profesor y la cual pueden ver todos los miembros del reino. Ilustración 42 Página principal reinos con galería y novedades. En la parte superior de la Ilustración 41 se puede apreciar un botón verde, este cumple con la funcionalidad de invocar una ventana modal (Ilustración 43) desde la cual se pueden añadir los elementos a la galería, en esta ventana se puede seleccionar el tipo de elementos que se desea añadir, si es un video de YouTube

77

se requiere el enlace completo al cual se le hace un tratamiento para convertirlo en un enlace compatible, luego de esto se almacena en la base de datos. Ilustración 43 Ventana modal adición de elementos en galería. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). 3.3.4.5) Retrospectiva del Sprint Este es el penúltimo Sprint, la planeación fue exitosa y el Sprint se ejecutó con el retraso de un día, la falla radica en la estimación de tiempos ya que las notificaciones abordan muchas otras funcionalidades y la preparación para la creación de novedades no se estimó correctamente, las novedades se disparan desde un punto centralizado pero los disparadores provienen de diferentes fuentes y esto provoca una confusión en el equipo de desarrollo, sin embargo las funcionalidades se completan satisfactoriamente. La creación de la galería superó las expectativas del cliente, el docente Luis Carlos Beltrán expresa su gusto por la galería tanto en su funcionalidad como en la parte visual y estética, la galería cumple con los requisitos al permitir que el profesor añada material y los miembros del reino puedan ver dicho contenido de manera ordenada por tipo de archivo y cronológicamente, la vista reducida de la galería en la página principal del reino como se plantea al inicio del Sprint permite visualizar los últimos elementos añadidos. Las novedades presentan un comportamiento estable al generarse cuando los eventos las disparan, estas se muestran correctamente para profesores y alumnos al mostrarse únicamente las últimas ocho (8) novedades las cuales a su vez se ordenan cronológicamente de la más nueva a la más antigua. El equipo de desarrollo muestra conformidad con el trabajo realizado durante en el Sprint, los aspectos positivos superan con creces la falta de comunicación al inicio de la preparación del Sprint y se presenta un muy animado al saber que se afronta el último Sprint con un buen trabajo realizado anteriormente.

78


80

3.3.4) Quinto Sprint 3.3.4.1) Definición del quinto Sprint Este es el último Sprint del proyecto Arcadia, hasta el momento se han desarrollado las HU de la 1000 hasta la 1009, únicamente restan las últimas dos (2) HU que son la 1010 y la 1011, esas dos se van a abordar durante este quinto Sprint dando prioridad a la HU 1011. La HU 1011 tiene como objetivo gamificar a Arcadia, brindarle al estudiante la sensación de que no solamente está estudiando si no que está jugando y sus logros académicos se ven reflejados en su personaje ficticio dentro del juego, por eso se brinda al estudiante la opción de pertenecer a una clase y que la clase tenga asociado un nivel dependiendo de la nota general en el reino, lo mismo al subir el estudiante de nivel, es decir que a medida que sus notas mejoren obtiene premios e incentivos, dada la importancia de esta HU se desarrolla primero durante el Sprint dejando como ultima HU a desarrollar la 1010. Desde el planteamiento del proyecto el docente Luis Carlos Beltrán hizo énfasis en las actividades tipo cuestionario sin embargo no estaba completamente claro el alcance de estas actividades o la forma de desarrollarse, se desea que este tipo de actividad tenga un papel protagónico o resaltado dentro de Arcadia, por esta misma razón se crea una HU únicamente para el tratamiento de los cuestionarios, esta HU se deja como ultima HU debido a que el cliente no tenía la idea totalmente definida desde un inicio, uno de los requisitos es el desarrollo de los cuestionarios bajo el ambiente de Unity, así mismo el tiempo de desarrollo de esta HU posee lagunas debido a la inexperiencia del equipo de desarrollo en Unity. Con base en lo anterior se definen los objetivos del Sprint, los cuales son la creación de las clases, el manejo de niveles, la creación de la nota en el reino, la creación y manejo de actividades tipo cuestionario, y por último una revisión general de todas las funcionalidades desarrolladas durante todos los cinco (5) Sprints. 3.3.4.2) Sprint Backlog Este es el segundo Sprint más largo, tiene una duración de cinco (5) semanas y un día, los miembros del equipo continúan con la inversión de veinte (20) horas semanales, cuarenta (40) horas semanales entre los dos miembros del grupo y el esfuerzo son doscientos tres (203) horas.

81

Las tareas de codificación se multiplican por dos (2) debido a la práctica de codificación en pares. ∑ = + + + + + + ∗ + ∗ + ∗ + ∗ + + + ++ ∗ + ∗ + + = 𝐻 𝑎 Teniendo las dos variables se reemplazan en la Ecuación 1. 𝑥 = = . 𝑎 𝑎 Se redondea hacia arriba lo que da un resultado de cinco (5) semanas y un día de duración del Sprint. Sprint Backlog: 5 Backlog ID: 10004 ID Historia de Usuario Tarea Prioridad Esfuerzo 1011 Actualización del modelo de bases de datos para soportar HU 1011 y 1010. 1 8 Diseño de clases para soportar funcionalidades de HU 1011 y 1010. 1 7 Definición de clases para los estudiantes según su género y niveles según su clase. 2 4 Diseño de imágenes para las clases definidas en la anterior tarea. 2 8 Diseño y modificación de los formularios de inscripción y edición de datos para el estudiante. 2 3 Diseño de iconos para los estudiantes según su clase. 3 2 Codificación para añadir la clase al estudiante. 3 8 Codificación para añadir el título al estudiante y la selección de un título entre muchos. 3 6 Codificación para añadir la opción al estudiante de seleccionar su avatar. 3 4 Codificación para cálculo de nivel, nota en región y novedad con respecto al nivel. 3 10 Integración de funcionalidades de HU 1011 con el proyecto. 1 8 1010 Diseño de Mockups para la adición de actividades tipo cuestionario en el formulario de creación de actividades. 1 6 Diseño de vistas para la resolución de actividades tipo cuestionario en Unity. 1 12 Investigación sobre la comunicación entre Unity y PHP. 2 8

82

Codificación de creación de actividades tipo cuestionario. 2 8 Codificación para la resolución de actividades tipo cuestionario en Unity y el almacenamiento de la nota en la base de datos. 2 20 Integración de funcionalidades de HU 1010 con el proyecto. 1 15 Revisión Revisión general de todas las funcionalidades. 1 10 Tabla 22 Sprint Backlog 5. Tabla 23 Funcionalidades Sprint 5.

Sprint ID 5 Backlog ID 10004 Historias de U. 1010 y 1011 Responsables Pablo Esteban y Julián Barbosa Descripción de las funcionalidades. La primera funcionalidad es la opción del estudiante de seleccionar una clase al momento de inscribirse en Arcadia, estas clases se muestran en la Tabla 25 y dependen del género del estudiante. La segunda funcionalidad es darle un título al estudiante, el título acompaña al nickname del estudiante. La tercera funcionalidad es permitir que el estudiante escoja su título y su avatar si puede hacerlo. La cuarta funcionalidad es calcular la nota en la región, la forma para calcular la nota se muestra en la Ecuación 2. La quinta funcionalidad es asignarle un nivel al estudiante dependiendo de su clase y su nota en el reino, los niveles se muestran en la Tabla 24. Cuando un estudiante sube de nivel, se le debe otorgar un nuevo título y un nuevo avatar dependiendo de su clase, esta es la sexta funcionalidad. La séptima funcionalidad es la creación de actividades tipo cuestionario, estas se deben poder crear en la página de creación de actividades. La octava funcionalidad es crear un banco de preguntas con opción múltiple y única respuesta. La octava funcionalidad es determinar la cantidad de preguntas a un cuestionario y añadir estas preguntas al cuestionario desde el banco de preguntas. La novena funcionalidad es mostrarle la actividad tipo cuestionario al estudiante. La décima funcionalidad radica en permitir que el estudiante pueda resolver el cuestionario y este se califique automáticamente.

83

3.3.5.3) Diagrama de Gantt Ilustración 46 Diagrama de Gantt Sprint 5 3.3.5.4) Ejecución de Sprint Para este último Sprint se realiza una revisión completa de la base de datos, verificando Tabla por Tabla y campo por campo todo este correcto, previo a la revisión se realizan las modificaciones a la estructura de la base de datos, se realiza la adición de las nuevas Tablas para el manejo de clases, títulos, niveles y cuestionarios, la Tabla honor_estudiante se encarga del manejo de los títulos del estudiante, por su parte la Tabla cuestionario se encarga de almacenar los cuestionarios y de relacionar las preguntas y sus respuestas a las actividades, posterior a la revisión y a la edición del modelo de bases de datos el diagrama de datos en su quinta y última versión se muestra en la Ilustración 57. La decisión de utilizar MVC desde el principio permitió generar una estructura flexible y estable para todo el proyecto, todas las funcionalidades se han desarrollado bajo la estructura con un buen resultado, estas últimas funcionalidades se han agregado de la misma manera que en las oportunidades anteriores, se adicionan las vistas para la visualización de cuestionarios, los modelos para el manejo de títulos y clases, y el DAO para la consulta de clases, el diagrama al igual que la base de datos se revisa y se verifica ya que esta es la última versión (Ilustración 47). El diagrama de clases se actualiza a su última versión para soportar las nuevas funcionalidades, se añaden las clases para los modelos de pregunta y respuesta con el respectivo DAO, las funciones para el manejo de títulos en la clase estudiante y el modelo de lógica de la clase, el diagrama de clases en su quinta versión se puede ver en la Ilustración 58.

84 Ilustración 47 Diagrama MVC v. 5 El desarrollo del Sprint incluye tareas en las cuales se definen los niveles de los estudiantes, uno de los objetivos de Arcadia es incentivar el estudio en los participantes, la forma de hacer esto es mediante la gamificacion y el juego, para tal fin Arcadia incluye un elemento que es el nivel, el nivel es el reflejo de la nota del estudiante, de tal manera que a medida el promedio del estudiante mejora, el nivel del estudiante también mejora, con esto se busca que el estudiante tenga un motivante extra a la nota final en su reino, y desligar la calificación clásica de Arcadia como lo solicita el docente Luis Carlos Beltrán. El manejo del nivel dentro de Arcadia está ligado a la clase que escoge un estudiante al momento de inscribirse, la clase está ligada al estudiante por lo cual en cualquier reino al cual se inscriba el estudiante siempre va a tener la misma clase, la clase depende del género del estudiante por lo tanto si el estudiante es de género femenino su clase es diferente a las de género masculino, mismo caso ocurre con los niveles, los niveles dependen de las clases, en la Tabla 24 se muestran las clases según el género y los respectivos niveles de acuerdo a la nota y a la clase.

85

Genero Clase Nivel Nota en el Reino Femenino Guerrera Cuidadora de vacas 𝑥 . Valiente . < 𝑥 . Capitana . < 𝑥 . Reina Guerrera 7.5 < 𝑥 . Maga Estudiosa 𝑥 . Arcanista . < 𝑥 . Invocadora . < 𝑥 . Archimaga 7.5 < 𝑥 . Cambia Pieles Oruga 𝑥 . Tumba Arboles . < 𝑥 . Reina de la Jungla . < 𝑥 . Madre de los Dragones 7.5 < 𝑥 . Slayer Amazona 𝑥 . Arciere . < 𝑥 . Protectora . < 𝑥 . Francotiradora 7.5 < 𝑥 . Masculino Guerrero Granjero 𝑥 . Mosquetero . < 𝑥 . Sargento . < 𝑥 . Invicto 7.5 < 𝑥 . Mago Aprendiz 𝑥 . Elementalista . < 𝑥 . Hechicero . < 𝑥 . Archimago 7.5 < 𝑥 . Cambia Formas Insecto 𝑥 . Emboscador . < 𝑥 . Demoledor . < 𝑥 . Fuego Eterno 7.5 < 𝑥 . Ranger Elfo 𝑥 . Lethal . < 𝑥 . Fusilero . < 𝑥 . Cazador de Cabezas 7.5 < 𝑥 . Tabla 24 Clases y niveles en Arcadia. La obtención del nivel es independiente en cada reino, por tanto en cada reino se tiene un nivel diferente dependiendo de la nota en el reino, el cálculo de la nota se realiza de acuerdo a las ecuaciones 3 y 4.

86

𝑃 𝑎 𝑎 𝐴 𝑎 = 𝑃 = ∑ 𝑖 𝑛𝑖=

𝑃 < , 𝑁 𝑎 = 𝑁 = ∑ 𝑎𝑖 ∗ 𝑖𝑛𝑖=

𝑃 , 𝑁 𝑎 = 𝑁 = ∑ 𝑎𝑖 ∗ 𝑖𝑃𝑛𝑖= El manejo de la nota se realiza según el acumulado del porcentaje de las actividades el cual se muestra como 𝑖 y la nota en una actividad se denomina 𝑎𝑖 dependiendo del valor que tome el acumulado se toman dos (2) casos, el primer caso (Ecuación 3) en el cual el acumulado es menos a 100, lo cual implica que las notas en las regiones no se han completado, con lo cual el estudiante adquiere niveles a medida que sus notas se van acumulando, el caso dos (2) en el cual la suma es mayor a 100 implica que una región ya se ha completado, la nota se sigue acumulando, por lo cual el estudiante puede subir de nivel o incluso descender dependiendo de su rendimiento en las nuevas actividades. Los títulos son frases que se colocan al final del nickname del estudiante, los títulos se ganan a medida que un estudiante sube de nivel, el título es el nombre del nivel,

por ejemplo si un estudiante sube al nivel Hechicero del mago obtiene el título “el Hechicero” en caso de ser el estudiante de género femenino y alcanza el nivel protectora obtiene el título “la Protectora”, una de las tareas de este Sprint se basa en la adquisición de títulos y selección de títulos por parte del estudiante, en la Ilustración 48 se muestra el título de un estudiante y la selección donde el estudiante puede escoger alguno de sus títulos obtenidos.

Ecuación 2 Sumatoria porcentaje actividades en reino Ecuación 3 Nota en reino caso 1. Ecuación 4 Nota en reino caso 2.

87 Ilustración 48 Titulo de un estudiante y selección de avatar. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). En el caso del avatar este se obtiene igual que los títulos, también se puede seleccionar en la misma vista de perfil del estudiante, al momento de seleccionar la clase en el registro por defecto se le da un avatar y un título dependiendo de la clase (Ilustración 49), adicionalmente al momento de seleccionar una clase se adquiere un poder en la vida real, los poderes se muestran en la Tabla 25. Ilustración 49 Registro del estudiante y las clases. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). Clase Poder Guerrero o Guerrera Puede comer en clase para regenerar su fuerza (No a la comida con olores fuertes)

88

Mago o Maga Puede hacerse invisible y llegar 5 minutos tarde a clase (No válido en Exámenes) Cambia Pieles o Cambia Formas Puede alterar su uniforme en clase (Debe seguir las reglas de la moda) Ranger o Slayer Pude escoger donde sentarse en clase gracias a su gran velocidad (Es genial) Tabla 24 Poder según la clase. La nota en el reino y el nivel se muestran en la página principal del reino del estudiante, en la Ilustración 50 se puede ver esta información, adicionalmente el oro, el cual se deja para futuros desarrollos ya que el docente Luis Carlos Beltrán no definió completamente el uso del oro. Ilustración 50 Nota y nivel del estudiante. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). Las tareas con respecto a las actividades tipo cuestionario se deciden afrontar en la parte final del proyecto debido a la dificultad de los requerimientos, el primer paso es la creación de las preguntas, para tal fin se genera un banco de preguntas en el cual el profesor añade, edita y elimina las preguntas, las preguntas únicamente pueden ser de opción múltiple con única respuesta, son cuatro (4) opciones, en la Ilustración 52 se muestra un ejemplo de una preguntas creadas y en la Ilustración 51 se puede ver el formulario para la creación de preguntas. Una vez el profesor ha definido sus preguntas se debe crear una actividad tipo cuestionario.

89 Ilustración 51 Creación preguntas. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). Ilustración 52 Listado de preguntas. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). La creación de la actividad tipo cuestionario (Ilustración 53) difiere completamente de los otros tipos de actividades, aunque incluye los campos usados en las actividades tipo archivo, los cuales son nombre de la actividad, fecha de vencimiento, porcentaje de la nota, descripción y cantidad de intentos, se añade un nuevo campo el cual es la cantidad de preguntas, este automáticamente añade la cantidad de preguntas a los campos del formulario, en cada campo se puede escoger una pregunta del banco de preguntas de la Ilustración 52, estas preguntas se seleccionan y se añaden al cuestionario, de tal manera que el cuestionario está listo para que el estudiante lo resuelva.

90 Ilustración 53 Creación actividad tipo cuestionario. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). El estudiante puede visualizar las actividades tipo cuestionario al igual que las demás actividades, la diferencia está en la forma en la cual se resuelve, al momento del estudiante intentar resolver la actividad tipo cuestionario aparece una ventana modal (Ilustración 54) en la cual se aparece la opción de ir al cuestionario. Ilustración 54 Ventana Modal Resolver Cuestionario. Tomado del sitio web proyectoarcadia.com. (Fecha de actualización 03/03/2017). La opción de resolver el cuestionario redirige al estudiante a una vista en la cual se encuentra embebida la aplicación desarrollada sobre Unity, en la vista está la opción de iniciar a resolver el cuestionario (Ilustración 55), una vez se inicia el cuestionario se muestra una pregunta a la vez, cada pregunta visualiza sus cuatro (4) opciones y su enunciado, un ejemplo de esto se puede ver en la Ilustración 56, una vez el estudiante ha terminado de resolver todas la preguntas se muestra el resultado y la nota final (Ilustración 57), esta nota se computa automáticamente con las demás

91

notas del estudiante, los cuestionarios se pueden resolver tantas veces como lo defina el profesor y únicamente es válido el último intento realizado por el estudiante. Ilustración 55 Vista inicial cuestionarios. Ilustración 56 Ejemplo de una pregunta en un cuestionario. Ilustración 57 Resultado de un cuestionario.

92

Con esto se completan las tareas definidas para las HU desde la 1000 hasta la 1011, la única tarea restante es una revisión general de todas las funcionalidades la cual se completa con satisfacción. 3.3.5.5) Retrospectiva del Sprint El manejo del tiempo de este Sprint muestra una falla en el proceso de asignación de tiempo al inicio del Sprint, debido a una demora en la finalización del Sprint, la demora es de cuarenta (40) horas, es decir una semana de desarrollo, el déficit de tiempo se basa en las tareas de la HU 1010, estas tareas presentan dificultades ya que los miembros del equipo de desarrollo muestran inexperiencia sobre el desarrollo en la plataforma Unity, la tarea de investigación también presenta una desatino en la estimación del tiempo y por su parte se demora el doble de lo que estaba estimado. Pese a los problemas el Sprint se culmina de manera satisfactoria en cuanto a las tareas se refiere, todas las tareas se logran terminar e integrar en el proyecto. Con respecto a las DH todas se logran superar al momento de las pruebas del cliente, en primera medida las DH de las HU 1010 que hablan sobre el desarrollo de una actividad tipo cuestionario en Unity, se cumplen y en palabras del cliente “superan sus expectativas”, las tareas de la HU 1011 también se completan, estas presentan una dificultad en la integración por la gran cantidad de funcionalidades a las cuales se debe adaptar, lo que implica un cuidado extra para evitar perjudicar el comportamiento de las demás funcionalidades. El proyecto se culmina con este último Sprint, los resultados son muy favorables en el tema de las HU, ya que todas se abordan y las tareas que se crean a partir de las HU se finalizan, las DH que plantea el docente Luis Carlos Beltrán se satisfacen en su totalidad, con lo cual se garantiza que el cliente obtuvo un producto que cumple con sus expectativas y sobre todo logra materializar la idea al inicio del proyecto. La duración total del desarrollo del proyecto es de catorce (17) semanas, lo que implica una inversión de seiscientos ochenta (680) horas. La versión final del proyecto se encuentra en enlace proyectoArcadia.net. El código del proyecto se puede ver en el repositorio de gitHub https://github.com/julbar22/Arcadia.

93

3.3.5.6) Anexos Ilustración 58 Diagrama Entidad-Relación v. 5

95

Capítulo 4. Conclusiones A lo largo de este trabajo se logra desarrollar una herramienta cuyo fin es el apoyar la educación bidireccional en el aula de clase, la herramienta es un entorno virtual de aprendizaje que recibe el nombre de Arcadia; un sitio web requiere cumplir con los elementaos definidos por Scagnoli para poder entrar en la categoría entorno virtual de aprendizaje, en primera medida Arcadia posee una galería en la cual se puede compartir información audiovisual y documentos, incluye un cuadro de novedades en donde profesores y estudiantes comparten sus logros e ideas, Arcadia permite al profesor crear diferentes tipos de actividades, estas actividades tienen límites de intentos, fecha de cierre, porcentaje acumulado y documentos anexos, así mismo estas actividades pueden ser resueltas por los alumnos, ya sea resolviendo cuestionarios o enviando sus respuestas como documento anexo, las actividades tienen asociada una nota, esta se coloca de forma automática o es puesta por el profesor, con esto se cumplen cuatro de los componentes esenciales de todo entorno virtual, el último componente está implícito en Arcadia y es la seguridad de la información, la información se almacena en una base de datos protegida por usuarios y contraseñas, la fiabilidad del sistema está garantizada por el modelo de arquitectura bajo el cual está hecho Arcadia el cual hace que la estructura a nivel lógico sea confiable y extensible, por lo tanto se concluye que proyectoArcadia.net satisface los requisitos para ser un entorno virtual de aprendizaje y por lo tanto es un entorno virtual de aprendizaje. Si bien Arcadia es un entorno virtual de aprendizaje no solamente busca ofrecerle una serie de servicios al profesor para mejorar sus procesos educativos, Arcadia busca llegar al estudiante y ser atractivo ante los ojos de éste, para tal fin se implementan elementos utilizados en múltiples videojuegos, entre los cuales están el nivel, los avatares, los títulos, el mapa y las clases, todo esto está enfocado en llevar a Arcadia a un punto en el cual se convierte en un juego educativo y desde el cual se permite tanto al profesor como al estudiante disfrutar de un punto de interés en común y lograr fortalecer el proceso bidireccional pedagógico, de esa manera proyectoArcadia.net ofrece las garantías necesarias para ser un puente entre estudiantes y docentes, y apoyar el crecimiento del proceso pedagógico bidireccional. El rediseño del sitio web mundoarcadia.co se obtiene al incluir durante todo el proceso de desarrollo del nuevo sitio proyectoArcadia.net al fundador del proyecto Arcadia, el docente Luis Carlos Beltrán, con lo cual se consigue la abstracción de las ideas de Beltrán y volverlas realidad en el nuevo Arcadia, tomando como punto de partida el sitio web de Beltrán se logra definir toda una serie de requerimientos

96

que se utilizan para mejorar y ampliar las funcionalidades de éste, entre las nuevas funcionalidades están la creación de usuarios, la agrupación de estudiantes, el manejo y creación de actividades, la administración de notas y la creación de mensajes de difusión personalizados, estas son las ventajas que presenta el nuevo sitio web de Arcadia con respecto a su anterior versión, con lo cual el proyectoArcadia.net presenta una fuerte mejora en cuanto a la cantidad y calidad de los servicios que ofrece a la comunidad académica, gracias a las funcionalidades, a la seguridad y a los servicios que posee proyectoArcadia.net se concluye que este nuevo entorno virtual es más usable y ofrece mayores garantías que el sitio web anterior. El proceso de desarrollo de proyectoArcadia.net se realiza bajo la metodología de desarrollo Scrum, esta ofrece las herramientas necesarias para culminar el proyecto de manera exitosa, además permite documentar todas las etapas de desarrollo desde su inicio hasta su fin de manera iterativa, la documentación se basa más en la explicación de lo hecho durante cada iteración y la entrega de un producto, y menos en la diagramación y documentación, sin embargo no se omite la implementación de diagramas que permitan facilitar y mejorar el trabajo durante cada iteración, Scrum consiente la flexibilidad de agregar elementos como los diagramas mientras esto no entorpezca el trabajo, con esto se concluye la buena escogencia de metodología de desarrollo Scrum para este proyecto ya que permitió finalizar el proyecto y entregar un producto finalizado al cliente.

97

Glosario En este glosario se procuran aclarar términos que los autores consideran pueden llegar a ser confusos para el lector o que se van a utilizar de manera continua durante todo el documento por lo cual se hace un énfasis especial en clarificar y unificar definiciones. OECD Fundada en 1961, la Organización para la Cooperación y el Desarrollo Económicos (OCDE) agrupa a 34 países miembros y su misión es promover políticas que mejoren el bienestar económico y social de las personas alrededor del mundo. La OCDE ofrece un foro donde los gobiernos puedan trabajar conjuntamente para compartir experiencias y buscar soluciones a los problemas comunes. Trabajamos para entender que es lo que conduce al cambio económico, social y ambiental. Medimos la productividad y los flujos globales del comercio e inversión. Analizamos y comparamos datos para realizar pronósticos de tendencias. Fijamos estándares internacionales dentro de un amplio rango de temas de políticas públicas. (OECD, 2015) Juegos de rol En estos, los jugadores toman o asumen un papel dentro de un ambiente fantástico que puede variar desde las epopeyas medievales hasta la ciencia ficción. Su origen parece haber iniciado con el SimSoc del profesor de sociología William A. Gamson, sin embargo, fue con el juego Calabozos y Dragones en la década de los 70 que este tipo de juegos adquirieron la forma con la que hoy se les conoce. Esto porque se dieron las características esenciales como la creación de reglas, la utilización de hojas de personaje para su desarrollo, mapas específicos para cada situación y la implementación de una guía de juego conocido como el “master”, todo esto fue diseñado como un juego de mesa para varios jugadores. Ya en la década de los 90, con el auge de los videojuegos, los juegos de rol hicieron su aparición en computadores y consolas conservando algunas características como el desarrollo del personaje; ejemplo de ello son juegos como La Leyenda de Zelda o Final Fantasy que gozan de mucha popularidad alrededor del mundo. Sin embargo, su evolución no pararía allí y con la llegada del internet a los hogares, los juegos de rol pasaron a la etapa de los MMORPG (Massive Multiplayer Online Rol

98

Playing Games), Juegos de rol masivos multijugador en línea por sus siglas en inglés. (Beltrán, 2014). Pruebas PISA El Programa para la Evaluación Internacional de Alumnos (PISA) es una encuesta trienal internacional que tiene como objetivo evaluar los sistemas de educación en todo el mundo mediante pruebas de las habilidades y conocimientos de los estudiantes de 15 años de edad. Hasta la fecha, los estudiantes que representan a más de 70 economías han participado en la evaluación. Los resultados más recientemente publicados son de la evaluación en 2016. Alrededor de 510.000 estudiantes en 65 economías participaron en la evaluación PISA 2016 de la lectura, las matemáticas y la ciencia que representa unos 28 millones de jóvenes de 15 años a nivel mundial. De esas economías, 44 participaron en una evaluación de solución creativa de problemas y 18 en una evaluación de la educación financiera. Shamanimals Shamanimals Fantastic Tales es una serie de libros animados e interactivos, los cuales recrean clásicos de la literatura universal con el objetivo de fomentar el hábito de lectura en niños de 6 a 8 años. La aplicación cuenta con trivias y ejercicios prácticos que evalúan el nivel de compresión de los usuarios. Detrás del desarrollo de Shamanimals, se encuentra Red Mapache, un emprendimiento social que desarrolla videojuegos y libros digitales con el propósito de impulsar el acceso igualitario al material educativo (Ortega, 2014). Sloan Consortium (Sloan-C) Comenzando en 1992 con el nombre de su fundador Alfred P. Sloan y cambiando en 2014 como una organización auto-sostenible en todo el mundo se le ha cambiado el nombre a Online Learning Consortium (OLC), la cual es la principal organización profesional dedicada al avance de la calidad del aprendizaje en línea, proporcionando desarrollo profesional, y siendo una guía para las mejores prácticas de instrucción, investigación, y orientación a los educadores, profesionales en línea y organizaciones en todo el mundo.

99

Según las directivas del Online Learning Consortium (2015) el valor real de OCL es ser parte de una comunidad global a la que pertenecen cientos de instituciones y empresas en más de 14 países dedicada a avanzar en las mejores prácticas del aprendizaje en línea. Ukanbook Se denomina Ukanbook como un aula de evaluación escolar que logró reconocimientos por la tecnología, veracidad, efectividad y soporte a las instituciones educativas en Sur América, Estados Unidos y Telavit. En la actualidad la plataforma es un aula de evaluación de grado 1º a 11º, que le brinda a los colegios contenido y estadísticas en tiempo real. Ukanbook se convierte en la herramienta que todos los colegios a nivel nacional puedan utilizar y apersonar para mejorar el rendimiento de sus estudiantes, no solo para las pruebas Saber 11- ICFES, sino también como aula de evaluación de primaria y secundaria (Ukanbook, 2015). WEB 2.0 Es un término que ha tenido un gran auge en la última década desde que Dale Dougherty lo utilizó por primera vez en 2004 en una conferencia que se llevaba a cabo sobre el futuro de la web. Sin embargo, el término ha adquirido cierta ambigüedad, ya que puede referirse, a un gran conjunto cambiante de herramientas tecnológicas o a una aproximación al uso social y tecnológicamente integrado de la tecnología (Light & Polin, 2010). Para esta investigación se tomará la primera definición, la cual se refiere al grupo de tecnologías que facilitan conectarse socialmente a la web a través de la adición o edición de información. Entre ellas están blogs, wikis, podcasts y redes sociales entre otros. (Beltrán, 2014) Gamificacion Para (Gallego, Molina , & Llorens, 2014) la gamificacion es “una técnica, un método y una estrategia. Parte del conocimiento de los elementos que hacen atractivos a los jugos e identifica, dentro de una actividad, tarea o mensaje determinado, en un entorno NO-juego, aquellos aspectos susceptibles de ser convertidos en juegos”.

100

Bibliografía Álvarez Garcia, A., de las Heras del Dedo, R., & Lasa Gómez, C. (2012). Métodos Ágiles y Scrum. En Métodos Ágiles y Scrum (págs. 30 - 45). Madrid: Anaya. Bahit, E. (28 de Junio de 2015). Dirección Universitaria de evaluación y acreditación. Obtenido de http://www.duea.umss.edu.bo/documentos/Plan_car_184799.pdf Barberà, E., & Badia, A. (2005). El uso educativo de las aulas virtuales emergentes. Revista de Universidad y Sociedad del Conocimiento, 1 - 12. Beltrán, L. C. (2014). Procesos comunicativos con enfoque bidireccional en una experiencia pedagógica basada en la web 2.0 y los juegos de rol. Bogota: Tecnologico de Monterrey. Booch, G., Rumbaugh, J., & Jaconson, I. (2006). El lenguaje Unificado de Modelado. En G. Booch, J. Rumbaugh, & I. Jaconson, El lenguaje Unificado de Modelado (págs. 3-38). Madrid: PEARSON EDUCACION S.A. Bruner , J. (1984). Pragmatics of Language and Language of Pragmatics. Social Research: An International Quarterly , 969-984. Calabria, L., & Piriz, P. (2003). Metodologia XP. Montevideo: Universidad ORT Uruguay. Capuñay, O. (2013). Desarrollo Web con PHP: Aprende PHP paso a paso. O. Capuñay, Desarrollo Web con PHP: Aprende PHP paso a paso, 1 - 6. Clarenc, C. A., & S. M. Castro, C. L. (Diciembre de 2013). Analizamos 19 plataformas de eLearning: Investigación colaborativa sobre LMS. Recuperado el 14 de Enero de 2016, de http://www.congresoelearning.org/

101

Derboven, J., Zaman, B., Vissers, J., & Geerts, D. (2015). The Fun-Serious Ambiguity in Educational Games. ACM, 2830-2832. Dillenbourg, P. (2000). Virtual Learning Environments. EUN Conference 2000: Learning in the millenium : Building new education strategies for schools, 1 - 30. Gallego, F., Molina , R., & Llorens, F. (2014). Gamificar una propuesta docente. XX Jornadas sobre la enseñanza universitaria de la informática (págs. 12-13). Alicante: AENUI. Granadoz, R. (2015). Desarrollo de aplicaciones web en el entorno servidor. Malaga: IC Editorial. Gurría, A. (2012). PISA 2012 Results. Paris: OECD. Herrera, H. J. (2005). Capitulo 3: Problemas Críticos Colombianos. En P. Amaya, Problemas Críticos Colombianos. Bogota. Ipsos-Napoleón Franco. (18 de Junio de 2015). Ipsos. Obtenido de Ipsos: http://www.ipsos.com.co/?q=es/ Kniberg, H. (2015). Scrum and XP From the Trenches . Gothenburg: InfoQ. Krick, E. (2004). Introduccion a la Ingenieria y al Diseño en la Ingenieria. Mexico D.F.: Limusa S.A. Kumar, N., & Kandasamy, M. (2011). The virtual classroom: A catalyst for institutional. Australasian Journal of Educational Technology, 1388-1412. Light, D., & Polin, D. (2010). Integratin Web 2.0 tools into the classroom: Changing the culture of learning. New York: Center for Children and Technology. Lopez, A. (2009). Fundamentos de informatica para profesionales de la Salud. Albacete: Creative Commons Attribution 2.0.

102

Manero, B., Torrente, J., Serrano, A., Martinez, I., & Baltasar, F. (2015). Can educational video games increase high school students' interest in theatre? ScienceDirect, 182-185. Marters , B., & Achten, H. (2008). Do you Moodle? Experiences with a virtual learning environment . International Conference on Education and Research in Computer Aided Architectural Design in Europe, 153 - 160. Martin, F. (2010). Best practices for teaching in a synchronous virtual classroom. International Conference on Technology for Education, 44 - 46. Martin, J. (4 de 3 de 2013). Pulso Social. Obtenido de Shamanimals, educación y entretenimiento con un solo clic: http://pulsosocial.com/2013/03/04/shamanimals-educacion-y-entretenimiento-con-un-solo-clic/ Minera, F. (2008). Curso de programación PHP. Buenos Aires: USERSHOP. MINTIC. (26 de Enero de 2015). Sitio Web Oficial del Ministerio de Tecnologias de la Informacion y las Comunicaciones. Obtenido de Sitio Web Oficial del Ministerio de Tecnologias de la Informacion y las Comunicaciones: http://www.mintic.gov.co/portal/604/w3-article-8215.html MinTic;Fedesoft. (2014). Fortalecimiento de la industria TI. Obtenido de Fortalecimiento de la industria TI: www.fiti.gov.co Muñoz, P. (2010). Mantenimiento de portales de informacion. Madrid: Visión Libros. Nyarko, M., & Ventura, N. (2010). E-Learning: Virtual Classrooms as an Added Learning. IEEE, 426-431. OECD. (2013). PISA 2012 Results in Focus. En OECD, PISA 2012 Results in Focus (pág. 4). OECD.

103

OECD. (18 de Junio de 2015). OECD. Obtenido de OECD: http://www.oecd.org/pisa/aboutpisa/ Online Learning Consortium. (18 de Junio de 2015). Online Learning Consortium. Obtenido de Online Learning Consortium: http://onlinelearningconsortium.org/about/olc-2/ Oracle. (1 de Marzo de 2016). Oracle.com. Obtenido de Oracle.com: http://www.oracle.com/technetwork/java/dataaccessobject-138824.html Ortega, C. (26 de Mayo de 2014). YOUNGMARKETING.CO. Obtenido de YOUNGMARKETING.CO: http://www.youngmarketing.co/aplicacion-convierte-clasicos-literarios-en-una-divertida-experiencia-educativa/ Peña, J. L. (2014). Las Cinco Tendencias del Uso de Internet en Colombia. Enter, 32. Pitt, C. (2012). Pro PHP MVC. Pro PHP MVC, 1 - 40. Pressman, R. (2010). Software Engineering A Practitioner`s Approach (7ma ed.). New York: McGraw Hill. Rosnay, J. (1977). El Macroscopio. Madrid: Editorial AC. Rubin, E. (1992). Patologia. Medicina, 188 - 189. Sampieri, R., Collado, C., & Baptista, P. (2006). METODOLOGÍA DE LA INVESTIGACIÓN. México, D.F: McGraw-Hill Education. Scagnoli, N. (2008). El aula virtual: usos y elementos que la componen. Schlusmans, K., Giesbertz, W., Rusman, E., & Spoelstra, H. (2009). The Introduction of a Virtual Classroom Instrument at the Open University of the Netherlands. M, 1 - 7. Schwaber, K., & Sutherland, J. (Julio de 2013). Scrum Guides. Obtenido de http://www.scrumguides.org/download.html

104

Sharma, S., Agada, R., & Ruggin, J. (2013). Virtual reality classroom as an constructivist approach. IEEE Southeast conference, 1 - 5. Silberschatz, A., Korth, H., & Sudarshan, S. (2002). FUNDAMENTOS DE BASES DE DATOS. Madrid: INTERAMERICANA DE ESPAÑA . Soflano, M., Connolly, T., & Hainey, T. (2015). An application of adaptive games-based learning based on learning style to teach SQL. ScienceDirect, 192-211. Sommerville, I. (2005). Ingeniería del software. En I. Sommerville, Ingeniería del software (Septima ed., págs. 357-378). Madrid: Pearson Educación S.A. Ukanbook. (2015). Ukanbook. Obtenido de Ukanbook: http://www.ukanbook.com/quienes_somos/ Universidad Internacional de Valencia. (s.f.). viu. Obtenido de viu: http://www.viu.es/caracteristicas-tipos-y-plataformas-mas-utilizadas-para-estudiar-a-distancia/ Valmorbida, G., Lu , W.-C., & Mora-Camino, F. (2005). A neural approach for fast simulation of flight mechanics . 38th Annual Simulation Symposium, 168 - 172. Zlobin, G. (2013). Learning Python Design Patterns. En G. Zlobin, Learning Python Design Patterns.

Brayan Julian Barbosa Sierra Pablo Andrés Esteban...

Documents

Transcript of Brayan Julian Barbosa Sierra Pablo Andrés Esteban...