0
PRESENTACIÓN SEMINARIO SOBRE
ASPECTOS TÉCNICOS, EMPAQUETADO
Y CATALOGACIÓN DE SIMULADORES
   CONCEBIDOS COMO OBJETOS
     ...
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 profesiona...
Objetivos específicos

•Identificar las características técnicas y didácticas que distinguen los
simuladores para la forma...
Presentaciones y ponentes

Pautas generales de Producción de Entornos de Simulación para
Formación Profesional (de acuerdo...
Pautas generales de Producción de Entornos
de Simulación para Formación Profesional
(de acuerdo al Pliego 729/07-SD de Red...
El valor de la creatividad es mucho mayor conforme se
disponga de menos recursos y tiempo y, por el
contrario, se deban ma...
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 (...
Características generales
de los simuladores

1.  Compatibilidad
2.  Fidelidad física y de percepción
3.  Accesibilidad
4....
1. Compatibilidad

• Los simuladores serán programas informáticos para
  ser usados con un ordenador de propósito general ...
1. Compatibilidad

• Funcionarán correctamente en las últimas versiones
  estables de los navegadores IE, FireFox, Opera y...
2. Fidelidad física y de percepción

•Los simuladores incluirán representaciones realistas.


•Incluirá 3D
pero no se
podr...
3. Accesibilidad

•Cada simulador debe tratar la accesibilidad para todos los
casos posibles y declararla desde la Ayuda.
...
4. Multilingüismo

Los simuladores de los distintos lotes del presente
pliego se producirán en 6 lenguas (castellano, cata...
5.Usabilidad

La producción de los simuladores seguirá las
siguientes pautas generales relativas a la usabilidad:

5.1 Nav...
5.1 Navegación guiada

El tipo de navegación será guiada a lo largo de toda la
simulación del proceso o procedimiento: apa...
5.1 Navegación guiada


Un simulador se puede asemejar a una máquina de
estados finitos: en cada estado, el usuario puede
...
5.2 Pistas y retroalimentación

•De ser necesario, antes de una acción el simulador
orientará al usuario mediante alguna p...
5.3 Visualización optimizada

 Resolución de pantalla
                               Los simuladores
                     ...
5.4 Impresión preconfigurada

Todas las páginas que contengan información relevante
para su lectura o visionado (instrucci...
5.5 Tratamiento de textos
en archivos independientes

•La programación y el diseño de las pantallas tendrán
en cuenta la n...
5.5 Tratamiento de textos
en archivos independientes

•Los ficheros de idiomas serán explícitos y estarán
modularmente sep...
6. Catalogación de simuladores

Para cada simulador se deberán catalogar
todas las categorías del LOMES v.1.0 en tantas
le...
7.    Empaquetado

Todos los simuladores se entregarán empaquetados
siguiendo el modelo de agregación SCORM 2004. Cada
sim...
8. Navegación y trazabilidad

•Los simuladores podrán emplearse en LMS y fuera de
LMS. En ambos casos se podrán consultar ...
8.1   Fuera de LMS

•En un navegador web (online o local). Los simuladores
contarán con una página principal o índice, que...
8.2   En un LMS SCORM 2004

El simulador comprobará si está siendo desplegado en
un LMS SCORM. En este caso, activará el s...
9. Arquitectura

  Los simuladores serán modulares (los módulos serán
  reutilizables). Hablamos de módulos de código (y, ...
9. Arquitectura

Por desagregación
técnica, los elementos
que conforman el
simulador estarán
ubicados en directorios
que p...
10.Configuración y parametrización

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

•Incluirán ficheros de configuración (igual que existen de
idiomas) que permitan carga...
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 esti...
TRAZABILIDAD
La adición de las trazas a los
contenidos binarios, se realiza en el
momento de creación de dichos
contenidos...
TRAZABILIDAD
• La navegación en un paquete se describe y
  gestiona mediante el uso de JavaScript
  embebido en los docume...
TRAZABILIDAD
• La lógica de proceso de estas funciones puede ser
  modificada, e incluso se pueden definir más
  funciones...
TRAZABILIDAD
     El script debe implementar al menos 4
•
     funciones básicas:
    – ScanForAPI(win).Esta función busca...
TRAZABILIDAD
        Un SCO puede reportar a un LMS dos tipos de
•
        informaciones:
          Información de progres...
TRAZABILIDAD
    Es recomendado usar JavaScript en el
•
    documento HTML que maneja la gestión de las
    sesiones de co...
TRAZABILIDAD
     Hay dos formas de verificar que se ha
•
     gestionado correctamente la trazabilidad:
    – Cargar el p...
TRAZABILIDAD FUERA DE
             LMS
    Cuando un paquete se ejecuta fuera de un LMS,
•
    mediante ejecución local en...
TRAZABILIDAD FUERA DE
             LMS
    Se recomienda usar un patrón de estrategia,
•
    para variar el comportamiento...
TRAZABILIDAD FUERA DE
             LMS
    Una vez obtenido el valor de la variable es
•
    cuando podremos aplicar el pa...
PERSISTENCIA
        En el protocolo de comunicación la normativa
•
        SCORM define un conjunto de campos/valores
   ...
PERSISTENCIA
    Por cada combinación SCO/estudiante, el LMS
•
    guarda este conjunto de campos/valores. Esto
    signif...
CONEXIÓN Y REGISTRO
    En el LMS la conexión de los alumnos y
•
    profesores se realiza a través del propio LMS
    med...
PERSISTENCIA FUERA DE
             LMS
        La solución propuesta debería de cumplir los
•
        siguientes requisito...
PERSISTENCIA FUERA DE
             LMS
    Por ello, planteamos como solución el uso de
•
    Objetos Compartidos Locales ...
PERSISTENCIA FUERA DE
             LMS
        Debido a que Flash Player de Adobe usa el
•
        “sandbox security model...
PERSISTENCIA FUERA DE
             LMS
    Al ser conocida la ubicación de los LSO, el
•
    usuario puede copiarlos en al...
PERSISTENCIA FUERA DE
             LMS
        La implementación podría ser la siguiente:
•
          Guardado de sesión
 ...
PERSISTENCIA FUERA DE
         LMS
 4.   Tanto si se selecciona una sesión ya existente como si se
      decide crear una ...
PERSISTENCIA FUERA DE
         LMS
    Recuperado de sesión
–
    1.   El usuario decide recuperar una sesión previamente
...
PERSISTENCIA FUERA DE
             LMS
        Requisitos mínimos
•
          Adobe Flash Player (cualquier versión o Macr...
PERSISTENCIA FUERA DE
             LMS
    La persistencia de datos en los Shared Objects
•
    se guardará en variables c...
API JavaScript SCORM
     Para el intercambio de datos es necesario
•
     implementar las siguientes funciones:
    – Sco...
API JavaScript SCORM
    ScormGetValue(Elemento de datos). Esta
–
    función permite recuperar datos almacenados
    en e...
API JavaScript SCORM
    ScormSetValue(Elemento de
–
    datos,Valor).Esta función permite enviar
    datos para su almace...
API JavaScript SCORM
    SCORM 2004 permite a un SCO crear hasta
•
    250 registros de interacción. Cada registro
    con...
API JavaScript SCORM
    La colección de registros de interacción no se
•
    encuentra almacenado en ningún orden
    det...
API JavaScript SCORM
Para gestionar esto se añaden nuevas funciones al
    script de SCORM:

    ScormInteractionGetCount ...
API JavaScript SCORM
    ScormInteractionAddRecord toma como
•
    parámetro el identificador de una interacción
    y un ...
API JavaScript SCORM
    ScormInteractionGetData toma como
–
    parámetro el identificador de la interacción y
    el ele...
API JavaScript SCORM
    ScormInteractionGetIndex toma como
–
    parámetro el identificador de la interacción.
    Retorn...
API JavaScript SCORM
    ScormInteractionSetData toma como parámetro el
–
    identificador de una interacción, el element...
DATAMODEL
• Significado de las principales variables que usa la
  API de JavaScript:
   – cmi.comments_from_learner: texto...
DATAMODEL
– cmi.credit: indica si se calificará el rendimiento
  del usuario en este SCO.
– cmi.entry: indica si el usuari...
DATAMODEL
– cmi.learner_name: nombre del usuario
– cmi.learner_preference: preferencias del
  usuario asociadas al uso del...
DATAMODEL
– cmi.progress_measure: medida del progreso
  que el estudiante ha hecho hacia la
  terminación del SCO
– cmi.sc...
DATAMODEL
– cmi.time_limit_action: indica qué debería
  hacer el SCO si se excede el tiempo máximo
  permitido.
– cmi.tota...
MÁS INFO
• Se recomienda consultar como documentación
  complementaria, aquella que se encuentra en la
  zona de documenta...
PAUTAS DE
EMPAQUETAMIENTO. USO
  DE AGREGA OFFLINE
ÍNDICE
1.   Requisitos previos
2.   Especificaciones técnicas
3.   Empaquetado.
4.   Aspectos a tener en cuenta
5.   Agreg...
Requisitos previos
Para seguir el contenido de estas transparencias
es necesario conocer la especificación de
empaquetamie...
Especificaciones técnicas
Respecto al empaquetamiento, el pliego
establece que los simuladores deben ser
paquetes SCORM 20...
Empaquetado
Físicamente un objeto de aprendizaje (OA), es
un paquete formado por una única organización
que dispone de un ...
Empaquetado
• En esta fase productiva se parte de los siguientes
  elementos:
   – Archivos binarios
   – Archivo SIM.html
Empaquetado
Archivos
           Empaquetado
binarios



                           Objeto
                         SCORM 2...
Empaquetado
• El empaquetado de un OA requiere realizar las siguientes
  actividades:
   – Subir los contenidos binarios q...
Empaquetado
El ciclo de vida del empaquetado de un OA es:
     UPLOAD
                       CREACIÓN     CREACIÓN
   CONT...
Ejemplo de empaquetado OA
• Se va a desarrollar un ejemplo de creación de un OA
  denominado “El tamaño lineal de los obje...
Ejemplo de empaquetado OA
• Se abre la “Carpeta Personal”
Ejemplo de empaquetado OA
• Se usa la opción de “Crear”
Ejemplo de empaquetado OA
• Se rellena el título del ODE que se va a crear
Ejemplo de empaquetado OA
• Se sube al área de Archivos los contenidos del
  OA. Para ello primero se zippean.
Ejemplo de empaquetado OA
• A continuación se sube los contenidos
  zippeados.
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
• Se crea un recurso con el contenido subido:
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
• Se crea la organización con el item en la zona
  de Organizations.
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
• A continuación se cataloga el objeto
  seleccionando la opción de “Catalogar” desde
  la organ...
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
Ejemplo de empaquetado OA
• Visualización final:
Aspectos a tener en cuenta
– La herramienta de empaquetado a usar es Agrega
  Offline.¡¡NO SE PUEDEN USAR OTRAS HERRAMIENT...
Aspectos a tener en cuenta
– El empaquetado de un paquete debe realizarse
  siempre con el perfil Avanzado de Agrega Offli...
Aspectos a tener en cuenta
– Todo paquete debe gestionar la trazabilidad de los
  contenidos , y ésta se implementa en los...
Aspectos a tener en cuenta
– Dado que en los contenidos se va a gestionar la
  trazabilidad de los mismos, el recurso que ...
Aspectos a tener en cuenta
– Todo paquete debe contener entre los archivos
  binarios que lo forman un archivo especial
  ...
Aspectos a tener en cuenta
– El archivo SIM.html es generado junto con los contenidos
  binarios. ¡¡AGREGA OFFLINE NO DA S...
Aspectos a tener en cuenta
• Agrega es capaz de generar un archivo
  especial index.html, diferente del archivo
  SIM.html...
Aspectos a tener en cuenta
– Si un paquete requiere secuenciación
  condicionada, está deberá estar implementada en
  el c...
Aspectos a tener en cuenta
- Todo paquete debería tener en su interior:
  – Esquemas de LOM-ES y SCORM 2004
  – Archivo im...
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...
CATALOGACIÓN
• Elementos de partida.
  – Paquete SCORM 2004
  – Ficha Instruccional.
  – Otros aspectos de diseño y estilo...
CATALOGACIÓN
• Ciclo de vida:                                     Parte del ciclo
                                        ...
CATALOGACIÓN
• Dentro de un paquete, existen diferentes lugares
  en los que se pueden introducir metadatos:
      Nivel  ...
CATALOGACIÓN
• Todo paquete SCORM 2004 debe estar catalogado con
  respecto al perfil de aplicación LOM-ES.
     ¡¡SOLO SE...
CATALOGACIÓN
• Todo paquete catalogado debe validarse su
  catalogación a través de la función de validación
  de Agrega O...
CATALOGACIÓN
    En los formularios que ofrece Agrega Offline para rellenar las
•
    categorías de metadatos de LOM-ES es...
CATALOGACIÓN
• Todos los campos con texto libre deben describirse en el
  idioma principal del paquete, y debe señalarse d...
CATALOGACIÓN
• Existe una documentación explícita de cómo
  rellenar la categoría 9 con cada una de las
  taxonomías y tes...
CATALOGACIÓN

• La verificación de la corrección de los aspectos sintácticos
  del etiquetado del paquete se realizará a t...
PROPUESTA CATALOGACIÓN
•   Los valores presentados refieren a la documentación de LOM-ES v1.0.
•   En la producción de los...
PROPUESTA CATALOGACIÓN
DEFINICIÓN DE CATEGORÍAS:
        CATEGORÍA GENERAL: Agrupa la información general que describe el ...
PROPUESTA CATALOGACIÓN
Nº      Nombre          Criterios de catalogación                            Ejemplo               ...
PROPUESTA CATALOGACIÓN
Nº      Nombre          Criterios de catalogación                              Ejemplo             ...
PROPUESTA CATALOGACIÓN
Nº      Nombre            Criterios de catalogación                                   Ejemplo      ...
PROPUESTA CATALOGACIÓN
Nº        Nombre         Criterios de catalogación                           Ejemplo               ...
PROPUESTA CATALOGACIÓN
                                  Varias instancias. Utilizaremos el campo quot;Sistema
           ...
PROPUESTA CATALOGACIÓN
Nº    Nombre                    Criterios de catalogación                            Ejemplo       ...
PROPUESTA CATALOGACIÓN
                                                                                                   ...
PROPUESTA CATALOGACIÓN
Nº      Nombre           Criterios de catalogación                          Ejemplo                ...
PROPUESTA CATALOGACIÓN

Nº        Nombre          Criterios de catalogación               Ejemplo                         ...
PROPUESTA CATALOGACIÓN
Nº    Nombre        Criterios de catalogación               Ejemplo                             Com...
PROPUESTA CATALOGACIÓN
Nº        Nombre            Criterios de catalogación                          Ejemplo             ...
EJEMPLO CATALOGACIÓN
EJEMPLO CATALOGACIÓN
EJEMPLO CATALOGACIÓN
EJEMPLO CATALOGACIÓN
EJEMPLO CATALOGACIÓN
EJEMPLO CATALOGACIÓN
EJEMPLO CATALOGACIÓN
EJEMPLO CATALOGACIÓN
EJEMPLO CATALOGACIÓN
EJEMPLO CATALOGACIÓN
EJEMPLO CATALOGACIÓN
EJEMPLO CATALOGACIÓN
ENTREGA DE LOS
 SIMULADORES COMO
  PAQUETES ZIP Y LA
VALIDACIÓN DE RED.ES

   Exp. 729/07-SD
ASPECTOS A TENER EN CUENTA:

1.   Pilotaje de la versión candidata a definitiva en
     castellano
2.   Pautas generales p...
PILOTAJE DE LA VERSIÓN CANDIDATA A DEFINITIVA EN
CASTELLANO

 Red.es procederá a pilotar la primera entrega para
 asegurar...
PAUTAS GENERALES PARA ENTREGA DE VERSIONES
DEFINITIVAS
 Se entregará un zip que incluya la catalogación y el empaquetado
 ...
VALIDACIÓN TÉCNICA Y FUNCIONAL
Red.es procederá a validar técnica y funcionalmente los
paquetes entregados
En el caso de e...
ENTREGABLE FÍSICO:
VERSIÓN DEFINITIVA, FUENTES Y DOCUMENTACIÓN

El entregable físico, que permite la aceptación de la
fact...
Referencias

SCORM ® 2004 3rd Edition Documentation
En: http://www.adlnet.gov/scorm/20043ED/Documentation.aspx

Proyecto A...
Upcoming SlideShare
Loading in...5
×

Seminario Pautas De Producción Simuladores

2,173

Published on

Seminario sobre las pautas de producción para los simuladores

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,173
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
43
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Seminario Pautas De Producción Simuladores"

  1. 1. 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
  2. 2. PAUTAS PARA EL DESARROLLO DE ENTORNOS DE SIMULACIÓN PARA FORMACIÓN PROFESIONAL Exp. 729/07-SD
  3. 3. 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.
  4. 4. 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.
  5. 5. 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
  6. 6. 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.
  7. 7. 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
  8. 8. En este seminario vamos tratar exclusivamente de las restricciones: •Técnicas •Técnico-didácticas
  9. 9. 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.
  10. 10. 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
  11. 11. 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.
  12. 12. 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.
  13. 13. 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.
  14. 14. 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.
  15. 15. 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.
  16. 16. 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.
  17. 17. 5.1 Navegación guiada El tipo de navegación será guiada a lo largo de toda la simulación del proceso o procedimiento: aparecerán mensajes instructivos antes, durante (pistas) y después (feedback o retroalimentación) de la interacción .
  18. 18. 5.1 Navegación guiada Un simulador se puede asemejar a una máquina de estados finitos: en cada estado, el usuario puede realizar acciones que le permitan pasar a otro.
  19. 19. 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.
  20. 20. 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.
  21. 21. 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.
  22. 22. 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.
  23. 23. 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.
  24. 24. 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.
  25. 25. 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
  26. 26. 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).
  27. 27. 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”.
  28. 28. 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)
  29. 29. 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).
  30. 30. 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.
  31. 31. 10.Configuración y parametrización Los simuladores son configurables tanto en cantidad de problemas como en valores para cada situación planteada.
  32. 32. 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.
  33. 33. PAUTAS DE PRODUCCIÓN
  34. 34. ÍNDICE 5. TRAZABILIDAD Y PERSISTENCIA 5.1 En LMS 5.2 Fuera de LMS 6. Modelos de datos del RUN TIME
  35. 35. 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.
  36. 36. 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
  37. 37. 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.
  38. 38. 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.
  39. 39. 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.
  40. 40. 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.
  41. 41. 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.
  42. 42. 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/
  43. 43. 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
  44. 44. TRAZABILIDAD FUERA DE LMS Se recomienda usar un patrón de estrategia, • para variar el comportamiento dependiendo de si la ejecución es local o en un LMS Se puede usar la variable • System.security.sandboxType para ver en qué modo se está ejecutando el SWF Esta variable es de sólo lectura, y permite saber • en tiempo de ejecución qué modelo de seguridad se está ejecutando la película swf. De esta manera podemos saber si el OA se está ejecutando dentro de un LMS (valor remote) o en un PC en local (valor localWithFile).
  45. 45. TRAZABILIDAD FUERA DE LMS Una vez obtenido el valor de la variable es • cuando podremos aplicar el patrón de estrategia, estableciendo comunicación con el LMS en el caso de que el OA se esté ejecutando dentro del mismo, o evitando esa comunicación en el caso de que la ejecución sea local. De esta manera evitaremos los errores que se muestran al usuario.
  46. 46. 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.
  47. 47. 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).
  48. 48. 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.
  49. 49. 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)
  50. 50. PERSISTENCIA FUERA DE LMS Por ello, planteamos como solución el uso de • Objetos Compartidos Locales de Flash (Local Shared Objects - LSO). Un LSO es una colección de datos almacenados • como un fichero en un PC, y es un medio de mantener datos persistentes de manera local. Funcionan de manera parecida a las “Cookies” de un navegador.
  51. 51. PERSISTENCIA FUERA DE LMS Debido a que Flash Player de Adobe usa el • “sandbox security model”, estos archivos no pueden ser creados en cualquier parte del sistema de ficheros, estando limitada su ubicación a un directorio concreto. La ubicación es dependiente del S.O., siendo estas las más comunes: Windows: Dentro del directorio Datos de Aplicaciones – del usuario logado, en MacromediaFlashPlayerSharedObjects Mac OS X: ~/Library/Preferentes/Macromedia/Flash – Player GNU-Linux: ~/macromedia –
  52. 52. PERSISTENCIA FUERA DE LMS Al ser conocida la ubicación de los LSO, el • usuario puede copiarlos en algún soporte magnético, como un PenDrive, y trasladarlos a otro ordenador, donde podrá continuar con la simulación La principal ventaja de esta solución es la • simplicidad; no es necesario instalar ningún tipo de software adicional, se puede usar directamente desde la API de Flash/Flex (ActionScript) sin necesidad de añadir ninguna librería externa, y es totalmente transparente para el usuario. Además, permite trasladar los ficheros generados entre distintos equipos, independientemente del S.O.
  53. 53. PERSISTENCIA FUERA DE 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
  54. 54. PERSISTENCIA FUERA DE 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
  55. 55. PERSISTENCIA FUERA DE 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ó
  56. 56. PERSISTENCIA FUERA DE LMS Requisitos mínimos • Adobe Flash Player (cualquier versión o Macromedia – Flash Placer v.6 ó superior Permiso de lectura/escritura en el directorio de – almacenamiento de los LSO Restricciones • Los LSO sólo pueden ser almacenados en un directorio – específico, sin posibilidad de acceder a la totalidad del sistema de ficheros local. El límite de almacenamiento por defecto es de 100KB, – pudiendo incrementarse hasta tamaño ilimitado si el usuario lo autoriza.
  57. 57. PERSISTENCIA FUERA DE LMS La persistencia de datos en los Shared Objects • se guardará en variables con el mismo nombre que las definidas en el API de SCORM (DATAMODEL).
  58. 58. 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.
  59. 59. API JavaScript SCORM ScormGetValue(Elemento de datos). Esta – función permite recuperar datos almacenados en el entorno de ejecución, hace uso de las funciones ScormGetLastError para detectar si se ha producido algún error, y de ScormErrorString para mostrar mensajes de error en caso de haberse producido alguno. Para ello toma como parámetros el elemento de datos del modelo CMI que se quiere consultar.
  60. 60. API JavaScript SCORM ScormSetValue(Elemento de – datos,Valor).Esta función permite enviar datos para su almacenamiento en el entorno de ejecución. Para ello toma como parámetros el elemento de datos del modelo CMI que se quiere actualizar, y el valor con el que se quiere actualizar(se trata de valores predefinidos para cada elemento de datos).
  61. 61. API JavaScript SCORM SCORM 2004 permite a un SCO crear hasta • 250 registros de interacción. Cada registro contiene un identificador para esa interacción. Durante una sesión de comunicación, el entorno • de ejecución almacena los registros en un array indexado. El array de interacciones solo persiste durante la sesión de comunicación y el entorno de ejecución puede usar distintas aproximaciones para almacenar estos registros entre sesiones.
  62. 62. API JavaScript SCORM La colección de registros de interacción no se • encuentra almacenado en ningún orden determinado. Debido a esto último, en una comunicación posterior, los registros de interacción podrían aparecer en un orden diferente. En este sentido si se van a usar de una sesión previa, habría que encontrar que índice del array se le asignó en la nueva sesión, para lo cual se buscará los registros por el identificador de interacción.
  63. 63. API JavaScript SCORM Para gestionar esto se añaden nuevas funciones al script de SCORM: ScormInteractionGetCount no toma ningún • parámetro y retorna un valor entero que representa el número de registros de interacción existentes.
  64. 64. API JavaScript SCORM ScormInteractionAddRecord toma como • parámetro el identificador de una interacción y un tipo de interacción válida. Retorna un entero que corresponde al índice del array de registros o -1 si ocurre algún error. Si un registro de interacción con el mismo identificador y el mismo tipo ya existe, la function no hace nada y retorna el índice del registro existente. Si un registro de interacción con el mismo identificador pero con diferente tipo ya existe, la function falla. Si el número de registros de interacción permitidos se excediera por la adicción de un nuevo registro, la función fallaría.
  65. 65. API JavaScript SCORM ScormInteractionGetData toma como – parámetro el identificador de la interacción y el elemento del modelo de datos dentro del registro de la interacción, y retorna un valor. Si el valor es una cadena vacía, podría indicar un posible error. La cadena que identifica el elemento de datos es la que aparece a la derecha de “interactions.n..” en la documentación de SCORM para el modelo de datos.
  66. 66. API JavaScript SCORM ScormInteractionGetIndex toma como – parámetro el identificador de la interacción. Retorna un entero, que es el índice del registro de la interacción o -1 si el registro no existe. Se puede usar esta función para chequear si existe un registro para esa interacción.
  67. 67. API JavaScript SCORM ScormInteractionSetData toma como parámetro el – identificador de una interacción, el elemento del modelo de datos dentro del registro de interacción y el valor a poner. Retorna cierto o falso. Si retorna falso, se puede analizar el estado de error. Dado que los datos no pueden ser almacenados en un registro de interacción hasta que el identificador es almacenado en el registro, y algunos datos no pueden ser almacenados apropiadamente a menos que el tipo de interacción sea conocida, la función fallará si el registro de interacción no ha sido creado previamente por una llamada ScormInteractionAddRecord. La cadena que identifica el elemento de datos es la que aparece a la derecha de “interactions.n..” en la documentación de SCORM para el modelo de datos.
  68. 68. 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
  69. 69. 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.
  70. 70. 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
  71. 71. 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
  72. 72. 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.
  73. 73. 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:
  74. 74. PAUTAS DE EMPAQUETAMIENTO. USO DE AGREGA OFFLINE
  75. 75. Í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
  76. 76. 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.
  77. 77. 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).
  78. 78. 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.
  79. 79. Empaquetado • En esta fase productiva se parte de los siguientes elementos: – Archivos binarios – Archivo SIM.html
  80. 80. Empaquetado Archivos Empaquetado binarios Objeto SCORM 2004 Archivo SIM.html Etiquetado
  81. 81. 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
  82. 82. 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
  83. 83. 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.
  84. 84. Ejemplo de empaquetado OA • Se abre la “Carpeta Personal”
  85. 85. Ejemplo de empaquetado OA • Se usa la opción de “Crear”
  86. 86. Ejemplo de empaquetado OA • Se rellena el título del ODE que se va a crear
  87. 87. Ejemplo de empaquetado OA • Se sube al área de Archivos los contenidos del OA. Para ello primero se zippean.
  88. 88. Ejemplo de empaquetado OA • A continuación se sube los contenidos zippeados.
  89. 89. Ejemplo de empaquetado OA
  90. 90. Ejemplo de empaquetado OA
  91. 91. Ejemplo de empaquetado OA • Se crea un recurso con el contenido subido:
  92. 92. Ejemplo de empaquetado OA
  93. 93. Ejemplo de empaquetado OA
  94. 94. Ejemplo de empaquetado OA
  95. 95. Ejemplo de empaquetado OA
  96. 96. Ejemplo de empaquetado OA
  97. 97. Ejemplo de empaquetado OA
  98. 98. Ejemplo de empaquetado OA
  99. 99. Ejemplo de empaquetado OA
  100. 100. Ejemplo de empaquetado OA
  101. 101. Ejemplo de empaquetado OA • Se crea la organización con el item en la zona de Organizations.
  102. 102. Ejemplo de empaquetado OA
  103. 103. Ejemplo de empaquetado OA
  104. 104. Ejemplo de empaquetado OA
  105. 105. Ejemplo de empaquetado OA
  106. 106. Ejemplo de empaquetado OA
  107. 107. Ejemplo de empaquetado OA • A continuación se cataloga el objeto seleccionando la opción de “Catalogar” desde la organización principal
  108. 108. Ejemplo de empaquetado OA
  109. 109. Ejemplo de empaquetado OA
  110. 110. Ejemplo de empaquetado OA • Visualización final:
  111. 111. 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!!
  112. 112. Aspectos a tener en cuenta – El empaquetado de un paquete debe realizarse siempre con el perfil Avanzado de Agrega Offline. El perfil Básico ofrece una vista limitada para generar paquetes SCORM 2004. ¡¡HAY QUE COMPROBAR SIEMPRE QUE EL PERFIL CONFIGURADO ES EL AVANZADO. EN CASO CONTRARIO SE DEBE CAMBIAR MEDIANTE LA OPCIÓN DE CONFIGURACIÓN DEL MENÚ PRINCIPAL DE AGREGA OFFLINE!!
  113. 113. Aspectos a tener en cuenta – Todo paquete debe gestionar la trazabilidad de los contenidos , y ésta se implementa en los propios contenidos binarios de forma simultánea con la creación de los mismos. ¡¡LA TRAZABILIDAD SON LLAMADAS A UNA API DE JAVASCRIPT ESTÁNDAR DEFINIDA EN SCORM 2004!! ¡¡AGREGA OFFLINE NO CUBRE NINGÚN ASPECTO DE LA TRAZABILIDAD: NO PUEDEN EDITARSE LOS CONTENIDOS PARA INTRODUCIR LAS LLAMADAS, NI GENERA LA API DE JAVASCRIPT NECESARIA. ÉSTA DEBE SER PROPORCIONADA JUNTO A LOS CONTENIDOS BINARIOS!!
  114. 114. Aspectos a tener en cuenta – Dado que en los contenidos se va a gestionar la trazabilidad de los mismos, el recurso que se cree a partir de los contenidos binarios debe declararse como SCO y no como ASSET.
  115. 115. Aspectos a tener en cuenta – Todo paquete debe contener entre los archivos binarios que lo forman un archivo especial denominado SIM.html. Este archivo debe permitir utilizar los contenidos del paquete fuera del contexto de un LMS, en el entorno de un navegador Web.¡¡EN LA GESTIÓN DE LA TRAZABILIDAD, SE DEBE TRATAR EL CASO DE QUE EL PAQUETE NO SE ENCUENTRE DENTRO DEL CONTEXTO DE UN LMS, PARA QUE EL USO DEL MISMO NO GENERE LLAMADAS DE ERROR, Y PUEDA NAVEGARSE POR EL MISMO!!
  116. 116. Aspectos a tener en cuenta – El archivo SIM.html es generado junto con los contenidos binarios. ¡¡AGREGA OFFLINE NO DA SOPORTE A LA CREACIÓN DEL ARCHIVO SIM.html!! – La ejecución del simulador mediante el archivo SIM.html COINCIDE CON EL ARCHIVO PRINCIPAL DEL ÚNICO RECURSO DEL PAQUETE, PERO “ELIMINA” LAS POSIBLES LLAMADAS A LA API DE JAVASCRIPT O BIEN SE TRATAN EN LAS PROPIAS FUNCIONES JAVASCRIPT.
  117. 117. Aspectos a tener en cuenta • Agrega es capaz de generar un archivo especial index.html, diferente del archivo SIM.html anteriormente mencionado, el cual simula el previsualizador de Agrega fuera del contexto de Agrega.
  118. 118. Aspectos a tener en cuenta – Si un paquete requiere secuenciación condicionada, está deberá estar implementada en el contenido binario. ¡¡NUNCA SE USARÁ IMS SIMPLE SEQUENCING!! – Un paquete sin etiquetar correctamente es un paquete no valido, aunque se pueda guardar como un .zip. ¡¡SIEMPRE HAY QUE VALIDAR ANTES DE GUARDAR EL PAQUETE COMO UN .zip!!
  119. 119. Aspectos a tener en cuenta - Todo paquete debería tener en su interior: – Esquemas de LOM-ES y SCORM 2004 – Archivo imsmanifest.xml – Carpetas o archivos de los contenidos binarios que conforman el paquete. – API JavaScript. – SIM.html
  120. 120. CATALOGACIÓN
  121. 121. ÍNDICE CATALOGACIÓN EJEMPLO CATALOGACIÓN DOCUMENTACIÓN
  122. 122. 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.
  123. 123. 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
  124. 124. CATALOGACIÓN • Ciclo de vida: Parte del ciclo de vida cubierto Archivos Recursos Crear organización Empaquetado Etiquetado Objetos Aprendizaje
  125. 125. 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”
  126. 126. 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!!
  127. 127. 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!!
  128. 128. 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!
  129. 129. 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.
  130. 130. 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.
  131. 131. 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.
  132. 132. 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.
  133. 133. PROPUESTA CATALOGACIÓN 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.
  134. 134. PROPUESTA CATALOGACIÓ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;
  135. 135. PROPUESTA CATALOGACIÓN Nº Nombre Criterios de catalogación Ejemplo Comentarios 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)
  136. 136. PROPUESTA CATALOGACIÓN Nº Nombre Criterios de catalogación Ejemplo Comentarios 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
  137. 137. PROPUESTA CATALOGACIÓN Nº Nombre Criterios de catalogación Ejemplo Comentarios 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;
  138. 138. PROPUESTA CATALOGACIÓN 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.
  139. 139. PROPUESTA CATALOGACIÓN Nº Nombre Criterios de catalogación Ejemplo Comentarios 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;
  140. 140. PROPUESTA CATALOGACIÓN 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;
  141. 141. PROPUESTA CATALOGACIÓN Nº Nombre Criterios de catalogación Ejemplo Comentarios 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
  142. 142. PROPUESTA CATALOGACIÓN Nº Nombre Criterios de catalogación Ejemplo Comentarios 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.
  143. 143. PROPUESTA CATALOGACIÓN Nº Nombre Criterios de catalogación Ejemplo Comentarios 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.
  144. 144. PROPUESTA CATALOGACIÓN Nº Nombre Criterios de catalogación Ejemplo Comentarios 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.
  145. 145. EJEMPLO CATALOGACIÓN
  146. 146. EJEMPLO CATALOGACIÓN
  147. 147. EJEMPLO CATALOGACIÓN
  148. 148. EJEMPLO CATALOGACIÓN
  149. 149. EJEMPLO CATALOGACIÓN
  150. 150. EJEMPLO CATALOGACIÓN
  151. 151. EJEMPLO CATALOGACIÓN
  152. 152. EJEMPLO CATALOGACIÓN
  153. 153. EJEMPLO CATALOGACIÓN
  154. 154. EJEMPLO CATALOGACIÓN
  155. 155. EJEMPLO CATALOGACIÓN
  156. 156. EJEMPLO CATALOGACIÓN
  157. 157. ENTREGA DE LOS SIMULADORES COMO PAQUETES ZIP Y LA VALIDACIÓN DE RED.ES Exp. 729/07-SD
  158. 158. 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
  159. 159. 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.
  160. 160. 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…..).
  161. 161. 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.
  162. 162. 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.
  163. 163. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×