Especificación IMS QTI v2.1 Results Reporting

La especificación sobre los informes de resultados de los candidatos pertenece al borrador IMS QTIv2.1. Es el primer documento que se publica sobre este tema, ya que la especificación 2.0 no menciona nada al respecto. Esta especificación pretende establecer un modelo para almacenar y compartir resultados obtenidos en elementos evaluativos (tests, conjuntos de preguntas, etc.).

Según la especificación el resultado de una evaluación, será el informe sobre un test o simplemente un conjunto de preguntas. Se creará un identificador sobre qué sistema realizo el informe (SessionIdentifier). Cada resultado estará asociado a un estudiante. Esta información se expresará según la especificación que ya comenté hace unos días (learner information package). Si se trata de un test, se deberá añadir información de cuando se registró el resultado de tal test y de forma optativo cualquier otro parámetro sobre el resultado del test y su duración. De forma obligatoria, hay que registrar los resultados de los elementos que componen la evaluación, de forma obligatoria se registra la fecha en la que se calificó el elemento y un estado de sesión de la misma, que sirve para interpretar las variables(itemVariable) de este elemento. Las variables pueden contener los valores de las variables incorporadas numAttempts, duration y completionStatus. Además, puede contener algún comentario del estudiante.

Las variables tienen un identificador, una cardinalidad y opcionalmente un tipo base. Diversos tipos de variables heredan de ésta: responseVariable, outcomeVariable y templateVariable(no implementada en SDocente). ResponseVariable deberá contener la respuesta del estudiante y, opcionalmente la respuesta correcta y también se puede informar, si se trata de un elemento de elección, si se han desordenado los elementos al presentarlos al estudiante. OutcomeVariable puede almacenar la información sobre el elemento outcomedeclaration de un examen (puntuación mínima, máxima normalizada, o puntuación mínima para considerar que un elemento está “aprobado”) y sobre quién tiene la posibilidad de ver toda esta información. De este modo, cuando el sistema que representa el informe de evaluación sabe a quién lo debe hacer visible. Todos los elementos de outcomeVariable son opcionales.

Aquí os muestro el diagrama de clases de SDocente a la hora de implementar esta especificación.

Informe de resultados

Tipos de IMS Learner Information Packaging

Al mostrar el diagrama de clases de SDocente, se me olvidó añadir los tipos utilizados: Gender, Partname y Address.

Regreso con más especificaciones

Tras unos meses sin postear, pero sin que el desarrollo del proyecto se detuviera, vuelvo para comentar en este y post sucesivos cosillas realizadas, así como nuevas especificaciones que han entrado en juego.

Hoy os comentaré de forma breve qué es y qué integración ha tenido en el proyecto la especificación IMS Learner Information Packaging.

La especificación IMS Learner Information Packaging pretende detallar un modelo de datos que describe las características de un estudiante necesarias para almacenar y gestionar su historial, objetivos y de logros de aprendizaje.

Como cualquier especificación se consigue la interoperabilidad, es decir, que varios sistemas puedan funcionar/entender los datos que cumplen esta especificación, respetando la privacidad y protección de los datos.

La especificación contempla una gran cantidad de información que puede recoger, almacenar y/o almacenar. La información del estudiante se divide en 11 categorías:

1. Identificación
2. Objetivo
3. Calificaciones, Certificaciones y licencias (qcl)
4. Actividad
5. Transcripción
6. Interés
7. Competencia
8. Afiliación
9. Accesibilidad
10. Código de seguridad
11. Relación

En un sistema de información de estudiantes podrían entrar en juego muchos actores como el propio estudiante, la escuela, empleados, publicadores, etc. recavando información de muchos medios.

Se escapa ell uso amplio de esta especificación para este proyecto, por lo que se ciñe sólo al uso reducido de la categoría identificación.

La estructura de datos de esta categoría no contiene campos obligatorios de primer nivel, es decir, ninguna de las estructuras que represetan la identificación del alumno es obligatoria, pero sí son obligatorios algunos campos si opta por ciertas estructuras. Por ejemplo, el uso de la estructura formname, que sirve para almacenar un nombre ya formateado, no es obligatoria pero si se usa esta estructura deberá de forma obligatoria rellenar su campo text.

La estructura de datos de identificación contiene estructuras como:

