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 •Los simuladores son
instructivo completo (contenidos, Objetos Digitales
actividades, evaluación, etc.) a la Educativos
combinación de uno o varios reutilizables (ODEs)
Medias o Medias Integrados. 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. Compatibilidad
2. Fidelidad física y de percepción
3. Accesibilidad
4. Multilingüismo
5. 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.


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 .


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.

Í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 ADICIÓN DE TRAZAS
CONTENIDOS A LOS CONTENIDOS
BINARIOS 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

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

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)

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.

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
MacromediaFlashPlayerSharedObjects
Mac OS X: ~/Library/Preferentes/Macromedia/Flash
–
Player
GNU-Linux: ~/macromedia
–

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.

LMS
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

LMS
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

LMS
Recuperado de sesión
–
1. El usuario decide recuperar una sesión previamente
guardada
2. El sistema muestra una lista de sesiones, si existen,
almacenadas previamente en local (una por cada LSO)
3. El usuario escoge una sesión
4. El sistema pide el password de la sesión seleccionada
5. 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ó

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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. Requisitos previos
2. Especificaciones técnicas
3. Empaquetado.
4. Aspectos a tener en cuenta
5. 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
Empaquetado
binarios

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
CREACIÓN CREACIÓN
CONTENIDOS
RECURSO ORGANIZATION
BINARIOS

VALIDAR ,
INSERTAR ASOCIAR
PREVISUALIZAR Y
METADATOS RECURSO A ITEM
GUARDAR .ZIP

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:

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

– 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

Í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: Parte del ciclo
de vida
cubierto

Archivos Recursos
Crear
organización Empaquetado
Etiquetado

Objetos
Aprendizaje

CATALOGACIÓN
• Dentro de un paquete, existen diferentes lugares
en los que se pueden introducir metadatos:
Nivel de objeto
–
Nivel de Organización.
–
Nivel de item.
–
Nivel de Recurso.
–
• En cualquiera de los casos, la forma de asociar
los metadatos, es mediante la opción de
“Catalogar”

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:
<lomes:source UniqueElementName=quot;sourcequot;>LOM-
ESv1.0</lomes:source>
• El orden en el que aparecen los tags en el xml es importante y hay que
respetarlo.

DEFINICIÓN DE CATEGORÍAS:
CATEGORÍA GENERAL: Agrupa la información general que describe el objeto de manera global.
1.
CATEGORÍA CICLO DE VIDA: Agrupa las características relacionadas con la historia y el estado
2.
actual del objeto, y aquellas que le han afectado durante su evolución.
CATEGORÍA META- METADATOS: Agrupa la información sobre la propia instancia de metadatos.
3.
(quien es el responsable de la documentación, cuando, etc.).
CATEGORÍA TÉCNICA: Agrupa los requerimientos y características técnicas del objeto.
4.
CATEGORÍA USO EDUCATIVO: Agrupa las características educativas y pedagógicas del objeto.
5.
CATEGORÍA DERECHOS: Agrupa los derechos de propiedad intelectual y las condiciones para el
6.
uso del objeto.
CATEGORÍA RELACIÓN: Agrupa las características que definen la relación entre este objeto y
7.
otros objetos digitales relacionados.
CATEGORÍA ANOTACIÓN: Permite incluir comentarios sobre el uso educativo, e información
8.
sobre cuándo y por quién fueron creados dichos comentarios.
CATEGORÍA CLASIFICACIÓN: Describe este objeto en relación a un determinado sistema de
9.
clasificación.

Nº Nombre Criterios de catalogación Ejemplo Comentarios

1 General

1.1 Identificador

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
1.1.1 Catálogo Valor Fijo para todas las OAs
plataforma AGREGA asignará automáticamente otro
identificador propio de la plataforma (UUID) cuando se
carguen los Objetos en ella.

Ver documento identificador
1.1.2 Entrada es_20090130_2_7241200

1.2 Título Título según la ficha de diseño instructivo Imágenes de Tomografía

Idioma del SD/OA según la traducción. Aunque en la norma ISO 639-1988 sólo figuran las
1.3 Idioma es
Seleccionar entre los valores: es, en, ca, gl, eu, siguientes lenguas de España: español, gallego,
va catalán y vasco, vamos a usar va para valenciano

