desarrollo de un mÓdulo de software para evaluar la

DESARROLLO DE UN MÓDULO DE SOFTWARE PARA EVALUAR LA CALIDAD DEOBJETOS DE APRENDIZAJE BASADO EN UN MODELO POR CAPAS SOBRE UN

REPOSITORIO DE CÓDIGO ABIERTO

ANDRÉS ALEXIS SALAZAR RINCÓNJAVIER MAURICIO GARCÍA BELTRÁN

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDASFACULTAD DE INGENIERÍA

PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMASBOGOTÁ D.C.

2017

DESARROLLO DE UN MÓDULO DE SOFTWARE PARA EVALUAR LA CALIDAD DEOBJETOS DE APRENDIZAJE BASADO EN UN MODELO POR CAPAS SOBRE UN

REPOSITORIO DE CÓDIGO ABIERTO

ANDRÉS ALEXIS SALAZAR RINCÓNJAVIER MAURICIO GARCÍA BELTRÁN

Trabajo de grado presentado como requisito parcial para obtener el título de:Ingeniero de Sistemas

Director:JOSÉ IGNACIO PALACIOS OSMA

Profesor Asociado

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDASFACULTAD DE INGENIERÍA

PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMASBOGOTÁ D.C.

2017

AGRADECIMIENTOS

Andrés:

A Dios por la vida, la salud y la familia que me ha dado, a mifamilia por su fe incondicional en mis capacidades, a losdocentes, compañeros y demás personas que contribuyeronen mi formación profesional y personal y a todos los que deuna u otra forma influyeron en mi para llegar a este punto.

Javier:

Gracias a mi madre por el soporte, a los profesores que seesmeraron por educar, sin ellos nada hubiera sido posible, ya todas aquellas personas que de una u otra forma meapoyaron durante el desarrollo de este proyecto.

Índice General

1. Descripción general del proyecto 1

1.1. Introducción ..................................................................................................... 1

1.2. Objetivo General .............................................................................................. 2

1.3. Objetivos Específicos ...................................................................................... 2

1.4. Descripción del problema ................................................................................ 3

1.5. Justificación ..................................................................................................... 4

1.6. Alcance ............................................................................................................ 7

1.7. Limitaciones .................................................................................................... 7

1.8. Formulación de la pregunta central del trabajo ................................................ 8

2. Marco Referencial 9

2.1. Antecedentes .................................................................................................. 9

2.1.1. Modelo de Evaluación de OAs (2004).................................................... 9

2.1.2. Herramienta de Análisis de Metadatos (2008)....................................... 10

2.1.3. Evaluación de Reusabilidad de OAs (2010)........................................... 10

2.1.4. Modelo de Calidad de OAs (2012)......................................................... 11

2.1.5. Evaluación de Calidad de Metadatos en ROAs (2013).......................... 11

2.2. Marco Teórico .................................................................................................. 12

2.2.1. Objeto de Aprendizaje............................................................................ 12

2.2.2. Metadatos.............................................................................................. 12

2.2.3. Estándares de Metadatos...................................................................... 13

2.2.4. Repositorio de Objetos de Aprendizaje.................................................. 14

2.2.5. Modelo referencia de evaluación de OAs............................................... 17

2.3. Marco metodológico ........................................................................................ 30

2.3.1. Roles...................................................................................................... 30

2.3.2. Actividades............................................................................................ 32

2.3.3. Artefactos............................................................................................... 33

3. Descripción de la solución 34

3.1. Caracterización de DSpace ............................................................................. 34

3.1.1. Arquitectura........................................................................................... 34

3.1.2. Módulo de adiciones (Additions Module)............................................... 37

3.1.3. Recubrimientos de Maven (Maven WAR Overlays)............................... 37

3.2. Especificación funcional del producto .............................................................. 38

3.2.1. Definición detallada del producto........................................................... 38

3.2.2. Requerimientos funcionales del sistema................................................ 40

3.2.3. Requerimientos específicos de interfaces.............................................. 44

3.2.4. Especificación de casos de uso............................................................. 52

3.2.5. Implementación de las métricas de la capa de gestión.......................... 86

3.2.6. Implementación de las métricas de la capa de expertos........................ 99

3.2.7. Implementación de las métricas de la capa de usuarios........................ 99

3.2.8. Implementación de la integración del modelo........................................ 100

3.3. Especificación estructural del producto ........................................................... 100

3.3.1. Modelo conceptual de negocio.............................................................. 100

3.3.2. Diseño de clases y objetos.................................................................... 103

3.3.3. Diseño de la Base de Datos................................................................... 125

3.3.4. Mapa de navegación.............................................................................. 132

3.4. Especificación dinámica del producto .............................................................. 133

4. Resultados, conclusiones y trabajo futuro 143

4.1. Metodología y desarrollo del proyecto ............................................................. 143

4.2. Resultados ...................................................................................................... 144

4.2.1. Perspectiva del administrador................................................................ 145

4.2.2. Perspectiva del experto.......................................................................... 149

4.2.3. Perspectiva del estudiante..................................................................... 151

4.3. Conclusiones ................................................................................................... 151

4.4. Trabajo Futuro ................................................................................................. 152

Anexos 153

Anexo I. Manual instalación ............................................................................. 153

Anexo II. Diseño y Ejecución de casos de prueba ........................................... 156

Bibliografía 181

Índice de Figuras

Figura 1: Modelo de evaluación referencia [2] ............................................................... 18

Figura 2: Instrumento para revisión de expertos ........................................................... 25

Figura 3: Instrumento para captura de la percepción de los usuarios [2] ...................... 26

Figura 4: Marco de trabajo de Scrum [27] ..................................................................... 30

Figura 5: Roles de Scrum [27] ....................................................................................... 31

Figura 6: Arquitectura de DSpace [28] .......................................................................... 35

Figura 7: JSP Model 2 Architecture ............................................................................... 36

Figura 8: Pantallas de parametrización de la evaluación .............................................. 44

Figura 9: Pantalla de ponderación de los criterios de evaluación .................................. 45

Figura 10: Pantalla de evaluación de estudiantes ......................................................... 45

Figura 11: Pantalla de evaluación de expertos .............................................................. 46

Figura 12: Pantallas de evaluación de métricas de la capa de administrador ............... 46

Figura 13: Pantalla de reporte de resultados de la evaluación ...................................... 47

Figura 14: Modelo de datos de DSpace ........................................................................ 48

Figura 15: Actores del Sistema ...................................................................................... 52

Figura 16: Capa de Administradores ............................................................................. 54

Figura 17: Iniciar Aplicación .......................................................................................... 56

Figura 18: Parametrizar Evaluación de OA ................................................................... 58

Figura 19: Cargar Parametrización de Evaluación ........................................................ 60

Figura 20: Evaluar Completitud ..................................................................................... 62

Figura 21: Evaluar Consistencia .................................................................................... 64

Figura 22: Evaluar Coherencia ...................................................................................... 66

Figura 23: Evaluar Disponibilidad .................................................................................. 68

Figura 24: Evaluar Reusabilidad ................................................................................... 70

Figura 25: Evaluar Visibilidad ........................................................................................ 72

Figura 26: Cargar Metadatos de OA .............................................................................. 74

Figura 27: Consolidar Resultados ................................................................................. 76

Figura 28: Capa de Estudiantes .................................................................................... 77

Figura 29: Evaluar OA según Estudiantes ..................................................................... 79

Figura 30: Capa de Expertos ......................................................................................... 80

Figura 31: Ponderar Criterios de Evaluación de OA según Experiencia ........................ 82

Figura 32: Evaluar OA según Expertos ......................................................................... 84

Figura 33: Matriz de cobertura de Requerimientos Funcionales vs Casos de Uso. ....... 85

Figura 34: Modelo conceptual de negocio ..................................................................... 102

Figura 35: Diagrama de clases ...................................................................................... 105

Figura 36: Modelo relacional ......................................................................................... 126

Figura 37: Mapa de navegación del módulo .................................................................. 132

Figura 38: Diagrama secuencia iniciar aplicación .......................................................... 133

Figura 39: Diagrama secuencia parametrización de evaluación ................................... 134

Figura 40: Diagrama secuencia parametrizar evaluación OA ........................................ 135

Figura 41: Diagrama secuencia evaluar completitud ..................................................... 136

Figura 42: Diagrama secuencia evaluar consistencia ................................................... 137

Figura 43: Diagrama secuencia evaluar disponibilidad ................................................. 138

Figura 44: Diagrama secuencia evaluar OA según estudiantes .................................... 139

Figura 45: Diagrama de secuencia ponderar criterios expertos .................................... 140

Figura 46: Diagrama de secuencia evaluar OA según expertos .................................... 141

Figura 47: Diagrama de secuencia consolidar resultados ............................................. 142

Figura 48: Vista de objeto de aprendizaje con opción para iniciar evaluación ............... 144

Figura 49: Pantalla principal de la perspectiva del administrador .................................. 145

Figura 50: Selección de capa en la parametrización ..................................................... 145

Figura 51: Selección métricas en la parametrización .................................................... 146

Figura 52: Ponderación de las dimensiones .................................................................. 146

Figura 53: Evaluación administrativa de la coherencia del objeto. ................................ 147

Figura 54: Reporte de la evaluación con todos los resultados ...................................... 148

Figura 55: Reporte de la evaluación con resultados parciales ...................................... 148

Figura 56: Eliminación evaluación 1 .............................................................................. 149

Figura 57: Eliminación evaluación 2 .............................................................................. 149

Figura 58: Ponderización por parte del experto ............................................................. 150

Figura 59: Encuesta del experto .................................................................................... 150

Figura 60: Encuesta del estudiante ............................................................................... 151

Índice de Tablas

Tabla 1: Ubicación paquetes correspondientes a cada una de las capas ..................... 35

Tabla 2: Clases de contenidos en DSpace ................................................................... 49

Tabla 3: Definición de actores ...................................................................................... 53

Tabla 4: Mapeo de campos LOM - DC ......................................................................... 87

Tabla 5: Campos DC para evaluar consistencia ........................................................... 89

Tabla 6: Mapeo MIME – Tipos de recurso DSpace ....................................................... 92

Tabla 7: Definición de regla de estructura (Reusabilidad) ............................................. 94

Tabla 8: Definición de regla de granularidad (Reusabilidad) ......................................... 96

Tabla 9: Ponderaciones para calcular índice total por capa .......................................... 100

Índice de Ecuaciones

Ecuación 1: Métrica de reusabilidad [2].............................................................................27

Ecuación 2: Métrica de disponibilidad [2]...........................................................................27

Ecuación 3: Métrica de completitud [2]..............................................................................28

Ecuación 4: Métrica de consistencia [2].............................................................................29

Ecuación 5: Métrica de coherencia (1) [2].........................................................................30

Ecuación 6: Métrica de coherencia (2) [2].........................................................................30

Ecuación 7: Métrica de coherencia [2]...............................................................................31

Ecuación 8: Métrica de visibilidad [2].................................................................................31

Ecuación 9: Métricas de Capa de Expertos [2]..................................................................32

Ecuación 10: Métricas de Capa de Usuarios [2]................................................................35

Ecuación 11: Índice por capa [2]........................................................................................35

Ecuación 12: Índice total de las capas [2]..........................................................................36

Ecuación 13: Índice por dimensión [2]...............................................................................36

Ecuación 14: Índice total de las dimensiones [2]...............................................................37

1. Descripción general del proyecto

1.1. Introducción

Durante la última década, la evolución vertiginosa de las Tecnologías de la Información yComunicación (TIC) se ha involucrado en todas las actividades humanas y la educaciónno ha sido la excepción. La incorporación de las nuevas tecnologías en la educación seha dado principalmente a través de la concepción, introducción y consolidación de laeducación virtual (e-learning) la cual, por su naturaleza, ha revolucionado los procesostradicionales de enseñanza-aprendizaje en todos los niveles educativos. Así, por ejemplo,han surgido nuevos paradigmas de educación como los Recursos Educativos Abiertos(Open Educational Resources, OER) [1]. Esta tendencia educativa está orientada agarantizar el acceso libre y público al conocimiento, además busca proporcionar unaalternativa a los paradigmas tradicionales de educación en el mundo.

Este modelo de formación académica presenta el reto de desarrollar y poner a disposicióndel público nuevos y mejores materiales educativos que permitan masificar el accesopúblico a la información y al conocimiento aprovechando las bondades de las TIC. De estaforma, además de ampliar la oferta y cobertura educativa, se busca aumentar lasposibilidades de generar innovación y mejorar la calidad de vida de las diferentespoblaciones alrededor del mundo que, por limitaciones geográficas, económicas, políticas,entre otras, no pueden acceder al modelo tradicional de educación. De acuerdo a estosprincipios surgen los Recursos Educativos Digitales Abiertos (REDA), los cuales estándestinados a apoyar e innovar los procesos pedagógicos. Dentro de los REDA sedestacan los Objetos de Aprendizaje (OA) que, gracias a sus características dereusabilidad, adaptabilidad, accesibilidad y escalabilidad permiten ofrecer una mayorinteractividad y, por tanto, eficiencia pedagógica respecto a otros tipos de recursoseducativos.

La producción de REDA crea la necesidad de desarrollar aplicaciones enfocadas alalmacenamiento, organización, publicación y visibilidad de tales recursos. Estasaplicaciones, denominadas comúnmente como Repositorios, facilitan la administración,

1

CAPÍTULO 1. DESCRIPCIÓN GENERAL DEL PROYECTO 2

búsqueda, recuperación y uso de los REDA.

Sin embargo, aún hoy en día persisten problemas relacionados con la búsqueda yrecuperación de los recursos almacenados en los repositorios. En repetidas ocasiones sehan publicado recursos a los que es imposible acceder porque los enlaces mostradosestán rotos, o porque los recursos se almacenan en el repositorio pero es imposiblerecuperarlos después. También sucede que el contenido de los materiales educativossencillamente no ofrece información pertinente, precisa y relevante que realmentesatisfaga los intereses de los usuarios de estas plataformas tecnológicas.

En este trabajo se propone el diseño e implementación de un módulo de software quepermita evaluar la calidad de los objetos de aprendizaje alojados en un repositorio decódigo abierto (open source). Dicho módulo se desarrolló para ser publicado como unaextensión (plugin, add-on) para la plataforma de código abierto DSpace y está basado enel modelo para la evaluación de la calidad de objetos de aprendizaje propuesto en [2].Esto permitirá a todas las instituciones que utilicen o piensen utilizar repositorios derecursos educativos digitales soportados en esta plataforma, evaluar la calidad de susrespectivos objetos de aprendizaje acorde con unos criterios y unas métricas biendefinidas. De esta forma se proporcionará una herramienta de gestión de la calidad paralos repositorios institucionales de objetos de aprendizaje, que ayude a garantizar laentrega al usuario de los mejores recursos que apoyen efectivamente sus procesos deaprendizaje.

1.2. Objetivo General

Diseñar e implementar un módulo de software basado en un modelo por capas paraevaluar objetos de aprendizaje, que funcione como una extensión del repositorio decódigo abierto DSpace.

1.3. Objetivos Específicos

Caracterizar el funcionamiento y las especificaciones técnicas del repositorio de códigoabierto DSpace que permitan la integración del módulo de evaluación propuesto.

Desplegar un repositorio de objetos de aprendizaje sobre la plataforma DSpace quesoporte el desarrollo y las pruebas del módulo de evaluación.

Especificar los requerimientos funcionales del módulo de evaluación de objetos deaprendizaje a implementar sobre DSpace.


Diseñar un modelo de Base de Datos que se pueda integrar al modelo implementado porDSpace y que permita soportar los requerimientos funcionales del prototipo.

Diseñar las estructuras lógicas que se puedan integrar con las estructuras existentes y secomporten acorde con la arquitectura de DSpace.

Diseñar los modelos dinámicos del módulo de evaluación de objetos de aprendizaje quepermita soportar los requerimientos funcionales del prototipo.

Implementar un módulo de evaluación de objetos de aprendizaje que pueda extender lasfuncionalidades de la plataforma de código abierto DSpace acorde con lasespecificaciones funcionales, estructurales y dinámicas.

Diseñar y ejecutar las pruebas unitarias y de integración necesarias para hacer losrespectivos ajustes al prototipo.

1.4. Descripción del problema

Los objetos de aprendizaje están destinados a innovar y apoyar los procesos deenseñanza-aprendizaje en distintos Entornos Virtuales de Aprendizaje (EVA), por lo quees necesario garantizar que los usuarios reciban únicamente los recursos de la más altacalidad. Sin embargo, hoy en día, en los repositorios existe una cantidad enorme deobjetos de aprendizaje pero pocos suplen las necesidades de los estudiantes y el procesode búsqueda de un recurso con información pertinente, precisa y relevante se vuelve unatarea dispendiosa y larga. En este sentido, un proceso de búsqueda, arroja un lista largade recursos que el usuario debe revisar uno a uno, encontrándose con muchos resultadosque tienen falencias, otros que no puede acceder, o simplemente que no cumplen con susmínimas expectativas [3], lo que puede conducir, no sólo a una perdida de tiempo, sino aldesinterés por este tipo de herramientas.

De ahí la importancia de tomar acciones que permitan entregar al usuario recursospertinentes y de calidad. Al respecto, la comunidad académica ha mostrado gran interés yen la literatura se encuentran diferentes iniciativas y propuestas para evaluar recursoseducativos digitales. Tales propuestas constituyen una herramienta idónea para elaseguramiento de la calidad de los recursos mantenidos en los repositorios. No obstante,estas propuestas se sesgan a unas u otras características específicas de los recursos, aunos aspectos a evaluar, a una sola perspectiva (bien sea de usuarios o expertos),dejando vacíos que pueden conducir a obtener resultados inapropiados en las búsquedas.

Por esta razón, en [2] se plantea un modelo por capas para evaluar la calidad de objetosde aprendizaje alojados en repositorios que recoge los conceptos planteados en otras


propuestas y, por ende, ofrece un enfoque genérico, integral, dinámico y escalable. Estaevaluación es integral porque contempla los aspectos técnicos, temáticos y pedagógicosde los recursos vistos desde diferentes perspectivas (usuarios, expertos,administradores), y es dinámica, porque permite evaluar una gran cantidad de recursosantes, durante y después de su publicación en el repositorio.

A pesar de la existencia de modelos de evaluación de objetos de aprendizaje como elexpuesto anteriormente, al día de hoy, miles de repositorios de recursos educativosdigitales soportados en plataformas de amplio uso a nivel mundial como DSpace, aún nocuentan con una herramienta de evaluación que garantice algún nivel de calidad de losrecursos albergados en el mismo. Es así como se identificó la necesidad de diseñar eimplementar procesos y procedimientos de evaluación de recursos educativos digitalesque permitan medir, valorar y discernir estos recursos conforme a los aspectos técnicos,temáticos y pedagógicos involucrados en su producción.

Por las razones mencionadas anteriormente, en este trabajo se diseñó, construyó eimplementó un prototipo de extensión (plugin, add-on) para DSpace que permite evaluarla calidad de los recursos educativos digitales almacenados en los repositoriosdesarrollados sobre dicha plataforma acorde con los criterios y las métricas definidas en elmodelo de evaluación referencia [2]. El módulo de software propuesto aumentará lasposibilidades de evaluar miles de recursos educativos digitales producidos y mantenidospor un gran número de instituciones a nivel mundial que implementan repositoriosbasados en DSpace. Esto permitirá aprovechar esta herramienta de gestión de calidadpara asegurar la entrega al usuario de los mejores recursos que apoyen los procesos deenseñanza-aprendizaje en Entornos Virtuales de Aprendizaje.

1.5. Justificación

La calidad en los objetos de aprendizaje se ve como el grado de cumplimiento de unconjunto de criterios que permiten valorar los recursos educativos y ayudan a determinarsu pertinencia en el proceso de aprendizaje para el que fue diseñado [4]. En la revisión dela literatura se encontraron diversos enfoques para evaluar objetos de aprendizaje (OAs)[5][6][7][8][9], pero en su mayoría solo consideran ciertas características, algunoscentrados en el producto, y otros centrados en los procesos, dejando vacíos que puedenconducir a listados de resultados inapropiados en búsquedas.

En relación con lo expuesto anteriormente, en [10], entre otras cosas, se encontró que: 1)los esfuerzos en la etapa de desarrollo, con aplicación de buenos principios de diseño,son más probables de producir OAs útiles y con buenos metadatos. 2) la validez queviene ganando la inclusión de valoraciones por parte de usuarios, y revisiones de pares,que repercute en confiabilidad hacia el repositorio; sin embargo, esto implica elcompromiso de los usuarios y la capacidad del repositorio de manejar comentarios,


valoraciones y revisiones. 3) la existencia de diferentes marcos de trabajo (frameworks)que tienen en cuenta diferentes aspectos de los recursos para realizar evaluaciones decalidad de OAs; dentro de estos, se encuentran:

• LORI (Learning Object Review Instrument): propone un formato con nuevecategorías, en las que se valoran y comentan diferentes aspectos los OAs, y unaevaluación total final. Las categorías incluidas son: calidad del contenido,alineamiento de la meta de aprendizaje, retroalimentación y adaptabilidad,motivación, presentación, facilidad de uso, accesibilidad, reusabilidad, conformidadcon estándares. Es ampliamente utilizado, y se recomienda acompañarlo consistema que permita revisar las calificaciones, para reducir el subjetivismoinherente a este tipo de métodos.

• LOAM (Learning Object Attribute Metrtic): Determina tres categorías (medio (tipode recurso), papel del aprendiz y actividad) con las que el evaluador determinaque parte del OA o actividad del usuario, corresponde con una serie opciones quedefine cada una de ellas. Cada categoría contiene una serie de atributospedagógicos, y algunos de estos se repiten en algunas categorías. Cada atributose mide en una una escala de 1-5. Aunque este enfoque contiene similitudes conLORI en las atributos pedagógicos , existen diferencias en la forma en que seLOAM esta enlazado al diseño del OA, y en el contenido y la forma de interpretarlas categorías.

• LOEM (Learning Object Evaluation Metric): Es un modelo multi-componentederivado de una revisión exhaustiva sobre el diseño para la enseñanza. Tienesimilitudes con los anteriores, pero no han sido estandarizadas algunas métricasusadas, y no se encuentra como una herramienta para evaluar los OAs.

A pesar de la importancia y la necesidad de la evaluación de objetos de aprendizaje, a lafecha no existe un consenso sobre los criterios o el modelo a seguir. Sin embargo, unesfuerzo realizado en el 2013 [2], de manera independiente, propone la unificación de loscriterios utilizados por diferentes autores (algunos descritos en los párrafos anteriores) enun modelo integrado para la evaluación de objetos de aprendizaje. Un modelo integradono solo considera el criterio de expertos, sino que tiene en cuenta la opinión de losusuarios, lo que es importante, y genera un impacto positivo porque aumenta el nivel deconfianza en el repositorio y además evidencia el compromiso por la calidad de loscreadores de contenidos, pues tienen en cuenta el criterio de los usuarios (están abiertosa sugerencias). Por las razones expuestas anteriormente, en este trabajo de grado seacoge este modelo para la implementación de un módulo de evaluación de OAs, quepueda ser incorporado a un repositorio de código abierto. El modelo, adicionalmente,ofrece la facilidad de ajustarse a las necesidades e intereses de repositorios específicos, ypor lo mismo, se toma como un referente teórico, susceptible de ser adecuado.

En este sentido, se considera que uno de los puntos claves para la evaluación de OAs


son los metadatos, en [7] y [11] se proponen medidas basadas en los metadatos paraestablecer el grado de reusabilidad de un objeto de aprendizaje, igualmente estasmétricas son parte fundamental del modelo base escogido para el desarrollo del módulo.Los resultados encontrados de esta manera parecen estar alineados con las evaluacioneshechas por usuarios y expertos, pero dependen de la exactitud y completitud de losmetadatos [10]. Para poder evaluar estos aspectos, los metadatos deben ceñirse a unestándar específico.

Por esta razón y considerando todos los esfuerzos existentes para la definición deestándares en las tecnologías de OAs, el estándar IEEE LOM [12] consolida la evoluciónde otras iniciativas de estandarización (Ariadne, Dublin Core e IMS) [13][14]. Laespecificación LOM es el estándar más utilizado en la construcción de repositorios deOAs y, por lo tanto, tiene un alto reconocimiento internacional. Por las razones expuestasanteriormente y con el objetivo de garantizar y maximizar el alcance de la aplicación delmódulo se escoge el estándar IEEE LOM para el desarrollo de este proyecto.

El prototipo de software propuesto en este trabajo de grado será diseñado y desarrolladopara que pueda ser acoplado a un repositorio que permita usar, modificar e integrarcódigo fuente libremente en la aplicación. De esta manera, el prototipo propuesto seráuna contribución a la plataforma y, por consiguiente, un beneficio para toda la comunidadde usuarios que estén interesados en evaluar los objetos de aprendizaje alojados en susrespectivos repositorios institucionales. En este sentido es claro que DSpace es lasolución de software más utilizada para la implementación de repositorios institucionales[15]. Según el Registro de Repositorios de Acceso Abierto (ROAR – Registry of OpenAccess Repositories) DSpace cuenta con 1489 implementaciones a nivel mundial [16], loque lo hace de lejos, la plataforma de código abierto más popular y probada. Esta granacogida en el mundo académico se debe a sus amplias funcionalidades, la posibilidad depersonalización acorde a necesidades especificas y su relativa facilidad de configuración[17]. Además, gracias a su tipo de licenciamiento (BSD) permite la extensión de susfuncionalidades a través de la instalación de distintos add-ons creados por la comunidadde desarrolladores y puestos a disposición de los usuarios para cubrir sus respectivosintereses. A pesar de esto, a la fecha no se ha evidenciado la existencia de una iniciativasimilar a esta propuesta, ni en sus funciones nativas, ni como una extensión desarrolladapor terceros [18]. De acuerdo con lo planteado anteriormente, DSpace es la plataformaseleccionada sobre la que se construirá el módulo de evaluación de objetos deaprendizaje propuesto en este trabajo.


