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.
PAUTAS DE
PRODUCCIÓN
ÍNDICE
5. TRAZABILIDAD Y PERSISTENCIA
5.1 En LMS
5.2 Fuera de LMS
6. Modelos de datos del RUN TIME

TRAZABILIDAD
• Elementos de partida.
– Contenidos binarios.
– Ficha Instruccional.
– Otros aspectos de diseño y estilo proporcionados
por Red.es
• Producto que se genera.
Contenidos binarios con gestión de trazas.
• Herramienta de catalogación
Herramienta de edición que se esté usando
para crear los contenidos binarios.
TRAZABILIDAD
La adición de las trazas a los
contenidos binarios, se realiza en el
momento de creación de dichos
contenidos:
CREACIÓN 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
Macromedia\FlashPlayer\SharedObjects
– 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
binarios Empaquetado
Objeto
SCORM 2004
Archivo
SIM.html
Etiquetado
Empaquetado
• El empaquetado de un OA requiere realizar las siguientes
actividades:
– Subir los contenidos binarios que se van a empaquetar a la
herramienta de edición.
– Convertir los contenidos binarios subidos en un recurso.
– Crear un organization con un único item, y referenciar el recurso
desde el mismo.
– Etiquetar el paquete a nivel de organization.
– Validar, previsualizar y guardar como un archivo .zip
Empaquetado
El ciclo de vida del empaquetado de un OA es:
UPLOAD
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
CATALOGACIÓN
ÍNDICE
CATALOGACIÓN
EJEMPLO CATALOGACIÓN
DOCUMENTACIÓN
REQUISITOS PREVIOS
Para seguir el contenido de estas transparencias es
necesario conocer y saber utilizar las
especificaciones:
–Perfil de aplicación LOM-ES.
–SCORM 2004 (IMS Content Packaging, IMS
Simple Sequencing , API de JavaScript de
SCORM 2004).
–Taxonomías y tesauros: ETB, Árbol Curricular,
Nivel Educativo, Accesibilidad, Disciplina y
Competencia.
CATALOGACIÓN
• Elementos de partida.
– Paquete SCORM 2004
– Ficha Instruccional.
– Otros aspectos de diseño y estilo proporcionados
por Red.es
– Agrega Offline
• Producto que se genera.
Paquete SCORM 2004 etiquetado.
• Herramienta de catalogación
Agrega Offline
CATALOGACIÓN
• Ciclo de vida: Parte del ciclo
de vida
cubierto
Archivos Recursos
Crear
organización Etiquetado Empaquetado
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="source">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:
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.
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.
1.1.2 Entrada Ver documento identificador es_20090130_2_7241200
1.2 Título Título según la ficha de diseño instructivo Imágenes de Tomografía
Idioma del SD/OA según la traducción. Aunque en la norma ISO 639-1988 sólo figuran las
1.3 Idioma Seleccionar entre los valores: es, en, ca, gl, eu, es 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 "CARACTERÍSTICAS". La instancia "características"
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
"lineal". En el caso de tratarse de un objeto
indivisible se pondrá atómica.
Valores fijos: Para un SD el valor es "3", para un

Nivel de
1.8 OA el valor es "2" y para medias y medias 2
Agregación
integrados "1"
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 "V1.0"
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 "final" automáticamente otro identificador propio de la
plataforma (UUID) cuando se carguen los
Objetos en ella.
2.3 Contribución
"Se usará el valor ""proveedor de contenidos""

2.3.1 Tipo (content provider) y otra instancia para ""editor de
la publicación"" (publisher)"
"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
"Se usará una VCARD con el valor de Organización VERSION 3.0 FN:EMAIL; 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)" END:VCARD No hace falta mantener la expresión regular,
han de ir todos los elementos, no hace falta
respetar los saltos de línea (solo un espacio
entre cada elemento)"
Proponemos poner una fecha distinta para cada