Descripción del objeto en 40-60 palabras para Para SD y OA no se usa la instancia
1.4 Descripción usar como texto alternativo en pantalla o breve quot;CARACTERÍSTICASquot;. La instancia quot;característicasquot;
descripción al referirse al objeto solamente se usa para los objetos de nivel 1.

Palabra En múltiples instancias se han de incluir un volantes, enfermera, bata, tac, paciente, IMPORTANTE: meter todas las palabras clave en
1.5
Clave conjunto de valores de texto libre celador, tomografía, emulador 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
Época, cultura, zona geográfica o región a la que
1.6 Ámbito universal campo opcional. Se podría elegir un descriptor
se refiere el contenido.
genérico para algunos contenidos que no se refieren a
ninguna época en concreto ni a ningún lugar, por
ejemplo: universal

Estructura organizativa del objeto. Se selecciona
un valor de un vocabulario. En general tanto para
1.7 Estructura SD como para OA se seleccionará el término “Lineal”, atómica, colección, en red y jerárquica En este caso Jerárquica
quot;linealquot;. En el caso de tratarse de un objeto
indivisible se pondrá atómica.

Valores fijos: Para un SD el valor es quot;3quot;, para un
Nivel de
1.8 2
OA el valor es quot;2quot; y para medias y medias
Agregación
integrados quot;1quot;


2 Ciclo de Vida

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

final
En este campo vamos a utilizar un catálogo
creado para el proyecto que se llama Catálogo
Ya que únicamente se va a etiquetar la versión unificado mec-red.es-ccaa de identificación
2.2 Estado entregable y no los prototipos previos, se usará el y además la plataforma AGREGA asignará
valor quot;finalquot; automáticamente otro identificador propio de la
plataforma (UUID) cuando se carguen los
Objetos en ella.

2.3 Contribución

quot;Se usará el valor quot;quot;proveedor de contenidosquot;quot;
2.3.1 Tipo (content provider) y otra instancia para quot;quot;editor de
la publicaciónquot;quot; (publisher)quot;

quot;El formato de Vcard es el siguiente
(manteniendo los saltos de línea y los campos
BEGIN:VCARD vacíos en caso de que no se
VERSION 3.0 FN:EMAIL;
quot;Se usará una VCARD con el valor de Organización rellenen):BEGIN:VCARD VERSION:3.0
2.3.2 Entidad (una para el proveedor de contenidos y otra para TYPE=INTERNET:ORG:ONECLICK FN:EMAIL;TYPE=INTERNET:ORG:END:VCARD
el editor de la publicación)quot; No hace falta mantener la expresión regular,
END:VCARD
han de ir todos los elementos, no hace falta
respetar los saltos de línea (solo un espacio
entre cada elemento)quot;

Proponemos poner una fecha distinta para cada
una de las entregas (entendiendo por entrega
quot;Fecha de entrega. aaaa-mm-dd Misma fecha para
2.3.3 Fecha quot;2009-01-302009-01-30quot; un conjunto de SDs con sus OAs y sus medias,
la instancia de Publisherquot;
por ejemplo las que coinciden con los hitos de
facturación)


3 Meta-Metadatos
Meta-

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

Catálogo unificado mec-red.es-ccaa-meta de
Se pueden incluir tantos identificadores como se
identificación de instancias de metadatos de
desee. Sigue los mismos criterios que el Catálogo
3.1.1 Catálogo Valor Fijo para todas las SD y OA ODE
unificado mec-red.es-ccaa de identificación de ODE
pero al final se añade quot;quot;-metaquot;quot;quot;

Consultar documento Identificador_729_V01.doc El código deberá coincidir con el del 1.1.2 pero
3.1.2 Entrada es_20090130_3_7241200-meta
añadiendo -meta al final

3.2 Contribución

quot;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
quot;creador” empresa
Se usará el valor quot;creadorquot; (creator) y otra instancia FN:EMAIL;TYPE=INTERNET:ORG:END:VCARD No
3.2.1 Tipo
para quot;revisorquot; (validator) hace falta mantener la expresión regular, han de ir
revisor“ RED
todos los elementos, no hace falta respetar los
saltos de línea (solo un espacio entre cada
elemento)quot;