1.6. Alcance

Con este proyecto se busca proporcionar una extensión (plugin, add-on) para laplataforma DSpace que permita evaluar la calidad de los objetos de aprendizajealmacenados en repositorios institucionales de recursos educativos digitalesimplementados en esta plataforma, basándose en un modelo de evaluación por capas [2].El prototipo propuesto permite a los administradores de los repositorios parametrizar lasevaluaciones de cada uno de los objetos de aprendizaje y, una vez realizadas, presentalos respectivos resultados para identificar los objetos de aprendizaje que presentan bajacalidad y así mejorarlos o depurarlos.

1.7. Limitaciones

El diseño, construcción e implementación de este prototipo de software esta sujeto a lassiguientes limitaciones:

• Se adoptó la arquitectura y los lineamientos de programación establecidos por laplataforma, se utilizaron las API’s disponibles para acceder a las funcionalidadesexistentes involucradas en el desarrollo del prototipo.

• Al modelo de Base de Datos existente se le incluyeron tablas adicionales querespetan la nomenclatura y los tipos de datos definidos en la arquitectura de laplataforma, se respeta la integridad referencial existente.

• El prototipo propuesto en este trabajo fue diseñado, construido e implementandoúnicamente para la interfaz de usuario de DSpace basada en JSP (JSPUI).

• El prototipo propuesto en este trabajo sólo está disponible en idioma inglés. Lasopciones de internacionalización manejadas por DSpace no están disponibles enesta versión.

• La autenticación es la misma que se utiliza para el acceso a la aplicación,únicamente se adicionaron los roles necesarios para la ejecución de lasfuncionalidades del prototipo.

• El “Modelo por Capas para Evaluación de la Calidad de Objetos de Aprendizaje enRepositorios de Objetos de Aprendizaje” [2] sirvió como base teórica para laimplementación del prototipo propuesto, sin embargo se realizaron modificacionescon el propósito de adecuarlo a las características conceptuales y técnicas deDSpace.

• Por motivos de compatibilidad con las versiones existentes de DSpace no serealizaron alteraciones en el esquema de metadatos (basado en Dublin Core) de laplataforma. Por ende, para evaluar los aspectos relacionados con los metadatosdonde fue necesario se realizó una correlación (mapeo) entre los campos de losestándares Dublin Core e IEEE LOM, el cual es el referente en el modelo teórico.


• Los valores de las evaluaciones en cada uno de sus criterios corresponden a unvalor promedio ponderado de la evaluación actual y la inmediatamente anterior. Nose almacena un histórico de las evaluaciones que hayan realizado todos losusuarios.

• Los resultados de la evaluación de cada uno de los objetos de aprendizaje sólopodrán ser consultados por separado y únicamente por los administradores de losrepositorios. Se debe definir un procedimiento operativo por parte de ellos para eltratamiento de estos datos con el fin de mejorar o depurar los objetos deaprendizaje que presenten falencias.

1.8. Formulación de la pregunta central del trabajo

¿Cómo incorporar métricas de calidad a un repositorio de código abierto de tal forma quese pueda realizar una evaluación integral y dinámica de sus objetos de aprendizaje pormedio de un prototipo de software basado en un modelo existente?

2. Marco Referencial

2.1. Antecedentes

Hoy en día la evaluación de objetos de aprendizaje es indispensable en el aseguramientode la calidad del contenido de estos recursos educativos. Un proceso de evaluaciónintegral que establezca criterios para evaluar distintos aspectos e involucre a todas laspartes interesadas en el uso, reuso y apropiación de los contenidos, tiene mayoresposibilidades de garantizar la entrega de OAs idóneos que realmente sirvan para apoyarlos procesos educativos. Respecto a este tema, en la literatura especializada existenvarios esfuerzos para establecer la calidad de los objetos de aprendizaje desde diferentesenfoques, técnicas y métricas utilizadas. Los trabajos más destacados se presentan acontinuación.

2.1.1. Modelo de Evaluación de OAs (2004)

En este artículo [5] se considera la evaluación de OAs como un proceso complejo querequiere que el evaluador considere la interacción de aspectos multivariadostransversales a los ciclos diseño, desarrollo y entrega de los OAs. Los aspectos en losque se enfoca el modelo de evaluación propuesto son:

• Diseño de contenido (centrado en principios pedagógicos y tecnológicos): paraevaluar este aspecto se propone un análisis de las necesidades de losestudiantes, incluye análisis de tareas para distinguir información crítica de losprerrequisitos de aprendizaje. Este análisis puede ser llevado a cabo por undiseñador pedagógico (experto) que usa la información obtenida para crearcontenidos acorde a la población objetivo. Luego se diseña un plan paradeterminar: que saben los estudiantes ahora, que quieren saber, y que deberíansaber.

• Diseño de motores de búsqueda y recuperación (entrega de los objetos): suevaluación requiere determinar: el desempeño del sistema de entrega de OAs

9

CAPÍTULO 2. MARCO REFERENCIAL 10

(capacidad de disco, de red y de respuesta a las solicitudes de los usuarios), suescalabilidad, seguridad y autenticidad. Otro aspecto importante que deben ofrecerestos sistemas es proporcionar la forma en que los estudiantes conozcan suprogreso a través del proceso de aprendizaje, y los administradores del sistemapuedan rastrear tales progresos.

• Capa de presentación (interfaz de usuario): trata la efectividad y la eficiencia de lainterfaz gráfica de usuario y la usabilidad general del sistema. Se deben usartécnicas para determinar buenas formas de presentar información, como porejemplo, la visibilidad de los contenidos. De tal forma que los estudiantes tengan lasensación de control sobre todo el proceso de aprendizaje. Se plantea lanecesidad de establecer rutas de navegación para responder preguntas como:¿Qué haría un estudiante para usar un OA? ¿Cómo se mueven de un recurso delsistema a otro? ¿Cómo pueden guardar su trabajo y retomarlo después desde elpunto donde estaban?

• Proceso de aprendizaje (entradas, procesamiento de la información y salidas):pretende determinar la efectividad de las actividades de aprendizaje midiendo loslogros alcanzados, lo que también involucra la utilidad de los OAs. Para mediresto, se utiliza una taxonomía de seis niveles de resultados de aprendizajeidentificados con un dominio cognitivo: conocimiento, comprensión, aplicación,análisis, síntesis y evaluación. Estos niveles buscan evaluar la interacción delestudiante con el OA durante el proceso de aprendizaje y determinar el grado enque la interacción ha afectado los resultados de aprendizaje.

Para evaluar un aspecto en particular, el evaluador debe desarrollar cuestionarios deevaluación teniendo en cuenta las metas de los objetivos de aprendizaje, según el nivelde análisis.

2.1.2. Herramienta de Análisis de Metadatos (2008)

En este trabajo [6] se presenta una herramienta web para evaluar la completitud de losmetadatos respecto al estándar Dublin Core. Esta herramienta está orientada a losrepositorios (aquellos que manejan el estándar OAI-PMH) más que a los OAs. Losresultados se visualizan a través de una síntesis descriptiva de los metadatospresentándolos en una lista ordenada según su grado de completitud.

2.1.3. Evaluación de Reusabilidad de OAs (2010)

En este artículo [7] se plantea un conjunto de métricas (enfocadas en IEEE LOM) que secalculan de forma semi-automática y que están basadas en las medidas de reusabilidaddel software. La métrica de Cohesión indica la capacidad de reutilización de un OA, por lo


que un OA con un bajo nivel de agregación tiene una mayor cohesión. El Acoplamiento esdirectamente proporcional al número de relaciones que presente el recurso, lo cual sepuede identificar en el campo Relación del estándar LOM. La métrica de Tamaño yComplejidad se basa en los metadatos Tamaño, Duración, Tipo de Recurso, TiempoTípico de Aprendizaje para definir el tamaño del recurso, ya que cuanto menor sea, mayores su capacidad de reutilización. Finalmente la métrica de Portabilidad determina lacapacidad de mover el recurso entre sistemas y se determina con los campos Formato yRequerimientos para la portabilidad tecnológica, y Contexto, Rango de Edad Típica,Lenguaje y Clasificación para la portabilidad educativa.

El autor también propone el cálculo automático de una medida de relevancia que integracomo indicadores de calidad tres dimensiones: la Valorativa, que reúne evaluacionesindividuales de expertos y de usuarios registrados, la Empírica, que tiene en cuenta losdatos implícitos de uso del material, y la Característica, que corresponde a la medida dereusabilidad propuesta.

2.1.4. Modelo de Calidad de OAs (2012)

En este trabajo [19] se propone un modelo para evaluación de calidad de los OAsteniendo en cuenta las recomendaciones definidas en el estándar IEEE LOM, aplicando11 reglas que deben cumplir los metadatos para determinar niveles de completitud yconformidad respecto al estándar. Para aplicar estas reglas establece dos niveles deconformidad: base, se da cuando los metadatos pueden incluir elementos extendidos oadicionales a los definidos por el estándar, y estricta, que se presenta cuando el OAcontiene únicamente metadatos definidos por el estándar. La implementación del modelose realizó a través de un servicio web que recibe los metadatos en formato XML y entregalos resultados en diferentes formatos como CSV o HTML.

2.1.5. Evaluación de Calidad de Metadatos en ROAs (2013)

En este trabajo [9] se propone evaluar la calidad de los metadatos de OAs a través de trescriterios: completitud, consistencia y coherencia; y se especifica una métrica particularpara cada uno a partir del estándar de metadatos IEEE LOM.

• La completitud indica si los metadatos describen los objetos tanto como seaposible. Al evaluar esta característica se comprueba si cada elemento de losmetadatos es efectivamente una instancia del estándar correspondiente y si cadainstancia contiene datos, midiendo que tanta información está disponible para elrecurso.

• La consistencia permite medir el nivel de conformidad con el estándar demetadatos o las reglas establecidas por el repositorio que almacena los OAs.


• La coherencia permite determinar el grado con el que los metadatos describen elmismo recurso teniendo en cuenta las relaciones existentes entre los elementosde datos en la especificación del estándar.

2.2. Marco Teórico

2.2.1. Objeto de Aprendizaje

En la comunidad académica no hay un consenso entorno a la definición formal de objetoaprendizaje. Una definición común es: “cualquier recurso digital que puede ser reutilizadopara apoyar el aprendizaje”, también existen definiciones más detalladas como: “un objetode aprendizaje es un recurso educativo digital con un único objetivo de aprendizaje y quepuede ser reutilizado en diferentes contextos” [5]. Sin embargo, teniendo en cuentareferentes nacionales e internacionales, la Estrategia Nacional de Recursos EducativosDigitales Abiertos, ha llegado a un acuerdo de lo que es un OA: “Un objeto de aprendizajees un conjunto de recursos digitales, 'autocontenible' y reutilizable, con un propósitoeducativo y constituido por al menos tres componentes internos: contenidos, actividadesde aprendizaje y elementos de contextualización. El objeto de aprendizaje debe tener unaestructura de información externa (metadatos) que facilite su almacenamiento,identificación y recuperación”. A pesar de la carencia de una definición oficial a nivelinternacional, la idea detrás de un objeto de aprendizaje es que pueda ser reutilizado endiferentes contextos y para diferentes propósitos educativos.

2.2.2. Metadatos

Es un término “acuñado por Jack Myers en la década de los 60, para describir conjuntosde datos”. Inicialmente aplicado a la bibliotecología, más tarde se extendió a la gestión derecursos digitales. La primera interpretación que se le dio fue la de "dato sobre el dato", yaque su propósito consistía en proporcionar la información mínima necesaria paraidentificar un recurso.

Un metadato es toda aquella información descriptiva sobre el contexto, calidad, condicióno características de un recurso digital, dato u objeto, que tienen la finalidad de facilitar surecuperación, autentificación, evaluación, preservación e interoperabilidad. Hoy en día losmetadatos están enfocados a permitir:

• La producción de recursos digitales bajo un enfoque de trabajo colaborativo,integrando de esta forma a todos los grupos de profesionales implicados en su


desarrollo.

• La inclusión de información sobre el contexto, contenido y control de los recursosdigitales. De este modo, se alcanzan objetivos como describir, identificar y definirun recurso para recuperar filtrar e informar sobre el licenciamiento y condicionesde uso, autentificación y evaluación, preservación e interoperabilidad. Todo estoconduce a una orientación hacia la web semántica.

Para lograr esto, los metadatos se deben proporcionar de manera formal, para dejarabierta la posibilidad de que los gestores de búsqueda los localicen y evalúen (razón delos estándares). Al usar tales metadatos se busca mejorar Internet, ampliando lainteroperabilidad entre los sistemas de información mediante una infraestructura común yde cooperación que permita compartir y reutilizar los datos a través de aplicaciones,empresas y comunidades [20].

2.2.3. Estándares de Metadatos

Uno de los aspectos más importantes a tener en cuenta para asegurar la reusabilidad deun objeto de aprendizaje tiene que ver con su descripción a través de sus metadatos. Silos metadatos utilizados (en la producción, catalogación y publicación de los OAs) seciñen a los estándares propuestos por los grupos importantes y se basan en tecnologíasabiertas, será más fácil garantizar la interoperabilidad y el éxito en las operaciones debúsqueda y recuperación.

Un ejemplo de estándar de metadatos de propósito general es la iniciativa de metadatosDublin Core, auspiciado por la DCMI (Dublin Core Metadata Initiative), y utilizadoampliamente en bibliotecas digitales. Por otro lado, como ejemplo de estándares demetadatos de propósito específico existe IEEE LOM utilizado en plataformas educativas yrepositorios de objetos de aprendizaje. A continuación se describen brevemente estosestándares:

• Dublin Core (DC) : es un esquema de metadatos que abarca conceptos de variasdisciplinas como: bibliotecología, ciencias de la computación y preservación dearchivos. Los estándares y definiciones de DC incentivan la interoperabilidad yson publicados en la web del DCMI, que contiene las definiciones actualizadas detodos los elementos del DC y sus propiedades. DC es un conjunto de 15elementos básicos, más 3 adicionales. Todos los elementos son opcionales yrepetibles, los elementos básicos son: Title, Creator, Subject, Description,Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation,Coverage, y Rights. Los elementos adicionales son: Audience, Provenance yRights Holder. DC permite refinamiento de elementos (o subcampos) queespecializa el significado de un elemento. El uso de estos refinamientos es


opcional, pero DC también permite la adición de elementos sin estandarizar parauso local [21].

• IEEE Learning Object Metadata (LOM): es un estándar orientado a la descripciónde recursos educativos, sean digitales o no. El estándar es multi-parte siendo lamás importante y representativa la dedicada al modelo de datos (1484.12.1-2002), en la que se especifica que partes de un recurso educativo deben serdescritas y que vocabulario utilizar para lograrlo. El modelo de datos define, entreotros aspectos, el vocabulario, la jerarquía de términos, los tipos de datospermitidos para cada elemento, y la multiplicidad que puede tener cada elemento.Las otras partes del estándar están orientadas a definir extensiones del modelode datos. LOM está organizado en nueve categorías de elementos para laadministración, ubicación y evaluación de los objetos de aprendizaje, las cualesson: general, lifecycle, metamentadata, technical, educational, rights, relation,annotation y classification. Al igual que DC, este estándar está diseñado para seradaptado a necesidades específicas [12].

2.2.4. Repositorio de Objetos de Aprendizaje

Un repositorio de objetos de aprendizaje (ROA) es una base de datos que hospeda unacolección de unidades de información educativa o actividades que pueden ser accedidaspara su uso y recuperación. Los ROA permiten organizar los objetos, mejorar la eficiencia,impulsar el reúso y la colaboración, y apoyan procesos educativos [22]. El ROA es vistocomo un tipo de librería que posibilita a los educadores compartir, administrar, y usarrecursos educativos, y que implementa algún estándar de metadatos o perfil de aplicación[23].

De acuerdo con la Estrategia Nacional de Recursos Educativos Digitales Abiertos lossiguientes servicios describen los requisitos funcionales que debe implementar unrepositorio institucional de recursos educativos digitales abiertos:

• Archivador o Depósito: capacidad del repositorio que permite las gestionesalrededor del almacenamiento, alojamiento y preservación de los archivos de losRecursos Educativos Digitales.

• Búsqueda y Recuperación: función que permite la consulta, exploración yrecuperación de información sobre los Recursos Educativos Digitales que contieneel repositorio, según necesidades específicas de los usuarios. La base para laimplementación de este servicio en el repositorio, es el perfil de aplicación oestándar de metadatos seleccionado.

• Navegación: estructura funcional que permite explorar los diferentes servicios,


secciones y colecciones que se encuentran en el repositorio, para acceder a losRecursos Educativos Digitales Abiertos según necesidades y expectativa delusuario.

• Visualización: si bien la búsqueda y navegación se desarrollan bajo criteriosdeterminados por el usuario, la visualización es la forma que se establece en elrepositorio para presentar la respuesta que se obtiene. Así el usuario, gracias alperfil de aplicación o estándar de metadatos, puede ver la información del recursoque ha seleccionado, igualmente le permite acceder a la ubicación del mismo biensea sobre el navegador o por descarga.

• Proveedor de datos (Cosechado): cada repositorio se alimenta con los RecursosEducativos propios de la Institución, igualmente para interoperar con otras IES yaprovechar el potencial de sus Recursos Educativos Digitales, deben funcionarbajo estándares y protocolos internacionales.

• Gestión de colecciones: este servicio facilita el control, manejo y organización dela oferta de Recursos Educativos Digitales Abiertos por parte de losadministradores, como también de los usuarios.

• Gestión de usuarios: corresponde al servicio que permite la identificación deacceso al repositorio de los diferentes tipos de usuarios según los privilegios deadministración o uso que les sean otorgados, en modo de consulta o en torno a lapublicación, acceso a fuentes, actualización, eliminación, modificación o adición derecursos.

• Reportes Estadísticos: para garantizar la calidad del servicio, su uso y apropiación,se hace necesario identificar a los usuarios, sus preferencias y costumbres de uso,así como la operación de los diferentes servicios, y con ello reconocer fortalezas odebilidades y generar planes de mejoramiento continuo en que hagan más intuitivala plataforma para los usuarios finales y que redunden en un mayor uso yapropiación de los Recursos Educativos Digitales.

Estos repositorios usualmente están programados como aplicativos web, desarrollados ymantenidos por instituciones educativas, pero también existen soluciones de propósitogeneral, que se pueden usar y adaptar para implementar dichos repositorios. Entre losúltimos, se encuentran varias opciones de código abierto, que han tenido gran acogida ,siendo los más importantes los siguientes:

• DSpace: Es la solución de código abierto más utilizada para implementarrepositorios institucionales. Fue originalmente creado por desarrolladores del MIT(Massachusetts Institute of Technology) y HP (Hewlett-Packard), y actualmente esadministrado por DuraSapce, una comunidad enfocada en el uso de tecnologíaslibres para el acceso a la información digital. Utiliza por defecto el estándar de


metadatos Dublin Core, pero permite el uso de otros estándares. Además de esto,proporciona medios para personalizar diferentes aspectos de la plataforma yencontrar los intereses propios de las comunidades, como la interfaz gráfica o labúsqueda de recursos [24]. La instalación de DSpace es relativamente sencilla, yse puede utilizar directamente, con poca configuración. Sin embargo, lapersonalización avanzada es una tarea mucho más complicada. La plataformacuenta con herramientas de versionamiento y preservación digital (en desarrollo),así como también incluye algunos reportes estadísticos básicos, además puedeser utilizado junto con Google Analytics y existen algunas extensiones que hacenesta tarea [15].

• E-Prints: desarrollado originalmente en la Universidad de Southampton, seconcibió como una herramienta para administrar documentos resultados deinvestigación, como artículos o trabajos de grado, y de hecho este es su usohabitual, aunque actualmente puede administrar cualquier tipo de archivo digital.Está pensado para ser un repositorio basado en web altamente configurable [25].La instalación de la plataforma es relativamente simple, posee una herramientaadministrativa para la configuración de opciones, y tiene un sistema para instalarextensiones de forma directa. Respecto a los metadatos, nativamente estádiseñado para trabajar con Dublin Core, pero soporta otros tipos de metadatos.Ofrece la opción de versionamiento y puede generar reportes del número de vecesque los recursos han sido descargados [15].

• Fedora: fue desarrollado originalmente por investigadores de la Universidad deCornell y la Universidad de Virginia Library, y actualmente es mantenido porDuraSpace. Funciona como un framework, que no incluye funcionalidad nativapara administración, indexación, descubrimiento y entrega de objetos, en cambio,está enfocado en ser una herramienta con un alto grado de flexibilidad yextensibilidad con al que se pueda crear diferentes características [15]. De hecho,hay numerosos ejemplos en los que Fedora se ha utilizado en coleccionesdigitales, investigación electrónica (e-research), bibliotecas digitales, archivos,preservación digital, repositorios institucionales, publicaciones de acceso abierto,gestión de documentos, gestión de activos digitales, y más [26].


2.2.5. Modelo referencia de evaluación de OAs

En este trabajo [2] se define un modelo por capas para evaluar la calidad de objetos deaprendizaje (OAs), a partir de la identificación de las principales características que debencumplir estos recursos y el establecimiento de diferentes métricas para determinar sugrado de cumplimiento. Dicho modelo está compuesto por:

• Capas: definidas de acuerdo a los actores (administrador, usuario y experto) ofuentes de información involucradas en el proceso de evaluación. Esto permiteevaluar los OAs según diferentes visiones, sin embargo no todos los OAs podránser evaluados desde todas las capas, debido a limitaciones de acceso a lainformación o de interacción.

• Dimensiones: son las características generales que pueden ser evaluadas paracada OA, estas son transversales a las capas y están compuestas por una seriede métricas que permiten establecer un valor cuantitativo para cada variable enobservación.

• Métricas: cada métrica arrojará un valor entre 0 y 1, para cada OA evaluado quecorresponderá al porcentaje de cumplimiento del respectivo criterio de calidad.

En total, el modelo se compone de tres capas, para cada una de estas se utiliza comoinsumo la información proveniente de diferentes fuentes y medios:

• Capa de gestión: evalúa características técnicas de los OAs y aquellas que son deinterés del administrador del repositorio. Utiliza como insumo para el cálculo de lasmétricas la información proveniente de los metadatos de cada OA y lasestadísticas de su uso.

• Capa de revisión: evalúa características de los OAs a partir de las valoracionesdadas por un grupo de expertos a partir de la aplicación de una encuesta.

• Capa de percepción: evalúa características de los OAs a partir de las valoracionesdadas por los usuarios después de utilizar cada OA.

El modelo concibe un total de seis dimensiones (Educativa, Contenido, Estética,Funcional, Metadatos y Contextual) transversales a las tres capas descritasanteriormente. Estas dimensiones agrupan características deseables de los objetos deaprendizaje que son evaluadas a través de 21 métricas propuestas. Al final, cada métricaarrojará un valor entre 0 y 1 para cada objeto de aprendizaje evaluado, que corresponderáal porcentaje de cumplimiento del respectivo criterio. En general para todas las métricasdebe hacerse un proceso de parametrización inicial, y deberían calcularse con cierta


periodicidad, ya que los repositorios son dinámicos y se espera tener siempre resultadosactualizados.

Figura 1: Modelo de evaluación referencia [2]

2.2.5.1. Métricas de la capa de gestión

Dimensión Funcional

• Reusabilidad: para que un objeto de aprendizaje pueda ser reutilizable debe ser:autocontenible, es decir que tenga sentido por sí mismo; modular, para que puedacombinarse con otros OAs y de granularidad media, es decir que su tamaño seaaceptable y esté enfocado a un único objetivo educativo. Para evaluar esta métricase debe definir un conjunto de reglas que permitan verificar los valores que tienenalgunos metadatos y su nivel de influencia en la reusabilidad del OA. El


administrador del repositorio debe definir si la estructura de metadatos que tienenlos recursos a evaluar contiene alguno de los metadatos recomendados (DensidadSemántica, Nivel de Agregación o Granularidad, Estructura y Contexto) para definirlas reglas, los posibles valores que estos presentan y una ponderación para cadavalor indicando su importancia en la reutilización del OA.

Para calcular esta métrica (ver ecuación 1) se deben evaluar cada una de las reglas de reusabilidad. Si el OA cumple con alguna de estas reglas se asigna el peso correspondiente, que es un valor entre 0 y 1. Luego se realiza un promedio aritmético de los valores obtenidos al evaluar las reglas, el cual indicará el nivel de reusabilidad del OA. Si no se pudo evaluar ninguna regla (R=0), entonces se define que no es posible calcular esta métrica para el OA en análisis.

MtReusabilidad=∑i=1

n M i

R

Ecuación 1: Métrica de reusabilidad [2]

Donde:

M i es el peso correspondiente dentro de la regla evaluada

R es el número de reglas analizadas

• Disponibilidad: la característica de disponibilidad es definida como la posibilidadque tiene un OA de ser usado en cualquier momento. Esta métrica se centra en elmetadato donde se indica la localización del objeto. Para calcular la métrica dedisponibilidad (ver ecuación 2) se analiza si los enlaces asociados a la localizacióndel OA están activos o no, se asigna un valor de 1 si es posible alcanzar el objetoo 0 en caso contrario. Debido a que en algunos estándares se pueden tener variasinstancias de este metadato, el valor es dividido por la cantidad de instanciasencontradas. En caso de que el OA no tenga un metadato de localización (L=0), lamétrica toma un valor de 0.