• Nombre
• Dirección
• Información de contacto
• Datos demográficos
• Agentes (información de las personas que pueden actuar en nombre del estudiante.
• Extensión (estructura para facilidar la extensión de la información del estudiante).

A continuación muestro un diagrama de como quedaría en SDocente la integración con las estructuras necesarias.

Learning Information Package en SDocente

Aplicación extensible = Plugable

La nueva idea en desarrollo es que la amplicación sea lo más extensible posible sin realizar esfuerzos muy costosos. La intención es poder agregar paquetes para poder añadir nuevos tipos de preguntas a la aplicación, incluyendo sólo unos determinados ficheros, sin modificar en la aplicación en sí. De este modo, se permitirá crear nuevos tipos de preguntas sin tener que recodificar el core de la aplicación. Cada paquete de nueva pregunta o plugin tendrá que incluir:

Controlador: Se encargará de la interacción con la gui de la pregunta, controles de la gui, recuperación de datos, etc.

Validador: Validará los datos que recogió el controlador.

Clase Pregunta: La nueva pregunta tendrá una lógica de negocio que quedará recogida en esta clase.

Render: Para que la pregunta puede visualizarse de algún modo, deberá crearse una clase que se encargué de mostrarla, por ejemplo en HTML, LaTeX, etc.

Código Base de Datos: Se tendrán que añadir un par de funciones para posibilitar tanto el almacenamiento como la recuperación de este tipo de preguntas.

Avances varios

Hace días que no escribo… en este tiempo, me he dedicado a muy variados asuntos. He estado creando una plantilla para la documentación según la normativa del PFC, he juntado, maquetado y revisado toda la documentación que había creado hasta el momento. Además, me he personalizado el paquete fncychap, que es un paquete de LaTeX para modificar el formato de los capítulos.

En cuanto a el framework que comenté en el anterior post, me he leído los capítulos básicos del libro de Django, estuve diseñando el aspecto de la aplicación y modificando el aspecto del render de las preguntas de HTML. El complemento para Iceweasel está muy curioso para el diseño web.

De todos modos, enseguida dejé aparcado el tema de Django, y volví a la aplicación de escritorio. He modificado la capa de persistencia, y he realizado los cambios necesarios en la capa de dominio, para que el Agente siempre devuelva objetos de la capa de dominio. De este modo se consiguen varios objetivos, pero hay que destacar que este es el modo para facilitar el uso de Slice e ICE. La aplicación todavía no la he modificado para que sea distribuida, espero hacerlo en breve. Sí he realizado el fichero slice, digamos que es un lenguaje que sirve para establecer un contrato entre las distintos lados(peers) de la aplicación. En este caso, un lado siempre hará de servidor y otro siempre de cliente. El lado del servidor se basará en el Agente y la base de datos. También he actualizado los diagramas de clases.

Los otros avances se han centrado en mejorar la interfaz a la hora de crear exámenes, así como en los render, a parte del comentado en HTML anteriormente, también se ha mejorado el render de LaTeX. Se ha añadido la lógica de negocio necesaria para trabajar con exámenes, así como las tablas en la base de datos, en la línea de la especificación IMS QTI v2.1. También, se crea el fichero xml de acuerdo a ésta especificación.

Las nuevas ideas que se están implementado ahora son ideas referentes a que una pregunta que ha sido utilizada en un examen, no puede ser editada, ya que si se edita una pregunta y se quiere ver el examen o datos almacenados relacionados a esa pregunta, se contemplarían datos falseados. Por lo tanto, hay que poner una barrera para no poder editar las preguntas utilizadas. Con objeto de no tener que crear de nuevo la pregunta con la modificación que se pretendía realizar, se trabaja en el clonado de una pregunta. Es decir, poder disponer de una pregunta igual(el mismo contenido) pero no la misma(no es el mismo archivo xml ni la misma instancia en la base de datos), de este modo, se puede editar la pregunta clonada para realizar las modificaciones que se deseen, utilizarla en futuros exámenes sin tener que crearla desde cero.

Framework elegido

De entre todos los frameworks, realicé una última criba por lenguaje. Sí, quizás hubiese sido magnífico hacerla desde el principio, pero hasta que no he visto un poquito más en profundidad no me he dado cuenta. Los de Java, ofrecen muchos efectos visuales casi todos basados en tecnología AJAX, pero lo necesario es buscar un framework que ofrezca mecanismos de seguridad, de desarrollo fácil y rápido, sesiones, etc. Por la parte de PHP, está muy de moda y eso, pero no lo he visto muy elegante, sobre todo, a la forma de trabajar con los datos. Por último Ruby o Python, me he quedado con Python porque conozco el lenguaje y me va a ser más sencillo programar en Python, aunque lo poco que he visto de Ruby está bastante bien.

Entre TurboGears y Django, la verdad es que son bastante parecidos, los dos se basan en CherryPy, otro framework de Python. Me he decantado finalmente por Django por dos motivos:

• La facilidad de crear interfaces de administración.
• La información de errores en el desarrollo. Si en Django intentas acceder a una URL no conocida, aparece una página de error muy bien formateada con las urls existentes, las variables de contexto y mucha más información.

He leído el tutorial, bastante largo, pero las cosas van quedando claras, menos las vistas generales, creo que por meterlas en el ejemplo y no hacer el tutorial más largo no quedan del todo ilustradas. Han sacado un libro y además, se está trabajando en la traducción al español del mismo.

Repaso de Frameworks

Hace tiempo ya hablé algo sobre los frameworks, han pasado unos meses y ahora que es el momento de utilizar alguno, creo que estaría bien, rehacer esa tabla con los frameworks más actualizados.

Table 1:
Frameworks ordenados por lenguaje

Lenguaje Framework Java Apache Cocoon · Apache Struts · Google Web Toolkit · Grails · JBoss Seam · OpenLaszlo · Spring Framework · Stripes · Wicket framework · ZK Framework PHP CakePHP · CodeIgniter · Horde · KohanaPHP ·  PRADO · Zend Framework Python Django · TurboGears Ruby Ruby on Rails