quot;BEGIN:VCARD VERSION 3.0 FN: quot;El formato de Vcard es el siguiente (manteniendo
EMAIL;TYPE=INTERNET:ORG:ONECLICK los saltos de línea y los campos vacíos en caso de
END:VCARDBEGIN:VCARD VERSION 3.0 que no se rellenen):BEGIN:VCARD VERSION:3.0
quot;Se usará una VCARD con el valor de Organización FN:Contenido digital educativo creado, FN:EMAIL;TYPE=INTERNET:ORG:END:VCARD Pero
3.2.2 Entidad
(una para el creador y otra para el revisor)quot; catalogado y financiado con fondos FEDER no hace falta mantener la expresión regular, así
dentro del expediente 729/08-Lote1 que han de ir todos los elementos pero no hace
EMAIL;TYPE=INTERNET:sugerencias@red.es falta respetar los saltos de línea (solo un espacio
ORG:RED.ES END:VCARDquot; entre cada elemento)quot;

quot;Fecha de entrega. aaaa-mm-dd quot;2009-01-30
3.2.3 Fecha Poner la misma fecha que en 2.3.3
Misma fecha para la instancia de validadorquot; 2009-01-30quot;

Esquema de Se utilizará el valor: “LOM-ES v1.0” o quot;LOM-ES
3.3 LOM-ES v.1.0
Metadatos v.1.0quot;

Aunque en la norma ISO 639-1988 sólo figuran las
Idioma de los metadatos según la traducción.
3.4 Idioma es siguientes lenguas de España: español, gallego,
Seleccionar entre los valores: es, en, ca, gl, eu, va, fr
catalán y vasco, vamos a usar va para valenciano


4 Técnica

quot;text/html
audio/mpeg
Tipos MIME usados en el objeto. Se utilizarán application/x-shockwave-flash
varios valores en instancias separadas, en la Este punto ha de ser descrito por part e de las
4.1 Formato text/xml
mayor parte de los casos serán siempre los empresas
application/pdf
mismos
image/jpg
image/gifquot;

18976545

4.2 Tamaño Tamaño en Bytes

Ha pasado a ser un campo recomendado y de
4.3 Localización
momento no hay que rellenarlo.

4.4 Requisitos

4.4.1 AgregadorOR

Varias instancias. Utilizaremos el campo quot;sistema quot;sistema operativo
4.4.1.1 Tipo operativoquot; con el valor quot;multi-osquot; y el campo
navegadorquot;
quot;navegadorquot; con el valor quot;anyquot;

Varias instancias. Utilizaremos el campo quot;Sistema
multi-so
4.4.1.2 Nombre Operativoquot; con el valor quot;multi-soquot; y el campo
cualquiera
quot;Navegadorquot; con el valor quot;Cualquieraquot;

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 No requiere instalación

Tarjeta de sonido, Tarjeta gráfica con Se podría resumir en: Plug-in de Flash
Otros Requisitos de Otros comentarios técnicos. En principio usaremos resolución de como mínimo 800x600 Player y Tarjeta de sonido
4.6
Plataforma siempre el mismo texto píxeles x 256 colores. Flash plug-in flash Si veis necesario incluir algún aspecto de la
8.0 o superior. tarjeta gráfica o de sonido pues también.

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


5 Uso Educativo

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

