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.esAna Á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íficoIdentificar 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.

Técnicas DidácticasTécnico-didácticas

Tipos de restricciones

En este seminario vamos tratar exclusivamente de las restricciones:

•Técnicas•Técnico-didácticas

Conceptos generalesDefinición

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

•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.

Características generalesde los simuladores

1. Compatibilidad2. Fidelidad física y de percepción3. Accesibilidad4. Multilingüismo5. Usabilidad (navegación, pistas y retroalimentación,

visualización, impresión, tratamiento de textos)6. Catalogación7. Empaquetado8. Trazabilidad y persistencia (fuera de LMS y en LMS

SCORM 20049. Arquitectura10. 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 guiada5.2 Pistas y retroalimentación5.3 Visualización optimizada5.4 Impresión preconfigurada5.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

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.

Resolución de pantalla

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 textosen 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 textosen 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 desagregablesporque 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

ÍNDICE5. TRAZABILIDAD Y PERSISTENCIA5.1 En LMS5.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.

CREACIÓN CONTENIDOS

BINARIOS

ADICIÓN DE TRAZAS A LOS CONTENIDOS

BINARIOS

La adición de las trazas a los contenidos binarios, se realiza en el momento de creación de dichos contenidos:

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

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


• 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).


• 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ónen 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)


• 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.


• 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áscomunes:– 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


• 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.


• La implementación podría ser la siguiente:– Guardado de sesión

1. El usuario decide guardar el estado de la simulación para continuar en otro momento o en otro ordenador

2. 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

3. 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


4. 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

5. Una vez guardada la sesión se le mostrará al usuario la ubicación del fichero para que pueda copiarlo si así lo desea


– Recuperado de sesión1. El usuario decide recuperar una sesión previamente

guardada2. El sistema muestra una lista de sesiones, si existen,

almacenadas previamente en local (una por cada LSO)3. El usuario escoge una sesión4. El sistema pide el password de la sesión seleccionada5. 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ó


• 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.


• 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 SCORMPara 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.

• 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

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

ÍNDICE1. Requisitos previos2. Especificaciones técnicas3. Empaquetado.4. Aspectos a tener en cuenta5. Agrega Offline.

EJEMPLO EMPAQUETADO OAENTREGACONTACTOS/DUDAS

Requisitos previosPara 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).

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

Empaquetado• En esta fase productiva se parte de los siguientes

elementos:– Archivos binarios– Archivo SIM.html

Archivo SIM.html

Etiquetado

EmpaquetadoArchivosbinarios

ObjetoSCORM 2004

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

UPLOAD CONTENIDOS

BINARIOS

CREACIÓNRECURSO

CREACIÓN ORGANIZATION

ASOCIAR RECURSO A ITEM

INSERTAR METADATOS

VALIDAR , PREVISUALIZAR Y

GUARDAR .ZIP

El ciclo de vida del empaquetado de un OA es:

Empaquetado

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.

• Se abre la “Carpeta Personal”


• Se usa la opción de “Crear”


• Se rellena el título del ODE que se va a crear


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


• A continuación se sube los contenidos zippeados.


• Se crea un recurso con el contenido subido:


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


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


• Visualización final:


– 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!!


– 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!!


– 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.


– 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!!


– 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.


• 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.


– 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!!


- 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


CATALOGACICATALOGACIÓÓNN

ÍÍNDICENDICE


EJEMPLO CATALOGACIEJEMPLO CATALOGACIÓÓNN

DOCUMENTACIDOCUMENTACIÓÓNN

REQUISITOS PREVIOSREQUISITOS PREVIOS

Para seguir el contenido de estas transparencias es Para seguir el contenido de estas transparencias es necesario conocer y saber utilizar las necesario conocer y saber utilizar las especificaciones: especificaciones:

––Perfil de aplicaciPerfil de aplicacióón LOMn LOM--ES.ES.––SCORM 2004 (IMS SCORM 2004 (IMS ContentContent PackagingPackaging, IMS , IMS Simple Simple SequencingSequencing , API de JavaScript de , API de JavaScript de SCORM 2004).SCORM 2004).––TaxonomTaxonomíías y tesauros: ETB, as y tesauros: ETB, ÁÁrbol Curricular, rbol Curricular, Nivel Educativo, Accesibilidad, Disciplina y Nivel Educativo, Accesibilidad, Disciplina y Competencia.Competencia.

CATALOGACICATALOGACIÓÓNN• 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ónAgrega Offline

•• Ciclo de vida:Ciclo de vida:

Recursos

Objetos Aprendizaje

Crear organización Etiquetado Empaquetado

Archivos

Parte del ciclo Parte del ciclo de vida de vida

cubiertocubierto


•• Dentro de un paquete, existen diferentes lugares Dentro de un paquete, existen diferentes lugares en los que se pueden introducir metadatos:en los que se pueden introducir metadatos:–– Nivel de objetoNivel de objeto–– Nivel de OrganizaciNivel de Organizacióón.n.–– Nivel de item.Nivel de item.–– Nivel de Recurso.Nivel de Recurso.

•• En cualquiera de los casos, la forma de asociar En cualquiera de los casos, la forma de asociar los metadatos, es mediante la opcilos metadatos, es mediante la opcióón de n de ““CatalogarCatalogar””


•• Todo paquete SCORM 2004 debe estar catalogado con Todo paquete SCORM 2004 debe estar catalogado con respecto al perfil de aplicacirespecto al perfil de aplicacióón LOMn LOM--ES.ES.

¡¡¡¡SOLO SE CATALOGA A NIVEL DE PAQUETE!!SOLO SE CATALOGA A NIVEL DE PAQUETE!!

•• Para catalogar el paquete se usarPara catalogar el paquete se usaráá la funcionalidad de la funcionalidad de catalogacicatalogacióón de Agrega n de Agrega OfflineOffline..

¡¡¡¡SE DEBE USAR ESTRICTAMENTE AGREGA OFFLINE. SE DEBE USAR ESTRICTAMENTE AGREGA OFFLINE. CUALQUIER OTRA HERRAMIENTA DE CATALOGACICUALQUIER OTRA HERRAMIENTA DE CATALOGACIÓÓN N

COMO RELOAD, DARCOMO RELOAD, DARÁÁ LUGAR A PAQUETES LUGAR A PAQUETES INVALIDOS!!INVALIDOS!!


•• Todo paquete catalogado debe validarse su Todo paquete catalogado debe validarse su catalogacicatalogacióón a travn a travéés de la funcis de la funcióón de validacin de validacióón n de Agrega de Agrega OfflineOffline..

¡¡¡¡UN PAQUETE CON ERRORES DE CATALOGACIUN PAQUETE CON ERRORES DE CATALOGACIÓÓN PUEDE N PUEDE SER GUARDADO COMO UN ARCHIVO .ZIP, POR LO SER GUARDADO COMO UN ARCHIVO .ZIP, POR LO QUE LA POSIBILIDAD DE GUARDAR COMO UN .ZIP, QUE LA POSIBILIDAD DE GUARDAR COMO UN .ZIP, NO ASEGURA QUE EL PAQUETE SEA CORRECTO!!NO ASEGURA QUE EL PAQUETE SEA CORRECTO!!


•• En los formularios que ofrece Agrega Offline para rellenar las En los formularios que ofrece Agrega Offline para rellenar las categorcategoríías de metadatos de LOMas de metadatos de LOM--ES ES eses necesario rellenar:necesario rellenar:

–– Todos los campos obligatorios que indica LOMTodos los campos obligatorios que indica LOM--ES.ES.¡¡¡¡EN AGREGA OFFLINE HAY UN INDICATIVO EN AGREGA OFFLINE HAY UN INDICATIVO GRGRÁÁFICO CON * QUE INDICA ESTOS CAMPOS!!FICO CON * QUE INDICA ESTOS CAMPOS!!

