Seminario Pautas De Producción Simuladores

PRESENTACIÓN SEMINARIO SOBRE ASPECTOS TÉCNICOS, EMPAQUETADO Y CATALOGACIÓN DE SIMULADORES CONCEBIDOS COMO OBJETOS DIGITALES EDUCATIVOS 30/01/2009

Exp. 729/07-SD

PAUTAS PARA EL DESARROLLO DE ENTORNOS DE SIMULACIÓN PARA FORMACIÓN PROFESIONAL

Exp. 729/07-SD

Objetivo general El seminario tiene por objetivo que las empresas adjudicatarias del pliego 729 y otros profesionales dedicados al diseño y desarrollo de simuladores didácticos conozcan las características técnicas que particularizan el desarrollo de simuladores para la formación profesional en el marco del empaquetado en SCORM2004, la catalogación en LOM-ESV1.0 y la inclusión de mecanismos de persistencia y trazabilidad para estas aplicaciones tanto en Learning Management Systems (LMS), como fuera de estas aplicaciones.

Objetivos específicos •Identificar las características técnicas y didácticas que distinguen los simuladores para la formación profesional descritos en el Pliego 729. •Incluir en el desarrollo de los simuladores los requerimientos de arquitectura, desarrollo, y organización de directorios y ficheros que contemplen el correcto empaquetado del recurso didáctico en el formato SCORM2004 mediante la herramienta Agrega offline. •Reconocer las etiquetas adecuadas para la catalogación de los simuladores de acuerdo con los requerimientos de catalogación del estándar LOM-ESV1.0 e incorporarlas en el archivo de catalogación mediante la herramienta incluida en Agrega offline para esta funcionalidad. •Probar los mecanismos para conseguir la persistencia y la trazabilidad de los simuladores en LMS SCORM2004 y en entornos WEB fuera de estas aplicaciones, en navegadores de uso general, mediante el recurso del registro de huellas en los Share Objects de Flash. •Nombrar y entregar de forma correctas los paquetes ZIP que incluyen los simuladores.

Presentaciones y ponentes Pautas generales de Producción de Entornos de Simulación para Formación Profesional (de acuerdo al Pliego 729/07-SD de Red.es) Max Hamann L. Pautas de desarrollo (trazabilidad y persistencia, configuración del Flash, estructura de carpetas y archivos, etc.) Daniel Ruiz Zorrilla Pautas de Empaquetado (SCORM 2004 y la utilización de la herramienta Agrega offline) Antonio Sarasa Cabezuelo Pautas de Catalogación (LOM-ES V1 y la utilización del catalogador avanzado de Agrega offline) Verónica Rico Nicolás y Fernando Vaquero Entrega de los simuladores como paquetes ZIP y la validación de Red.es Ana Álvarez Lacambra y Consuelo Roso

Pautas generales de Producción de Entornos de Simulación para Formación Profesional (de acuerdo al Pliego 729/07-SD de Red.es) Max Hamann L. Objetivo específico Identificar las características técnicas y didácticas que distinguen los simuladores para la formación profesional descritos en el Pliego 729.

El valor de la creatividad es mucho mayor conforme se disponga de menos recursos y tiempo y, por el contrario, se deban manejar más restricciones. En este proyecto, los recursos y el tiempo no han sido particularmente escasos, pero las restricciones … tampoco. Tipos de restricciones Técnicas

Técnico-didácticas

Didácticas

En este seminario vamos tratar exclusivamente de las restricciones: •Técnicas •Técnico-didácticas

Conceptos generales Definición •Se obtienen al aplicar un diseño instructivo completo (contenidos, actividades, evaluación, etc.) a la combinación de uno o varios Medias o Medias Integrados.

•Los simuladores son Objetos Digitales Educativos reutilizables (ODEs) correspondientes al nivel de agregación 2, es decir, a los ODEs más simples e indivisibles que conllevan una función didáctica explícita.

Características generales de los simuladores 1. 2. 3. 4. 5.