quot;En múltiples instancias se han de seleccionar un Simulador
conjunto de valores del siguiente vocabulario (se Escenario real o virtual de aprendizaje.
utiliza únicamente la categoría 'Contenido
didáctico'):lecturas guiadas, lección magistral,
Tipo de Recurso comentario de texto-imagen, actividad de
5.2
Educativo 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ónquot;

Se seleccionará uno de estos valores: muy bajo,
5.3 Nivel de Interactividad Muy alto
bajo, medio, alto, muy alto.

Se seleccionará uno de estos valores: muy baja,
5.4 Densidad Semántica Alta
baja, media, alta, muy alta.

En múltiples instancias se seleccionarán los
5.5 Destinatario quot;alumno individual docente quot;
siguientes valores: quot;alumno, individual, docentequot;

quot;En múltiples instancias se seleccionarán los
quot;aula domicilio mixto docente
siguientes valores: quot;quot;aula, domicilio, mixto,
5.6 Contexto independiente mixta presencial
docente, familia, compañero, independiente,
semipresencial distanciaquot;
mixta, presencial, semipresencial, distanciaquot;quot;quot;

quot;Este campo es de texto libre pero lo vamos a
Rango Típico de Rango de edad del usuario. Se deduce del nivel educativo y homogeneizar poniendo edad mínima, edad
5.7 14-23
Edad se expresa en edad mínima - edad máxima máxima y una descripción (cuando sea
necesario).

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

Tiempo que el destinatario tarda en asimilar el contenido. Todos los campos duración y fecha tienen 2
Tiempo Típico de (Viene en la ficha de diseño instructivo) etiquetas, una para la codificación del tiempo o
5.9 PT(tiempo)H
Aprendizaje de la fecha y otra para una descripción (texto
libre)

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

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

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


6 Derechos

6.1 Coste Siempre el valor quot;noquot; no

creative commons: reconocimiento - no En caja baja: creative commons: reconocimiento
nomercial - compartir igual - no comercial - compartir igual
Derechos de
Siempre el valor: quot;Creative Commons:
6.2 Autor y otras
Reconocimiento - No Comercial - Compartir Igualquot;
Restricciones

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

6.4 Acceso

6.4.1 Tipo de acceso Siempre el valor quot;universal“ universal

6.4.2 Descripción Siempre la misma descripción No existen restricciones



7 Relación
Relació

es parte de (si es un OA que forma parte de una
7.1 Tipo Solo completar si es un OA no
SD)

7.2 Recurso

7.2.1 Identificador

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

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

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

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


8 Anotación
Anotació

8.1 Entidad N/A

8.2 Fecha N/A

N/A

8.3 Descripción

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


9 Clasificación
Clasificació

Se realizarán múltiples instancias de este
9.1 Propósito quot;accesibilidad disciplina competencia nivel educativoquot;
campo, abordando los valores quot;accesibilidadquot;,
quot;disciplinaquot; , quot;competenciaquot; y quot;nivel educativoquot;

9.2 Ruta Taxonómica

Para cada uno de los propósitos seleccionados quot;Restricciones de accesibilidad: “Accesibilidad LOM-ESv1.0”
se eligen como fuente los vocabularios Nivel educativo: “Nivel educativo LOM-ESv1.0”
correspondientes
9.2.1 Fuente 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” quot;

9.2.2 Taxón

quot;ID valores seleccionados en accesibilidad
ID valores seleccionados en disciplina
Para cada uno de los propósitos seleccionados
ID valores seleccionados en competencia
9.2.2.1 Identificador se eligen múltiples instancias de entre los
ID valores seleccionados en nivel educativo
vocabularios correspondientes
Ejemplo sobre el nivel educativo<lomes:taxon> <lomes:id
uniqueElementName=quot;quot;idquot;quot;>2</lomes:id> quot;

quot;valores seleccionados en accesibilidad
valores seleccionados en disciplina
Para cada uno de los propósitos seleccionados
valores seleccionados en competencia
9.2.2.2 Entrada se eligen múltiples instancias de entre los
valores seleccionados en nivel educativo
vocabularios correspondientes
Ejemplo sobre el nivel educativo<lomes:entry>
<lomes:string>Educación infantil</lomes:string> quot;

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

<imsmd:keyword>
<imsmd:string>Visual</imsmd:string>
Se hande incluir en múltiples instancias, un
9.4 Palabra clave <imsmd:keyword>
conjunto de valores de texto libre.

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 funcional
4. 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 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/lom-
es_v1.pdf

Seminario Pautas De Producción Simuladores

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (17)

Similar a Seminario Pautas De Producción Simuladores

Similar a Seminario Pautas De Producción Simuladores (20)

Más de red.es

Más de red.es (20)

Último

Último (20)

Seminario Pautas De Producción Simuladores