una de las entregas (entendiendo por entrega
"Fecha de entrega. aaaa-mm-dd Misma fecha para
2.3.3 Fecha "2009-01-302009-01-30" un conjunto de SDs con sus OAs y sus medias,
la instancia de Publisher"
por ejemplo las que coinciden con los hitos de
facturación)
3 Meta-
Meta-Metadatos
Ya que únicamente se va a etiquetar la versión

3.1 Identificador entregable y no los prototipos previos, se usará el V1.0
valor "V1.0"
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 ""-meta"""
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
"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
Se usará el valor "creador" (creator) y otra instancia "creador” empresa FN:EMAIL;TYPE=INTERNET:ORG:END:VCARD No
3.2.1 Tipo
para "revisor" (validator) revisor“ RED 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: "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
"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)" 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:VCARD" entre cada elemento)"
"Fecha de entrega. aaaa-mm-dd "2009-01-30

3.2.3 Fecha Poner la misma fecha que en 2.3.3
Misma fecha para la instancia de validador" 2009-01-30"
Esquema de Se utilizará el valor: “LOM-ES v1.0” o "LOM-ES

3.3 LOM-ES v.1.0
Metadatos v.1.0"
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
"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
mismos application/pdf
image/jpg
image/gif"
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 "sistema "sistema operativo

4.4.1.1 Tipo operativo" con el valor "multi-os" y el campo
"navegador" con el valor "any" navegador"
Varias instancias. Utilizaremos el campo "Sistema
multi-so
4.4.1.2 Nombre Operativo" con el valor "multi-so" y el campo
cualquiera
"Navegador" con el valor "Cualquiera"
4.4.1.3 Versión Mínima N/A
4.4.1.4 Versión Máxima N/A
4.5 Pautas de Instalación 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
"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ón"
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 "alumno individual docente "
siguientes valores: "alumno, individual, docente"
"En múltiples instancias se seleccionarán los

"aula domicilio mixto docente
siguientes valores: ""aula, domicilio, mixto,
5.6 Contexto independiente mixta presencial
docente, familia, compañero, independiente,
semipresencial distancia"
mixta, presencial, semipresencial, distancia"""
"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).
Se seleccionará uno de estos valores: muy fácil, fácil, difí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)
"Descripción del uso del objeto educativo. Estructurado en