MtDisponibilidad=∑i=1

n M i

L

Ecuación 2: Métrica de disponibilidad [2]

Donde:


M i es el valor binario que indica si el metadato i está disponible

L es el número de campos de localización que presenta el OA

Dimensión Metadatos

• Completitud: consiste en revisar un subconjunto de los campos que componen losmetadatos para determinar si contienen algún valor o en el caso de los camposcon múltiples valores si contienen por lo menos una instancia. El cálculo de estamétrica requiere un proceso de parametrización inicial donde se indique elestándar de metadatos asociado, el cual se evaluaría estrictamente, o cada uno delos metadatos que serán analizados y su respectivo peso. Dado que no todos loscampos de los metadatos tienen la misma importancia, se propone el uso de unsistema de ponderaciones para considerar la importancia relativa de los mismos,estos pesos se encuentran en un rango entre 0 y 1. Para determinar tales pesosse recomienda evaluar, por ejemplo, cuales metadatos son más utilizados en lasbúsquedas avanzadas y cuales son exhibidos a los usuarios en los resultados delas búsquedas. Una vez calculados los pesos para todos los metadatos, el cálculode la métrica completitud (ver ecuación 3) para un OA específico consiste enrevisar cada campo de los metadatos dando un valor de 1 si tiene algún valor oinstancia o 0 en caso contrario. Estos valores se multiplican luego por el pesocorrespondiente y el resultado final de la métrica corresponde a la sumatoria deestos resultados, donde un valor de 0 significa que el OA no tiene ningún metadatodiligenciado, mientras que un valor de 1 indica que todos los metadatos lo están.

MtCompletitud=∑i=1

n

k i∗M i

Ecuación 3: Métrica de completitud [2]

Donde:

k i es el peso del metadato i

M i es el valor binario que indica si el metadato i tiene algún valor o instancia

• Consistencia: se evalúa a partir de la especificación del estándar de metadatosdefinida por el repositorio, el cual establece si un determinado metadato puedetomar valores libres, o si por el contrario existe una lista de valores posibles. Eladministrador del ROA debe indicar cuales son los posibles valores de cadacampo o simplemente la sujeción al estándar adoptado con las restriccionesdefinidas por este. Un aspecto importante que afecta directamente los resultados


es el idioma o idiomas en los que se encuentra definido tanto la estructura comolos valores de los metadatos, ya que de esto depende las comparaciones que sehagan, por lo tanto quien esté interesado en el cálculo de la métrica deberá indicartambién esta información.

Para calcular esta métrica (ver ecuación 4) se revisa para cada metadato si su valor corresponde con los valores permitidos y, en caso afirmativo, se asigna una valor de 1 o de 0 en caso contrario. Posteriormente, la sumatoria de estos valores es dividida por la cantidad de comparaciones posibles, obteniendo así el valor finalde la métrica (promedio). Para esta métrica un valor de 0 significa que el OA presenta inconsistencia en todos sus metadatos analizados, entre tanto, un valor de 1 significa que el OA tiene diligenciados todos los metadatos evaluados y que los valores de estos son consistentes. En caso de que no se pueda realizar ninguna comparación (R=0) la consistencia toma un valor de “No Aplica” y no es involucrada en el cálculo.

MtConsistencia=∑i=1

n M i

R

Ecuación 4: Métrica de consistencia [2]

Donde:

M i es el valor binario que indica si el metadato i cumple con la regla


• Coherencia: un OA es coherente si toda la información contenida en susmetadatos describe el mismo recurso, por lo que esta métrica compara y revisa elvalor de un metadato en relación con el valor de otro. Tanto desde el punto de vistaconceptual como de la especificación del estándar, existen metadatos que tienenuna alta correlación y este hecho determina su coherencia. Debido a que sepresentan campos con valores definidos y otros de texto libre, se han definido dosformas de evaluar la coherencia, con el fin de analizar el mayor número demetadatos posible y llegar a un valor final de la métrica más completo. En primerlugar se contemplan los metadatos que tienen valores posibles y su relación entreellos. En este caso se establece un valor escalonado que da cuenta de lapertinencia de cada combinación de valores. Para calcular la métrica se revisapara un OA si existe alguna de las combinaciones válidas, en caso afirmativo, seasigna el valor de la combinación correspondiente, o 0 en caso contrario.Posteriormente, la sumatoria de estos valores es dividida por la cantidad decomparaciones posibles, obteniendo así el valor final de la métrica (ver ecuación


5).

MtCoherencia1=∑i=1

n M i

R

Ecuación 5: Métrica de coherencia (1) [2]

Donde:

M i es el valor asignado a la combinación según la regla aplicada


La segunda parte del cálculo de la métrica se realiza sobre los valores de losmetadatos de texto libre, determinando si existe correlación entre estos. Se calculala distancia semántica entre ellos, utilizando la Medida del Coseno, que permitecalcular la similitud entre dos vectores. En este caso se genera un vector paracada metadato a analizar (preferiblemente el título, la descripción y las palabrasclave) y se realizan todas las comparaciones posibles y su respectivo promedio(valor entre 0 y 1) que indica cual es el nivel de relación entre los camposanalizados. Para esta métrica se establece que a partir de un valor igual o mayor a0.7 el nivel de similitud es alto y para la unión con la otra parte de la métrica decoherencia se asigna un valor de 1 y para los otros valores se calculanproporcionalmente. Este cálculo se presenta a continuación:

MtCoherencia2=∑1

k ∑i=1

n

(P i∗Qi)/√ ∑i=1

n

Pi2∗∑

i=1

n

Qi2

k

Ecuación 6: Métrica de coherencia (2) [2]

Donde:

k es la cantidad de metadatos analizadosPi es la frecuencia del término i en el campo 1

Qi es la frecuencia del término i en el campo 2

Finalmente para realizar el cálculo final de la métrica de coherencia (ver ecuación


7) se aplica la siguiente fórmula, donde se combinan los dos valores, para arrojar un valor entre 0 y 1, donde 0 indica que los metadatos que describen el OA no tienen correlación entre sí, lo que podrá llevar a pensar que no están describiendo el mismo objeto, y un resultado de 1 indica que los metadatos son coherentes entre sí completamente.

MtCoherencia=MtCoherencia1+MtCoherencia2

2Ecuación 7: Métrica de coherencia [2]

Dimensión Contextual

• Visibilidad: la visibilidad del OA está asociada con la relación entre las visitas queha tenido el OA evaluado y el total de visitas a los objetos en el repositorio. Deesta forma se puede identificar en términos generales si el OA presenta mejorescaracterísticas, asumiéndose que al ser más usado es más relevante para elusuario, bien sea por su contenido o sus metadatos.

Para calcular esta métrica (ver ecuación 8) se toman los valores asociados a cada OA, que pueden ser cantidad de visitas y/o cantidad de descargas, y estos valoresse comparan respecto a los totales para todos los objetos dentro del ROA.

MtVisibilidad=V +D

TEcuación 8: Métrica de visibilidad [2]

Donde:

V es la cantidad de visitas que ha tenido el OAD es la cantidad de descargas que ha tenido el OAT es la cantidad total de descargas y visitas en el repositorio


2.2.5.2. Métricas de la capa de revisión de expertos

Para que un OA pueda ser evaluado desde la perspectiva de un experto en alguna de lasdimensiones propuestas en el modelo de evaluación se propuso una encuesta técnicapara facilitar la recopilación de los conceptos de expertos. En la figura 2 se presentan lasvariables evaluadas, las preguntas y su respectiva codificación. Las respuestas dadas acada pregunta debe ser un valor numérico entre 0 y 5, donde 0 es el nivel más bajo y 5 elmás alto.

El repositorio que esté interesado en evaluar sus OAs a través de esta capa debe definir:

• Cuales métricas desea aplicar y seleccionar las preguntas correspondientes• El mecanismo para definir los expertos • El momento y la forma como realizarán las revisiones

Entre mayor sea la cantidad de respuestas más cercanos serán los valores de lasmétricas con la realidad, sin embargo podrían calcularse con solo una respuesta. Con elfin de dar mayor relevancia a las respuestas, se pide que no solo se respondan laspreguntas, sino que también el experto defina para cada dimensión, entre 1 y 5 el nivel deexperticia/bagaje que considera que tiene frente a este criterio. Esto es opcional y en casode que no se indique el cálculo de las métricas se haría teniendo en cuenta las respuestasbajo el mismo nivel de importancia. El siguiente es el cálculo general que debería hacersepara cada métrica. Se divide entre 5 para que el resultado de la métrica sea una valor enel rango [0,1].

MetricasCapaExpertos=( 15n

)(∑i=1

n ∑j=1

k

(Eij∗NE j)

∑j=1

k

NE j

)

Ecuación 9: Métricas de Capa de Expertos [2]

Donde:

n es la cantidad de preguntas asociadas con la métricak es la cantidad de respuestas que tiene la pregunta iEij es la respuesta a la pregunta i dada por el experto j

NE j es el nivel de experticia de la dimensión asociada a la pregunta i dada por el

experto j


En el siguiente gráfico se presenta el cuestionario utilizado como instrumento pararecopilar el concepto de los expertos sobre los objetos de aprendizaje.

Figura 2: Instrumento para revisión de expertos


2.2.5.3. Métricas de la capa de percepción de usuarios

La propuesta está orientada a que sea evaluado cada recurso después de la interaccióncon el usuario, solicitándole la realización de una corta encuesta que debería ser opcionaly fácil de diligenciar. Al igual que en la capa de expertos, es decisión del repositorio quedesee realizar la evaluación, la forma como se hará el proceso de captura de lasrespuestas.

Se propone un instrumento donde se plantean las preguntas que podrían hacerse alusuario y que están asociadas con una dimensión especifica. Se pueden realizar todas laspreguntas o solo algunas de ellas de acuerdo a los intereses específicos del repositorio.Las respuestas se deben dar en una escala de 0 a 5, donde 0 es el nivel más bajo y 5 elmás alto.

Figura 3: Instrumento para captura de la percepción de los usuarios [2]

El propósito de esta encuesta es que sea lo más sencilla posible para el usuario, ya queno siempre cuenta con el tiempo y la disposición para responder las preguntas. Sinembargo, de acuerdo a los intereses de los administradores de repositorios donde sealojan los objetos de aprendizaje, se podrían agregar más preguntas asociadas a unamétrica o más características a evaluar. La siguiente fórmula muestra el cálculo de las


métricas.

MetricasCapaUsuarios=( 15n

)(∑i=1

n ∑j=1

k

U ij

k)

Ecuación 10: Métricas de Capa de Usuarios [2]

Donde:

n es la cantidad de preguntas asociadas con la métricak es la cantidad de respuestas que tiene la pregunta iU ij es la respuesta a la pregunta i dada por el usuario j

2.2.5.4. Integración del modelo

El modelo de evaluación propone, a partir del cálculo de la media, realizar una integraciónpor capas o por dimensiones. En el primer caso se le asigna una ponderación a cadadimensión dentro de la capa y en el segundo caso estos valores se le asignan a cadacapa dentro de la dimensión.

• Integración por capas: se pretende generar un indicador de la calidad del OA porcada capa, lo que nos indicaría desde la gestión del OA (específicamentemetadatos y uso del OA), desde las revisiones de los expertos y desde el punto devista de los usuarios cual es el nivel de cumplimiento de las característicasdeseables de los OA. En cada capa se realiza una ponderación de lasdimensiones, asignándole un valor entre 0 y 1, y solo se le asigna a lasdimensiones que tienen métricas calculadas. La suma de estos valores debe serigual a 1. La siguiente ecuación muestra cómo se calcularía el índice por cadacapa:

IndiceCapaX=∑i=1

n

(∑j=1

k

M j

k∗Di)

Ecuación 11: Índice por capa [2]


Donde:

n es la cantidad de dimensiones que se tiene en la capak es la cantidad de métricas para la dimensión iM j es el valor de la métrica j en la dimensión i

Di es el peso asignado a la dimensión i

El índice total para cada OA se obtiene a partir del producto del índice por capas y la ponderación asignada a cada una de ellas por el interesado en la evaluación, como se muestra en la siguiente ecuación:

IndiceTotalCapas=∑i=1

n

IC i∗Ci

Ecuación 12: Índice total de las capas [2]

Donde:

n es la cantidad de capasIC i es el índice calculado para la capa i

Ci es el peso asignado a la capa i

Este índice final para todas las capas, podría servir como criterio de ordenamiento en los resultados de las búsquedas realizadas en los repositorios (para generar algún tipo de ranking de objetos de aprendizaje en los repositorios).

• Integración por dimensiones: se realiza un promedio ponderado con el fin dedefinir para cada OA un valor que corresponde al nivel de cumplimiento de lasvariables o criterios de cada dimensión. La siguiente ecuación muestra el cálculodel índice por dimensión:

IndiceDimensionX=∑i=1

n

(∑j=1

k

M j

k∗Ci)

Ecuación 13: Índice por dimensión [2]


Donde:

n es la cantidad de capas que se tiene en la dimensiónk es la cantidad de métricas para la capa iM j es el valor de la métrica j en la capa i

Ci es el peso asignado a la capa i

El cálculo del índice total para todas las dimensiones se obtiene a partir de la siguienteecuación:

IndiceTotalDimensiones=∑i=1

n

IDi∗D i

Ecuación 14: Índice total de las dimensiones [2]

Donde:

n es la cantidad de dimensionesIDi es el índice calculado para la dimensión i

Di es el peso asignado a la dimensión i

De acuerdo con la propuesta metodológica la institución propietaria del repositorio o eladministrador del mismo deben definir las ponderaciones en cada caso. Para el caso delpresente trabajo, a partir de la evaluación técnica de cada método de cálculo, se escogerálas opción más conveniente.


2.3. Marco metodológico

Se propone el uso del proceso de desarrollo ágil Scrum, bajo la premisa que por el tipo deproyecto a implementar se cree conveniente hacer entregables cortos y en tiempostempranos que permitan evaluar y ajustar el trabajo realizado así como identificarfalencias y dificultades, y corregirlas o mitigarlas a corto plazo, tanto en el producto comoen el proceso de desarrollo mismo, gracias a que el proceso de desarrollo es iterativo, yusa iteraciones cortas, cuya duración generalmente está en el rango de 15 a 30 días. Elmarco de trabajo de Scrum, se puede definir desde una serie de directrices que derivanen el uso de un conjunto de roles, actividades y artefactos en el desarrollo [27], estemarco se describe en estos términos en el gráfico 18, y en los siguientes párrafos seexplica y aclara su aplicación al proyecto.

Figura 4: Marco de trabajo de Scrum [27]

2.3.1. Roles

Definen las responsabilidades de los participantes en el desarrollo, y pueden ser de trestipos tal y como lo define la metodología (ver gráfico 19):

• El encargado del producto (Product Owner): es la persona que define lasprioridades de las tareas que se van a realizar, y que da la aceptación al trabajoque se va realizando en cada iteración; en términos generales el encargado delproducto es el que sabe lo que se quiere hacer y tiene el conocimiento del


negocio. Para los propósitos de este proyecto, este rol pertenece principalmente alprofesor director del proyecto y de ser posible al profesor evaluador.

• El experto en Scrum (Scrum Master): es la persona que guía al equipo en laadopción del proceso de desarrollo, garantiza que las tareas y actividades serealicen, y ayuda a encontrar las prácticas y procedimientos que garanticen elbuen desempeño. Este rol pertenece a alguno de los dos estudiantes realizadores.

• El equipo de desarrollo (Development Team): son las personas encargadas deimplementar las características definidas para cada iteración, alineándose a losrequerimientos del encargado del producto, y bajo la guía del experto en Scrum. Elequipo es multifuncional, en el sentido que debe desarrollar todas las tareas deingeniería de software necesarias para terminar satisfactoriamente la iteración(diseño, implementación, pruebas, etc ), y es adaptativo en el sentido que elequipo debe auto organizarse para encontrar con el tiempo la mejor forma decumplir satisfactoriamente con las metas establecidas en cada iteración corta. Esterol pertenece a los dos estudiantes que van a realizar el proyecto. El hecho queuno de los dos estudiantes, tome al mismo tiempo el rol de experto en scrum ydesarrollador, no es impedimento para la aplicación del proceso, y es una prácticaque se puede encontrar, inclusive, en la implantación de la metodología en elmercado, cuando el líder del equipo de desarrollo a su vez es el “scrum master”.

Figura 5: Roles de Scrum [27]


2.3.2. Actividades

Son las etapas y reuniones que definen a cada iteración corta (ver gráfico 18). En primerlugar está el “sprint”, que es la iteración corta en sí misma. El sprint, generalmente, tieneuna duración entre 15 a 30 días, e idóneamente, la duración debe permanecer invariantedurante el desarrollo. Por supuesto, se puede variar el tiempo de un sprint para encontrarel que mejor se acomode al equipo de trabajo y el que responda de mejor forma a lasnecesidades particulares del desarrollo, pero una vez se ha superado esta etapa, lossprint deberían, todos, compartir la misma duración. Una característica sobresaliente delos sprints, es que tienen un objetivo claro, que en la mayoría de los casos, implica eldesarrollo de una característica potencialmente liberable a producción. Para el desarrollode este proyecto se utilizarán sprints con una duración de dos semanas (15 díascalendario, 10 días hábiles), porque es un tiempo prudente para realizar avancessustanciales (objetivo del sprint) y coherente con los tiempos de desarrollo cortos propiosde este tipo de proyectos.

El “scrum planning” o reunión de planeación es una actividad que se realiza al principiodel sprint, y en la que los diferentes roles se reúnen para definir el conjunto de tareas arealizar durante el mismo. En la reunión de planeación se eligen tareas que lleven a larealización de una característica potencialmente entregable, y se describen y priorizan. Esuna buena práctica definir las subtareas que implica cada tarea, y criterios de aceptaciónque describan claramente cuando se puede considerar que una tarea ha sido realizadaexitosamente. El resultado de la reunión es una lista de tareas por realizar para ese sprint(sprint backlog). Luego de esto, se realiza la ejecución del sprint, a cargo del equipo dedesarrollo multifuncional, en la que se realizan todas las actividades propias de laingeniería de software (implementación, pruebas, documentación, etc.). Cada día de laejecución del sprint, incluye una reunión corta (en lo concerniente a este proyecto serealizarán de 5 minutos), denominada reunión diaria (daily), en la que se evalúa el trabajorealizado durante el día, o lo que es equivalente, el trabajo realizado desde la últimareunión diaria. En esta reunión, se busca, esencialmente, socializar con el equipo dedesarrollo, los avances logrados, que se espera realizar hasta la próxima reunión, y quéobstáculos entorpecieron el desarrollo, si existieron.

Por último, al final de cada sprint se realizan dos actividades. La primera es la revisión(sprint review), en la que el encargado del producto, y las partes interesadas, dan suretroalimentación sobre la característica potencialmente entregable (objetivo del sprint),que en términos de proyecto se entiende como una reunión al final del sprint con elprofesor director, y de ser posible con el evaluador, para la revisión del avance logrado. Lasegunda es la retrospectiva (sprint retrospective), en la que se evalúa y ajusta el procesode desarrollo; aquí se incluye una lista de aspectos buenos y aspectos por mejorar, asícomo problemas que pudieron surgir en el desarrollo, si se terminó o no el sprint, es decir,se realizó el objetivo propuesto en la planeación, o si hubo sobreestimación osubestimación de tareas. Mientras la primera es revisión del producto, la segunda es unarevisión del proceso.


2.3.3. Artefactos

El insumo de entrada para el desarrollo está definido por una lista de tareas pendientes(backlog), administradas por el encargado del producto, conocidas generalmente como“issues” o historias, y ordenadas por su importancia o prioridad, de tal forma que si algunahistoria se deja de desarrollar, por cualquier inconveniente que pueda surgir, sea la quemenos impacto tenga en la funcionalidad del producto. La lista, como el proceso mismo,es adaptativa y por lo tanto se pueden agregar o eliminar tareas en el tiempo. De esta listade historias, se escoge un subconjunto (sprint backlog) en la reunión de planeación, conla idea de que el subconjunto lleve a la consecución del objetivo del sprint, unacaracterística potencialmente entregable. De esta forma, la lista de historias que se eligen,y que el equipo de desarrollo estima puede realizar en el sprint, constituye el objetivo delsprint, y es una característica entregable, o por lo menos un avance significativo en eldesarrollo.

La aplicación de la metodología de desarrollo, se pretende soportar mediante el uso de laherramienta gratuita para uso académico Jira. Dicha aplicación permite documentar lashistorias y crear reportes de los avances realizados, entre otras cosas.

3. Descripción de la solución

3.1. Caracterización de DSpace

A continuación se describen un conjunto de especificaciones técnicas del repositorio quefueron indispensables para el desarrollo de la extensión propuesta. Las siguientesconsideraciones son el producto del estudio de la plataforma a través de sudocumentación y uso. En las secciones siguientes, cada vez que se hace uso de [dspace]se está haciendo referencia a la carpeta de instalación de DSpace, el directorio quecontiene el código compilado con sus respectivos archivos de configuración, listo para serdesplegado, mientras que [dspace-source] hace referencia a la carpeta que contiene elcódigo fuente de la plataforma, desde la cual se compila, y en donde se realizó laextensión.

3.1.1. Arquitectura

La plataforma está construida sobre una arquitectura de tres capas que sigue el modeloMVC (Modelo-Vista-Controlador), cada una de estas capas consta de varios componentesde software que interactúan entre si. La solución propuesta en este documento se ciñe ala arquitectura descrita a continuación.

En primer lugar, la capa de almacenamiento es la encargada del alojamiento físico de losmetadatos y el contenido. En segundo lugar, la capa de lógica de negocio trata todo lorelacionado con la administración de los contenidos, usuarios, permisos y flujos detrabajo. Por último, la capa de aplicación contiene los componentes de software quepermiten la comunicación de DSpace con el exterior (interfaz gráfica de usuario einterfaces con otras aplicaciones).

Cada uno de los componentes de las capas de almacenamiento y de lógica de negociotiene una API definida, los cuales se agrupan para conformar la API de almacenamiento y

34

CAPÍTULO 3. DESCRIPCIÓN DE LA SOLUCIÓN 35

la API pública de DSpace respectivamente. La Figura 6 ilustra las capas descritas y susrespectivos componentes.

Figura 6: Arquitectura de DSpace [28]

El código fuente está organizado para corresponder de forma estricta con la arquitecturadescrita. Debido a esto, sólo a los métodos en una API pública de componente se lesconcede el nivel de acceso público. De esta manera el compilador Java ayuda a asegurarque el código fuente esté escrito conforme a la arquitectura definida. La Tabla 1 relacionala ubicación de los componentes de cada capa con el respectivo paquete de código fuentedefinido para tal.

Componentes en Capa Paquete

Capa de aplicación org.dspace.app

Capa de negocio org.dspace (menos app y storage)

Capa de almacenamiento org.dspace.storage

Tabla 1: Ubicación paquetes correspondientes a cada una de las capas


Respecto a la seguridad, aunque la lógica para los permisos de diferentes acciones sobreel sistema se encuentra en la capa de lógica de negocio, cada uno de los componentesde la capa de aplicación tiene sus propios métodos para autenticar los usuarios. Esto,debido a que los métodos de autenticación podrían variar ampliamente entre diferentesaplicaciones, por lo que esta responsabilidad recae en cada una por separado.

En cuanto a la Interfaz Gráfica de Usuario (IGU), y debido a su naturaleza web, estaplataforma ofrece la posibilidad de escoger entre dos opciones para la presentación de loscontenidos: una versión basada en XML (XMLUI) y otra basada en Java Server Pages(JSPUI). La solución propuesta en este documento se diseñó, construyó e implementósobre la versión JSPUI de DSpace porque es la IGU más extendida y más estable hastael momento, ya que XMLUI solo esta disponible desde la versión 4 de DSpace.

Teniendo esto en cuenta, se debe aclarar que DSpace con JSPUI utiliza un enfoque delmodelo arquitectural MVC conocido como “JSP Model 2 Architecture”. Bajo este enfoqueel Modelo está constituido por la API pública de DSpace, la Vista corresponde al conjuntode archivos JSP (Java Server Pages) que permiten presentar los contenidos al usuario yel Controlador está compuesto por Java Servlets que permiten procesar las peticiones delusuario y determinar la respuesta que debe dar el servidor.

El funcionamiento básico es el siguiente (Figura 21):

Figura 7: JSP Model 2 Architecture

1. Se recibe una petición HTTP desde el navegador2. El Servlet correspondiente es invocado y procesa la petición llamando a la API


pública de DSpace3. Dependiendo de la salida del procesamiento, el Servlet invoca el correspondiente

JSP4. Los datos recuperados desde el modelo y procesados por el Servlet son pasados

como parámetros a los respectivos JSP para que sean presentados al usuario5. El JSP es procesado por el contenedor (Tomcat) y presentado en el navegador

La solución propuesta introduce nuevo código fuente en los paquetes de aplicación y delógica de negocio, ya que utiliza la API pública y la API de almacenamiento para suoperación. De esta forma, el código nuevo se acopla al resto de la plataforma respetandola arquitectura y estándares de codificación definidos por el equipo de desarrollo deDSpace. Además se trató de reutilizar al máximo las funcionalidades existentes para nogenerar código redundante. En resumen, el módulo aquí propuesto, utiliza la GUI basadaen JSP, para agregar las vistas y controladores, y extiende la API pública, para agregar elmodelo; esto se logra a través de los recubrimientos de Maven, y del uso de los módulosJSPUI y Additions.