–– Aquellos campos que de manera explAquellos campos que de manera explíícita Red.es, haya cita Red.es, haya indicado a travindicado a travéés de la documentacis de la documentacióón que se entrega n que se entrega en cada Proyecto.en cada Proyecto.

–– Una instancia de la categorUna instancia de la categoríía 9, por cada taxonoma 9, por cada taxonomíía y a y tesauro indicados para estos proyectos:tesauro indicados para estos proyectos: ETB, ETB, ÁÁrbol rbol Curricular, Accesibilidad, Nivel Educativo, Curricular, Accesibilidad, Nivel Educativo, Competencias y DisciplinaCompetencias y Disciplina..

¡¡¡¡EN AGREGA OFFLINE SE PUEDEN INCLUIR TANTAS EN AGREGA OFFLINE SE PUEDEN INCLUIR TANTAS INSTANCIAS DE LA CATEGORIA 9 COMO SISTEMAS INSTANCIAS DE LA CATEGORIA 9 COMO SISTEMAS DE CLASIFICACIDE CLASIFICACIÓÓN SE USEN PARA CATALOGAR!N SE USEN PARA CATALOGAR!


•• Todos los campos con texto libre deben describirse en el Todos los campos con texto libre deben describirse en el idioma principal del paquete, y debe seidioma principal del paquete, y debe seññalarse dicho alarse dicho idioma mediante el atributo del idioma que acompaidioma mediante el atributo del idioma que acompañña a a a estos camposestos campos..

¡¡¡¡ESTE ES UN FALLO HABITUAL. ESCRIBIR EL VALOR ESTE ES UN FALLO HABITUAL. ESCRIBIR EL VALOR DE TEXTO LIBRE Y NO INDICAR EL IDIOMA DE DE TEXTO LIBRE Y NO INDICAR EL IDIOMA DE

DICHO VALOR!!DICHO VALOR!!

•• Los campos con vocabularios definidos, deben Los campos con vocabularios definidos, deben describirse en ingldescribirse en ingléés. Si se usa Agrega Offline, estos s. Si se usa Agrega Offline, estos campos se distinguen del resto al tratarse de campos campos se distinguen del resto al tratarse de campos con listas desplegables, y salvo manipulacicon listas desplegables, y salvo manipulacióón, no debern, no deberíía a poderse rellenar de otra forma que con el tpoderse rellenar de otra forma que con el téérmino del rmino del desplegable.desplegable.


• 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.


•• La verificaciLa verificacióón de la correccin de la correccióón de los aspectos sintn de los aspectos sintáácticos cticos del etiquetado del paquete se realizardel etiquetado del paquete se realizaráá a trava travéés de la s de la funcifuncióón de validacin de validacióón que presenta Agrega Offline en la n que presenta Agrega Offline en la zona de catalogacizona de catalogacióón o de edicin o de edicióón del paquete (en ambas n del paquete (en ambas zonas se validan los metadatos).zonas se validan los metadatos).

•• La validaciLa validacióón de los aspectos semn de los aspectos semáánticos de la catalogacinticos de la catalogacióón n ssóólo se pueden verificar manualmente.lo se pueden verificar manualmente.


PROPUESTAPROPUESTA CATALOGACICATALOGACIÓÓNN

•• Los valores presentados refieren a la documentaciLos valores presentados refieren a la documentacióón de LOMn de LOM--ES v1.0.ES v1.0.•• En la producciEn la produccióón de los ODE relativos al exp. 729 se exige la n de los ODE relativos al exp. 729 se exige la

catalogacicatalogacióón de los campos aqun de los campos aquíí descritos aunque no sean descritos aunque no sean obligatorios segobligatorios segúún LOMn LOM--ES.ES.

•• Los valores de las columnas Nombre y Ejemplo se presentan en Los valores de las columnas Nombre y Ejemplo se presentan en castellano, sin embargo en los ficheros castellano, sin embargo en los ficheros xmlxml, todos los valores , todos los valores pertenecientes a vocabularios definidos se deberpertenecientes a vocabularios definidos se deberáán poner en su n poner en su correspondiente idioma y en mincorrespondiente idioma y en minúúsculas.sculas.