tres instancias: Conocimiento previo Objetivos didácticos Conocimiento previo:
5.10 Descripción
Tipo de Conocimiento: seleccionar a partir del vocabulario: Objetivos didácticos:
""declarativo, procedimental, condicional, metacognitivo"""
Idioma del destinatario. En general se seleccionará entre los

5.11 Idioma valores "es, ga, ca, eu y va" 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: "analizar, aplicar, colaborar,
comparar, compartir, competir, comprender, comprobar,
comunicar, contextualizar, controlar, cooperar, crear,
"analizar aplicar comprender
decidir, definir, describir, discutir, diseñar, evaluarse,
5.12 Proceso Cognitivo contextualizar controlar describir
explicar, extrapolar, innovar, investigar, juzgar, motivar,
investigar"
observar, organizar, organizarse, planificar, practicar,
producir, reconocer, recordar, redactar, reflexionar,
relacionar, representar, resolver, simular, sintetizar,
valorar"
6 Derechos
6.1 Coste Siempre el valor "no" no
creative commons: reconocimiento - no En caja baja: creative commons: reconocimiento

Derechos de nomercial - compartir igual - no comercial - compartir igual
Siempre el valor: "Creative Commons:
6.2 Autor y otras
Reconocimiento - No Comercial - Compartir Igual"
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 "universal“ universal
6.4.2 Descripción Siempre la misma descripción No existen restricciones

7 Relació
Relación
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ó
Anotación
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ó
Clasificación
Se realizarán múltiples instancias de este

9.1 Propósito campo, abordando los valores "accesibilidad", "accesibilidad disciplina competencia nivel educativo"
"disciplina" , "competencia" y "nivel educativo"
9.2 Ruta Taxonómica
Para cada uno de los propósitos seleccionados "Restricciones de accesibilidad: “Accesibilidad LOM-ESv1.0”
se eligen como fuente los vocabularios Nivel educativo: “Nivel educativo LOM-ESv1.0”
9.2.1 Fuente correspondientes 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” "
9.2.2 Taxón
"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
vocabularios correspondientes ID valores seleccionados en nivel educativo
Ejemplo sobre el nivel educativo<lomes:taxon> <lomes:id
uniqueElementName=""id"">2</lomes:id> "
"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
vocabularios correspondientes valores seleccionados en nivel educativo
Ejemplo sobre el nivel educativo<lomes:entry>
<lomes:string>Educación infantil</lomes:string> "
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

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Seminario Pautas de Producción Simuladores

Cargado por

Copyright:

Formatos disponibles

PRESENTACIÓN SEMINARIO SOBRE

ASPECTOS TÉCNICOS, EMPAQUETADO

El seminario tiene por objetivo que las empresas

•Identificar las características técnicas y didácticas que distinguen los

Pautas generales de Producción de Entornos de Simulación para

Pautas de desarrollo (trazabilidad y persistencia, configuración

Pautas de Empaquetado (SCORM 2004 y la utilización de la

Pautas de Catalogación (LOM-ES V1 y la utilización del

Entrega de los simuladores como paquetes ZIP y la validación de

En este proyecto, los recursos y el tiempo no han sido

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

• Los simuladores serán programas informáticos para

• Funcionarán correctamente en las últimas versiones

• Los tres lotes desarrollan los simuladores en Flash,

•Los simuladores incluirán representaciones realistas.

•Cada simulador debe tratar la accesibilidad para todos los

Sin embargo, de forma específica (según las recomendaciones

Los simuladores de los distintos lotes del presente

La producción de los simuladores seguirá las

5.1 Navegación guiada

El tipo de navegación será guiada a lo largo de toda la

Un simulador se puede asemejar a una máquina de

•De ser necesario, antes de una acción el simulador

Todas las páginas que contengan información relevante

•La programación y el diseño de las pantallas tendrán

•Los ficheros de idiomas serán explícitos y estarán

Para cada simulador se deberán catalogar

Todos los simuladores se entregarán empaquetados

•Los simuladores podrán emplearse en LMS y fuera de

•En un navegador web (online o local). Los simuladores

•El simulador comprobará

El simulador comprobará si está siendo desplegado en

Itinerario de aprendizaje (1 OA = Simulador)

Los simuladores serán modulares (los módulos serán

La arquitectura facilitará la independencia del contenido

Los simuladores son configurables tanto en cantidad de

•Incluirán ficheros de configuración (igual que existen de

6. Modelos de datos del RUN TIME

• SCORM 2004 describe una API estándar de

• ScormInteractionGetCount no toma ningún

• Para catalogar el paquete se usará la funcionalidad de

¡¡UN PAQUETE CON ERRORES DE CATALOGACIÓN PUEDE

¡¡ESTE ES UN FALLO HABITUAL. ESCRIBIR EL VALOR

• Los campos con vocabularios definidos, deben

• Salvo indicación explícita, solo se rellenan los

• La verificación de la corrección de los aspectos sintácticos

• La validación de los aspectos semánticos de la catalogación

En este campo vamos a utilizar un catálogo creado

1.1.2 Entrada Ver documento identificador es_20090130_2_7241200

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

Descripción del objeto en 40-60 palabras para Para SD y OA no se usa la instancia

No se debe rellenar por defecto España, Internet en el

Estructura organizativa del objeto. Se selecciona

Valores fijos: Para un SD el valor es "3", para un

Ya que únicamente se va a etiquetar la versión

"Se usará el valor ""proveedor de contenidos""

"El formato de Vcard es el siguiente

Proponemos poner una fecha distinta para cada

Ya que únicamente se va a etiquetar la versión

Catálogo unificado mec-red.es-ccaa-meta de

"El formato de Vcard es el siguiente (manteniendo

"BEGIN:VCARD VERSION 3.0 FN: "El formato de Vcard es el siguiente (manteniendo

"Fecha de entrega. aaaa-mm-dd "2009-01-30

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