Compatibilidad Fidelidad física y de percepción Accesibilidad Multilingüismo Usabilidad (navegación, pistas y retroalimentación, visualización, impresión, tratamiento de textos) 6. Catalogación 7. Empaquetado 8. Trazabilidad y persistencia (fuera de LMS y en LMS SCORM 2004 9. Arquitectura 10. Configuración y parametrización

1. Compatibilidad • Los simuladores serán programas informáticos para ser usados con un ordenador de propósito general y deberán seguir principios basados en la independencia tecnológica. • Se basarán en tecnologías y formatos accesibles por navegadores WEB y no requerirían la instalación de aplicaciones propietarias en cliente.

1. Compatibilidad • Funcionarán correctamente en las últimas versiones estables de los navegadores IE, FireFox, Opera y Safari.

• Los tres lotes desarrollan los simuladores en Flash, desde Macromedia Flash o desde Adobe Flex.

2. Fidelidad física y de percepción •Los simuladores incluirán representaciones realistas.

•Incluirá 3D pero no se podrá emplear renderización en tiempo real porque ello exige instalaciones.

3. Accesibilidad •Cada simulador debe tratar la accesibilidad para todos los casos posibles y declararla desde la Ayuda.

Sin embargo, de forma específica (según las recomendaciones del especialista de la ONCE) en algunos no será necesario atender a determinadas discapacidades por la naturaleza de la disciplina a simular.

4. Multilingüismo Los simuladores de los distintos lotes del presente pliego se producirán en 6 lenguas (castellano, catalán, euskera, gallego, valenciano e inglés internacional estándar) incluyendo la catalogación en dichas lenguas. El lote 1, además, traducirá al francés.

5.Usabilidad La producción de los simuladores seguirá las siguientes pautas generales relativas a la usabilidad: 5.1 Navegación guiada 5.2 Pistas y retroalimentación 5.3 Visualización optimizada 5.4 Impresión preconfigurada 5.5 Tratamiento de textos en archivos independientes.

5.1 Navegación guiada El tipo de navegación será guiada a lo largo de toda la simulación del proceso o procedimiento: aparecerán mensajes instructivos antes, durante (pistas) y después (feedback o retroalimentación) de la interacción .

5.1 Navegación guiada

Un simulador se puede asemejar a una máquina de estados finitos: en cada estado, el usuario puede realizar acciones que le permitan pasar a otro.

5.2 Pistas y retroalimentación •De ser necesario, antes de una acción el simulador orientará al usuario mediante alguna pista y, tras la acción del alumno, el simulador deberá otorgarle un feedback. •Será información específica y no general. Dará información sobre las consecuencias de la acción e incluso dará pistas específicas también sobre otras posibles acciones.

5.3 Visualización optimizada Resolución de pantalla

Los simuladores deberán estar optimizados para visualizarse correctamente como mínimo en pantallas de 1024x768, aunque se deberá procurar un visionado adecuado para resoluciones de 800x600.

5.4 Impresión preconfigurada Todas las páginas que contengan información relevante para su lectura o visionado (instrucciones, evaluaciones, imágenes importantes para el estudio, etc.), se podrán imprimir, reorganizando la información a formato A4.

Para esto, se pueden emplear CSS o similares para todas las pantallas, o una clase de impresión en Flash.

5.5 Tratamiento de textos en archivos independientes •La programación y el diseño de las pantallas tendrán en cuenta la necesidad de adaptación a diferentes longitudes de textos producidos en las traducciones. •Se evitará la rotulación en ilustraciones y otros media. •Se utilizarán elementos sin particularidades autonómicas.

5.5 Tratamiento de textos en archivos independientes •Los ficheros de idiomas serán explícitos y estarán modularmente separados del motor de simulación.

6. Catalogación de simuladores Para cada simulador se deberán catalogar todas las categorías del LOMES v.1.0 en tantas lenguas como estén producidos.

7.

Empaquetado

Todos los simuladores se entregarán empaquetados siguiendo el modelo de agregación SCORM 2004. Cada simulador dará lugar a un paquete por cada una de las lenguas, que incluirá tanto los contenidos como los metadatos en esa lengua. El simulador

Componentes SCORM

8. Navegación y trazabilidad •Los simuladores podrán emplearse en LMS y fuera de LMS. En ambos casos se podrán consultar los datos del aprovechamiento del usuario, y guardar cargar sesiones. •Tanto el estudiante como el docente accederán a ambas funcionalidades. •Esta información podrá consultarse si el simulador opera dentro de un LMS (desde la sección correspondiente en el mismo LMS) o fuera (desde un apartado específico en la interfaz del simulador).

8.1

Fuera de LMS

•En un navegador web (online o local). Los simuladores contarán con una página principal o índice, que será el punto de acceso a los contenidos. Se denominará SIM.html y actuará como lanzadera del simulador. •El simulador comprobará si está siendo desplegado fuera de un LMS y, entonces, activará el sistema de trazabilidad y persistencia para esta modalidad de uso. •Por persistencia,, el usuario podría guardar sesión en donde se encuentre para, en otro momento, “cargar partida”.

8.2

En un LMS SCORM 2004

El simulador comprobará si está siendo desplegado en un LMS SCORM. En este caso, activará el sistema de trazabilidad y persistencia mediante la SCORM API con objeto de comunicarse con el LMS.

Itinerario de aprendizaje (1 OA = Simulador)

Sistema de consulta de las estadísticas del usuario del LMS (Dokeos)

9. Arquitectura Los simuladores serán modulares (los módulos serán reutilizables). Hablamos de módulos de código (y, por tanto, de desagregación técnica). No confundir esta característica con la desagregación por niveles o desagregación de ODEs: los simuladores no son desagregables porque pertenecen al nivel 2(OA).

9. Arquitectura Por desagregación técnica, los elementos que conforman el simulador estarán ubicados en directorios que permitan extraerlos e independizarlos. La arquitectura facilitará la independencia del contenido del simulador con la lengua utilizada: todos los elementos dependientes de esta (textos, iconos, etc.) estén claramente localizados dentro de la estructura. También será posible que el SIM crezca a través de bibliotecas de casos.

10.Configuración y parametrización Los simuladores son configurables tanto en cantidad de problemas como en valores para cada situación planteada.

10.Configuración y parametrización •Incluirán ficheros de configuración (igual que existen de idiomas) que permitan cargar casos, actividades, opciones, etc. •Los parámetros podrán ser configurados por el usuario desde un panel amigable accesible desde la carcasa marco.

PAUTAS DE PRODUCCIÓN

ÍNDICE 5. TRAZABILIDAD Y PERSISTENCIA 5.1 En LMS 5.2 Fuera de LMS 6.

Modelos de datos del RUN TIME

TRAZABILIDAD • Elementos de partida. – Contenidos binarios. – Ficha Instruccional. – Otros aspectos de diseño y estilo proporcionados por Red.es

• Producto que se genera. Contenidos binarios con gestión de trazas. • Herramienta de catalogación Herramienta de edición que se esté usando para crear los contenidos binarios.

TRAZABILIDAD La adición de las trazas a los contenidos binarios, se realiza en el momento de creación de dichos contenidos: CREACIÓN CONTENIDOS BINARIOS

ADICIÓN DE TRAZAS A LOS CONTENIDOS BINARIOS

TRAZABILIDAD • La navegación en un paquete se describe y gestiona mediante el uso de JavaScript embebido en los documentos HTML que forman parte del contenido de los paquetes. • SCORM 2004 describe una API estándar de funciones JavaScript, que todo LMS compatible con este tipo de empaquetado debería tener implementado.

TRAZABILIDAD • La lógica de proceso de estas funciones puede ser modificada, e incluso se pueden definir más funciones de las que propone el API, en base a las funciones que se sabe que están implementadas. • Un script mínimo debe proporcionar funciones para inicializar y terminar la sesión de comunicación automáticamente si existe una instancia de la API de SCORM 2004.Además debe poner el estado de terminación del SCO a “completado” cuando el SCO termina.

TRAZABILIDAD •

El script debe implementar al menos 4 funciones básicas: – ScanForAPI(win).Esta función busca la existencia de una instancia de la API de SCORM 2004 en el sistema. – GetAPI(win).Esta función recupera una instancia de la API de SCORM 2004, en caso de existir en el sistema. – ScormInitialize(). Esta función inicializa la comunicación con una instancia de la API de SCORM 2004. – ScormTerminate().Esta función finaliza la comunicación con una instancia de la API de SCORM 2004.

TRAZABILIDAD Un SCO puede reportar a un LMS dos tipos de informaciones:

• –

Información de progreso, que puede ser a su vez de dos tipos: • •

–

Estado de completitud .Toma el valor de completado o no completado. Medida del progreso. Es un ratio entre lo que está realizado y lo que puede ser realizado, y se representa como un valor en coma flotante entre 0 (nada realizado) y 1 (completamente realizado).

Información del éxito, que puede ser a su vez de dos tipos: • •

Estado del éxito. Toma el valor de aprobado o fallado. Medida del éxito.Es un valor escalado en el rango entre 1.0 y 1.0, donde 0 representa no éxito, 1.0 representa éxito total, y los valores negativos representan penalizaciones.

TRAZABILIDAD •

•

Es recomendado usar JavaScript en el documento HTML que maneja la gestión de las sesiones de comunicación. Es recomendable que todas las comunicaciones entre ActionScript y la implementación de la API sean realizadas a través de funciones JavaScript descansando en la página HTML. Es importante enviar los datos si algo significante está ocurriendo, en vez de esperar a que finalice la película.

TRAZABILIDAD •

Hay dos formas de verificar que se ha gestionado correctamente la trazabilidad: – Cargar el paquete en el RunTime que ofrece ADL para SCORM 2004: http://www.adlnet.gov/downloads/downloadPag e.aspx?id=280 – Cargar el paquete en el RunTime online gratuito que ofrece Rustici: http://www.scorm.com/

TRAZABILIDAD FUERA DE LMS • •

•

Cuando un paquete se ejecuta fuera de un LMS, mediante ejecución local en un PC, no existe trazabilidad Cualquier intento de acceso a la API JavaScript SCORM desde AS generará una alerta de seguridad por parte de Flash cuando los SWF se ejecuten en este modo (local) Para evitar este problema, y ya que no es necesaria la trazabilidad, hay que evitar acceder a cualquier función JavaScript desde AS

TRAZABILIDAD FUERA DE LMS • • •

Se recomienda usar un patrón de estrategia, para variar el comportamiento dependiendo de si la ejecución es local o en un LMS Se puede usar la variable System.security.sandboxType para ver en qué modo se está ejecutando el SWF Esta variable es de sólo lectura, y permite saber en tiempo de ejecución qué modelo de seguridad se está ejecutando la película swf. De esta manera podemos saber si el OA se está ejecutando dentro de un LMS (valor remote) o en un PC en local (valor localWithFile).

TRAZABILIDAD FUERA DE LMS •

Una vez obtenido el valor de la variable es cuando podremos aplicar el patrón de estrategia, estableciendo comunicación con el LMS en el caso de que el OA se esté ejecutando dentro del mismo, o evitando esa comunicación en el caso de que la ejecución sea local. De esta manera evitaremos los errores que se muestran al usuario.

PERSISTENCIA En el protocolo de comunicación la normativa SCORM define un conjunto de campos/valores (DATAMODEL cmi) que se pueden almacenar en la base de datos del servidor LMS. Estos valores permiten:

•

• • •

Personalizar el contenido: por ejemplo, visualizar un feedback con el nombre del estudiante. Mejorar la navegación por el contenido: por ejemplo, guardar la última página vista. Registrar el seguimiento: guardar la puntuación para poder evaluar al estudiante.

PERSISTENCIA •

Por cada combinación SCO/estudiante, el LMS guarda este conjunto de campos/valores. Esto significa que, por ejemplo, a cada SCO de un curso le corresponde una puntuación por cada estudiante inscrito en el curso (y respectivamente un valor para cada campo definido en el datamodel, si se configura la API de SCORM para que envíe el valor al campo correspondiente).

CONEXIÓN Y REGISTRO •

En el LMS la conexión de los alumnos y profesores se realiza a través del propio LMS mediante una pantalla de login propia. En este punto, al detectar el simulador la existencia de plataforma, no se visualizarán las pantallas de login y carga de sesión que la aplicación incorpora. En el LMS el registro de los alumnos se realiza por el profesor (o el administrador de la plataforma) a través del propio sistema, dando de alta a los alumnos en el curso correspondiente. En cuanto al seguimiento del alumno, las diversas plataformas o LMS proporcionan mecanismos para visualizar el progreso de los alumnos.

PERSISTENCIA FUERA DE LMS La solución propuesta debería de cumplir los siguientes requisitos:

• – – – – – – – –

Sin instalación de ningún tipo de software adicional Modelo descentralizado, los datos de cómo el alumno utiliza el simulador deben guardarse en local Sin conectividad de red Posibilidad de guardar los datos en soporte externo, como un PenDrive, para poder cargarlos desde otro equipo Soporte multiusuario (varios usuarios pueden ejecutar la simulación desde la misma cuenta del equipo) Soporte multiplataforma Simplicidad Posibilidad de identificar a un usuario individual o funcionar con uno genérico (tipo invitado)

PERSISTENCIA FUERA DE LMS • •

Por ello, planteamos como solución el uso de Objetos Compartidos Locales de Flash (Local Shared Objects - LSO). Un LSO es una colección de datos almacenados como un fichero en un PC, y es un medio de mantener datos persistentes de manera local. Funcionan de manera parecida a las “Cookies” de un navegador.

PERSISTENCIA FUERA DE LMS Debido a que Flash Player de Adobe usa el “sandbox security model”, estos archivos no pueden ser creados en cualquier parte del sistema de ficheros, estando limitada su ubicación a un directorio concreto. La ubicación es dependiente del S.O., siendo estas las más comunes:

•

– – –

Windows: Dentro del directorio Datos de Aplicaciones del usuario logado, en Macromedia\FlashPlayer\SharedObjects Mac OS X: ~/Library/Preferentes/Macromedia/Flash Player GNU-Linux: ~/macromedia

PERSISTENCIA FUERA DE LMS •

•

Al ser conocida la ubicación de los LSO, el usuario puede copiarlos en algún soporte magnético, como un PenDrive, y trasladarlos a otro ordenador, donde podrá continuar con la simulación La principal ventaja de esta solución es la simplicidad; no es necesario instalar ningún tipo de software adicional, se puede usar directamente desde la API de Flash/Flex (ActionScript) sin necesidad de añadir ninguna librería externa, y es totalmente transparente para el usuario. Además, permite trasladar los ficheros generados entre distintos equipos, independientemente del S.O.

PERSISTENCIA FUERA DE LMS La implementación podría ser la siguiente:

• –

Guardado de sesión 1. 2.

3.

El usuario decide guardar el estado de la simulación para continuar en otro momento o en otro ordenador El sistema le presenta una lista de “sesiones” ya almacenadas para reutilizar o la posibilidad de crear una nueva. Habrá tantas sesiones como simulaciones cuyo estado se haya guardado previamente en esa cuenta de usuario Si se crea una nueva sesión el usuario introducirá un nombre para identificarla, no pudiendo existir más de una sesión con el mismo nombre

PERSISTENCIA FUERA DE LMS 4.

5.

Tanto si se selecciona una sesión ya existente como si se decide crear una nueva, el sistema pedirá el password de la sesión. Si es una sesión ya existente y el password no coincide, se mostrará un error y no se permitirá grabar en esa sesión Por motivos de seguridad, se recomienda que el password sea cifrado antes de guardarse en el LSO mediante un algoritmo de reducción criptográfico Una vez guardada la sesión se le mostrará al usuario la ubicación del fichero para que pueda copiarlo si así lo desea

PERSISTENCIA FUERA DE LMS –

Recuperado de sesión 1. 2. 3. 4. 5.

El usuario decide recuperar una sesión previamente guardada El sistema muestra una lista de sesiones, si existen, almacenadas previamente en local (una por cada LSO) El usuario escoge una sesión El sistema pide el password de la sesión seleccionada Si el password es correcto, el sistema carga la sesión y el usuario puede continuar la simulación en el estado en el que la salvó

PERSISTENCIA FUERA DE LMS Requisitos mínimos

• – –

Adobe Flash Player (cualquier versión o Macromedia Flash Placer v.6 ó superior Permiso de lectura/escritura en el directorio de almacenamiento de los LSO

Restricciones

• – –

Los LSO sólo pueden ser almacenados en un directorio específico, sin posibilidad de acceder a la totalidad del sistema de ficheros local. El límite de almacenamiento por defecto es de 100KB, pudiendo incrementarse hasta tamaño ilimitado si el usuario lo autoriza.

PERSISTENCIA FUERA DE LMS •

La persistencia de datos en los Shared Objects se guardará en variables con el mismo nombre que las definidas en el API de SCORM (DATAMODEL).

API JavaScript SCORM •

Para el intercambio de datos es necesario implementar las siguientes funciones: – ScormGetLastError().Esta función recupera un código que representa el estado de error de la sesión de comunicación después de la última llamada a la API. – ScormGetErrorString(Estado de Error). Esta función recupera el mensaje de error asociado a un estado error determinado especificado en sErr.

API JavaScript SCORM –

ScormGetValue(Elemento de datos). Esta función permite recuperar datos almacenados en el entorno de ejecución, hace uso de las funciones ScormGetLastError para detectar si se ha producido algún error, y de ScormErrorString para mostrar mensajes de error en caso de haberse producido alguno. Para ello toma como parámetros el elemento de datos del modelo CMI que se quiere consultar.

API JavaScript SCORM –

ScormSetValue(Elemento de datos,Valor).Esta función permite enviar datos para su almacenamiento en el entorno de ejecución. Para ello toma como parámetros el elemento de datos del modelo CMI que se quiere actualizar, y el valor con el que se quiere actualizar(se trata de valores predefinidos para cada elemento de datos).

API JavaScript SCORM • •

SCORM 2004 permite a un SCO crear hasta 250 registros de interacción. Cada registro contiene un identificador para esa interacción. Durante una sesión de comunicación, el entorno de ejecución almacena los registros en un array indexado. El array de interacciones solo persiste durante la sesión de comunicación y el entorno de ejecución puede usar distintas aproximaciones para almacenar estos registros entre sesiones.

API JavaScript SCORM •

La colección de registros de interacción no se encuentra almacenado en ningún orden determinado. Debido a esto último, en una comunicación posterior, los registros de interacción podrían aparecer en un orden diferente. En este sentido si se van a usar de una sesión previa, habría que encontrar que índice del array se le asignó en la nueva sesión, para lo cual se buscará los registros por el identificador de interacción.

API JavaScript SCORM Para gestionar esto se añaden nuevas funciones al script de SCORM: •

ScormInteractionGetCount no toma ningún parámetro y retorna un valor entero que representa el número de registros de interacción existentes.

API JavaScript SCORM •

ScormInteractionAddRecord toma como parámetro el identificador de una interacción y un tipo de interacción válida. Retorna un entero que corresponde al índice del array de registros o -1 si ocurre algún error. Si un registro de interacción con el mismo identificador y el mismo tipo ya existe, la function no hace nada y retorna el índice del registro existente. Si un registro de interacción con el mismo identificador pero con diferente tipo ya existe, la function falla. Si el número de registros de interacción permitidos se excediera por la adicción de un nuevo registro, la función fallaría.

API JavaScript SCORM –

ScormInteractionGetData toma como parámetro el identificador de la interacción y el elemento del modelo de datos dentro del registro de la interacción, y retorna un valor. Si el valor es una cadena vacía, podría indicar un posible error. La cadena que identifica el elemento de datos es la que aparece a la derecha de “interactions.n..” en la documentación de SCORM para el modelo de datos.

API JavaScript SCORM –

ScormInteractionGetIndex toma como parámetro el identificador de la interacción. Retorna un entero, que es el índice del registro de la interacción o -1 si el registro no existe. Se puede usar esta función para chequear si existe un registro para esa interacción.

API JavaScript SCORM –

ScormInteractionSetData toma como parámetro el identificador de una interacción, el elemento del modelo de datos dentro del registro de interacción y el valor a poner. Retorna cierto o falso. Si retorna falso, se puede analizar el estado de error. Dado que los datos no pueden ser almacenados en un registro de interacción hasta que el identificador es almacenado en el registro, y algunos datos no pueden ser almacenados apropiadamente a menos que el tipo de interacción sea conocida, la función fallará si el registro de interacción no ha sido creado previamente por una llamada ScormInteractionAddRecord. La cadena que identifica el elemento de datos es la que aparece a la derecha de “interactions.n..” en la documentación de SCORM para el modelo de datos.

DATAMODEL • Significado de las principales variables que usa la API de JavaScript: – cmi.comments_from_learner: texto para el usuario. – cmi.comments_from_lms: comentarios y anotaciones que se ofrecen al usuario – cmi.completionThreshold: indica cuánto ha progresado el usuario hacia la finalización del SCO

DATAMODEL – cmi.credit: indica si se calificará el rendimiento del usuario en este SCO. – cmi.entry: indica si el usuario ha accedido previamente al SCO – cmi.exit: indica cómo y por qué el usuario ha dejado el SCO. – cmi.interactions: define información relativa a una interacción para medida o verificación. – cmi.launch_data: datos específicos del SCO que éste puede usar para su iniciación. – cmi.learner_ide: identifica al usuario para el que se ha lanzado la instancia del SCO.

DATAMODEL – cmi.learner_name: nombre del usuario – cmi.learner_preference: preferencias del usuario asociadas al uso del SCO. – cmi.location: localización dentro del sco – cmi.max_time_allowed:tiempo máximo para ejecutar un intento del SCO. – cmi.mode:modos en los que puede presentarse el SCO al usuario. – cmi.objectives:objetivos de aprendizaje o rendimiento asociados al SCO

DATAMODEL – cmi.progress_measure: medida del progreso que el estudiante ha hecho hacia la terminación del SCO – cmi.scale_passing_score: puntuación escalada para un SCO – cmi.score: puntuación del usuario para el SCO – cmi.session_time: tiempo que ha pasado el usuario en la sesión actual del SCO – cmi.success_status:indica si el usuario ha superado el SCO – cmi.suspend_data: ofrece información creada por un SCO como resultado de interacción con un usuario

DATAMODEL – cmi.time_limit_action: indica qué debería hacer el SCO si se excede el tiempo máximo permitido. – cmi.total_time: tiempo acumulado de todos los intentos del usuario anteriores a la sesión actual.

MÁS INFO • Se recomienda consultar como documentación complementaria, aquella que se encuentra en la zona de documentación del sitio del proyecto, www.proyectoagrega.es:

PAUTAS DE EMPAQUETAMIENTO. USO DE AGREGA OFFLINE

ÍNDICE 1. 2. 3. 4. 5.

Requisitos previos Especificaciones técnicas Empaquetado. Aspectos a tener en cuenta Agrega Offline.

EJEMPLO EMPAQUETADO OA ENTREGA CONTACTOS/DUDAS

Requisitos previos Para seguir el contenido de estas transparencias es necesario conocer la especificación de empaquetamiento de SCORM 2004, y saber utilizar la herramienta Agrega Offline.

Especificaciones técnicas Respecto al empaquetamiento, el pliego establece que los simuladores deben ser paquetes SCORM 2004 de nivel de agregación 2 (Objetos de Aprendizaje (OA) según LOM-ES v1.0).

Empaquetado Físicamente un objeto de aprendizaje (OA), es un paquete formado por una única organización que dispone de un único item que referencia a un único recurso. Este recurso generalmente será una película Flash desde la que se llamará a otras películas Flash. Las condiciones de navegación están fijadas dentro de dichos archivos Flash.

Empaquetado • En esta fase productiva se parte de los siguientes elementos: – Archivos binarios – Archivo SIM.html

Empaquetado Archivos binarios

Empaquetado

Objeto SCORM 2004 Archivo SIM.html

Etiquetado

Empaquetado • El empaquetado de un OA requiere realizar las siguientes actividades: – Subir los contenidos binarios que se van a empaquetar a la herramienta de edición. – Convertir los contenidos binarios subidos en un recurso. – Crear un organization con un único item, y referenciar el recurso desde el mismo. – Etiquetar el paquete a nivel de organization. – Validar, previsualizar y guardar como un archivo .zip

Empaquetado El ciclo de vida del empaquetado de un OA es: UPLOAD CONTENIDOS BINARIOS

CREACIÓN RECURSO

CREACIÓN ORGANIZATION

VALIDAR , PREVISUALIZAR Y GUARDAR .ZIP

INSERTAR METADATOS

ASOCIAR RECURSO A ITEM

Ejemplo de empaquetado OA • Se va a desarrollar un ejemplo de creación de un OA denominado “El tamaño lineal de los objetos” formado por los archivos que se ven en la captura.

Ejemplo de empaquetado OA • Se abre la “Carpeta Personal”

Ejemplo de empaquetado OA • Se usa la opción de “Crear”

Ejemplo de empaquetado OA • Se rellena el título del ODE que se va a crear

Ejemplo de empaquetado OA • Se sube al área de Archivos los contenidos del OA. Para ello primero se zippean.

Ejemplo de empaquetado OA • A continuación se sube los contenidos zippeados.

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA • Se crea un recurso con el contenido subido:

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA • Se crea la organización con el item en la zona de Organizations.

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA • A continuación se cataloga el objeto seleccionando la opción de “Catalogar” desde la organización principal

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA

Ejemplo de empaquetado OA • Visualización final:

Aspectos a tener en cuenta – La herramienta de empaquetado a usar es Agrega Offline.¡¡NO SE PUEDEN USAR OTRAS HERRAMIENTAS DE EMPAQUETADO COMO RELOAD, DADO QUE NO ESTÁN ADAPTADAS A LAS NECESIDADES DEL PROYECTO.POR LO QUE NO PODRÁN CARGARSE LOS OBJETOS DESARROLLADOS CON ESTAS HERRAMIENTAS EN AGREGA!!

Aspectos a tener en cuenta – El empaquetado de un paquete debe realizarse siempre con el perfil Avanzado de Agrega Offline. El perfil Básico ofrece una vista limitada para generar paquetes SCORM 2004. ¡¡HAY QUE COMPROBAR SIEMPRE QUE EL PERFIL CONFIGURADO ES EL AVANZADO. EN CASO CONTRARIO SE DEBE CAMBIAR MEDIANTE LA OPCIÓN DE CONFIGURACIÓN DEL MENÚ PRINCIPAL DE AGREGA OFFLINE!!

Aspectos a tener en cuenta – Todo paquete debe gestionar la trazabilidad de los contenidos , y ésta se implementa en los propios contenidos binarios de forma simultánea con la creación de los mismos. ¡¡LA TRAZABILIDAD SON LLAMADAS A UNA API DE JAVASCRIPT ESTÁNDAR DEFINIDA EN SCORM 2004!! ¡¡AGREGA OFFLINE NO CUBRE NINGÚN ASPECTO DE LA TRAZABILIDAD: NO PUEDEN EDITARSE LOS CONTENIDOS PARA INTRODUCIR LAS LLAMADAS, NI GENERA LA API DE JAVASCRIPT NECESARIA. ÉSTA DEBE SER PROPORCIONADA JUNTO A LOS CONTENIDOS BINARIOS!!

Aspectos a tener en cuenta – Dado que en los contenidos se va a gestionar la trazabilidad de los mismos, el recurso que se cree a partir de los contenidos binarios debe declararse como SCO y no como ASSET.

Aspectos a tener en cuenta – Todo paquete debe contener entre los archivos binarios que lo forman un archivo especial denominado SIM.html. Este archivo debe permitir utilizar los contenidos del paquete fuera del contexto de un LMS, en el entorno de un navegador Web.¡¡EN LA GESTIÓN DE LA TRAZABILIDAD, SE DEBE TRATAR EL CASO DE QUE EL PAQUETE NO SE ENCUENTRE DENTRO DEL CONTEXTO DE UN LMS, PARA QUE EL USO DEL MISMO NO GENERE LLAMADAS DE ERROR, Y PUEDA NAVEGARSE POR EL MISMO!!

Aspectos a tener en cuenta – El archivo SIM.html es generado junto con los contenidos binarios. ¡¡AGREGA OFFLINE NO DA SOPORTE A LA CREACIÓN DEL ARCHIVO SIM.html!! – La ejecución del simulador mediante el archivo SIM.html COINCIDE CON EL ARCHIVO PRINCIPAL DEL ÚNICO RECURSO DEL PAQUETE, PERO “ELIMINA” LAS POSIBLES LLAMADAS A LA API DE JAVASCRIPT O BIEN SE TRATAN EN LAS PROPIAS FUNCIONES JAVASCRIPT.

Aspectos a tener en cuenta • Agrega es capaz de generar un archivo especial index.html, diferente del archivo SIM.html anteriormente mencionado, el cual simula el previsualizador de Agrega fuera del contexto de Agrega.

Aspectos a tener en cuenta – Si un paquete requiere secuenciación condicionada, está deberá estar implementada en el contenido binario. ¡¡NUNCA SE USARÁ IMS SIMPLE SEQUENCING!! – Un paquete sin etiquetar correctamente es un paquete no valido, aunque se pueda guardar como un .zip. ¡¡SIEMPRE HAY QUE VALIDAR ANTES DE GUARDAR EL PAQUETE COMO UN .zip!!

Aspectos a tener en cuenta - Todo paquete debería tener en su interior: – Esquemas de LOM-ES y SCORM 2004 – Archivo imsmanifest.xml – Carpetas o archivos de los contenidos binarios que conforman el paquete. – API JavaScript. – SIM.html

CATALOGACIÓN

ÍNDICE

CATALOGACIÓN EJEMPLO CATALOGACIÓN DOCUMENTACIÓN

REQUISITOS PREVIOS Para seguir el contenido de estas transparencias es necesario conocer y saber utilizar las especificaciones: –Perfil de aplicación LOM-ES. –SCORM 2004 (IMS Content Packaging, IMS Simple Sequencing , API de JavaScript de SCORM 2004). –Taxonomías y tesauros: ETB, Árbol Curricular, Nivel Educativo, Accesibilidad, Disciplina y Competencia.

CATALOGACIÓN • Elementos de partida. – Paquete SCORM 2004 – Ficha Instruccional. – Otros aspectos de diseño y estilo proporcionados por Red.es – Agrega Offline

• Producto que se genera. Paquete SCORM 2004 etiquetado. • Herramienta de catalogación Agrega Offline

CATALOGACIÓN • Ciclo de vida: Archivos

Parte del ciclo de vida cubierto

Recursos Crear organización Objetos Aprendizaje

Etiquetado

Empaquetado

CATALOGACIÓN • Dentro de un paquete, existen diferentes lugares en los que se pueden introducir metadatos: – – – –

Nivel Nivel Nivel Nivel

de de de de

objeto Organización. item. Recurso.

• En cualquiera de los metadatos, “Catalogar”

los es

casos, la forma de asociar mediante la opción de

CATALOGACIÓN • Todo paquete SCORM 2004 debe estar catalogado con respecto al perfil de aplicación LOM-ES. ¡¡SOLO SE CATALOGA A NIVEL DE PAQUETE!!

• Para catalogar el paquete se usará la funcionalidad de catalogación de Agrega Offline. ¡¡SE DEBE USAR ESTRICTAMENTE AGREGA OFFLINE. CUALQUIER OTRA HERRAMIENTA DE CATALOGACIÓN COMO RELOAD, DARÁ LUGAR A PAQUETES INVALIDOS!!

CATALOGACIÓN • Todo paquete catalogado debe validarse su catalogación a través de la función de validación de Agrega Offline. ¡¡UN PAQUETE CON ERRORES DE CATALOGACIÓN PUEDE SER GUARDADO COMO UN ARCHIVO .ZIP, POR LO QUE LA POSIBILIDAD DE GUARDAR COMO UN .ZIP, NO ASEGURA QUE EL PAQUETE SEA CORRECTO!!

CATALOGACIÓN •

En los formularios que ofrece Agrega Offline para rellenar las categorías de metadatos de LOM-ES es necesario rellenar:

– Todos los campos obligatorios que indica LOM-ES.

¡¡EN AGREGA OFFLINE HAY UN INDICATIVO GRÁFICO CON * QUE INDICA ESTOS CAMPOS!! – Aquellos campos que de manera explícita Red.es, haya indicado a través de la documentación que se entrega en cada Proyecto. – Una instancia de la categoría 9, por cada taxonomía y tesauro indicados para estos proyectos: ETB, Árbol Curricular, Accesibilidad, Nivel Educativo, Competencias y Disciplina. ¡¡EN AGREGA OFFLINE SE PUEDEN INCLUIR TANTAS INSTANCIAS DE LA CATEGORIA 9 COMO SISTEMAS DE CLASIFICACIÓN SE USEN PARA CATALOGAR!

CATALOGACIÓN • Todos los campos con texto libre deben describirse en el idioma principal del paquete, y debe señalarse dicho idioma mediante el atributo del idioma que acompaña a estos campos. ¡¡ESTE ES UN FALLO HABITUAL. ESCRIBIR EL VALOR DE TEXTO LIBRE Y NO INDICAR EL IDIOMA DE DICHO VALOR!! • Los campos con vocabularios definidos, deben describirse en inglés. Si se usa Agrega Offline, estos campos se distinguen del resto al tratarse de campos con listas desplegables, y salvo manipulación, no debería poderse rellenar de otra forma que con el término del desplegable.

CATALOGACIÓN • Existe una documentación explícita de cómo rellenar la categoría 9 con cada una de las taxonomías y tesauros, que puede encontrarse en la web del proyecto Agrega. www.proyectoagrega.es

• Salvo indicación explícita, solo se rellenan los metadatos a nivel de paquete, y nunca para otros elementos más internos tales como items, recursos,etc.

CATALOGACIÓN • La verificación de la corrección de los aspectos sintácticos del etiquetado del paquete se realizará a través de la función de validación que presenta Agrega Offline en la zona de catalogación o de edición del paquete (en ambas zonas se validan los metadatos). • La validación de los aspectos semánticos de la catalogación sólo se pueden verificar manualmente.

PROPUESTA CATALOGACIÓN • •

•

• • •

•

Los valores presentados refieren a la documentación de LOM-ES v1.0. En la producción de los ODE relativos al exp. 729 se exige la catalogación de los campos aquí descritos aunque no sean obligatorios según LOM-ES. Los valores de las columnas Nombre y Ejemplo se presentan en castellano, sin embargo en los ficheros xml, todos los valores pertenecientes a vocabularios definidos se deberán poner en su correspondiente idioma y en minúsculas. Los valores de los vocabularios controlados siempre irán en inglés, aunque en los ejemplos de este documento aparezcan en castellano. En el fichero xml es mejor que no aparezcan los tags de los campos que no se vayan a completar. Todas las etiquetas referidas a vocabularios controlados deberán llevar el siguiente tag: LOMESv1.0 El orden en el que aparecen los tags en el xml es importante y hay que respetarlo.

PROPUESTA CATALOGACIÓN DEFINICIÓN DE CATEGORÍAS: 1.

CATEGORÍA GENERAL: Agrupa la información general que describe el objeto de manera global.

2.

CATEGORÍA CICLO DE VIDA: Agrupa las características relacionadas con la historia y el estado actual del objeto, y aquellas que le han afectado durante su evolución.

3.

CATEGORÍA META- METADATOS: Agrupa la información sobre la propia instancia de metadatos. (quien es el responsable de la documentación, cuando, etc.).

4.

CATEGORÍA TÉCNICA: Agrupa los requerimientos y características técnicas del objeto.

5.

CATEGORÍA USO EDUCATIVO: Agrupa las características educativas y pedagógicas del objeto.

6.

CATEGORÍA DERECHOS: Agrupa los derechos de propiedad intelectual y las condiciones para el uso del objeto.

7.

CATEGORÍA RELACIÓN: Agrupa las características que definen la relación entre este objeto y otros objetos digitales relacionados.

8.

CATEGORÍA ANOTACIÓN: Permite incluir comentarios sobre el uso educativo, e información sobre cuándo y por quién fueron creados dichos comentarios.

9.

CATEGORÍA CLASIFICACIÓN: Describe este objeto en relación a un determinado sistema de clasificación.

PROPUESTA CATALOGACIÓN Nº

Nombre

1

General

1.1

Identificador

Criterios de catalogación

Ejemplo

Comentarios

En este campo vamos a utilizar un catálogo creado para el proyecto que se llama Catálogo unificado mec-red.es-ccaa de identificación y además la plataforma AGREGA asignará automáticamente otro identificador propio de la plataforma (UUID) cuando se carguen los Objetos en ella.

1.1.1

Catálogo

Valor Fijo para todas las OAs

1.1.2

Entrada

Ver documento identificador

es_20090130_2_7241200

1.2

Título

Título según la ficha de diseño instructivo

Imágenes de Tomografía

1.3

Idioma

Idioma del SD/OA según la traducción. Seleccionar entre los valores: es, en, ca, gl, eu, va

1.4

Descripción

Descripción del objeto en 40-60 palabras para usar como texto alternativo en pantalla o breve descripción al referirse al objeto

1.5

Palabra Clave

En múltiples instancias se han de incluir un conjunto de valores de texto libre

es

Para SD y OA no se usa la instancia "CARACTERÍSTICAS". La instancia "características" solamente se usa para los objetos de nivel 1. volantes, enfermera, bata, tac, paciente, celador, tomografía, emulador

Ámbito

Época, cultura, zona geográfica o región a la que se refiere el contenido.

1.7

Estructura

Estructura organizativa del objeto. Se selecciona un valor de un vocabulario. En general tanto para SD como para OA se seleccionará el término "lineal". En el caso de tratarse de un objeto indivisible se pondrá atómica.

“Lineal”, atómica, colección, en red y jerárquica

1.8

Nivel de Agregación

Valores fijos: Para un SD el valor es "3", para un OA el valor es "2" y para medias y medias integrados "1"

2

1.6

Aunque en la norma ISO 639-1988 sólo figuran las siguientes lenguas de España: español, gallego, catalán y vasco, vamos a usar va para valenciano

universal

IMPORTANTE: meter todas las palabras clave en minúsculas, excepto si hubiera nombres propios… No se debe rellenar por defecto España, Internet en el Aula. Se debe poner el lugar y/o época al que se refiere el contenido, o dejarlo en blanco pues es un campo opcional. Se podría elegir un descriptor genérico para algunos contenidos que no se refieren a ninguna época en concreto ni a ningún lugar, por ejemplo: universal

En este caso Jerárquica

PROPUESTA CATALOGACIÓN Nº

Nombre

2

Ciclo de Vida

2.1

Versión

Criterios de catalogación

Ejemplo

Ya que únicamente se va a etiquetar la versión entregable y no los prototipos previos, se usará el valor "V1.0"

V1.0

Comentarios

final

2.2

Estado

2.3

Contribución

2.3.1

Tipo

2.3.2

2.3.3

En este campo vamos a utilizar un catálogo creado para el proyecto que se llama Catálogo unificado mec-red.es-ccaa de identificación y además la plataforma AGREGA asignará automáticamente otro identificador propio de la plataforma (UUID) cuando se carguen los Objetos en ella.

Ya que únicamente se va a etiquetar la versión entregable y no los prototipos previos, se usará el valor "final"

"Se usará el valor ""proveedor de contenidos"" (content provider) y otra instancia para ""editor de la publicación"" (publisher)"

Entidad

"Se usará una VCARD con el valor de Organización (una para el proveedor de contenidos y otra para el editor de la publicación)"

Fecha

"Fecha de entrega. aaaa-mm-dd Misma fecha para la instancia de Publisher"

BEGIN:VCARD VERSION 3.0 FN:EMAIL; TYPE=INTERNET:ORG:ONECLICK END:VCARD

"2009-01-302009-01-30"

"El formato de Vcard es el siguiente (manteniendo los saltos de línea y los campos vacíos en caso de que no se rellenen):BEGIN:VCARD VERSION:3.0 FN:EMAIL;TYPE=INTERNET:ORG:END:VCARD No hace falta mantener la expresión regular, han de ir todos los elementos, no hace falta respetar los saltos de línea (solo un espacio entre cada elemento)" Proponemos poner una fecha distinta para cada una de las entregas (entendiendo por entrega un conjunto de SDs con sus OAs y sus medias, por ejemplo las que coinciden con los hitos de facturación)

PROPUESTA CATALOGACIÓN Nº

Nombre

3

MetaMeta-Metadatos

3.1

Identificador

3.1.1

Catálogo

3.1.2

Entrada

3.2

Contribución

3.2.1

Tipo

Criterios de catalogación

Ejemplo

Ya que únicamente se va a etiquetar la versión entregable y no los prototipos previos, se usará el valor "V1.0"

V1.0

Valor Fijo para todas las SD y OA

Catálogo unificado mec-red.es-ccaa-meta de identificación de instancias de metadatos de ODE

Comentarios

Se pueden incluir tantos identificadores como se desee. Sigue los mismos criterios que el Catálogo unificado mec-red.es-ccaa de identificación de ODE pero al final se añade ""-meta"""

es_20090130_3_7241200-meta

El código deberá coincidir con el del 1.1.2 pero añadiendo -meta al final

Se usará el valor "creador" (creator) y otra instancia para "revisor" (validator)

"creador” empresa revisor“ RED

"El formato de Vcard es el siguiente (manteniendo los saltos de línea y los campos vacíos en caso de que no se rellenen):BEGIN:VCARD VERSION:3.0 FN:EMAIL;TYPE=INTERNET:ORG:END:VCARD No hace falta mantener la expresión regular, han de ir todos los elementos, no hace falta respetar los saltos de línea (solo un espacio entre cada elemento)" "El formato de Vcard es el siguiente (manteniendo los saltos de línea y los campos vacíos en caso de que no se rellenen):BEGIN:VCARD VERSION:3.0 FN:EMAIL;TYPE=INTERNET:ORG:END:VCARD Pero no hace falta mantener la expresión regular, así que han de ir todos los elementos pero no hace falta respetar los saltos de línea (solo un espacio entre cada elemento)" Poner la misma fecha que en 2.3.3

Consultar documento Identificador_729_V01.doc

3.2.2

Entidad

"Se usará una VCARD con el valor de Organización (una para el creador y otra para el revisor)"

"BEGIN:VCARD VERSION 3.0 FN: EMAIL;TYPE=INTERNET:ORG:ONECLICK END:VCARDBEGIN:VCARD VERSION 3.0 FN:Contenido digital educativo creado, catalogado y financiado con fondos FEDER dentro del expediente 729/08-Lote1 EMAIL;TYPE=INTERNET:[email protected] ORG:RED.ES END:VCARD"

3.2.3

Fecha

"Fecha de entrega. aaaa-mm-dd Misma fecha para la instancia de validador"

"2009-01-30 2009-01-30"

3.3

Esquema de Metadatos

Se utilizará el valor: “LOM-ES v1.0” o "LOM-ES v.1.0"

LOM-ES v.1.0

3.4

Idioma

Idioma de los metadatos según la traducción. Seleccionar entre los valores: es, en, ca, gl, eu, va, fr

es

Aunque en la norma ISO 639-1988 sólo figuran las siguientes lenguas de España: español, gallego, catalán y vasco, vamos a usar va para valenciano

PROPUESTA CATALOGACIÓN Nº

Nombre

4

Técnica

4.1

Formato

Criterios de catalogación

Ejemplo

Tipos MIME usados en el objeto. Se utilizarán varios valores en instancias separadas, en la mayor parte de los casos serán siempre los mismos

"text/html audio/mpeg application/x-shockwave-flash text/xml application/pdf image/jpg image/gif"

Comentarios

Este punto ha de ser descrito por part e de las empresas

18976545

4.2

Tamaño

4.3

Localización

4.4

Requisitos

4.4.1

AgregadorOR

4.4.1.1

Tipo

Tamaño en Bytes

Ha pasado a ser un campo recomendado y de momento no hay que rellenarlo.

Varias instancias. Utilizaremos el campo "sistema operativo" con el valor "multi-os" y el campo "navegador" con el valor "any"

"sistema operativo navegador"

PROPUESTA CATALOGACIÓN 4.4.1.2

Nombre

Varias instancias. Utilizaremos el campo "Sistema Operativo" con el valor "multi-so" y el campo "Navegador" con el valor "Cualquiera"

4.4.1.3

Versión Mínima

N/A

4.4.1.4

Versión Máxima

N/A

4.5

Pautas de Instalación

4.6

Otros Requisitos de Plataforma

Otros comentarios técnicos. En principio usaremos siempre el mismo texto

4.7

Duración

Duración del objeto en uso normal. Solo es relevante para determinados tipos de objetos de nivel de agregación 1.

multi-so cualquiera

No requiere instalación

Tarjeta de sonido, Tarjeta gráfica con resolución de como mínimo 800x600 píxeles x 256 colores. Flash plug-in flash 8.0 o superior.

Se podría resumir en: Plug-in de Flash Player y Tarjeta de sonido Si veis necesario incluir algún aspecto de la tarjeta gráfica o de sonido pues también.

PROPUESTA CATALOGACIÓN Nº

Nombre

Criterios de catalogación

Ejemplo

5

Uso Educativo

5.1

Tipo de interactividad

Se seleccionará uno de estos valores: expositivo, activo o combinado

combinado

5.2

Tipo de Recurso Educativo

"En múltiples instancias se han de seleccionar un conjunto de valores del siguiente vocabulario (se utiliza únicamente la categoría 'Contenido didáctico'):lecturas guiadas, lección magistral, comentario de texto-imagen, actividad de discusión, ejercicio o problema cerrado, caso contextualizado, problema abierto , escenario real o virtual de aprendizaje, juego didáctico, webquest, experimento, proyecto real, simulación, cuestionario, examen, autoevaluación"

5.3

Nivel de Interactividad

Se seleccionará uno de estos valores: muy bajo, bajo, medio, alto, muy alto.

Muy alto

5.4

Densidad Semántica

Se seleccionará uno de estos valores: muy baja, baja, media, alta, muy alta.

Alta

5.5

Destinatario

En múltiples instancias se seleccionarán los siguientes valores: "alumno, individual, docente"

"alumno individual docente "

5.6

Contexto

"En múltiples instancias se seleccionarán los siguientes valores: ""aula, domicilio, mixto, docente, familia, compañero, independiente, mixta, presencial, semipresencial, distancia"""

"aula domicilio mixto docente independiente mixta presencial semipresencial distancia"

Simulador Escenario real o virtual de aprendizaje.

Comentarios

PROPUESTA CATALOGACIÓN 5.7

Rango Típico de Edad

Rango de edad del usuario. Se deduce del nivel educativo y se expresa en edad mínima - edad máxima

5.8

Dificultad

Se seleccionará uno de estos valores: muy fácil, fácil, medio, difícil, muy difícil

5.9

Tiempo Típico de Aprendizaje

5.10

Descripción

"Descripción del uso del objeto educativo. Estructurado en tres instancias: Conocimiento previo Objetivos didácticos Tipo de Conocimiento: seleccionar a partir del vocabulario: ""declarativo, procedimental, condicional, metacognitivo"""

Conocimiento previo: Objetivos didácticos:

5.11

Idioma

Idioma del destinatario. En general se seleccionará entre los valores "es, ga, ca, eu y va" ya que en principio no se han creado contenidos para alumnos con idioma materno inglés

es

Proceso Cognitivo

En múltiples instancias se seleccionarán algunos de entre los siguientes valores: "analizar, aplicar, colaborar, comparar, compartir, competir, comprender, comprobar, comunicar, contextualizar, controlar, cooperar, crear, decidir, definir, describir, discutir, diseñar, evaluarse, explicar, extrapolar, innovar, investigar, juzgar, motivar, observar, organizar, organizarse, planificar, practicar, producir, reconocer, recordar, redactar, reflexionar, relacionar, representar, resolver, simular, sintetizar, valorar"

"analizar aplicar comprender contextualizar controlar describir investigar"

5.12

Tiempo que el destinatario tarda en asimilar el contenido. (Viene en la ficha de diseño instructivo)

14-23

"Este campo es de texto libre pero lo vamos a homogeneizar poniendo edad mínima, edad máxima y una descripción (cuando sea necesario).

difícil

PT(tiempo)H

Todos los campos duración y fecha tienen 2 etiquetas, una para la codificación del tiempo o de la fecha y otra para una descripción (texto libre)

PROPUESTA CATALOGACIÓN Nº

Nombre

Criterios de catalogación

Ejemplo

6

Derechos

6.1

Coste

Siempre el valor "no"

no

Derechos de Autor y otras Restricciones

Siempre el valor: "Creative Commons: Reconocimiento - No Comercial - Compartir Igual"

6.2

Comentarios

creative commons: reconocimiento - no nomercial - compartir igual

En caja baja: creative commons: reconocimiento - no comercial - compartir igual

Siempre la misma descripción

La utilización de estos contenidos es universal, gratuita y abierta, siempre y cuando se trate de un uso educativo no comercial. Las acciones, productos y utilidades derivadas de su utilización no podrán, en consecuencia, generar ningún tipo de lucro. Asimismo, es obligada la referencia a la fuente.

Los derechos no se aplican solo a España. Podría ser algo así: La utilización de estos contenidos es universal, gratuita y abierta, siempre y cuando se trate de un uso educativo no comercial. Las acciones, productos y utilidades derivadas de su utilización no podrán, en consecuencia, generar ningún tipo de lucro. Asimismo, es obligada la referencia a la fuente.

6.3

Descripción

6.4

Acceso

6.4.1

Tipo de acceso

Siempre el valor "universal“

universal

6.4.2

Descripción

Siempre la misma descripción

No existen restricciones

PROPUESTA CATALOGACIÓN Nº

Nombre

Criterios de catalogación

Ejemplo

Comentarios

7

Relació Relación

7.1

Tipo

Solo completar si es un OA

no

es parte de (si es un OA que forma parte de una SD)

7.2

Recurso

7.2.1

Identificador

7.2.1.1

Catálogo

Catálogo unificado mec-red.es-ccaa de identificación de ODE

7.2.1.2

Entrada

Identificador de la SD (1.1.2.) de la que es parte este OA

7.2.2

Descripción

Poner la descripción del campo 1.4 de la SD de la que es parte el OA

Recordad que todos los vocabularios controlados van siempre en inglés.

PROPUESTA CATALOGACIÓN Nº

Nombre

Criterios de catalogación

8

Anotació Anotación

8.1

Entidad

N/A

8.2

Fecha

N/A

Ejemplo

Comentarios

N/A

8.3

Descripción

Recordad que todos los vocabularios controlados van siempre en inglés.

PROPUESTA CATALOGACIÓN Nº

Nombre

9

Clasificació Clasificación

9.1

Propósito

9.2

Ruta Taxonómica

9.2.1

Fuente

9.2.2

Taxón

9.2.2.1

9.2.2.2

9.3

9.4

Identificador

Entrada

Criterios de catalogación

Ejemplo

Se realizarán múltiples instancias de este campo, abordando los valores "accesibilidad", "disciplina" , "competencia" y "nivel educativo"

"accesibilidad disciplina competencia nivel educativo"

Para cada uno de los propósitos seleccionados se eligen como fuente los vocabularios correspondientes

Para cada uno de los propósitos seleccionados se eligen múltiples instancias de entre los vocabularios correspondientes

"ID valores seleccionados en accesibilidad ID valores seleccionados en disciplina ID valores seleccionados en competencia ID valores seleccionados en nivel educativo Ejemplo sobre el nivel educativo 2 "

Para cada uno de los propósitos seleccionados se eligen múltiples instancias de entre los vocabularios correspondientes

"valores seleccionados en accesibilidad valores seleccionados en disciplina valores seleccionados en competencia valores seleccionados en nivel educativo Ejemplo sobre el nivel educativo Educación infantil " Ejemplo para descripción de accesibilidad: Se trata de un recurso con adaptabilidad alta

Descripción

Palabra clave

"Restricciones de accesibilidad: “Accesibilidad LOM-ESv1.0” Nivel educativo: “Nivel educativo LOM-ESv1.0” Competencia: “Competencia LOM-ESv1.0” Y para Disciplina usaremos 2:“Árbol curricular LOE 2006” “ETB MEC-CCAA V.1.0” “ETB-LRE MEC-CCAA V.1.0” "

Se hande incluir en múltiples instancias, un conjunto de valores de texto libre.

Visual

Comentarios

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

ENTREGA DE LOS SIMULADORES COMO PAQUETES ZIP Y LA VALIDACIÓN DE RED.ES Exp. 729/07-SD

ASPECTOS A TENER EN CUENTA: 1. 2. 3. 4.

Pilotaje de la versión candidata a definitiva en castellano Pautas generales para entrega de versiones definitivas Validación técnica y funcional Entregable físico: versión definitiva, fuentes y documentación

PILOTAJE DE LA VERSIÓN CANDIDATA A DEFINITIVA EN CASTELLANO Red.es procederá a pilotar la primera entrega para asegurar el avance del proyecto Los adjudicatarios contarán con pautas y herramientas de validación (como plantillas en XML) para que realicen las pruebas para agilizar el proceso de validación técnico.

PAUTAS GENERALES PARA ENTREGA DE VERSIONES DEFINITIVAS Se entregará un zip que incluya la catalogación y el empaquetado en un DVD correctamente etiquetado indicando fecha, empresa y datos identificativos del simulador. La estructura modular característica de un OA obliga a empaquetar todos los elementos que lo conforman como un archivo único de extensión ZIP, requisito necesario para su efectiva publicación en Agrega y para su carga en un LMS (Learning Management System). Su nomenclatura se ajustará a las indicaciones dadas a cada adjudicatario y que están recogidas en el Manual de Referencia

El zip irá acompañado de una Hoja de entrega (a modo de Checklist) que seguirá una plantilla elaborada por Red.es. En ella se indicará los detalles de la entrega y el cumplimiento de los requisitos técnicos (compatibilidad, accesibilidad, usabilidad, catalogación, empaquetado, navegación y trazabilidad, independencia del contenido en la arquitectura…..).

VALIDACIÓN TÉCNICA Y FUNCIONAL Red.es procederá a validar técnica y funcionalmente los paquetes entregados En el caso de encontrar errores, el adjudicatario recibirá un Informe de Validación donde según el tipo de error encontrado se aportarán detalles y/o soluciones. En ningún caso la validación de Red.es debe sustituir el control de calidad que deben hacer los adjudicatarios Una vez emitido el Certificado de Validación, el adjudicatario procederá a la entrega final facturable.

ENTREGABLE FÍSICO: VERSIÓN DEFINITIVA, FUENTES Y DOCUMENTACIÓN El entregable físico, que permite la aceptación de la factura, deberá ser en DVD con:

-el archivo .zip validado -los ficheros fuente de todos los contenidos desarrollados en cualquier formato -y la documentación asociada a cada uno de ellos.

Referencias SCORM ® 2004 3rd Edition Documentation En: http://www.adlnet.gov/scorm/20043ED/Documentation.aspx Proyecto Agrega En: http://www.proyectoagrega.es Pliego de cláusulas técnicas que regirán la realización de cuatro contratos de “servicios de elaboración de entornos de simulación para formación profesional”. Exp. 729/07-SD. Procedimiento abierto. (Sin publicar) GT9 / GT8 - SC 36/AENOR Perfil de aplicación LOM-ES1 V.1.0. En: http://www.proyectoagrega.es/documentos/Productores%20de%20 contenidos/Etiquetado/Normas%20de%20etiquetado/lomes_v1.pdf