•• Los valores de los vocabularios controlados siempre irLos valores de los vocabularios controlados siempre iráán en ingln en ingléés, s, aunque en los ejemplos de este documento aparezcan en castellanoaunque en los ejemplos de este documento aparezcan en castellano..

•• En el fichero En el fichero xmlxml es mejor que no aparezcan los es mejor que no aparezcan los tagstags de los campos de los campos que no se vayan a completar.que no se vayan a completar.

•• Todas las etiquetas referidas a vocabularios controlados deberTodas las etiquetas referidas a vocabularios controlados deberáán n llevar el siguiente llevar el siguiente tagtag: :

<<lomes:sourcelomes:source UniqueElementNameUniqueElementName="="sourcesource">LOM">LOM--ESv1ESv1.0</.0</lomes:sourcelomes:source>>

•• El orden en el que aparecen los El orden en el que aparecen los tagstags en el en el xmlxml es importante y hay que es importante y hay que respetarlo.respetarlo.

DEFINICIDEFINICIÓÓN DE CATEGORN DE CATEGORÍÍAS: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 CATALOGACIPROPUESTA CATALOGACIÓÓNN


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

Nivel de Agregación

1.8

En este caso Jerárquica“Lineal”, atómica, colección, en red y jerárquica

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.

Estructura1.7

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

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

Ámbito1.6

IMPORTANTE: meter todas las palabras clave en minúsculas, excepto si hubiera nombres propios…

volantes, enfermera, bata, tac, paciente, celador, tomografía, emulador

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

Palabra Clave1.5

Para SD y OA no se usa la instancia "CARACTERÍSTICAS". La instancia "características" solamente se usa para los objetos de nivel 1.

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

Descripción1.4

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

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

Idioma1.3

Imágenes de TomografíaTítulo según la ficha de diseño instructivoTítulo1.2

es_20090130_2_7241200Ver documento identificadorEntrada1.1.2

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.

Valor Fijo para todas las OAsCatálogo1.1.1

Identificador1.1

General General 1

ComentariosEjemploCriterios de catalogaciónNombreNº


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)

"2009-01-302009-01-30""Fecha de entrega. aaaa-mm-dd Misma fecha para la instancia de Publisher"

Fecha2.3.3

"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.0FN: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)"

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

"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)"

Entidad2.3.2

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

Tipo2.3.1

Contribución2.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óny además la plataforma AGREGA asignaráautomáticamente otro identificador propio de la plataforma (UUID) cuando se carguen los Objetos en ella.

final

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

Estado2.2

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

Versión2.1

Ciclo de VidaCiclo de Vida2



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

Esquema de Metadatos

3.3

Poner la misma fecha que en 2.3.3"2009-01-302009-01-30"

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

Fecha3.2.3

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

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

Idioma3.4

"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)"

"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"

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

Entidad3.2.2

"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)"

"creador” empresarevisor“ RED

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

Tipo3.2.1

Contribución3.2

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

es_20090130_3_7241200-metaConsultar documento Identificador_729_V01.doc

Entrada3.1.2

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"""

Catálogo unificado mec-red.es-ccaa-meta de identificación de instancias de metadatos de ODE Valor Fijo para todas las SD y OACatálogo3.1.1

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

Identificador3.1

MetaMeta--MetadatosMetadatos3



"sistema operativonavegador"

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

Tipo4.4.1.1

AgregadorOR4.4.1

Requisitos4.4

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

Localización4.3

18976545

Tamaño en BytesTamaño4.2

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

"text/htmlaudio/mpegapplication/x-shockwave-flash text/xmlapplication/pdfimage/jpgimage/gif"

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

Formato4.1

TTéécnicacnica4


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

Duración4.7

Se podría resumir en: Plug-in de Flash Player y Tarjeta de sonidoSi veis necesario incluir algún aspecto de la tarjeta gráfica o de sonido pues tambié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.

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

Otros Requisitos de Plataforma

4.6

No requiere instalaciónPautas de Instalación4.5

N/AVersión Máxima4.4.1.4

N/AVersión Mínima4.4.1.3

multi-socualquiera

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

Nombre4.4.1.2



"aula domicilio mixto docente independiente mixta presencial semipresencial distancia"

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

Contexto5.6

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

Destinatario5.5

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

Densidad Semántica5.4

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

Nivel de Interactividad5.3

SimuladorEscenario real o virtual de aprendizaje.

"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"

Tipo de Recurso Educativo5.2

combinadoSe seleccionará uno de estos valores: expositivo,

activo o combinado Tipo de interactividad5.1

Uso EducativoUso Educativo5


"analizar aplicar comprender contextualizar controlar describir investigar"

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"

Proceso Cognitivo5.12

esIdioma 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

Idioma5.11

Conocimiento previo: Objetivos didácticos:

"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"""