3.1.2. Módulo de adiciones (Additions Module)

Este módulo es utilizado para almacenar cambios al módulo de lógica de negocio(dspace-api), extensiones a las funcionalidades existentes (como la nuestra), entre otros.Las clases que se disponen en la ruta [dspace-source]/dspace/modules/additionsreemplazarán a las que están ubicadas en dspace-api. Este módulo será utilizado portodas las aplicaciones localizadas en el directorio [dspace-source]/dspace/modules y en lainterfaz por línea de comandos. Se recomienda disponer todos los cambios a dspace-apien este módulo de tal forma que los cambios realizados estarán contenidos en un únicomódulo, facilitando el mantenimiento de los mismos. El código fuente del desarrollocorrespondiente a este proyecto se centró en dicha ubicación

3.1.3. Recubrimientos de Maven (Maven WAR Overlays)

Permiten la extensión y personalización de los diferentes módulos y aplicaciones web deDSpace, centralizando los cambios en un solo directorio. Dicho directorio se encuentra en[dspace-source]/dspace/modules/*, donde se encuentran carpetas asociadas a cada unode los módulos del sistema. Los cambios que se puedan llegar a especificar en una deestas carpetas, se sobrescriben en el módulo correspondiente. La idea detrás de esto, esmezclar (merge) las aplicaciones web, permitiendo agregar nuevos artefactos de softwarea las aplicaciones e inclusive modificar los existentes. Para el desarrollo de este proyectofue necesario realizar adiciones a dos de estos módulos, en primera instancia a additions,donde se agregó el núcleo de la solución, es decir, el modelo o la lógica de negocio, y en


segunda instancia a jspui, en el que se incluyeron vista como JPSs y controladores comoservlets. DSpace ofrece dos opciones para la construcción de los módulos, unaconstrucción rápida de Maven (quick build), que a diferencia de la construcción completa(full build), sólo toma los archivos ubicados en el directorio de los módulos, los recompila yaplica al código fuente previamente compilado. De esta forma se evita compilar toda laaplicación cada vez que se requiera evidenciar los cambios introducidos.

3.2. Especificación funcional del producto

3.2.1. Definición detallada del producto

El módulo de evaluación de Objetos de Aprendizaje propuesto en este trabajo es unprototipo de extensión (plugin, add-on) para el repositorio digital de código abierto,DSpace. Le proporciona diversas herramientas a los administradores de repositoriosinstitucionales basados en esta plataforma para garantizar unos niveles mínimos decalidad en sus respectivos objetos de aprendizaje, aunque también (bajo ciertascondiciones) se pueden evaluar otros tipos de recursos educativos digitales. Esto, graciasa la implementación de un modelo por capas para evaluar la calidad de los objetos deaprendizaje que, por medio del cálculo de unas métricas, permite valorarlos de acuerdo algrado de cumplimiento de unos criterios bien definidos.

Para acoplar el módulo de evaluación propuesto con DSpace, el administrador delrepositorio debe seguir las siguientes instrucciones de instalación (para más detallesrevisar: Anexo I. Manual instalación):

• Ejecutar un Recubrimiento Maven (Maven Overlay). Esta operación puederealizarse en el momento de la instalación de la plataforma con una construccióncompleta (full build) o, una vez ya esté instalada, con una construcción rápida(quick build).

• Ejecutar un script en la Base de Datos para adicionar las tablas donde sealmacenarán los datos correspondientes a la parametrización y los resultados decada evaluación. Además (ejecutando otro script) se agregan unos registrosadicionales en la tabla “EpersonGroup” para incluir los grupos de expertos yestudiantes que, junto al de administradores (ya existente), son necesarios paralas ejecutar las funcionalidades del módulo.

• Agregar los usuarios nuevos o existentes que vayan a utilizar el módulo a algunode los tres grupos nombrados anteriormente según el rol que desempeñan en elrepositorio institucional.


El prototipo contempla tres roles de usuario: Administrador del Repositorio, Experto yEstudiante, quienes evalúan el objeto de aprendizaje desde diferentes perspectivas.Estas perspectivas (o capas, según el modelo de referencia) se diferencian por lasfuentes de datos y por los métodos utilizados para calcular las respectivas métricas quepermitirán determinar el nivel de conformidad del objeto de aprendizaje de acuerdo a loscriterios de calidad definidos en el modelo. Estos criterios están enmarcados dentro deseis dimensiones: educativa, de contenido, estética, funcional, de metadatos y contextual,que representan los aspectos más relevantes a evaluar para determinar el grado decalidad de un objeto de aprendizaje.Este prototipo permite definir, calcular y evaluar hasta 21 métricas de calidad. Ladefinición de las métricas depende de las capas y dimensiones previamenteseleccionadas por el administrador del repositorio (con sus respectivos pesos) para teneren cuenta en la evaluación de cada uno de los objetos de aprendizaje. Una vezestablecidas las métricas, el cálculo se realiza a partir de datos recopilados por el sistemao de las valoraciones de los usuarios. De no haber configurado ninguna capa, dimensión ymétrica, nadie podrá hacer uso del módulo para evaluar el objeto de aprendizaje.

Las métricas correspondientes a la Capa de Administrador son calculadas por el sistemacon base en: la información recolectada de los metadatos registrados de cada objeto deaprendizaje en la Base de Datos del repositorio y los datos estadísticos de visitas ydescargas de cada objeto de aprendizaje en el repositorio consultadas en el índice SOLRde DSpace.

Las métricas correspondientes a la Capa de Experto son calculadas con base en lasvaloraciones otorgadas por los usuarios del repositorio pertenecientes al grupo deexpertos a cada uno de los criterios de calidad del objeto de aprendizaje expuestos en uncuestionario. Previo a la aplicación del cuestionario el experto debe ponderar, de acuerdoal nivel de experiencia que acredita tener, cada una de las dimensiones que evaluará yesto determinará el peso de su valoración en el puntaje final del objeto de aprendizaje.

Las métricas correspondientes a la Capa de Estudiante son calculadas con base en lasvaloraciones otorgadas por los usuarios del repositorio pertenecientes al grupo deestudiantes a cada uno de los criterios de calidad del objeto de aprendizaje expuestos enuna encuesta.

Al terminar el proceso de evaluación del objeto de aprendizaje en todas las capas ydimensiones configuradas previamente por el administrador, cada métrica arrojará unnúmero real entre 0 y 1. Este valor corresponderá al porcentaje de cumplimiento delobjeto de aprendizaje para el respectivo criterio según el evaluador o el sistema, estosresultados se integran para obtener un índice general de cada una de las capasinvolucradas en la evaluación del objeto de aprendizaje. Es decir, se obtiene un valorpromedio de las calificaciones de los expertos, estudiantes y/o el administrador delrepositorio. Los índices calculados de cada una de las capas serán consolidados en un


único valor denominado como puntaje general del OA, representado por un número realentre 1 y 10.

Por último, el sistema genera un reporte de resultados que contiene los siguientesdatos: ID del OA, puntaje general, índices de cada capa evaluada y los valores de cadauna de sus métricas. Esta información estará disponible únicamente para el administradordel repositorio quien, de esta forma, podrá tener una idea del nivel de calidad del recursoal que están accediendo los usuarios. De esta forma se podrán determinar losprocedimientos operativos necesarios para mejorar o depurar los contenidos quepresenten baja calidad en el repositorio.

3.2.2. Requerimientos funcionales del sistema

ID RF-001 Naturaleza del sistema

Descripción El sistema debe funcionar como una extensión (plugin, add-on) de laplataforma DSpace. De tal forma que se pueda acoplar con esta y, asímismo, se pueda desinstalar sin afectar las demás funcionalidades.

Prioridad Alta

ID RF-002 Autenticación en el sistema

Descripción El sistema debe identificar si el usuario pertenece a alguno de los rolespermitidos: Administrador, Experto o Estudiante. De lo contrario debedenegar el acceso.

Prioridad Alta

ID RF-003 Administración de permisos

Descripción El sistema debe desplegar, según el rol del usuario, la IGUcorrespondiente. Si es administrador, la pantalla de parametrizacióngeneral de evaluación; para los expertos, la pantalla de ponderación deexperiencia en cada dimensión de la evaluación y para los estudiantesla pantalla con la encuesta a diligenciar.

Prioridad Alta

ID RF-004 Ponderación de dimensiones

Descripción El sistema debe permitir la asignación de pesos a las dimensionesseleccionadas para la evaluación por cada una de sus respectivascapas. La suma de las ponderaciones del número total de dimensionesseleccionadas por capa debe ser igual al 100%


Prioridad Alta

ID RF-005 Ponderación de experiencia

Descripción El sistema debe permitir la asignación de pesos al nivel deconocimiento de cada uno de los expertos en dimensionesseleccionadas para la evaluación de estos. Los valores de laexperiencia deben expresarse a través de una escala de uno (1) acinco (5), donde 1 representa experiencia mínima y 5 experienciamáxima en la respectiva dimensión a evaluar.

Prioridad Alta

ID RF-006 Definición de métricas

Descripción El sistema debe permitir seleccionar hasta 21 métricas de calidad paraevaluar cada objeto de aprendizaje. Estas métricas deben tener losmismos nombres y deben desplegarse según las capas y dimensionesdefinidas en el modelo de evaluación que se tiene como referenteteórico.

Prioridad Alta

ID RF-007 Métricas de capa de administrador

Descripción El administrador del repositorio debe poder evaluar hasta seis (6)métricas de calidad (Coherencia, Consistencia, Completitud,Disponibilidad, Reusabilidad y Visibilidad) por cada objeto deaprendizaje. El sistema debe calcular los valores de estas métricas apartir de los valores de los metadato, los números de descargas y devisitas del objeto de aprendizaje en el repositorio. El cálculo deberetornar un número real entre 0 y 1 para cada una de las métricasseleccionadas.

Prioridad Alta

ID RF-008 Métricas de capa de experto

Descripción El usuario experto del repositorio debe poder evaluar hasta ocho (8)


métricas de calidad (Completitud, Diseño Visual, Efectividad Potencial,Facilidad de Acceso, Facilidad de Uso, Pertinencia y Rigurosidad,Precisión y Reusabilidad) por cada objeto de aprendizaje. El sistemadebe calcular los valores de estas métricas a partir de los valoresingresados por el usuario en el formulario. El cálculo debe retornar unnúmero real entre 0 y 1 para cada una de las métricas seleccionadas.

Prioridad Alta

ID RF-009 Métricas de capa de estudiante

Descripción El usuario estudiante del repositorio debe poder evaluar hasta siete (7)métricas de calidad (Diseño Visual, Disponibilidad, Efectividad,Facilidad de Uso, Motivación, Precisión y Relevancia) por cada objetode aprendizaje. El sistema debe calcular los valores de estas métricasa partir de los valores ingresados por el usuario en el formulario. Elcálculo debe retornar un número real entre 0 y 1 para cada una de lasmétricas seleccionadas.

Prioridad Alta

ID RF-010 Uso de metadatos de DSpace

Descripción El sistema debe acceder a los metadatos de todos los objetos deaprendizaje almacenados en la Base de Datos de la plataforma. Esto,para calcular las métricas que requieran sus valores, sin modificarlos.

Prioridad Alta

ID RF-011 Uso de estadísticas de visitas y descarga

Descripción El sistema debe acceder a las estadísticas de visitas y descarga decada uno de los objetos de aprendizaje almacenados en losrepositorios. Esto, para calcular las métricas que requieran sus valores,sin modificarlos.

Prioridad Alta

ID RF-012 Evaluación en conformidad con IEEE LOM

Descripción El sistema debe calcular las métricas relacionadas con los metadatosde acuerdo a las especificaciones del modelo de evaluación tomadocomo referente teórico. Es decir, que la evaluación de los metadatos serealizará teniendo en cuenta los campos tomados del estándar IEEELOM.


Prioridad Alta

ID RF-013 Evaluación de capa de administrador

Descripción El sistema debe desplegar un listado de las métricas habilitadas paraser evaluadas por el administrador del sistema y un mensaje deresultado por cada una de ellas, una vez sea ejecutada la evaluación.

Prioridad Alta

ID RF-014 Evaluación de capas de experto y estudiante

Descripción El sistema debe desplegar un formulario donde el usuario pueda daruna valoración (1 a 5 o SI/NO) a cada una de las preguntasrelacionadas con las métricas habilitadas previamente para evaluar elrespectivo objeto de aprendizaje.

Prioridad Alta

ID RF-015 Valoración general del objeto de aprendizaje

Descripción El sistema debe presentar un resultado general de la evaluación,expresado en un puntaje de 1 a 10, que recoja las valoracionesrealizadas por administradores, usuarios y/o expertos sobre un objetode aprendizaje en particular.

Prioridad Alta

ID RF-016 Reporte de resultados

Descripción El sistema debe generar y almacenar en la Base de Datos un reportede resultados que contenga los siguientes datos: ID del OA, puntajegeneral, índices de cada capa evaluada y los valores de cada una desus métricas. Este reporte debe actualizarse cada vez que un usuarioejecute una nueva evaluación sobre el objeto de aprendizaje.

Prioridad Alta


3.2.3. Requerimientos específicos de interfaces

Debido a que el prototipo propuesto en este trabajo se trata de una extensión (plugin,add-on) de una plataforma como DSpace, existen unas interfaces con esta última a travésde las API pública y de almacenamiento. Además, por tener interacción directa con losusuarios también se requiere de una interfaz gráfica de usuario (IGU). Estas interfaces sedescriben a continuación.

3.2.3.1. Interfaz gráfica de usuario

En esta sección se presentan los bocetos que dan una idea de las pantallas con las quepodrá interactuar el usuario del prototipo propuesto.

Figura 8: Pantallas de parametrización de la evaluación


Figura 9: Pantalla de ponderación de los criterios de evaluación

Figura 10: Pantalla de evaluación de estudiantes


Figura 11: Pantalla de evaluación de expertos

Figura 12: Pantallas de evaluación de métricas de la capa de administrador


Figura 13: Pantalla de reporte de resultados de la evaluación

3.2.3.2. Interfaz de aplicación

El módulo de evaluación de objetos de aprendizaje hace uso de otras funcionalidadesnativas de DSpace tales como: autorización, manejo de contenidos, persistencia e índicede estadísticas SOLR por medio de la API de almacenamiento y algunas API´s de la capade lógica de negocio. Estas API’s, de gran utilidad durante el desarrollo, se describenbrevemente a continuación.

Paquete org.dspace.authorize

Maneja todos los permisos para los contenidos en DSpace. El sistema de autorizacionesde DSpace sigue la filosofía clásica de seguridad del “estado policial”: el usuario no puedehacer nada, a menos que esté específicamente permitido. Esos permisos se explican con


los objetos de tipo ResourcePolicy, almacenados en la tabla homónima en la Base deDatos.

Las políticas de recursos se asignan a todos los objetos de contenido de DSpace:colecciones, comunidades, elementos, paquetes y flujos de bits, por ende resuelve si unusuario tiene o no privilegios para realizar una acción concreta sobre un objeto concretode acuerdo al grupo al que pertenece.

El proceso de instalación debe crear dos grupos especiales: grupo 0, para accesoanónimo/público y grupo 1 para administradores. El grupo 0 (público/anónimo) permiteque cualquier usuario acceda, incluso si no están autenticados. Los miembros del grupo 1(admin) tienen derechos de superusuario, y se les permite cualquier acción sobrecualquier objeto. Para el correcto funcionamiento del módulo propuesto, se crearon dosgrupos adicionales en la Base de Datos (expertos 2 y estudiantes 3) que permitenacceder a evaluaciones del objeto de aprendizaje desde perspectivas distintas.

Paquete org.dspace.content Proporciona una API para leer y manipular contenido en el sistema DSpace. Los datos enDSpace se almacenan según el siguiente modelo.

Figura 14: Modelo de datos de DSpace


Clase Descripción

ComunidadCommunity

Las comunidades corresponden a unidades organizacionales dentro deuna institución. Por ejemplo, un departamento, centro de investigación olaboratorio dentro de una Universidad.

ColecciónCollection

Las colecciones son agrupaciones de contenido relacionado. Unacolección puede aparecer en más de una comunidad. Por ejemplo, uncurso de cálculo integral, física mecánica, literatura clásica, etc...

ElementoItem

Los elementos son las unidades básicas de archivo. Un elementocorresponde a una sola pieza lógica de contenido y metadatos asociados.Un elemento puede aparecer en varias colecciones pero tiene una únicacolección propietaria. Por ejemplo, un objeto de aprendizaje, un capítulode un libro, un video, una presentación por diapositivas, etc.

PaqueteBundle

Los paquetes son agrupaciones de flujos de bits que no tienen sentido porsi solos. Por ejemplo, los archivos que componen un documento HTMLirían todos en un mismo paquete. Una versión en PDF del mismoelemento, o un conjunto de datos almacenados con el el elemento, iría enun paquete independiente.

Flujo de bitsBitstream

Son secuencias de bits, normalmente archivos, que forman el contenidobruto de los elementos. Además, cada flujo de bits esta asociado con unformato; esto describe información sobre el formato y la codificación delflujo de bits, incluyendo un nombre (por ejemplo, “Adobe PDF”), un tipoMIME y un nivel de soporte.

Tabla 2: Clases de contenidos en DSpace

Las diferentes clases de contenidos presentados en la Tabla 2 son muy importantes parael propósito del módulo propuesto en este trabajo. Estas clases, disponibles en el API decontenido, son utilizadas para obtener los metadatos que servirán para calcular lasdiferentes métricas de calidad de la capa de gestión.

Paquete org.dspace.eperson

Proporciona clases que representan a usuarios y a los grupos de usuarios. En el caso delmódulo propuesto en este trabajo, se utilizan métodos de la clase Group para determinarla pertenencia de los usuarios a uno de los grupos definidos por la aplicación paraacceder a sus funcionalidades: 1-Administradores, 2-Expertos o 3-Estudiantes. En casode que el usuario autenticado en el sistema DSpace no pertenezca a ninguno de estosgrupos, no podrá acceder a ninguna de las funcionalidades del módulo de evaluación.


Paquete org.dspace.statistics

Proporciona clases y métodos para acceder al índice SOLR y a varios reportesestadísticos sobre los contenidos y uso del sistema que son generados automáticamente,esto se realiza analizando los archivos de registro de Dspace (Dspace's log files). Lasestadísticas se pueden mostrar por periodos mensuales, algunas de estas estadísticasincluyen:

• Número de elementos guardados• Número de vistas de bitstream• Número de vistas/descargas a la página de un elemento• Número de vistas a la página de una colección• Número de vistas a la página de una comunidad• Número de accesos de usuario• Número de búsquedas realizadas• Número de rechzos de licencia• Número de peticiones OAI, etc.

Paquete org.dspace.storage.rdbms

Proporciona una API para acceder a un sistema de gestión de base de datos relacional(RDBMS). La clase principal es DatabaseManager, que ejecuta consultas SQL y retornaobjetos de tipo TableRow (para un único resultado) o TableRowIterator (para variosresultados). La clase DatabaseUtils se utiliza para cargar SQL en el RDBMS a través delFlyway DB.

En la mayoría de los casos el uso de la API de almacenamiento se usa combinado con laAPI de contenido el cual encapsula el uso de la base de datos. Las clases de estepaquete se utilizan para crear imágenes en memoria que representan los objetos lógicoscorrespondientes almacenados en Base de Datos. Cuando se realiza la lectura omanipulación, el Contexto puede ser abortado, en cuyo caso se descartan los cambios, opuede ser completado, en cuyo caso los cambios realizados son confirmados en la Basede Datos.

Si se produce algún error mientras se producen cambios, se debería abortar el contextoactual, ya que las imágenes en memoria podrían estar en un estado inconsistente.

Normalmente, al cambiar un objeto particular en el sistema, los cambios no se escribiránen el almacenamiento principal de DSpace a menos que se realice la actualización en elobjeto antes de completar el Contexto. Donde este caso no ocurre, se indica en ladocumentación del método.

Todas las tablas en el sistema DSpace tienen una única llave primaria, la cual es unentero. La columna de la llave primaria lleva el nombre de la tabla a la que pertenece, por


ejemplo, la tabla Eperson tiene la columna eperson_id.

Se pueden asignar ID’s de base de datos llamando la función SQL getnextid con elnombre de la tabla como único parámetro. El backend de la base de datos puedeimplementarlo de cualquier manera adecuada, debe ser robusto para el acceso a travésde múltiples clientes simultáneos y transacciones.

El paradigma general para usar DSpace es crear un Contexto porque mantieneinformación relevante, realiza una serie de procesos, y está involucrado en un grannúmero de operaciones (muchos métodos lo requieren). Por ejemplo, el Contexto,contiene una referencia al usuario activo, abre una conexión con una Base de Datos oadministra un caché de objetos instanciados, reduciendo la carga sobre la base de datosy evitando instancias múltiples de un mismo objeto. Las instancias de las clases en estepaquete están vinculadas al Contexto; cuando el Contexto ha sido terminado, los objetosse vuelven inválidos.

3.2.3.3. Requerimientos de persistencia

DSpace utiliza una base de datos relacional para guardar toda la información acerca de laorganización del contenido, metadatos de los contenidos, información sobre los usuarios yautorización, y el estado de los flujos de trabajo operando en el momento. El sistemaDSpace también usa la base de datos para mantener índices que los usuarios puedenexplorar.

La mayoría de las funcionalidades que utiliza DSpace pueden ser ofrecidas por cualquierbase de datos SQL estándar que admita transacciones. Sin embargo, en este momento,las API’s de DSpace utilizan algunas características especificas de PostgreSQL y Oracle,por lo que sería necesario realizar modificaciones al código fuente antes de utilizarDSpace plenamente con una base de datos alternativa de fondo.

El paquete org.dspace.storage.rdbms proporciona acceso a una base de datos SQL deuna manera más simple que utilizando el JDBC directamente. Por esto se decidió utilizarla API de almacenamiento descrita anteriormente para acceder a los datoscorrespondientes a los usuarios, ítems, colecciones, comunidades, etc... de la aplicacióny, adicionalmente, a las tablas que se requiere adicionar a la Base de Datos Relacionalutilizada por DSpace (PostgreSQL u Oracle) para almacenar los datos correspondientes ala parametrización de cada evaluación (capas, dimensiones, métricas) y los resultados delas mismas para la posterior generación de los respectivos reportes.


3.2.4. Especificación de casos de uso

3.2.4.1. Definición de actores

Figura 15: Actores del Sistema


Actor Descripción

Administrador Responsable de: • Definir las capas, dimensiones y métricas que se tendrán en

cuenta para la evaluación de cada objeto de aprendizaje.• Establecer los pesos de las dimensiones por capa involucradas en

la evaluación de cada objeto de aprendizaje.• Evaluar las métricas correspondientes a la capa de administrador

que se hayan definido previamente.• Generar el reporte de resultados de la evaluación de cada objeto

de aprendizaje y usar esta información para determinar lasacciones a realizar sobre cada objeto de aprendizaje.

DSpace Responsable de:• Proporcionar métodos de autenticación y autorización para los

usuarios del sistema y del módulo de evaluación• Generar y transmitir las estadísticas de visita y descarga de cada

uno de los objetos de aprendizaje en el repositorio.• Almacenar y proporcionar acceso a los metadatos registrados

para cada objeto de aprendizaje para que puedan ser accedidospor el módulo.

Estudiante Responsable de:• Evaluar las métricas correspondientes a la capa de estudiantes

que se hayan definido previamente.

Experto Responsable de:• Establecer los pesos de las dimensiones definidas previamente en

la capa de expertos de acuerdo a su propio nivel de experienciaen cada una de ellas.

• Evaluar las métricas correspondientes a la capa de expertos quese hayan definido previamente.

Tabla 3: Definición de actores


3.2.4.2. Casos de uso de la capa de administradores

Figura 16: Capa de Administradores


3.2.4.2.1 C.U. Iniciar Aplicación

Caso de Uso CU-001 Iniciar Aplicación

Actores Usuario, DSpace

Tipo Primario

Descripción Despliega la Interfaz Gráfica de Usuario (IGU) del módulo de evaluaciónde acuerdo al rol del usuario. Si el usuario no pertenece a ninguno de losroles autorizados, se deniega el acceso.

ReferenciasCruzadas

• Este caso de uso incluye: CU-003 Cargar Parametrización deEvaluación, CU-012 Evaluar OA según Estudiantes, CU-014Evaluar OA según Expertos

• Este caso de uso es extendido por: CU-002 ParametrizarEvaluación de OA, CU-004 Evaluar Completitud, CU-005 EvaluarConsistencia, CU-006 Evaluar Coherencia, CU-007 EvaluarDisponibilidad, CU-008 Evaluar Reusabilidad, CU-009 EvaluarVisibilidad, CU-011 Consolidar Resultados.

Pre-condición El usuario se debe haber autenticado en el sistema y debe pertenecer auno de los grupos de usuarios: Administradores, Estudiantes o Expertos.

Pos-condición El sistema desplegará la IGU correspondiente al rol de usuario detectado.


Figura 17: Iniciar Aplicación


3.2.4.2.2 C.U. Parametrizar Evaluación de OA

Caso de Uso CU-002 Parametrizar Evaluación de OA

Actores Administrador

Tipo Primario

Descripción Permite establecer las capas, dimensiones (con sus respectivasponderaciones según su relevancia en el puntaje general) y métricas quese tendrán en cuenta para evaluar cada uno de los OAs.

ReferenciasCruzadas

• Este caso de uso extiende a CU-001 Iniciar Aplicación.

Pre-condición El usuario se debe haber autenticado en el sistema como administradordel repositorio.

Pos-condición El sistema guardará en la base de datos los parámetros establecidos porel administrador para evaluar el objeto de aprendizaje actual.


Figura 18: Parametrizar Evaluación de OA


3.2.4.2.3 C.U. Cargar Parametrización de Evaluación

Caso de Uso CU-003 Cargar Parametrización de Evaluación

Actores Usuario

Tipo Primario

Descripción Carga desde la base de datos los parámetros de evaluación establecidospreviamente para el objeto de aprendizaje actual. Estos se puedensobreescribir con una nueva parametrización.

ReferenciasCruzadas

• Este caso de uso es incluido por: CU-001 Iniciar Aplicación, CU-012 Evaluar OA según Estudiantes, CU-013 Ponderar Criterios deEvaluación de OA según Experiencia.

Pre-condición Deben existir parámetros de evaluación para el objeto de aprendizajeactual almacenados en la base de datos.

Pos-condición El sistema recuperará desde la base de datos los parámetros deevaluación para el objeto de aprendizaje actual y los cargará en memoria.


Figura 19: Cargar Parametrización de Evaluación


3.2.4.2.4 C.U. Evaluar Completitud

Caso de Uso CU-004 Evaluar Completitud


Tipo Primario

Descripción Valida si están diligenciados todos los campos de metadatos necesarios ysuficientes para describir de forma completa el objeto de aprendizaje.Tiene en cuenta los metadatos que debieron haberse registrado al subircada objeto de aprendizaje al repositorio.

ReferenciasCruzadas

• Este caso de uso incluye: CU-010 Cargar Metadatos de OA.• Este caso de uso extiende a CU-001 Iniciar Aplicación.

Pre-condición Debe estar marcada la métrica “Completitud” de la capa de administradoren los parámetros de evaluación del objeto de aprendizaje actual.

Pos-condición El sistema calculará el valor correspondiente de la métrica con base en lavalidación del valor de cada uno de los campos de metadatos cargadosdesde la base de datos del repositorio.


Figura 20: Evaluar Completitud


3.2.4.2.5 C.U. Evaluar Consistencia

Caso de Uso CU-005 Evaluar Consistencia


Tipo Primario

Descripción Verifica si algunos de los campos de metadatos del objeto de aprendizajeregistrados en la base de datos contienen los valores permitidos en laespecificación del estándar de metadatos adoptado por el repositorio.

ReferenciasCruzadas


Pre-condición Debe estar marcada la métrica “Consistencia” de la capa deadministrador en los parámetros de evaluación del objeto de aprendizajeactual.

Pos-condición El sistema calculará el valor correspondiente de la métrica con base en lacomparación del valor de algunos de los metadatos con valoresrestringidos determinados por el esquema de metadatos del repositorio.


Figura 21: Evaluar Consistencia


3.2.4.2.6 C.U. Evaluar Coherencia

Caso de Uso CU-006 Evaluar Coherencia


Tipo Primario

Descripción Verifica si algunos de los campos de metadatos del objeto deaprendizaje, que guardan relación con otros campos determinados por laespecificación del estándar de metadatos del repositorio, estándiligenciados coherentemente.

ReferenciasCruzadas


Pre-condición Debe estar marcada la métrica “Coherencia” de la capa de administradoren los parámetros de evaluación del objeto de aprendizaje actual.

Pos-condición El sistema calculará el valor correspondiente de la métrica con base en lacomparación entre los valores de algunos de los campos de metadatos,que guardan relación entre sí, según la especificación del estándar demetadatos del repositorio.


Figura 22: Evaluar Coherencia


3.2.4.2.7 C.U. Evaluar Disponibilidad

Caso de Uso CU-007 Evaluar Disponibilidad


Tipo Primario

Descripción Verifica si la ubicación del objeto de aprendizaje y su informaciónasociada, a través de una o varias URL registradas en los metadatos, esaccesible a través de una petición GET.

ReferenciasCruzadas


Pre-condición Debe estar marcada la métrica “Disponibilidad” de la capa deadministrador en los parámetros de evaluación del objeto de aprendizajeactual.

Pos-condición El sistema calculará el valor correspondiente de la métrica con base en elresultado obtenido al realizar la petición GET sobre la(s) direccion(es)URL registradas en los campos de metadatos de ubicación del OA.


Figura 23: Evaluar Disponibilidad


3.2.4.2.8 C.U. Evaluar Reusabilidad

Caso de Uso CU-008 Evaluar Reusabilidad


Tipo Primario

Descripción Determina el nivel de reutilización del objeto de aprendizaje en otroscontextos con base en la evaluación de unas reglas que reciben comoentrada algunos de los valores registrados en sus metadatos.

ReferenciasCruzadas


Pre-condición Debe estar marcada la métrica “Reusabilidad” de la capa deadministrador en los parámetros de evaluación del objeto de aprendizajeactual.

Pos-condición El sistema calculará el valor correspondiente de la métrica con base enlos valores calculados por las reglas establecidas al evaluar los valoresde los campos de metadatos involucrados en dichas reglas.


Figura 24: Evaluar Reusabilidad


3.2.4.2.9 C.U. Evaluar Visibilidad

Caso de Uso CU-009 Evaluar Visibilidad


Tipo Primario

Descripción Determina el grado de aparición y, por tanto, de relevancia del objeto deaprendizaje en el repositorio con base en el número de visitas ydescargas del mismo.Este caso de uso incluye: CU-010 CargarMetadatos de OA.Este caso de uso extiende a CU-001 Iniciar Aplicación.

ReferenciasCruzadas


Pre-condición • Debe estar marcada la métrica “Visibilidad” de la capa deadministrador en los parámetros de evaluación del objeto deaprendizaje actual.

• Dspace debe proporcionar un medio para acceder las estadísticasde uso del objeto de aprendizaje almacenadas en el índice SOLR.

Pos-condición El sistema calculará el valor correspondiente de la métrica con base enlas estadísticas de uso del objeto de aprendizaje (número de visitas ydescargas) proporcionadas por el módulo SOLR de DSpace.


Ver anexo SalazarRinconAndresAlexis-1.jpg

Figura 25: Evaluar Visibilidad


3.2.4.2.10C.U. Cargar Metadatos de OA

Caso de Uso CU-010 Cargar Metadatos de OA

Actores Usuario

Tipo Primario

Descripción Carga desde la base de datos del repositorio los valores de metadatosregistrados del objeto de aprendizaje, pasa los valores de la consulta amemoria para ser utilizados en los cálculos de cada una de las métricasque los necesiten.

ReferenciasCruzadas

• Este caso de uso es incluido por: CU-004 Evaluar Completitud,CU-005 Evaluar Consistencia, CU-006 Evaluar Coherencia, CU-007 Evaluar Disponibilidad, CU-008 Evaluar Reusabilidad.

Pre-condición Se debe ejecutar alguna de las funcionalidades que necesitan consultarlos valores de metadatos.

Pos-condición El sistema cargará en memoria una lista con los valores de los camposde metadatos del objeto de aprendizaje registrados en el repositorio,según sea el caso.


Figura 26: Cargar Metadatos de OA


3.2.4.2.11 C.U. Consolidar Resultados

Caso de Uso CU-011 Consolidar Resultados

Actores Usuario

Tipo Primario

Descripción Calcula y despliega los índices por cada capa utilizada en la evaluación yel índice total de las capas utilizadas (puntaje general) para valorar elobjeto de aprendizaje con un número de 1 a 10. Además genera y guardaun reporte con los datos respectivos de cada evaluación: ID del objeto deaprendizaje, puntaje general, índices de cada capa evaluada y los valoresde cada una de sus métricas.

ReferenciasCruzadas


Pre-condición Se debe haber ejecutado y calculado todas las métricas habilitadas por eladministrador del repositorio para evaluar el objeto de aprendizaje.

Pos-condición El sistema desplegará el reporte de resultados de la evaluación del objetode aprendizaje.


Figura 27: Consolidar Resultados


3.2.4.3. Casos de uso de la capa de estudiantes

Figura 28: Capa de Estudiantes


3.2.4.3.1 C.U. Evaluar OA según Estudiantes

Caso de Uso CU-012 Evaluar OA según Estudiantes

Actores Estudiante

Tipo Primario

Descripción Despliega un formulario para que el estudiante califique cada una de lasmétricas habilitadas por el administrador para evaluar el objeto deaprendizaje.

ReferenciasCruzadas

• Este caso de uso incluye CU-003 Cargar Parametrización deEvaluación.

• Este caso es incluido por CU-001 Iniciar Aplicación.

Pre-condición • El usuario se debe haber autenticado en el sistema comoestudiante.

• Debe estar marcada al menos una métrica de la capa deestudiantes en los parámetros de evaluación del objeto deaprendizaje actual.

Pos-condición El sistema calculará el valor de las métricas correspondientes a la capade estudiantes con base en las respuestas ingresadas por los usuariosen el formulario.


Figura 29: Evaluar OA según Estudiantes


3.2.4.4. Casos de uso de la capa de expertos

Figura 30: Capa de Expertos


3.2.4.4.1 C.U. Ponderar Criterios de Evaluación de OA según Experiencia

Caso de Uso CU-013 Ponderar Criterios de Evaluación de OA según Experiencia

Actores Experto

Tipo Primario

Descripción Permite definir el nivel de dominio del experto en cada una de lasdimensiones habilitadas por el administrador del repositorio para evaluarel OA en la capa de expertos.

ReferenciasCruzadas

• Este caso de uso incluye CU-003 Cargar Parametrización deEvaluación.

• Este caso es incluido por CU-014 Evaluar OA según Expertos.

Pre-condición • El usuario se debe haber autenticado en el sistema como experto.• Debe estar marcada al menos una métrica de la capa de expertos

en los parámetros de evaluación del objeto de aprendizaje actual.

Pos-condición El sistema guardará en la base de datos las ponderaciones definidas porel experto para cada dimensión habilitada en la evaluación del objeto deaprendizaje.


Figura 31: Ponderar Criterios de Evaluación de OA según Experiencia


3.2.4.4.2 C.U. Evaluar OA según Expertos

Caso de Uso CU-014 Evaluar OA según Expertos

Actores Experto

Tipo Primario

Descripción Despliega un formulario para que el experto califique cada una de lasmétricas habilitadas por el administrador para evaluar el objeto deaprendizaje.

ReferenciasCruzadas

• Este caso de uso incluye CU-013 Ponderar Criterios deEvaluación de OA según Experiencia.

• Este caso es incluido por CU-001 Iniciar Aplicación.

Pre-condición • El usuario se debe haber autenticado en el sistema como experto.• Debe estar marcada al menos una métrica de la capa de expertos

en los parámetros de evaluación del objeto de aprendizaje actual.• Debe estar parametrizada la ponderación de las dimensiones

involucradas en la evalución

Pos-condición El sistema calculará el valor de las métricas correspondientes a la capade expertos con base en las respuestas ingresadas por los usuarios en elformulario.


Figura 32: Evaluar OA según Expertos


3.2.4.5. Matriz de cobertura

La siguiente matriz presenta la relación entre los requerimientos funcionales descritos

anteriormente y los casos de uso propuestos para atenderlos.

Figura 33: Matriz de cobertura de Requerimientos Funcionales vs Casos de Uso.


3.2.5. Implementación de las métricas de la capa de gestión

La capa de gestión del módulo de evaluación propuesto le permite al administrador delrepositorio evaluar hasta seis métricas de calidad para cada objeto de aprendizaje.Aunque se mantuvo el concepto de estas métricas con respecto al modelo tomado comoreferencia, su cálculo varía ligeramente debido a limitaciones técnicas propias de laplataforma DSpace.

El método de cálculo implementado para cada una de las métricas de esta capa sedescribe a continuación.

3.2.5.1. Métrica de completitud

Para evaluar esta métrica el modelo de evaluación de referencia definió 15 campos demetadatos, tomados del estándar IEEE LOM, como necesarios y suficientes para describircompletamente un objeto de aprendizaje. Además estableció una ponderación para cadauno de los campos de metadatos seleccionados de acuerdo a su relevancia en ladescripción de los objetos de aprendizaje. Sin embargo, DSpace incorpora por defecto unesquema de metadatos propio basado en el estándar Dublin Core.

Por lo tanto para conservar la compatibilidad del módulo de evaluación propuesto con losrepositorios existentes, se decidió establecer un mapeo (correlación) entre los campos delestándar y del esquema de metadatos que permita evaluar la característica decompletitud en los objetos de aprendizaje de DSpace. En el mapeo establecido se definióuna ponderación proporcional en cada campo de metadatos Dublin Core que correspondacon su respectivo campo IEEE LOM.

En la Tabla 4 se presenta el mapeo descrito con las ponderaciones propuestas, tanto porel modelo de evaluación como para el módulo de evaluación propuesto, para cada uno delos campos de metadatos involucrados en la evaluación de completitud.


Nombre campoIEEE LOM

Descripción Pesopropuestoen modelo

Pesopropuestoen módulo

Nombre campoDublin Core

General.Title Título 0,15 0,17 dc.title

General.Keyword Palabras Clave 0,14 0,16 dc.subject

General.Description Descripción breve /Resumen

0,12 0,14 dc.description.abstract

LifeCycle.Contribute.Entity

Autor 0,11 0,13 dc.contributor.author

Educational.LearningResourceType

Tipo de RecursoEducativo

0,09 0,11 dc.type

Technical.Format Formato 0,08 N/A N/A

Educational.Context Contexto 0,06 N/A N/A

General.Language Idioma 0,05 0,07 dc.language.iso

Educational.InteractivityType

Tipo de Interactividad 0,04 N/A N/A

Educational.TypicalAgeRange

Rango de EdadTípico

0,03 N/A N/A

General.AgregationLevel

Nivel de Agregación 0,03 N/A N/A

Technical.Location Localización 0,03 0,03 dc.identifier.uri

Rights.Cost Costo 0,03 N/A N/A

LifeCycle.Status Estado 0,02 0,02 dc.description.provenance

Rights.CopyrightandOtherRestrictions

Derechos de autor yotras restricciones

0,02 0,00 dc.rights

N/A Fecha de creacióndel objeto deaprendizaje

N/A 0,12 dc.date.issued

N/A Descripcióndetallada del objetode aprendizaje

N/A 0,02 dc.description

TOTAL 1,00 1,00

Tabla 4: Mapeo de campos LOM - DC


Los campos de metadatos Dublin Core seleccionados para el cálculo de la completitudson, en su mayoría, de obligatorio diligenciamiento por el usuario al momento de subir unnuevo objeto en DSpace. Los demás los determina el sistema cuando culmina el procesode ingreso del objeto al repositorio.

Los dos últimos campos de metadatos, aunque no tienen relación con ninguno de lospropuestos por el modelo de evaluación, fueron seleccionados debido a la relevancia quetiene el conocer la antigüedad de un objeto de aprendizaje y una descripción que ampliedetalles que no están expresados en el resumen general. Los demás campos demetadatos no tienen correspondencia en el esquema de DSpace o, de tenerlos, no seidentificó la forma en que pueden ser diligenciados por el usuario.

Para calcular esta métrica sobre un objeto de aprendizaje dado, el sistema obtiene losvalores de cada uno de los diez campos de metadatos seleccionados. Si el valor obtenidoes diferente de nulo se suma el valor de la ponderación respectiva, de lo contrario seasigna un valor de cero.

El sistema obtiene la suma total de las ponderaciones y despliega en pantalla este valorjunto con un mensaje que explica si el objeto de aprendizaje tiene sus metadatoscompletos a un nivel alto (mayor a 70%), medio (entre 30% y 70%) o bajo (menor a 30%).

3.2.5.2. Métrica de consistencia

Para evaluar esta métrica el modelo de evaluación de referencia, basado en el estándarIEEE LOM, definió un conjunto de valores permitidos para el diligenciamiento de 15campos de metadatos. El cálculo de la métrica se realiza comparando los valoresdiligenciados (en caso que haya) con los permitidos, en caso de que coincidan se asignaun valor de uno, de lo contrario será cero. Al final, el valor de la métrica corresponderá a lasuma de los valores asignados sobre el número total de comparaciones realizadas por elsistema.

Siguiendo este método, para el caso del esquema de metadatos de DSpace, en el módulode evaluación propuesto se encontraron seis campos de metadatos que pueden serdiligenciados acorde con un vocabulario controlado respectivamente. Los camposmencionados corresponden al formato (MIME), el idioma, el tipo y la materia que tratará elrecurso a evaluar de acuerdo a tres clasificaciones aceptadas por DSpace y ampliamenteconocidas (Dewey Decimal Classification -DDC-, Library of Congress Classification -LCC-y Medical Subject Headings -MeSH-).

En algunos campos se permite un número corto de valores, los cuales el sistemacomparará con los valores diligenciados y en caso de que coincidan se asignará un valorde uno, de lo contrario cero. Mientras que en los campos en los que existe una gran


cantidad de valores permitidos, para asegurar que ningún valor quede excluido, sedispuso una lista de los valores permitidos en archivos separados por comas (.csv). Elsistema recorrerá estos archivos cada vez que se evalúe el campo respectivo compararácon los valores diligenciados y en caso de que coincidan se asignará un valor de uno, delo contrario cero. Si alguno de estos campos no está diligenciado, no se realizará lacomparación.

La Tabla 5 presenta los seis campos de metadatos Dublin Core seleccionados paraevaluar la consistencia, con sus valores permitidos o el nombre del archivo donde estosse encuentran. Estos archivos de valores permitidos son proporcionados y deben serdispuestos en el servidor de aplicación de DSpace en la instalación del módulo deevaluación de objetos de aprendizaje.

Nombre campo Dublin Core

Descripción Valores permitidos onombre de archivo de VP

dc.format.mimetype Formato de archivo MIME Home/Allowedvalues/media-types.csv

dc.language.iso Idioma del recurso en_US, en, es, de, fr, it, ja,zh, tr, other

dc.subject.ddc Materia/Tema de estudio del recursosegún la clasificación Dewey DecimalClassification

ddc.csv

dc.subject.lcc Materia/Tema de estudio del recursosegún la clasificación Library ofCongress Classification

lcc.csv

dc.subject.mesh Materia/Tema de estudio del recursosegún la clasificación MedicalSubject Headings

mesh.csv

dc.type Tipo de recurso almacenado en elrepositorio Dspace

Animation; Article; Book;Book chapter; Dataset;Learning Object; Image;Image, 3-D; Map; MusicalScore; Plan or blueprint;Preprint; Presentation;Recording, acoustical;Recording, musical;Recording, oral; Software;Technical Report; Thesis;Video; Working Paper; Other

Tabla 5: Campos DC para evaluar consistencia


Por último, el valor de la métrica de consistencia se obtiene a partir del coeficiente de lasuma de todos los valores asignados entre el número de comparaciones realizadas. Elsistema despliega un mensaje en pantalla que le indica al usuario si los metadatosanalizados son consistentes en un nivel alto (mayor a 70%), medio (entre 30% y 70%) obajo (menor a 30%). En caso que todos los campos seleccionados para la métrica seannulos, la métrica no podrá ser evaluada.

3.2.5.3. Métrica de coherencia

La evaluación de esta métrica es más exhaustiva debido a que relaciona los valores entrealgunos campos de metadatos. A partir del estándar IEEE LOM, el modelo de evaluaciónde referencia definió 15 combinaciones válidas (coherentes) de posibles valores entre 5campos de metadatos y le otorgó unas ponderaciones a cada combinación. La suma totalde los valores de las combinaciones aplicadas se divide entre el número de reglasanalizadas y este coeficiente corresponde con el valor de la métrica.

Para aplicar esta evaluación con el esquema de metadatos de DSpace se tuvieron encuenta los campos Dublin Core correspondientes a idioma, titulo, materia/tema de estudio,resumen, descripción, tipo y formato de archivo. Con estos campos se van a analizar dosreglas básicas de coherencia: el idioma en el que están diligenciados algunos metadatosy el tipo de archivo respecto al tipo de recurso a evaluar en DSpace. Se analizaron variasposibilidades para implementar una solución fiable y modular que permitiera calcular ladistancia semántica entre dos palabras (segundo método de cálculo de la métrica) perono fue posible, por lo que solo se implementó el primer método de cálculo propuesto en elmodelo de evaluación de referencia [2].

Regla de idioma: dc.language.iso

Permite validar que los metadatos diligenciados por el usuario: titulo (dc.title),materia/tema de estudio (dc.subject), resumen (dc.description.abstract) y descripción(dc.description) estén escritos en el idioma seleccionado para el recurso(dc.language.iso), el módulo de evaluación propuesto implementó una librería dedetección de idioma de terceros escrita en Java (com.cybozu.labs.langdetect.Detector).

Esta librería determina el idioma de un texto calculando las probabilidades a partir de lascaracterísticas de ortografía particulares de cada idioma utilizando un filtro bayesianosencillo. Esto le da un 99% de precisión sobre 53 idiomas (incluyendo idiomas asiáticos) yuna detección rápida. Para lograr esto hace uso de unos perfiles de entrenamiento paracada uno de los idiomas, unos archivos ligeros (profiles.sm) que son proporcionados conla instalación. Es una librería de código abierto con licencia Apache 2.0.


Teniendo en cuenta que la librería descrita anteriormente permite detectar cualquiera delos ocho idiomas que pueden ser seleccionados para el recurso en DSpace, para laevaluación de la regla de coherencia correspondiente al idioma el sistema procede de lasiguiente forma:

• Valida que el campo dc.language.iso no sea nulo• Valida que cada uno de los campos dc.title, dc.subject, dc.description.abstract,

dc.description no sean nulos• En los campos validados anteriormente se obtiene el valor correspondiente y se

detecta el idioma en el que están escritos con base en los perfiles de la libreríade detección para textos cortos (que dan una mayor precisión).

• Una vez detectado el idioma del texto diligenciado en cada uno de los campos,este se compara con el valor obtenido del campo dc.language.iso. Si estos soniguales se asigna un uno, de lo contrario cero.

• Por último, el valor de la regla se obtiene a partir del coeficiente de la suma detodos los valores asignados entre el número de comparaciones realizadas.

Regla de formato de archivo vs tipo de recurso: dc.format.mimetype vs dc.type

Permite validar que el formato del archivo subido en el repositorio (dc.format.mimetype)corresponda con el tipo del recurso que se registró en el momento de ingreso a DSpace(dc.type). Se parte de que los tipos de archivos son MIME y están agrupados en cincocategorías: texto, video, imagen, audio y aplicación.

Por otro lado, DSpace permite clasificar los recursos que se suben a los repositoriossegún los siguientes tipos:

• Animation• Article• Book• Book chapter• Dataset• Learning Object• Image• Image, 3-D• Map• Musical Score• Plan or blueprint

• Preprint• Presentation• Recording, acoustical• Recording, musical• Recording, oral• Software• Technical Report• Thesis• Video • Working Paper• Other

Se realizó un estudio de los tipos de formato MIME y su correspondencia con los tipos derecurso que pueden subirse a DSpace. En la Tabla 6 se tiene el mapeo (correlación)propuesto para evaluar la regla de coherencia correspondiente al formato de archivo vstipo de recurso.


Application Audio Image Text Video

Animation X X

Article X X

Book X

Bookchapter

X X

Dataset X X

Image X

Image, 3-D X

LearningObject

X

Map X X

MusicalScore

X

Plan orblueprint

X

Preprint X

Presentation X X X

Recording,acoustical

X

Recording,musical

X

Recording,oral

X

Software X

TechnicalReport

X X

Thesis X

Video X

WorkingPaper

X X

Other

Tabla 6: Mapeo MIME – Tipos de recurso DSpace

Para el cálculo de la regla de coherencia de formato de archivo vs tipo de recurso el


sistema procede de la siguiente forma:

• Valida que los campos dc.format.mimetype y dc.type no sean nulos• Valida que el valor del campo dc.format.mimetype sea un formato de archivo de

tipo MIME y esté dentro de alguna de las cinco categorías definidas• Obtiene el valor del campo dc.type y a partir del formato MIME obtenido

previamente evalúa si la combinación tipo-formato concuerda con las que estándefinidas en la tabla anterior. En caso afirmativo se asigna un valor de uno, de locontrario se le da un valor de cero.

• Por último, el valor de la regla se obtiene a partir del coeficiente de la suma detodos los valores asignados entre el número de comparaciones realizadas.

El valor de la métrica de coherencia corresponde al promedio aritmético de la evaluaciónde ambas reglas o de una de ellas en caso que alguno de los campos dc.language.iso,dc.format.mimetype o dc.type sean nulos. Por último, el sistema despliega en pantallaeste valor junto con un mensaje que le explica si los metadatos analizados soncoherentes entre sí en un nivel alto (mayor a 70%), medio (entre 30% y 70%) o bajo(menor a 30%). La métrica no podrá ser evaluada en caso que todos estos campos seannulos.

3.2.5.4. Métrica de reusablidad

Para evaluar esta métrica el modelo de evaluación seleccionó 4 campos de metadatosIEEE LOM con sus posibles valores y les asignó una ponderación a cada uno de acuerdoa su influencia en el nivel de reusabilidad. A partir de esta información se definieron unasreglas que permiten determinar el nivel de reusabilidad de cada objeto de aprendizaje.

Para replicar este procedimiento con el esquema de metadatos de DSpace se tomaron loscampos Dublin Core dc.type y dc.relation.ispartofseries. Con los valores de estosmetadatos se formularon dos reglas de reusabilidad: una basada en la estructura y otrabasada en la granularidad de los recursos a evaluar.

Regla de estructura: dc.type

La estructura de un recurso educativo digital se puede clasificar dentro de cinco tipos:atómica, colección, en red, jerárquica o lineal. La estructura atómica asegura que elrecurso es autocontenido y por si solo puede ejecutarse y tratar su contenido, por lo quese puede utilizar en varios contextos. Las demás estructuras implican algún nivel derelación con otros recursos que pueden limitar el contexto en el que pueden ejecutarse otener relevancia su contenido.

Teniendo en cuenta la anterior definición del modelo de evaluación y del estudio de los


diferentes tipos de recursos educativos digitales aceptados por DSpace se estableció lacategorización, propuesta en la Tabla 7, de los posibles recursos en DSpace dentro de lasdistintas clases de estructuras. A cada estructura le corresponde una ponderación dereusabilidad, donde 1 seria una reusabilidad total y cero significaría un recurso imposiblede reutilizar fuera de su propio contexto.

Tabla 7: Definición de regla de estructura (Reusabilidad)

A partir de esto, se formularon las siguientes reglas para definir la estructura y, por ende,el nivel de reusabilidad de los recursos en DSpace a partir de su respectivo tipo.

IF (dc.type IS EQUAL TOAnimation

Animation

Atomic 0,9

Learning ObjectImageImage, 3-D

Plan or blueprintPreprintArticle

Collection 0,75

Book chapterMap

Working PaperSoftware

Network 0,5OtherBook

Hierarchical 0,25PresentationThesisDataset

Linear 0,1

Musical Score

Recording, oralVideo

Tipo de Recurso DSpace

Estructura del recurso

Peso en la reusabilidad

Technical Report

Recording, acousticalRecording, musical


Learning ObjectImageImage, 3-DPlan or blueprintPreprint)THEN CONTENT STRUCTURE IS ATOMIC

IF (dc.type IS EQUAL TO ArticleBook chapterMapTechnical ReportWorking Paper)THEN CONTENT STRUCTURE IS COLLECTION

IF (dc.type IS EQUAL TO SoftwareOther)THEN CONTENT STRUCTURE IS NETWORK

IF (dc.type IS EQUAL TO BookPresentationThesis)THEN CONTENT STRUCTURE IS HIERARCHICAL

IF (dc.type IS EQUAL TO DatasetMusical ScoreRecording, acousticalRecording, musicalRecording, oralVideo)THEN CONTENT STRUCTURE IS LINEAR

El valor de la regla se obtiene a partir del coeficiente de la suma de todos los valoresobtenidos en la evaluación de las reglas de estructura entre el número de comparacionesrealizadas.

Regla de granularidad: dc.type y dc.relation.ispartofseries

La granularidad de un recurso educativo digital hace referencia al grado de dependenciade su contenido respecto a otros recursos. Una granularidad baja en un recurso indicaque este es conciso y su contenido se entiende por si solo, por ende tiene una baja


dependencia de otros recursos. Por el contrario, una granularidad alta indica que elrecurso abarca un contenido extenso que podría necesitar complementarse con otrosrecursos para facilitar su comprensión.

Para evaluar esta regla se hace uso del campo Dublin Core dc.relation.ispartofseries elcual indica que el recurso puede ser parte de una colección que trata sobre un tema enespecífico (Por ejemplo, capítulos de un documental sobre la primera guerra mundial o undiapositivas de un curso de cocina). En la Tabla 8 se pueden apreciar las ponderacionesde reusabilidad para cada nivel de granularidad, donde 1 indica un nivel mínimo y 0 unnivel máximo de granularidad.

Nivel de granularidad del recurso Peso en la reusabilidad

Baja 0,9

Media 0,5

Alta 0,1

Tabla 8: Definición de regla de granularidad (Reusabilidad)

A partir de esto, se formularon las siguientes reglas para definir la granularidad y, porende, el nivel de reusabilidad de los recursos en DSpace a partir de su respectivo tipo.

IF (ANY dc.type)AND dc.relation.ispartofseries IS NULLTHEN GRANULARITY IS LOW

IF (dc.type IS EQUAL TO AnimationArticleBookBook chapterMusical ScoreRecording, acousticalRecording, musicalRecording, oralTechnical ReportVideoWorking Paper)AND dc.relation.ispartofseries IS NOT NULLTHEN GRANULARITY IS AVERAGE

IF (dc.type IS EQUAL TODatasetLearning Object


ImageImage, 3-DMapPlan or blueprintPreprintPresentationSoftwareThesis)AND dc.relation.ispartofseries IS NOT NULLTHEN GRANULARITY IS HIGH

El valor de la regla se obtiene a partir del coeficiente de la suma de todos los valoresobtenidos en la evaluación de las reglas de granularidad entre el número decomparaciones realizadas.

Finalmente el valor de la métrica de reusabilidad corresponde al promedio aritmético de laevaluación de ambas reglas o de una en caso que el campo dc.relation.ispartofseries seanulo. Además el sistema despliega un mensaje que le indica al usuario el nivel dereusabilidad del objeto de aprendizaje: alto (mayor a 70%), medio (entre 30% y 70%) obajo (menor a 30%). La métrica no podrá ser evaluada en caso que los campos dc.type ydc.relation.ispartofseries sean nulos.

3.2.5.5. Métrica de disponibilidad

Al igual que en el modelo de evaluación de referencia el cálculo de esta métrica se realizaanalizando la actividad de los enlaces asociados al recurso. Para el caso de DSpace esnecesario tener en cuenta que una característica importante de su núcleo (kernel), es lacreación de un identificador persistente para cada elemento, colección y comunidadalmacenada en Dspace. Tal identificador permite obtener una ubicación confiable en laweb para los recursos almacenados en el repositorio proporcionando enlaces persistentesy estables en el tiempo.

Dspace utiliza el CNRI Handle System como un mecanismo independiente dealmacenamiento y localización para crear y mantener los identificadores únicos (handles).Dspace usa los handles principalmente como un medio para asignar identificadoresúnicos globales a los objetos. Cada sitio web que corre Dspace necesita obtener un“prefijo de handle” único del CNRI, de esta forma se sabe que si se crearonidentificadores con ese prefijo, no van a entrar en conflicto con los identificadores creadosen otros lugares.

En esta versión de DSpace los hanldes se asignan a las comunidades, colecciones yobjetos (items). Para poder aprovechar las funcionalidades del Handle System, los


repositorios basados en Dspace tambien deben correr un Handle Server que puedaaceptar y resolver las solicitudes de resolución entrantes. El código necesario para estoestá incluido en el paquete de código fuente de Dspace. Es responsabilidad del sitiobasado en Dspace mantener la asociación entre un full handle y la comunidad, colecciónu objeto en cuestión.

El módulo de evaluación propuesto valida el código de respuesta HTTP de todos losenlaces almacenados en los campos Dublin Core con alguna URI. Principalmente seevalúa el campo dc.identifier.uri que contiene el identificador global único (handle) que enun ambiente productivo permite una ubicación confiable en la web para el recurso, esteidentificador depende de la activación del servicio de un tercero. DSpace proporcionaunos identificadores por defecto que no son accesibles en la web y, por ende, producenun resultado negativo (cero) en la evaluación de la métrica de disponibilidad.

Si el código de respuesta a la petición HTTP está en el rango de 200 a 299 (lo queindicaría una respuesta exitosa desde la URI) la métrica tendrá un valor de uno, de locontrario se asignará un valor de cero.

3.2.5.6. Métrica de visibilidad

Como se definió en el modelo de evaluación esta métrica está asociada al número devisitas y descargas del recurso respecto al número total de visitas y descargas realizadasen el repositorio.

DSpace hace uso de una infraestructura basada en Apache SOLR para registrar y mostrarpáginas vistas y descargas de archivos. Sin embargo, debido a que la información dedescargas de archivos solo proporciona estadísticas a nivel de objeto (ítem), es imposibleobtener el total de descargas en el repositorio.

Por esta limitación técnica para el cálculo de la métrica de visibilidad, el módulo deevaluación propuesto utiliza exclusivamente los datos correspondientes a las visitas delobjeto a evaluar y al total de visitas del repositorio a través del mecanismo explicado acontinuación:

• Obtiene, del índice SOLR, el número total de visitas del recurso (ítem) a evaluar.• Obtiene, del índice SOLR, el número total de visitas de la colección a la que

pertenece el recurso. Este número representa las visitas realizadas a todos loselementos de tal colección.

• Obtiene, del índice SOLR, el número total de visitas de las demás colecciones delrepositorio. De esta forma se obtiene el número de visitas realizadas a todos loselementos restantes del repositorio.

• Calcula el coeficiente de la suma de las visitas realizadas sobre el recurso entre la


suma del número total de visitas de todas las colecciones del repositorio. El valorde este coeficiente corresponde con el valor de la métrica de visibilidad.

El valor de la métrica corresponde a un número real entre cero (0%) y uno (100%), elgrado de visibilidad del objeto de aprendizaje dentro del repositorio esta clasificado en alto(mayor a 70%), medio (entre 30% y 70%) o bajo (menor a 30%). Donde 100% indica queel objeto es altamente popular en el repositorio (frecuentemente visitado y/o descargado),por el contrario 0% indica que el recurso es descartado por los usuarios del repositorio (noes accedido ni mucho menos descargado).

3.2.6. Implementación de las métricas de la capa de expertos

La capa de expertos del módulo de evaluación propuesto le permite a los docentes,expertos en pedagogía, orientadores o expertos en algún área del conocimiento evaluar,desde su perspectiva, los objetos de aprendizaje almacenados en el repositorio virtual. Enesta capa es posible evaluar hasta ocho métricas de calidad para cada objeto deaprendizaje mediante la aplicación de una encuesta técnica y concisa que también tieneen cuenta el nivel de experticia o bagaje del evaluador.

Se mantuvieron las preguntas, los posibles grados de respuesta para cada una de ellas yel cálculo de las respuestas (Ecuación 9), con respecto al modelo tomado comoreferencia, aunque solo hubo una variación importante en el momento de laimplementación. En el módulo de evaluación propuesto es obligatorio introducir el gradode experiencia del evaluador en cada una de las dimensiones en las que estáninvolucrados los aspectos a evaluar. Por lo que no es posible realizar una evaluación deexpertos sin introducir el respectivo nivel de experiencia para cada una de lasdimensiones involucradas en la evaluación. Para próximas versiones será posible incluirlas características de internacionalización (idiomas) compatibles con DSpace y nuevaspreguntas que permitan evaluar nuevos aspectos de los objetos de aprendizaje.

3.2.7. Implementación de las métricas de la capa de usuarios

La capa de usuarios del módulo de evaluación propuesto le permite a los estudiantes,monitores de curso o usuarios de algún tipo evaluar, desde su perspectiva, los objetos deaprendizaje almacenados en el repositorio virtual. En esta capa es posible evaluar hastasiete métricas de calidad para cada objeto de aprendizaje mediante la aplicación de unaencuesta orientada hacia la experiencia del usuario con el objeto de aprendizajealmacenado en el repositorio.

Se mantuvieron las preguntas, los posibles grados de respuesta para cada una de ellas yel cálculo de las respuestas (Ecuación 10) con respecto al modelo tomado comoreferencia. Para próximas versiones será posible incluir las características de


internacionalización (idiomas) compatibles con DSpace y nuevas preguntas que permitanevaluar nuevos aspectos de los objetos de aprendizaje.

3.2.8. Implementación de la integración del modelo

Para la integración del modelo de evaluación se escogió la alternativa del índice por capaporque presentó mayor facilidad en la implementación. Por ende para el cálculo de losíndices de capa y el índice total de la evaluación se mantuvo el método propuesto en elmodelo de referencia (Ecuación 11 y 12 respectivamente).

Sin embargo para el cálculo del índice total de la evaluación se definieron las siguientesponderaciones de acuerdo a las capas parametrizadas previamente para cadaevaluación. Estas ponderaciones están definidas en la Tabla 9.

Capa de Gestión Capa de Expertos Capa de Usuarios

Caso 1 (Total = 100%) 50% 30% 20%

Caso 2 (Total = 100%) 60% 40%

Caso 3 (Total = 100%) 70% 30%

Caso 4 (Total = 100%) 60% 40%

Caso 5 (Total = 100%) 100%

Caso 6 (Total = 100%) 100%

Caso 7 (Total = 100%) 100%

Tabla 9: Ponderaciones para calcular índice total por capa

3.3. Especificación estructural del producto

3.3.1. Modelo conceptual de negocio

A partir de la especificación funcional descrita en el apartado anterior surgen algunostérminos relevantes que se explican a continuación:

• Métrica: Es la unidad básica del modelo de evaluación y hace referencia a lascaracterísticas deseables en los objetos de aprendizaje. Son 21 y estándistribuidas entre las seis dimensiones y tres capas del modelo. Una mismamétrica (en apariencia) puede aparecer en más de una capa sin embargo suconcepto y, por ende, su cálculo varían completamente.


• Dimensión: Es el conjunto de métricas que permite evaluar alguno de los aspectosque deben ser considerados a la hora de producir, utilizar y administrar un objetode aprendizaje en un repositorio de recursos educativos digitales para aseguraruna efectiva transmisión de conocimiento. Teniendo en cuenta esto, el modelo deevaluación definió las dimensiones de: contenido, contextual, educativa, estética,funcional y de metadatos.

• Capa: Hace referencia al conjunto de métricas y dimensiones que permitenevaluar los objetos de aprendizaje desde la perspectiva de uno de los tres distintosactores (stakehokders) de un repositorio de recursos educativos digitales:administrador, experto o estudiante.

• Administrador: Es el usuario que, como su nombre lo indica, administra elrepositorio de recursos educativos digitales y el usuario final de la aplicaciónpropuesta. El prototipo le permite establecer los parámetros de evaluación paracada objeto de aprendizaje, evaluarlos desde una perspectiva técnica y generar (yvisualizar) un reporte de resultados de cada evaluación.

• Experto: Es el usuario (por lo general docentes) que, siendo experto en alguna delas dimensiones, otorga un concepto especializado de los aspectos a evaluar en elobjeto de aprendizaje. El concepto de estas personas es importante a tener encuenta para determinar que tan bien concebido fue el objeto por quienes loprodujeron y si este es riguroso para cumplir los propósitos educativos.

• Estudiante: Es el usuario final de los objetos de aprendizaje y, por lo tanto, aportala perspectiva idónea para determinar si estos son útiles, fáciles de entender einteractivos. El concepto de estos usuarios permitirá determinar si el objeto esefectivo a la hora de transmitir los conocimientos para los que fue producido.

• Reporte de resultados: Es la salida final de la aplicación propuesta, ya que brindaun resumen de la evaluación realizada sobre cada objeto de aprendizaje. Estereporte contiene los resultados por métrica, los índices por capa y el índice generalde cada objeto. A partir de estos datos, el administrador podrá tomar decisionessobre el nivel de calidad de los objetos y las medidas necesarias paraconservarlos, mejorarlos o depurarlos.

Los anteriores términos y la relación que existe entre ellos es representada en el modeloconceptual de negocio presentado en la Figura 34.

CAPITULO 3. DESCRIPCIÓN DE LA SOLUCIÓN 102


Figura 34: Modelo conceptual de negocio


3.3.2. Diseño de clases y objetos

De acuerdo con el modelo conceptual descrito anteriormente, de las consideracionespresentadas respecto a la implementación de las evaluaciones de cada una de las capas,y de la integración de estas para calcular un índice total y dar un puntaje al objeto deaprendizaje, se planteó el siguinete diagrama de clases y su respectivo diccionario.

3.3.2.1. Diagrama de clases

A continuación se presenta el diagrama de clases de la solución desarrollada. Esimportante aclarar que las clases consideradas fueron las del núcleo de la solución, esdecir, el modelo en una arquitectura MVC, y son las que hacen parte del proyectoadditions, mientras que las clases y artefactos que hacen parte de jspui, y que constituyela vista y el controlador en MVC, no se incluyen en este diagrama.

Dentro del diagrama se puede observar una relación jerárquica para la realización deevaluaciones administrativas que está basada en el patrón comando, constituido por unainterfaz comando y seis implementaciones o comandos concretos que representan cadauna de las seis métricas que se pueden evaluar por parte del administrador, esta decisiónde diseño permite agregar, eliminar o remplazar las métricas administrativas, másconcretamente la forma como estas se realizan, de forma transparente fomentando laextensión sobre la modificación (principio open-close). Aunque la estructura difiererespecto a la de un patrón comando convencional, especialmente porque el comandoconcreto y el realizador de la operación son el mismo objeto, fue una adaptación a lasnecesidades del proyecto.

Por otro lado, las operaciones a base de datos se hacen a través de una serie de clasesutilitarias (Layer, Dimension, Metric, AssessParam), que además de representarrelaciones del modelo de datos descrito anteriormente, contienen una serie de métodosestáticos para recuperar, eliminar, actualizar y crear (operaciones CRUD) dichasrelaciones en base de datos. Estas clases son utilizadas principalmente por las clasesdenominadas “helpers” en el modelo. Éstas últimas constituyen el punto de acceso almódulo de evaluación.

En el diagrama se omiten los métodos accesores y modificadores (setters y getters)convencionales de los atributos de las clases, a no ser que incluyan alguna lógicaadicional a la usual; en el caso de la interfaz del patrón comando se da por sentado quecada una de las clases concretas (comandos concretos) implementa el método y seomite. Además el modelo no muestra las interacciones con DSpace, pero el uso del APIde DSpace fue esencial en la elaboración de esta solución, especialmente el API depersistencia y de contenido.



Figura 35: Diagrama de clases


3.3.2.2. Diccionario de Clases

A continuación se presenta descripción de las características lógicas de atributos ymétodos, con el fin de dar precisión sobre los datos que se manejan en el sistemaevitando malas interpretaciones o ambigüedades, además una descripción de la razón deexistencia de la clase. En algunas descripciones de este diccionario, se hace mención aentidades del modelo de datos que se describe en la sección siguiente.


Nombre: StartAssessHelper

Descripción: Está clase contiene métodos utilitarios para iniciar la evaluación y realizarla parametrización de la evaluación.

Capa de métodos

Visibilidad Nombre TipoParámetros

Semántica Retorno

public getDimensions -Context: contextoDspace.-List: ListaAssessParams -int: identificadorde la capa.

Devuelve lista con losnombres de lasdimensiones que seencuentran en la lista deAssessParam para lacapa dada

Vector: Lista deStrings con losnombres de lasdimensiones

public getDimensions -Context: contextoDspace.

Recupera la lista dedimensiones de la basede datos

Vector: Lista deobjetos tipoDimension

public getMetrics -Context: contextoDspace.-List: ListaAssessParams -int: identificadorde la capa

Devuelve lista con losnombres de las métricasque se encuentran en lalista de AssessParampara la capa dada

Vector: Lista deStrings con losnombres de lasmétricas

public getLayers -Context: contextode Dspace

Recupera las capasde la base de datos.

Vector: Lista deString con losnombres de lascapas

public verifyCheckedDimensions

-Context: contextoDspace.-Vector: Lista dede valoresseparados porcoma coninformación de lacapa, la dimensióny la métrica.-int: identificadorde la capa.

Retorna lista de Stringscon los nombres de lasdimensiones en la listade valores separadospor comas

Vector: Lista deStrings connombre de lasdimensiones.


Nombre: AdminAssessHelper

Descripción: Realiza las operaciones del módulo de evaluación relacionadas con la capaadministrativa, dentro de las que se encuentra visualización de resultados globales, evaluación delas métricas propias de la capa.

Capa de atributos

Visibilidad Nombre Tipo Semántica Dominio devalores

private criteriaCommand AdminAssessmentCommandInterface

Almacena unainstancia de uncomando concreto, esdecir, de unainstancia de una claseque implementa lainterfaz

Posibles objetosde tipoAdminAssessmentCommandInterface

Capa de métodos

Visibilidad Nombre Tipo Parámetros Semántica Retorno

public assess - String: nombre dela evaluación quese va a realizar- DSpaceObject:ítem del repositorio- Context: contextoDSpace

Realiza la evaluaciónindicada sobre el ítemque se pasa

AssessResult:Objeto con lainformaciónresultado de laevaluación

public getAssessmentResults

- Int: id del item- Context: contextode DSpace

Retorna la informaciónsobre el resultado dela evaluación.

Vector: Lista deStrings convalores separadospor coma

public calculateLayerIndex

- Vector: Lista deAssessParam delítem- int: identificadorcapa

Calcula el índice ovalor ponderado de unítem para una capadada.

double: el puntajefinal para la capa.

public calculateTotalIndex - double: índicecapa administrativa- double: índicecapa expertos- double: índicecapa estudiantes

Calcula el índice ovalor final de un objeto

double: puntajefinal.


Nombre: ExpertAssessHelper

Descripción: Contiene operaciones necesarias para realizar las acciones relacionadas con laevaluación de la capa de expertos.

Capa de atributos


private itemId int Identificador del ítemque se evalúa

Valores enterospositivos

private oldDimWeights Map Mapa con informaciónde las dimensiones y elpeso dado por elexperto antes de quese actualice

Pares,compuestos poridentificador de ladimensión y elpeso, un valorentero entre 1 y 5

private dimWeights Map Mapa con informaciónde las dimensiones y elpeso dado por elexperto después deque se actualice

Pares,compuestos poridentificador de ladimensión y elpeso, un valorentero entre 1 y 5

private metricsValues Map Mapa para mantener enmemoria valores de lasmétricas antes de laactualización

Pares,compuestos poridentificador de lamétrica y supuntaje, undecimal entre 0 y1.

Capa de métodos


Semántica Retorno

public ExpertAssessHelper

int: identificadordel ítem que seevalúa

Constructor encargadode iniciar variablesantes de realizar laevaluación

NA

public setExpertWeight - Context: contextoDspace Map: mapa dedimensiones ypeso dado a cadadimension

Actualiza o agrega elpeso dado por unexpertos a lasdimensiones

void


Nombre: ExpertAssessHelper

public setExpertAssessment

- Context: contextoDspace - Map: mapa demétricas y lista devalores dado paracada métrica

Actualiza o agrega elpuntaje dado por unexperto a las métricas

void

* Esta clase también incluye los métodos accesores y modificadores para cada uno de losatributos

Nombre: StudentAssessHelper

Descripción: Contiene operaciones necesarias para realizar las acciones relacionadas con laevaluación de la capa de estudiantes.

Capa de métodos


public setExpertAssessment

Context: contextoDspace Map: mapa demétricas y lista devalores dado paracada métrica

Actualiza o agrega elpuntaje dado por unestudiante a las métricas

void

Nombre: AdminAssessmentCommandInterface

Descripción: Interfaz para la evaluación de métricas de la capa de administradores. Hace elpapel de interfaz del patrón comando.

Capa de métodos


public executeAssessment

- DSpaceObject: objetodspace sobre el que seaplica la evaluación- Context: contextoDspace

Ejecuta laevaluación sobre elobjeto dado. Puedearrojar unaexcepción de tipoAdminAssessmentException cuandoalgo sale mal en laejecución de laevaluación.

AssessParam:objeto coninformación delresultado de laevaluaciónadministrativa


Nombre: AssessResult

Descripción: Encapsular información sobre el resultado de una evaluación administrativa

Capa de atributos


private task String Nombre de la métrica “Coherence”,“Availability”, etc

private score double Puntaje obtenido Valor decimalentre 0 y 1

private handle String Identificador del ítemevaluado

Cadena de texto

private status String Identificador del resultado “Success”,“Failed”

private result String Descripción del resultadoobtenido

Cadena de texto

private isSuccess boolean Sí se logró o no efectuarla evaluación

true, false

Capa de métodos


public AssessResult String: taskdouble: scoreString: habdleString: statusString: resultboolean: isSuccess

Constructor que crea unnuevo objeto asignandolos valores dados a loscorrespondientesatributos de la clase

NA



Nombre: AdminAssessmentException

Descripción: Excepción personalizada que se utiliza para indicar que algo fue mal con laevaluación administrativa

Capa de métodos


Semántica Retorno

public AdminAssessmentException

String: mensajepersonalizado

Constructor quepermite agregar unmensajepersonalizado, a laexcepción

NA

Nombre: ReusabilityAssessCommand

Descripción: Comando concreto que se encarga de realizar la evaluación administrativa de lamétrica de reusabilidad

Capa de atributos


private HIGHT double Constante con valor quese le deben asignar aobjetos con altagranularidad

0.1

private AVERAGE double Constante con valor quese le deben asignar aobjetos con mediagranularidad

0.5

private LOW double Constante con valor quese le deben asignar aobjetos con altagranularidad

0.9

private ATOMIC double Constante con el valorque se le deben asignara objetos con estructuraatómica

0.9

private COLLECTION double Constante con el valorque se le deben asignara objetos con estructurade collección

0.75


Nombre: ReusabilityAssessCommand

private NETWORK double Constante con el valorque se le deben asignara objetos con estructurade red

0.5

private HIERCAL double Constante con el valorque se le deben asignara objetos con estructurajerárquica

0.25

private LINEAR double Constante con el valorque se le deben asignara objetos con estructuraleneal

0.1

Capa de métodos



- DSpaceObject:objeto dspace sobreel que se aplica laevaluación- Context: contextoDspace

Implementación delmétodo descrito enAdminAssessmentCommandInterface para laevaluación dereusabilidad

AssessmentResult

private checkGranularityRule

String: tipo decontenido

Determina lagranularidad de acuerdocon el tipo de contenidopasado

Double: valorrepresentando lagranularidad

private checkStructureRule

String: tipo decontenido

Determina la estructurade acuerdo con el tipo decontenido pasado

double: valorrepresentando laestructura

Nombre: CompletenessAssessCommand

Descripción: Comando concreto que se encarga de realizar la evaluación administrativa de lamétrica de completitud

Capa de atributos


private TITLE double Constante con el valor quese le debe sumar si elobjeto tiene título

0.17

private SUBJECT double Constante con el valor quese le debe sumar si elobjeto tiene asignatura

0.16


Nombre: CompletenessAssessCommand

private ABSTRACT double Constante con el valor quese le debe sumar si elobjeto tiene “abstract”

0.14

private AUTHOR double Constante con el valor quese le debe sumar si elobjeto tiene autor

0.13

private DATE double Constante con el valor quese le debe sumar si elobjeto tiene fecha

0.12

private TYPE double Constante con el valor quese le debe sumar si elobjeto tiene tipo

0.11

private LANG double Constante con el valor quese le debe sumar si elobjeto tiene lenguage

0.07

private DESCR double Constante con el valor quese le debe sumar si elobjeto tiene descripción

0.05

private LOCATION double Constante con el valor quese le debe sumar si elobjeto tiene identificador porURI

0.03

private STATUS double Constante con el valor quese le debe sumar si elobjeto tiene procedencia

0.02

Capa de métodos



- DSpaceObject:objeto dspace sobreel que se aplica laevaluación- Context: contextoDspace

Implementación del métododescrito enAdminAssessmentCommandInterface para laevaluación de completitud

AssessmentResult


Nombre: ConsistencyAssessCommand

Descripción: Comando concreto que se encarga de realizar la evaluación administrativa de lamétrica de consistencia

Capa de atributos


private log Logger Atributo que permiteenviar mensajes usandoel sistema de logs de laplataforma. Se utilizaporque la métrica implicael manejo deexcepciones de las quese debe dejar traza enlos logs

Posibles objetosde tipo Logger

Capa de métodos



- DSpaceObject:objeto dspacesobre el que seaplica la evaluación- Context: contextoDspace

Implementación delmétodo descrito enAdminAssessmentCommandInterface para laevaluación deconsistencia

AssessmentResult

private compareCSValues

String: ruta alarchivo con losregistros decomparaciónString: valor que sedesea comparar

Compara el registro convalores en el archivoCSV pasado, buscandoun registro igual paravalidar el valor.

boolean: si elcampo tiene unigual en el archivoo no


Nombre: VisibilityAssessCommand

Descripción: Comando concreto que se encarga de realizar la evaluación administrativa de lamétrica de visibilidad

Capa de atributos


private log Logger Atributo que permite enviarmensajes usando elsistema de logs de laplataforma. Se utilizaporque la métrica implica elmanejo de excepciones delas que se debe dejar trazaen los logs


Capa de métodos



- DSpaceObject:objeto dspacesobre el que seaplica la evaluación- Context: contextoDspace

Implementación delmétodo descrito enAdminAssessmentCommandInterface para laevaluación de visibilidad

AssessmentResult

Nombre: AvailabilityAssessCommand

Descripción: Comando concreto que se encarga de realizar la evaluación administrativa de lamétrica de disponibilidad

Capa de métodos



- DSpaceObject: objetoDSpace sobre el quese aplica la evaluación- Context: contextoDSpace

Implementación delmétodo descrito enAdminAssessmentCommandInterface para laevaluación dedisponibilidad

AssessmentResult

private getURLs -Item: Objeto deDSpace

Obtiene las URLs queel objeto puedaobtener en susmetadatos

List: lista destrings con lasURLsencontradas


Nombre: AvailabilityAssessCommand

private checkURL -String: URL Obtiene la respuestaHTTP de la URL dada,y con base a estodetermina si la URLresponde o no.

boolean:devuelve si laURL responde ono.

private getResponseStatus

-String: URL Devuelve el código deestado HTTP

String: códigorespuesta

Nombre: CoherenceAssessCommand

Descripción: Comando concreto que se encarga de realizar la evaluación administrativa de lamétrica de coherencia

Capa de atributos


private log Logger Atributo que permiteenviar mensajesusando el sistema delogs de la plataforma.Se utiliza porque lamétrica implica elmanejo deexcepciones de las quese debe dejar traza enlos logs


Capa de métodos



- DSpaceObject:objeto dSpace sobre elque se aplica laevaluación- Context: contextoDSpace

Implementación delmétodo descrito enAdminAssessmentCommandInterface para laevaluación decoherencia

AssessmentResult

private init Carga los archivosque necesita la libreríautilizada para detectaridiomas en mensajes


Nombre: CoherenceAssessCommand

private detect String: texto que sedesea analizar

Haciendo uso del APIde la librería externapara la detección deidiomas, determina elidioma del mensajedado.

String: idioma delmensaje dado

private searchFormaType

String: campometadatos con el tipoMIME

Revisa por el formatomultimedia del campodado, haciendo uso dearchivo CSV con tiposMIME válidos y susrespectivos formatos

String: formatodel tipo MIME

Nombre: Layer

Descripción: Representa una capa del modelo, y agrupa métodos estáticos para realizaroperaciones a base de datos relacionadas con las capas y los índices (resultados consolidadosde las evaluaciones ) del modelo

Capa de atributos


private id int Identificador de la capa Valores enterospositivos

private name String Nombre de la capa “Administrator”,“Expert”, “Student”

Capa de métodos


Semántica Retorno

public Layer - Context: contextoDSpace- TableRow: Filadel API depersistencia deDSpace

Constructor que crea unnuevo objeto a partir delobjeto TableRowotorgado

NA

public findAllLayers - Context: contextoDSpace

Recupera las capas dela base de datos

Layer[]: Arreglo decapas


Nombre: Layer

public addAssessmentIndexes

- Context: contextoDSpace- int: identificadordel ítem- double: índice dela capa deadministradores- double: índice dela capa deexpertos- double: índice dela capa deestudiantes- double: índicetotal

Agrega los índicesconsolidados por capa,y el índice total para elítem dado en la base dedatos

void

public updateAssessIndexes

- Context: contextoDSpace- double: índice dela capa deadministradores- double: índice dela capa deexpertos- double: índice dela capa deestudiantes- double: índicetotal- int: identificadordel ítem

Actualiza los índicesconsolidados por capa,y el índice total para elítem dado en la base dedatos

void

public deleteAssessIndexes

- Context: contextoDSpace- int: identificadordel ítem

Elimina el registro en larelaciónAssessment_Historypara el ítem dado, esdecir, elimina losíndices consolidados dela base de datos

int: número defilas afectadas (0o 1)

public findIndexByItem - Context: contextoDSpace- int: identificadordel ítem

Recupera elidentificador de laentidadAssessment_Historypara el ítem dado

Int: identificadordel registro de losíndices para elítem



Nombre: Dimension

Descripción: Representa una dimensión del modelo, y agrupa métodos estáticos para realizaroperaciones a base de datos relacionadas con las dimensiones del modelo y los pesos que losadministradores y expertos le dan a estas (parametrización).

Capa de atributos


private id int Identificador de ladimensión

Enteros positivos

private name String Nombre de la dimensión “Content”,“Contextual”,“Educational” ,“Esthetic”,“Functional”,“Metadata”

private layerId int Identificador de la capa ala que pertenece ladimensión

Entero positivo

Capa de métodos


public Dimension - Context: contextoDSpace- TableRow: Fila delAPI de persistenciade DSpace


NA

public findByLayer Context: contextode DSpaceString: nombre de lacapa

Recupera lasdimensiones asociadas auna capa

Dimension[]:Colección dedimensionespertenecientes ala capa.

public findNameByID - Context: contextoDSpace- int: identificador dela dimensión

Recupera de base dedatos el nombre de ladimensión cuyoidentificador es dado.

String: nombredimensión.

public addDimensionWeight

- Context: contextoDSpace- int: identificador dela dimensión- int: identificador dela capa- int: identificadordel ítem de DSpaceString: peso comocadena de texto

Agrega el peso dado porel administrador alregistro correspondientea los valores pasados.

void


Nombre: Dimension

public updateExpertWeight

- Context: contextoDSpace- int: identificador dela base de datos delregistro de laparametrización- int: identificadordel ítem de DSpace- int: peso dado

Actualiza el peso dadopor el experto al registrocorrespondiente al ítem yel id pasados

void

public deleteDimensionWeighting

- Context: contextoDSpace-int: identificador dela capa-int: identificador dela dimensión-int: identificador delítem

Elimina el registro de labase de datos en larelaciónDimension_Weigthingpara los parámetrosdados, es decir, borra lospesos dados por eladministrador y elexperto

Int: número defilas afectadas (0o 1)

public deleteAssessWeights

- Context: contextoDSpaceint: del ítem deDSpace

Elimina los pesos dadosa las dimensionesasociadas a este ítem

int: número defilas afectadas(0 o1)

public deleteWeightsById

- Context: contextoDSpace-int: identificador delítem -int: identificador dela capa

Elimina el registro de labase de datos en larelaciónDimension_Weigthingpara el ítem y la capadados

int: número defilas afectadas


Nombre: Metric

Descripción: Representa una métrica del modelo, y agrupa métodos estáticos para realizaroperaciones a base de datos relacionadas con las métricas y los resultados de las evaluaciones

Capa de atributos


private id int Identificador de lamétrica

Enteros positivos


Nombre: Metric

private name String Nombre de la métrica “Accessibility”,”Accuracy”,”Availability”,”Coherence”,”Completeness”,”Consistency”, ”Easeto use”,”Effectiveness”,”Motivation”,”Potential”,”Effectiveness”,”Relevance”,”Reusability”, ”Rigorand Relevance”,”Visibility”, ”VisualDesign”

Capa de métodos


public Metric - Context: contextoDSpace- TableRow: Fila delAPI de persistenciade DSpace

Constructor que creaun nuevo objeto apartir del objetoTableRow otorgado

NA

public findByLayer - Context: contextoDSpace- String: Layer name

Recupera de base dedatos la lista demétricas asociados ala capa dada

Metric[]: Colección demétricas

public findNameByID - Context: contextoDSpace- int: identificador dela métrica

Retorna el nombrede la métrica para elidentificador dado

String: nombremétrica

public addAssessMetric

- Context: contextoDSpace- int: identificador dela métrica- int: identificador delítem

Agrega un registro ala entidadAssessment_Resultpara la métrica daday el ítem otorgado

void

public deleteAssessMetric

- Context: contextoDSpace- int: identificador dela métrica- int: identificador delítem

Elimina el registro dela entidadAssessment_Resultcorrespondiente alos identificadores dela métrica e ítempasados

void


Nombre: Metric

public addAssessValue

- Context: contextoDSpace- double: valor dadoa la métrica- String: nombre dela métrica- int: identificador dela capa- int: identificador delítem

Asigna el valor dadoen el registro de laentidadAssessment_Resultcorrespondiente alos identificadorespasados

void

public deleteAssessValues

- Context: contextoDSpace- int: identificador delítem

Elimina todos losregistros de laentidadAssessmentResultasociados al ítem

int: número deregistros afectados



Nombre: AssessParam

Descripción: Clase que encapsula la información relevante sobre la evaluación y sus resultados,dentro de lo que se incluye los pesos dados por el experto y el administrador, además el valordado a la métrica

Capa de atributos


private assessmentMetricId

int Identificador de lamétrica

Enteros positivos

private itemId int Identificador del ítem Enteros positivos

private dimWeightId int Identificador del registroDimension_Weigthing

Enteros positivos

private layerId int Identificador de la capa Enteros positivos

private dimId int Identificador de ladimensión

Enteros positivos

private expWeight int Peso dado por el experto Npumero enteroentre 1 y 5

private metricValue String Valor dado a la métrica Valor decimalentre 0 y 1

private admWeight String Peso dado por eladministrador

Valor decimalentre 0 y 100

Capa de métodos


public AssessParam - Context: contextoDSpace- TableRow: Fila delAPI de persistenciade DSpace


NA

public findParam - Context: contextoDSpace- int: identificadordel ítem

Recupera la lista deAssessParam asociadosa un ítem

Vector: lista deobjetosAssessParam

public findParam - Context: contextoDSpace- int: identificadordel ítem- int: identificador dela capa

Recupera la lista deAssessParamcorrespondientes a unítem y la capa dada

Vector: lista deobjetosAssessParam



3.3.3. Diseño de la Base de Datos

El modelo relacional propuesto a continuación permite asegurar la persistencia de losdatos concernientes a la definición, parametrización y ejecución de la evaluación deobjetos de aprendizaje, además de la generación del reporte de resultados. Todos estosdatos servirán tanto de insumo como de salida para los propósitos del módulo deevaluación propuesto.

Al realizar el diseño del modelo relacional se persiguen dos objetivos fundamentales:

• Conseguir el mayor acoplamiento posible con el modelo de datos ya existente enDSpace, de tal forma que la puesta en operación del modelo relacional propuestopara el funcionamiento de la extensión no produzca traumatismos ni fallas en laBase de Datos (PostgreSQL u Oracle).

• Hacerlo en conformidad con las propiedades ACID, con el fin de asegurar laintegridad de los datos.

Para conseguir los dos propósitos descritos anteriormente se hizo uso de la llave“ITEM_ID” de la tabla ITEM en el modelo de datos de DSpace, esta llave permite ligar laevaluación de cada una de las métricas disponibles a los recursos educativos digitalesalmacenado en DSpace. El modelo de datos resultante es implementado en un script DDLpara la Base de Datos (PostgreSQL u Oracle) que debe ser ejecutado en elcorrespondiente servidor en el momento de la instalación de la extensión propuesta. En lafigura 36 se presenta el modelo relacional obtenido.



Figura 36: Modelo relacional


3.3.3.1. Diccionario de datos

Reglas Generales

• Se utilizarán exclusivamente caracteres alfanuméricos de la lengua inglesa. Porende se prohibe el uso de caracteres de puntuación o simbolos especiales.

• Para mantener la cohesión, el nombre elegido para las tablas y relaciones debedescribir de la mayor forma posible el tipo de registros que almacena.

• Los nombres no deben abreviarse, salvo que por necesidad específica debaespecificarse más de una palabra en los mismos.

Reglas de nomenclatura para tablas

• Los nombres deben especificarse en singular y acorde a las reglas generales.• En el caso de las tablas que se relacionan específicamente con otra tabla (ej:

tablas tipo, entidades débiles, entre otras), esta relación debe quedar expresadaen el nombre. Para ello se seguirá la notación del modelo de datos de DSpacecomo por ejemplo “LAYER2DIMENSION”.

• Las tablas de relación (objetos asociativos, representan relaciones de muchos amuchos) deben nombrarse utilizando los nombres de las tablas intervinientes,siguiendo un orden lógico de frase.

Reglas de nomenclatura para campos clave

• Toda tabla debe tener al menos un campo clave.• El nombre del campo clave debe notarse así: nombre de la tabla en singular +

“_ID” (para claves no compuestas).• Los campos clave siempre deben ubicarse al inicio de la definición de cada tabla.• Las claves compuestas sólo deben utilizarse en caso de contar con tablas de

relación o entidades débiles• Toda relación entre tablas debe implementarse mediante claves foráneas que

aseguren la integridad referencial de la base de datos. Estos deben nombrarse dela misma manera que los campos clave (usando el nombre de la tabla a la quehacen referencia).

Reglas de nomenclatura para los demás campos

• Todo campo que represente un nombre o descripción será definidoinmediatamente después de los campos clave y se notará así: nombre de la tablaen singular + “_NAME”.

• Los campos correspondientes a llaves foráneas (foreing keys) deben nombrarsede la misma manera que los campos clave (usando el nombre de la tabla a la quehacen referencia).


ASSESSMENT_METRIC

Campo Descripción Tipo de dato Dominio Requerido PK FK UK

Integer X X X

LAYER_ID Integer X X

DIMENSION_ID Integer X X

CRITERIA_ID Integer X X

Descripción: Es una tabla de referencia que contiene todas las posibles combinaciones de capas, dimensiones y criterios definidas por el modelo de evaluación. A cada combinación se le denomina métrica.

ASSESSMENT_METRIC_ID

Identificador de métrica

Números enteros positivos

Identificador de capa


Identificador de dimensión


Identificador de criterio


ASSESSMENT_RESULT


Integer X X X

Integer X X

ITEM_ID Integer X X

METRIC_VALUE Real Número real positivo X

Descripción: Contiene los valores de todas las métricas del modelo de evaluación por item que han sido parametrizadas y ejecutadas.

ASSESSMENT_RESULT_ID

Identificador de resultado


ASSESSMENT_METRIC_ID

Identificador de métrica


Identificador del item


Valor de la métrica


ASSESSMENT_HISTORY


Integer X X X

Integer X X X

ITEM_ID Integer X X

ADMIN_INDEX Real Número real positivo

EXPERT_INDEX Real Número real positivo

USER_INDEX Real Número real positivo

ASSESS_VALUE Real Número real positivo X

Descripción: Contiene los valores de todos los índices del modelo de evaluación por item obtenidos a partir de las métricas evaluadas previamente.

ASSESSMENT_HISTORY_ID

Identificador de resultado histórico


ASSESSMENT_RESULT_ID

Identificador de resultado




Indice de capa administradorIndice de capa expertoIndice de capa estudianteValor final de la evaluación


DIMENSION_WEIGHTING


Integer X X X

LAYER_ID Integer X X


ITEM_ID Integer X X

ADMIN_WEIGHT Real X

EXPERT_WEIGHT Integer

Descripción: Contiene los valores de todas las ponderaciones dadas por el administrador y (dado el caso) por los expertos para cada dimensión correspondiente en cada evaluación.

DIMENSION_WEIGHTING_ID

Identificador de ponderación de dimensión


Identificador de capa






Ponderacion dada por el administrador

Número real positivo

Ponderación dada por el experto

Números enteros [1,5]

DIMENSION


DIMENSION_ID Integer X X X

DIMENSION_NAME String X X

Descripción: Contiene las dimensiones que conforman el modelo de evaluación. Para evaluar un objeto una capa debe tener al menos una dimensión.



Nombre de la dimensión

Cadena de caracteres

CRITERIA


CRITERIA_ID Integer X X X

CRITERIA_NAME Nombre del criterio String X X

Descripción: Contiene los criterios que conforman el modelo de evaluación. Para evaluar un objeto, una dimensión debe tener al menos un criterio.

Identificador de criterio

Números enteros positivosCadena de caracteres


LAYER


LAYER_ID Identificador de capa Integer X X X

LAYER_NAME Nombre de la capa String X X

Descripción: Contiene las capas que conforman el modelo de evaluación. Para evaluar un objeto, la evaluación debe realizarse al menos con una capa.

Números enteros positivosCadena de caracteres

LAYER2DIMENSION


LAYER_ID Identificador de capa Integer X X


Descripción: Tabla de ruptura que contiene todas las capas con sus respectivas dimensiones. Una dimensión puede pertenecer a varias capas y varias capas pueden tener la misma dimensión según el modelo de evaluación.





3.3.4. Mapa de navegación

Figura 37: Mapa de navegación del módulo


3.4. Especificación dinámica del producto

A continuación se presentan los diferentes diagramas de secuencia del productoimplementado.


Figura 38: Diagrama secuencia iniciar aplicación



Figura 39: Diagrama secuencia parametrización de evaluación



Figura 40: Diagrama secuencia parametrizar evaluación OA



Figura 41: Diagrama secuencia evaluar completitud



Figura 42: Diagrama secuencia evaluar consistencia



Figura 43: Diagrama secuencia evaluar disponibilidad



Figura 44: Diagrama secuencia evaluar OA según estudiantes



Figura 45: Diagrama de secuencia ponderar criterios expertos



Figura 46: Diagrama de secuencia evaluar OA según expertos



Figura 47: Diagrama de secuencia consolidar resultados

4. Resultados, conclusiones y trabajo futuro

4.1. Metodología y desarrollo del proyecto

Para el desarrollo de este prototipo se planeó seguir la metodología ágil SCRUM,estableciendo unos sprints y unos objetivos específicos para cada sprint. Debido a la faltade recursos suficientes (personas, equipos, espacios, herramienta de gestión documental)no fue posible implementar esta metodología, por lo cual se decidió usar el ProcesoUnificado (UP) como modelo de proceso.

La primera fase del proyecto correspondió a la conceptualización del dominio delproblema y, a partir de ahí, poder empezar a esbozar una posible solución. Estocomprendió un estudio profundo del modelo de evaluación de referencia y de laplataforma de código abierto seleccionados. Al estudiar esto, el equipo pudo comprenderlos conceptos importantes del modelo (capas, dimensiones, métricas) y la relación entreellas. Una vez comprendida la parte funcional y lo que se busca obtener aplicando laevaluación sobre los objetos, se buscó dentro de la arquitectura de la plataforma decódigo abierto aquellas oportunidades de integración disponibles que permitieranincorporar un módulo de evaluación de objetos de aprendizaje sin afectar lacompatibilidad ni las funcionalidades existentes. De esta forma se encontró que DSpacepermite extender sus funcionalidades por medio de los recubrimientos de Maven (MavenOverlays).

La segunda fase del proyecto consistió en identificar las herramientas tecnológicasproporcionadas por la plataforma que facilitaran incorporar las funcionalidades requeridas.Siguiendo esta filosofía, se encontró que el esquema de metadatos propio de laplataforma nos permitía conciliar los objetivos trazados: obtener los metadatos necesariospara el cálculo de las métricas técnicas propuestas en el modelo de evaluación ymantener la compatibilidad de la propuesta con versiones existentes y en uso de laplataforma (hasta la versión 5). Por estos motivos se decidió utilizar el esquema demetadatos propio de DSpace basado en Dublin Core e implementar las métricas técnicas

142

CAPÍTULO 4. RESULTADOS, CONCLUSIONES Y TRABAJO FUTURO 143

con base en sus campos. Seguido a esto, se realizó la especificación funcional delprototipo a entregar sin perder como referencia el modelo de evaluación adoptado.

La tercera fase comprendió los diseños estructurales (clases y tablas de persistencia) quehacen parte del módulo de evaluación de objetos, asegurando una integración casi naturalcon la plataforma y aprovechando las funcionalidades de esta que se pudieran reutilizar.Posteriormente, el desarrollo requirió el uso de las API’s (pública y de almacenamiento)ofrecidas por la plataforma para poder utilizar algunas de las características de lógica denegocio y de persistencia. Cabe anotar que el modelo de persistencia implementado porel módulo añade tablas nuevas al modelo de datos de la plataforma sin afectar susrestricciones, índices, procedimientos almacenados o cualquier otro objeto de base dedatos implementado previamente.

Por último y, en paralelo con el desarrollo de la aplicación propuesta se realizaron losdiseños dinámicos (diagramas de secuencia) que permiten seguir una traza del ciclo devida de los objetos durante la ejecución de las funcionalidades disponibles en el prototipo.Con esto aseguramos una arquitectura dirigida por modelos (Model Driven Architecture –MDA-) que es robusta y facilita la evolución y la escalabilidad de la aplicación paradesarrollos futuros.

4.2. Resultados

El resultado obtenido se presenta desde la perspectiva de cada uno de los perfiles deusuario. Para cada uno de los roles se despliega la opción de evaluar un objeto deaprendizaje en la página principal del mismo y por lo tanto este botón establece el puntode entrada al módulo desarrollado. De acuerdo con la especificación funcional, el puntode entrada es el mismo, y se debe resolver en primera instancia el rol de usuario queaccede a la aplicación para desplegar la respectiva interfaz gráfica.

Figura 48: Vista de objeto de aprendizaje con opción para iniciar evaluación


4.2.1. Perspectiva del administrador

El administrador tiene la posibilidad de ejecutar las evaluaciones administrativas, que sonautomáticas pero necesitan ser iniciadas una a una, además puede ver el reporte deresultados del objeto con sus respectivos índices, parametrizar y eliminar las evaluacionesdadas a un objeto. En las siguientes figuras se puede evidenciar en gran medida laperspectiva del administrador. En la pantalla principal se muestran las diferentesopciones, cuando el administrador no ha realizado la parametrización sobre un objeto nose puede realizar la evaluación y se despliega el respectivo mensaje informando elproblema.

En este caso el administrador debe realizar la parametrización antes de continuar con laevaluación. Para ello debe utilizar el enlace para asignar los parámetros y luego escogerla capa que desea parametrizar.

Luego de esto, el administrador selecciona las métricas que desea incluir en la evaluaciónpara la capa seleccionada. Es importante recordar que si ya se realizó unaparametrización previa, en esta pantalla aparecerán marcadas las métricas que fueronseleccionadas anteriormente y estás pueden mantenerse o borrarse.

Figura 49: Pantalla principal de la perspectiva del administrador

Figura 50: Selección de capa en la

parametrización


A continuación, se asigna pesos a cada una de las dimensiones habilitadas según lasmétricas seleccionada, sólo se muestran y habilitan aquellas para las que por lo menosescogió una métrica. Una vez asignada la ponderación sobre las métricas regresa a lafigura 50, dónde puede continuar con la parametrización de otra capa, o volver a lapantalla principal.

Figura 52: Ponderación de las dimensiones

Figura 51: Selección métricas en la parametrización


Una vez se ha realizado la ponderación para la capa del administrador se pueden ejecutarlas diferentes evaluaciones. Cada evaluación arroja un resultado con una valoracióncuantitativa (valor de 0 a 1) y su respectiva descripción.

Los reportes de resultados son una funcionalidad exclusiva del administrador delrepositorio. Allí se muestran los siguientes datos: id del OA evaluado, el resultado generalde su evaluación (un valor de 1 – 10), los índices de cada capa evaluada y los valoresobtenidos para cada una de las métricas. De esta forma se busca dar una idea general dela calidad del recurso al que están accediendo los usuarios para una mejoradministración. Adicionalmente, si el administrador lo desea, desde esta pantalla puedeeliminar todos los valores asociados a la evaluación del objeto hasta el momento.

Figura 53: Evaluación administrativa de la coherencia del objeto.


Figura 55: Reporte de la evaluación con resultados parciales

Figura 54: Reporte de la evaluación con todos los resultados


4.2.2. Perspectiva del experto

Para poder acceder a esta evaluación el administrador debe haber parametrizado almenos una métrica correspondiente a esta capa. Posteriormente el experto debe asignarun peso a cada dimensión parametrizada de acuerdo a su experiencia. Una vezestablecida la ponderación de cada dimensión, se desplegará un cuestionario con el quedebe emitir sus concepto a cerca de las diferentes métricas del objeto.

Figura 57: Eliminación evaluación 2

Figura 56: Eliminación evaluación 1


Figura 58: Ponderización por parte del experto

Figura 59: Encuesta del experto


4.2.3. Perspectiva del estudiante

Al estudiante se le presenta un cuestionario, que contiene las métricas de calidadparametrizadas por el administrador para conocer que tan útiles son los recursosexpuestos en el repositorio a sus usuarios finales y además puede informar la percepciónque se tiene del objeto de aprendizaje.

4.3. Conclusiones

El desarrollo del módulo para evaluar la calidad de objetos de aprendizaje en DSpacedescrito en este trabajo se integró de forma casi natural tanto con el modelo teóricoseleccionado como con la plataforma. A excepción del esquema de metadatos trabajadoen el modelo de referencia para la evaluación de los OAs, todos los demás aspectos delmodelo fueron integrados fielmente en el módulo de evaluación. Sin embargo paramantener la consistencia de los cálculos se hizo posible un mapeo, entre el esquema demetadatos IEEE LOM y el nativo de DSpace (Basado en Dublin Core).

En la parte técnica, gracias al uso de los recubrimientos y de la API pública de laplataforma, fue posible, entre otras, acceder al contenido del repositorio, a sus metadatos,a las estadísticas y realizar operaciones a base de datos de forma transparente, sinpreocuparse por el motor de datos configurado (Postgres u Oracle).

Gracias a que DSpace es una plataforma de código abierto bien documentada y con unaAPI pública clara de integración, se facilitó estudiar su funcionamiento y comprenderalternativas para extender sus funcionalidades. Una de estas ventajas la constituye los

Figura 60: Encuesta del estudiante


recubrimientos de Maven (Maven overlays), que ofrecen una forma rápida de extensiónde la plataforma; tienen la ventaja de incluir un método de compilación rápida que sólotiene en cuenta los cambios efectuados en ficheros especiales y los aplica, después de sucompilación, al código previamente empaquetado, haciendo un remplazamiento o unaadición a las aplicaciones dependiendo del caso.

De acuerdo a todo lo expuesto anteriormente, en el presente trabajo se proporciona unaextensión robusta, a las funcionalidades nativas de DSpace que permite evaluar todos losrecursos almacenados en repositorios institucionales basado en esta plataforma a nivelinternacional. Este módulo, fiel al modelo base, permite evaluar los objetos de aprendizajedesde tres perspectivas diferentes y a través de 21 métricas de calidad para ofrecer a losadministradores un concepto integral y fiable que permita gestionar los recursos de susrepositorios para hacer auditoría de estos

4.4. Trabajo Futuro

La solución implementada en este proyecto se ciñe fielmente al modelo teórico dereferencia [2]. Sin embargo, se identifican una serie de características deseables, quedan versatilidad y un mayor alcance al prototipo presentado. Estas características sonpresentadas a continuación y pueden ser incluidas en próximas versiones.

En primer lugar, el prototipo actual funciona únicamente con una de las interfacesdisponibles para DSpace (JSPUI), para una próxima versión se debe cubrir la otra interfazdisponible (XMLUI).

Con el fin de darle mayor alcance a la solución se puede soportar internacionalización(i18n). En el momento, el módulo se presenta en su totalidad en inglés, y esto incluyepreguntas en los cuestionarios y componentes de interfaz gráfica como dropdowns ymensajes de alerta.

De igual forma, es deseable crear un módulo administrativo, que soporte la configuraciónde grupos adicionales a los que se tienen para cada una de las capas. De esta forma si secrea un grupo nuevo, se puede otorgar fácilmente permisos para habilitar la evaluaciónpara sus integrantes. En este mismo sentido, el módulo administrativo, también deberíapresentar una opción para modificar los cuestionarios planteados a los expertos yestudiantes, permitiendo agregar, cambiar o inclusive eliminar preguntas, así como lasopciones de respuesta y el puntaje dado a cada una de ellas.

Con la inclusión de las características nombradas anteriormente será posible, ampliar aúnmás el alcance del módulo de evaluación y adaptar esta herramienta a la escalabilidadpropia de DSpace como plataforma dedicada a la educación virtual.

Anexos

Anexo I. Manual instalación

En este anexo se describe el proceso que se debe seguir para poder utilizar la extensióndesarrollada en este proyecto.

Prerrequisitos

El módulo desarrollado se escribió para el repositorio de código abierto DSpace, por lotanto, es necesario tener una instalación del mismo para poder ejecutar y probar laextensión, concretamente se escribió sobre la versión 5 del repositorio, por ser la versiónestable más reciente en el momento del inicio del proyecto. El resto de herramientas quese utilizan en este manual de instalación son necesarias para la instalación de DSpace 5,y por lo tanto se da por sentado que ya se cuenta con ellas. Quizás la única herramientaque podría no tener un ambiente con DSpace 5, es el sistema de control de versiones Git,y por lo tanto es necesario instalarlo antes de poder proseguir con este manual.

En una máquina con DSpace se debe contar con un directorio de instalación, que hemosdenominado a lo largo de este documento como [dspace] y un directorio con el códigofuente denominado [dspace-source]. Básicamente [dspace-source] fue el sitio en el quese descomprimió o clonó el proyecto, y [dspace] el directorio configurado para almacenarlos archivos compilados y el cual posee las aplicaciones web que se desplegan en elcontenedor.

Configuración repositorio

Lo primero que se debe hacer es configurar el repositorio. El proyecto fue desarrolladohaciendo uso de Git, y se encuentra alojado en la nube en Github, se puede explorar enlínea en la dirección web https://github.com/jmgarciabe/loa. Para la configuración se debeseguir los siguientes pasos desde la línea de comandos:

152

https://github.com/jmgarciabe/loa

ANEXOS 153

• Verificar que se cuenta con git: para ello se debe ejecutar el comando “git--version”, y el sistema debe devolver la versión que tenemos instalada.

• Ubicarse en la línea de comandos en el directorio de los módulos que seencuentra en [dspace-source]/dspace/modules

• Luego se deben ejecutar las siguientes instrucciones de git, que inicializan elrepositorio, agregan la información del repositorio remoto, y descarga el contenido:“git init”, “git remote add originhttps://github.com/jmgarciabe/loa.git”, “git fetch” y “gitcheckout -t origin/master -f”

Con esto se finaliza la configuración del repositorio. Después de esto, los módulosadditions y jspui, contienen los archivos del desarrollo y adicionalmente se agrega unacarpeta con los scripts de bases de datos necesarios para la configuración de la siguientesección.

Configuración de la base de datos

Una vez se haya configurado el repositorio, en la ruta [dspace-source]/dspace/modules/loaDbScripts se pueden encontrar los scripts necesarios paracrear las entidades del módulo de evaluación. En este directorio se encuentra tres scriptsdiferentes, uno con sentencias DDL (Data Definiton Language) para PostgreSQL, quedeben ejecutar los usuarios que utilicen la plataforma junto a este motor de base de datos,otro con sentencias DDL para Oracle, y finalmente un archivo con sentencia DML (DataManipulation Langauge) que deben ser ejecutado en ambos motores después del

ANEXOS 154

respectivo archivo DDL.

Para el caso de PostgreSQL, se debe correr primero postgresDdl.sql seguido porloaDml.sql. En el caso de Oracle primero oracleDdl.sql seguido por loaDml.sql. Esimportante recordar que se debe utilizar el usuario que se creó durante la instalación deDSpace, y que es el propietario de la base de datos del sistema. En la ejemplificaciónsiguiente el usuario creado se llama dspace y la base de datos creada dentro del motor sellama igualmente dspace.

Luego se ejecuta el script DML.

Compilación de los módulos

De acuerdo a lo descrito en la sección 3.1.3 existen dos formas para aplicar los cambioshaciendo uso de Maven, la recomendada es el quick-build que sólo toma los archivosubicados en el directorio de los módulos ([dspace-source]/dspace/modules), los recompilay los aplica al código previamente compilado. Para esto, desde [dspace-source]/dspace/se debe ejecutar el siguiente comando, en caso de que se esté utilizando Oracle se debeagregar la opción -Ddb.name=oracle.

Luego de esto, se utiliza Ant para reemplazar las aplicaciones web en la carpeta deinstalación [dspace] por las que se compilaron en el paso anterior. Al igual que Maven,Ant es indispensable en la instalación de DSpace 5, y por lo tanto estas herramientasdeben estar instaladas. El siguiente comando se debe ejecutar desde [dspace-source]/dspace/target/dspace-installer.

Con esto se ha agregado la extensión desarrollada a DSpace, y se puede probar. Esimportante aclarar, aunque ya se ha hecho con anterioridad, que para efectos de este

ANEXOS 155

prototipo se asume que los usuarios registrados que pertenecen al grupo con ID 1 son losadministradores, los que pertenecen al grupo de DSpace con ID 2 son los expertos, y losque pertenecen al grupo con ID 3 son los estudiantes. Por esto, puede ser necesarioregistrar usuarios para cada una de estos grupos, con el propósito de revisar laevaluación desde cada una de estas perspectivas.

Anexo II. Diseño y Ejecución de casos de prueba

A continuación se presenta el diseño y la ejecución de pruebas de tipo de caja blanca ycaja negra, las cuales permiten verificar y validar respectivamente el comportamiento delproducto para asegurar su conformidad con los requerimientos funcionales previamenteplanteados.

Las pruebas de caja blanca se realizan desde la perspectiva del desarrollo y tienen comointención asegurar que el flujo de control y de datos dentro de la aplicación se ejecutaeficazmente. Por otro lado, las pruebas de caja negra tienen como único objetivo asegurarque las funcionalidades planteadas en la especificación de requerimientos se cumplan ensu totalidad, por lo que se puede entender que se realizan desde la perspectiva delusuario. Aunque el diseño y la ejecución de los casos de prueba son dos tareasindependientes, por practicidad y con el fin de evitar redundancia, se unen en lassecciones siguientes.

Diseño y resultados pruebas de caja blanca

Identificador: CP01

Nombre: Eliminación y adición de métricas en la parametrización

Propósito: Validar que cuando se realizan cambios en la parametrización administrativa estos seven reflejados en la base de datos, y en memoria.

Pre-condiciones: Iniciar sesión como administrador, e iniciar la parametrización de la capa deestudiantes.

Paso Descripción Comentario

1 En la parametrización de la capa de estudianteselegir las métricas correspondientes a la dimensióneducativa, estética y contextual

ANEXOS 156

Identificador: CP01


2 Validar que en memoria y base de datos se veareflejada esta elección

ANEXOS 157

Identificador: CP01


3 Finalizar la parametrización y volver iniciar en lacapa de estudiantes pero esta vez elegir las métricascorrespondientes a la dimensión de metadatos yfuncional

4 Validar resultados en memoria y base de datos

ANEXOS 158

Identificador: CP01


Identificador: CP02

Nombre: Cambio en los pesos otorgados por el administrador

Propósito: Verificar el proceso de asignación de pesos en la parametrización administrativacuando se realiza un cambio en los pesos asignados

Pre-condiciones: Iniciar sesión como administrador e ingresar a la parametrización


1 Elegir la parametrización para la capa deexpertos y eligiendo todas las métricas dar pesoa las dimensiones.

Se propone dar un peso de 60 a ladimensión educativa, y 10 al resto.

ANEXOS 159

Identificador: CP02


2 Validar valores en memoria y base de datos

ANEXOS 160

Identificador: CP02


3 Volver a iniciar la parametrización para la capa deexpertos y esta vez elegir todas las métricas aexcepción de las de la dimensión educativa ycambiar los pesos asignados a cada capa

Se propone asignar 25 a cada una delas 4 dimensiones de este paso

4 Validar valores en memoria y base de datos

ANEXOS 161

Identificador: CP02


Identificador: CP03

Nombre: Evaluación de coherencia

Propósito: Validar proceso de la evaluación administrativa de coherencia

Pre-condiciones: Iniciar sesión como administrador.


1 Ejecutar evaluación administrativa de coherencia

2 Verificar coherencia en el idioma del título delobjeto de aprendizaje y el asignado en losmetadatos

Revisar como se realiza estavalidación a nivel de código

Se cargan lo perfiles para detectar lenguajes en mensajes de la librería utilizada

Posteriormente se utiliza esta librería para detectar idioma del título y compararlo con el idiomaasignado en los metadatos

ANEXOS 162

Identificador: CP03

Nombre: Evaluación de coherencia

3 Revisar puntaje obtenido y compararlo con elmostrado al final

Identificador: CP04

Nombre: Cambio asignación pesos por experto

Propósito: Verificar el proceso de asignación de pesos en la parametrización del experto

Pre-condiciones: Realizar la parametrización administrativa eligiendo todas la métricas. Iniciarsesión como experto e iniciar evaluación de objeto de aprendizaje.


1 Dar pesos a cada una de las dimensiones Se propone dar un peso de 2 a todaslas dimensiones.

ANEXOS 163

Identificador: CP04


2 Validar los datos en memoria y base de datos

Los identificadores de las dimensiones con sus respectivos pesos

ANEXOS 164

Identificador: CP04


3 Terminar evaluación para la capa de expertos einiciar nuevamente la evaluación, esta vezcambiar los pesos asignados

Se propone dar un peso de 3 a todaslas dimensiones

4 Validar los datos en memoria y base de datos

ANEXOS 165

Identificador: CP05

Nombre: Cambio en evaluación de estudiantes

Propósito: Validar el cambio en el puntaje asignado por los estudiantes cuando se realiza unaevaluación adicional

Pre-condiciones: Iniciar sesión como estudiante e iniciar proceso de evaluación sobre objeto deaprendizaje


1 Gestionar encuesta y enviar resultados Se propone elegir la opción más bajapara cada una de las preguntas delcuestionario.

2 Validar puntaje en memoria y base de datos

ANEXOS 166

Identificador: CP05


Identificador de la métrica y el valor dado en la encuesta

3 Volver a iniciar la evaluación y esta vez dar unvalor diferente

Se propone elegir la opción más altapara cada una de las preguntas delcuestionario.

ANEXOS 167

Identificador: CP05


4 Validar puntaje en memoria y base de datos

ANEXOS 168

Diseño y resultados pruebas de caja negra

Identificador: CP06

Nombre: Recordar selección previa en parametrización administrativa

Propósito: Verificar que cuando se realiza la parametrización sobre un objeto de aprendizaje queya había sido previamente parametrizado se le presenta al administrador las métricas que sehabían seleccionado en el proceso anterior

Pre-condiciones: Iniciar sesión como administrador y elegir un objeto de aprendizaje sinparametrización. Iniciar parametrización para la capa de administradores


1 Validar que los checkboxes no se encuentranseleccionados

2 Elegir las métricas de la capa funcional, ycompletar el proceso de parametrización para lacapa

ANEXOS 169

Identificador: CP06


3 Volver a iniciar la parametrización para la capa deadministradores, y verificar que las métricasseleccionadas anteriormente se encuentranchequeadas

4 Seleccionar todas la métricas y terminar elproceso de parametrización

ANEXOS 170

Identificador: CP06


5 Volver a iniciar la parametrización administrativa yverificar que todas las métricas se encuentranseleccionadas

ANEXOS 171

Identificador: CP07

Nombre: Validar cambios en el reporte

Propósito: Revisar como varía el reporte a medida que se realizan evaluaciones sobre un objetode aprendizaje

Pre-condiciones: Iniciar sesión como administrador e iniciar evaluación sobre objeto deaprendizaje que no se haya evaluado.


1 Revisar reporte y validar que no se ha realizadoninguna evaluación sobre le objeto deaprendizaje

ANEXOS 172

Identificador: CP07


2 Realizar la evaluación administrativa dedisponibilidad

3 Realizar evaluación administrativa de completitud

4 Validar estado de reporte

ANEXOS 173

Identificador: CP07


5 Iniciar sesión como estudiante y realizar laevaluación

6 Iniciar sesión como administrador y validar estadodel reporte

ANEXOS 174

Identificador: CP07


Identificador: CP08

Nombre: Evaluación administrativa de completitud

Propósito: Verificar como cambia la evaluación administrativa de completitud a medida que semodifican los metadatos

Pre-condiciones: Iniciar sesión como administrador


1 Elegir objeto de aprendizaje que incluya el campode abstract en sus metadatos

ANEXOS 175

Identificador: CP08


2 Realizar evaluación administrativa de completitudsobre el objeto de aprendizaje y revisar resultado

3 Eliminar el campo se abstract en los metadatosdel objeto de aprendizaje

ANEXOS 176

Identificador: CP08


4 Volver a realizar evaluación de completitud yrevisar el cambio en el resultado

Identificador: CP09

Nombre: Validación en formularios

Propósito: Revisar que los formularios presentan validación en los datos ingresados

Pre-condiciones: NA


1 Revisar validación cuando no se ha realizadoparametrización sobre la capa administrativa

2 Revisar la validación sobre los pesos asignadosen la parametrización administrativa

Elegir la parametrización de la capaadministrativa y dar pesos que superenun valor de 100 en la sumatoria

ANEXOS 177

Identificador: CP09


3 Revisar la validación de los pesos asignados porel experto

Asignar valores mayores a 5

4 Revisar la validación en el cuestionario de la capade estudiantes

Enviar formulario sin haber diligenciadoel cuestionario en su totalidad

ANEXOS 178

Identificador: CP09


Identificador: CP10

Nombre: Parametrización administrativa

Propósito: Revisar el efecto de la parametrización administrativa sobre las capas

Pre-condiciones: Iniciar sesión como administrador e iniciar parametrización


1 Elegir la parametrización de la capa de expertos ysólo elegir la métrica de la capa educativa, luegocompletar proceso de parametrización

ANEXOS 179

Identificador: CP10


2 Elegir la parametrización de la capa deestudiantes y sólo elegir las métricas de la capafuncional, luego completar proceso deparametrización

3 Iniciar sesión como experto y validar laparametrización y el cuestionario desplegado

Solo se debe mostrar lo concerniente ala dimensión educativa

ANEXOS 180

Identificador: CP10


4 Iniciar sesión como estudiante y validar elcuestionario desplegado

Solo se debe mostrar lo concerniente ala dimensión funcional

Bibliografía

[1] WIKIPEDIA (Artículo modificado por última vez el 4 de Agosto de 2014). Open EducationalResources. Consultado Agosto 01 de 2014, enhttp://en.wikipedia.org/wiki/Open_educational_resources

[2] TABARES MORALES, Valentina. Modelo por Capas para Evaluación de la Calidad deObjetos de Aprendizaje en Repositorios de Objetos de Aprendizaje. Medellín, 2013, 132p.Trabajo de grado (Magister en Ingeniería de Sistemas). Universidad Nacional de Colombia.Sede Medellín. Facultad de Minas. Departamento de Ciencias de la Computación y de laDecisión.

[3] UNIVERSIDAD DISTRITAL. Foro las TIC y la Educación Superior, Conferencia: RecursosEducativos Digitales. Dra. Donna Zapata, Universidad de Antioquia. Auditorio Investigadores,sede Aduanilla de Paiba. Octubre 9 de 2014, Calle 13 No. 31 - 75, Bogotá D.C.

[4] MINISTERIO DE EDUCACIÓN NACIONAL. Criterios y recomendaciones para la evaluaciónde Recursos Educativos Digitales Abiertos y la indexación de repositorios institucionales.Bogotá D.C., 2013, Disponible en http://186.113.12.159/Documentacion/Marcos_Politicas.pdf

[5] DANIEL, B.K.; MOHAN, P. A model for evaluating learning objects. Advanced LearningTechnologies, 2004. Proceedings. IEEE International Conference, pp.56,60, 30 Aug.-1 Sept.2004.

[6] NICHOLS, D., CHAN, C., & BAINBRIDGE, D. A Tool for Metadata Analysis. Hamilton, NewZealand, 2008.

[7] SANZ, J. Evaluación Apriorística de la Reusabilidad de los Objetos de Aprendizaje.Universidad de Alcalá de Henares, 2010.

[8] MASSA, S. M.. Objetos de Aprendizaje: Metodología de Desarrollo y Evaluación de laCalidad. Universidad Nacional de La Plata, 2012.

[9] TABARES MORALES, VALENTINA; DUQUE MÉNDEZ, NESTOR DARÍO; MORENOCADAVID, JULIÁN; OVALLE CARRANZA, DEMETRIO ARTURO Y VICARI, ROSA MARIA.Evaluación de la calidad de metadatos en repositorios digitales de objetos de aprendizaje.En: Revista Interamericana de Bibliotecología, ISSN: 0120-0976, Volumen 36, No. 3, p 183 -195. Escuela Interamericana de Bibliotecología. Medellín, Colombia. Octubre de 2013.

[10] J. SINCLAIR, M. JOY, J. YIN-KIM YAU, S. HAGAN. A practice-oriented review of learningobjects. IEEE Trans. Learn. Technol., vol. 6, no. 2, pp. 177–192, 2013.

181

http://186.113.12.159/Documentacion/Marcos_Politicas.pdf

http://en.wikipedia.org/wiki/Open_educational_resources

BIBLIOGRAFÍA 182

[11] J. SANZ-RODRÍGUEZ, J. M. DODERO, S. SANCHEZ-ALONSO. Ranking learning objectsthrough integration of different quality indicators. IEEE Trans. Learn. Technol., vol. 3, no. 4,pp. 358–363, 2010.

[12] IEEE. Standard for Learning Object Metadata. IEEE Std 1484.12.1-2002, pp.i,32. 2002.

[13] BARKER PHIL. What is IEEE Learning Object Metadata / IMS Learning Resource Metadata?JISC, University of Boston. 2005.

[14] TOBAR C.M., DE LIMA S.I., Assessing a learning object standard adherence. Frontiers InEducation Conference - Global Engineering: Knowledge Without Borders, OpportunitiesWithout Passports, 2007. FIE '07. 37th Annual, pp.T2D-7,T2D-12, 10-13 Oct. 2007

[15] M. CASTAGNÉ. Institutional repository software comparison: DSpace, EPrints, DigitalCommons, Islandora and Hydra. University of British Columbia. 2013.

[16] UNIVERSITY OF SOUTHAMPTON, SCHOOL OF ELECTRONICS AND COMPUTERSCIENCE. The Registry of Open Access Repositories. Consultado en miércoles 05 deNoviembre, en: http://roar.eprints.org/view/software/

[17] JOINT INFORMATION SYSTEMS COMMITTEE, REPOSITORIES SUPPORT PROJECT.Repository software survey, November 2010: Product Comparison Table. ConsultadoNoviembre 05 de 2014, en http://www.rsp.ac.uk/start/software-survey/results-2010/

[18] DURA SPACE. Extensions and Addons Work. Consultado Octubre 17 de 2014, enhttps://wiki.duraspace.org/display/DSPACE/Extensions+and+Addons+Work.

[19] MENÉNDEZ, V. H., CASTELLANOS, M. E., VIDAL, C., & SEGURA, A.. Un Modelo de Calidad de Objetos de Aprendizaje basado en la Semántica de sus Metadatos. LACLO 2012 - Séptima Conferencia Latinoamericana de Objetos y Tecnologías de Aprendizaje, 2012.

[20] AGUDELO BENJUMEA, MÓNICA MARÍA. ¿Cómo se publica un Objeto de Aprendizaje?:Metadatos. Consultado Agosto 07 de 2014, enhttp://aprendeenlinea.udea.edu.co/lms/men/docsoac3/0301_metadatos.pdf

[21] M. KURTZ, Dublin Core, DSpace, and a Brief Analysis of Three University Repositories. Inf.Technol. Libr., vol. 29, no. 1, pp. 40–46, Jan. 2013.

[22] LEHMAN R. Learning object repositories. New Dir. Adult \& Contin. Educ., vol. 2007, no. 113,pp. 57–66, 2007.

[23] EDUTECH WIKI (Artículo modificado por última vez el 24 de Octubre de 2013). LearningObject Repository. Consultado Noviembre 06 de 2014, enhttp://edutechwiki.unige.ch/en/Learning_object_repository.

[24] DSPACE. About DSpace. Consultado Octubre 22 de 2014, enhttp://www.dspace.org/introducing.

[25] EPRINTS. What is EPrints? EPrints Introduction. Consultado Octubre 22 de 2014, enhttp://wiki.eprints.org/w/Introduction.

[26] FEDORA. Fedora Repository Project. Consultado Octubre 22 de 2014, en: http://www.fedora-

http://www.fedora-commons.org/about

http://wiki.eprints.org/w/Introduction

http://www.dspace.org/introducing

http://edutechwiki.unige.ch/en/Learning_object_repository

http://aprendeenlinea.udea.edu.co/lms/men/docsoac3/0301_metadatos.pdf

https://wiki.duraspace.org/display/DSPACE/Extensions+and+Addons+Work

http://www.rsp.ac.uk/start/software-survey/results-2010/

http://roar.eprints.org/view/software/

BIBLIOGRAFÍA 183

commons.org/about.

[27] KENNETH S. R. Essential Scrum: A Practical Guide to the Most Popular Agile Process.Addison-Wesley, 2012.

[28] THE DSPACE DEVELOPER TEAM. DSpace 5.X Documentation. 2015.



desarrollo de un mÓdulo de software para evaluar la

Documents