Descripción5.10

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)

PT(tiempo)H

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

Aprendizaje5.9

difícilSe seleccionará uno de estos valores: muy fácil, fácil, medio, difícil, muy difícilDificultad5.8

"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).

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

Rango Típico de Edad

5.7



No existen restriccionesSiempre la misma descripciónDescripción6.4.2

universalSiempre el valor "universal“Tipo de acceso6.4.1

Acceso6.4

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.

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.

Siempre la misma descripción

Descripción6.3

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

creative commons: reconocimiento - no nomercial - compartir igual

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

Derechos de Autor y otras Restricciones

6.2

noSiempre el valor "no"Coste6.1

DerechosDerechos6



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

Descripción7.2.2

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

Entrada7.2.1.2

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

Catálogo7.2.1.1

Identificador7.2.1

Recurso7.2

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

noSolo completar si es un OATipo7.1

RelaciRelacióónn7


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


N/A

Descripción8.3

N/AFecha8.2

N/AEntidad8.1

AnotaciAnotacióónn8


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


<imsmd:keyword><imsmd:string>Visual</imsmd:string>

<imsmd:keyword>Se hande incluir en múltiples instancias, un conjunto de valores de texto libre.

Palabra clave9.4

Ejemplo para descripción de accesibilidad:<imsmd:description><imsmd:string>Se trata de un recurso con adaptabilidad

alta</imsmd:string><imsmd:description>

Descripción9.3

"valores seleccionados en accesibilidadvalores seleccionados en disciplinavalores seleccionados en competenciavalores seleccionados en nivel educativoEjemplo sobre el nivel educativo<lomes:entry> <lomes:string>Educación infantil</lomes:string> "

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

Entrada9.2.2.2

"ID valores seleccionados en accesibilidadID valores seleccionados en disciplinaID valores seleccionados en competenciaID valores seleccionados en nivel educativoEjemplo sobre el nivel educativo<lomes:taxon> <lomes:iduniqueElementName=""id"">2</lomes:id> "

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

Identificador9.2.2.1

Taxón9.2.2

"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” "

Para cada uno de los propósitos seleccionados se eligen como fuente los vocabularios correspondientesFuente9.2.1

Ruta Taxonómica9.2

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

Propósito9.1

ClasificaciClasificacióónn9


EJEMPLO CATALOGACIEJEMPLO CATALOGACIÓÓNN

ENTREGA DE LOS SIMULADORES COMO PAQUETES ZIP Y LA

VALIDACIÓN DE RED.ES

Exp. 729/07-SD

ASPECTOS A TENER EN CUENTA:

1. Pilotaje de la versión candidata a definitiva en castellano

2. Pautas generales para entrega de versiones definitivas

3. Validación técnica y funcional4. 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 Check-list) 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 DocumentationEn: http://www.adlnet.gov/scorm/20043ED/Documentation.aspx

Proyecto AgregaEn: 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/AENORPerfil de aplicación LOM-ES1 V.1.0.En: http://www.proyectoagrega.es/documentos/Productores%20de%20contenidos/Etiquetado/Normas%20de%20etiquetado/lom-es_v1.pdf

seminario pautas de producción simuladores

Education