Fundamentos Del Diseñoi Learning PDF

Fundamentos del diseño
técnico-pedagógico
en e-learning
Jordi Casas Roma
P06/M1103/01584
Modelos de diseño
de las TIC
U
www.uoc.edu
Jordi Casas Roma
Ingeniero en Informática
por la Universidad Autónoma
de Barcelona (UAB).
Participación en la Cátedra
IBM-La Caixa, dirigida por la UOC,
en Estructuración de Materiales e
Incorporación en Entornos e-learning.
Responsable de autoría: Josep Prieto (Universitat Oberta de Catalunya)

Modelos de diseño de las TIC © FUOC • P06/M1103/01584
Índice
Introducción ................................................................... 5
1. La importancia de los estándares en el diseño

de un modelo tecnológico de e-learning ................. 7
1.1. Introducción. ¿Qué es un estándar? ....................... 7
1.2. Estándar frente a propietario. ¿Por qué es
importante un estándar? ....................................... 8
1.3. Resumen .............................................................. 9
2. Principales estándares para el e-learning ................ 11

2.1. Introducción ......................................................... 11
2.2. ADL Initiative ........................................................ 12
2.3. Aviation Industry CBT Committee ........................... 13
2.4. IMS Global Consortium ......................................... 13
2.5. IEEE Learning Technology Standards Committee ..... 14
2.6. Otros estándares .................................................. 15
2.7. Resumen .............................................................. 15
3. Los componentes del modelo tecnológico

del e-learning ........................................................... 17
3.1. Introducción ........................................................ 17
3.2. Componentes del e-learning ................................. 19
3.2.1. Learning Management System
(LMS, Sistema de gestión del aprendizaje) ....... 19
3.2.2. Learning Objects
(LO, objetos de aprendizaje) ........................ 20
3.2.3. Content Structures
(CS, estructuras del contenido) ..................... 22
ANOTACIONES
3.3. Resumen .............................................................. 25
4. ¿Qué estándares? Emparejando estándares

y componentes e-learning ........................................ 27
4.1. Introducción ......................................................... 27
4.2. Estándares para meta-data ................................... 31
4.2.1. Introducción ................................................ 31
4.2.2. SCORM meta-data ...................................... 32
3
© FUOC • P06/M1103/01584 Fundamentos del diseño técnico-pedagógico en e-learning
4.3. Estándares para evaluación (Assessment) ............... 33

4.3.1. Introducción ................................................ 33
4.3.2. The IMS Question & Test Interoperability
Models (QTI) ............................................... 34
4.4. Estándares para estructura
del contenido (Content Structure) ............................ 38
4.4.1. Introducción ................................................ 38
4.4.2. El SCORM Content Packaging Model ............ 39
4.4.3. El AICC Course Interchange Files ................. 41
4.5. Estándares para monitorización (Data Tracking) ..... 42
4.5.1. Introducción ................................................ 42
4.5.2. El estándar API ............................................ 44
4.5.3. El estándar HACP ........................................ 45
4.6. Resumen ............................................................... 46
5. Proceso de diseño de unos materiales e-learning .... 49

5.1. Introducción .......................................................... 49
5.2. Planteamiento general ........................................... 50
5.2.1. Definición de los objetivos ............................ 50
5.2.2. Creación del mapa del curso ....................... 51
5.2.3. Análisis de requerimientos y necesidades ...... 52
5.2.4. Recursos disponibles .................................... 54
5.2.5. Elección de los estándares ............................ 55
5.2.6. Una mirada al futuro ................................... 56
5.3. Diseño de los materiales ........................................ 57
5.3.1. Creación de los ‘Learning Objects’ ............... 58
5.3.2. Creación del meta-data ............................... 61
5.3.3. Creación de la estructura del curso
y de la secuenciación ................................... 63
5.4. Resumen ............................................................... 66
Resumen ......................................................................... 67
Mapa conceptual ............................................................ 69
Glosario .......................................................................... 71
Bibliografia ..................................................................... 79
ANOTACIONES
Apéndice A: el lenguaje XML ......................................... 83
Apéndice B: documentación de los principales

estándares ...................................................................... 93
Apéndice C: ejemplos comerciales en el entorno

del e-learning ................................................................ 97
Apéndice D: estructura del curso de ejemplo

del capítulo 5 ................................................................. 109
4
Introducción
En este módulo se proporcionará al estudiante una visión general del

diseño tecnológico de entornos e-learning, es decir, del conjunto for-
mado por los materiales y el sistema de gestión de dichos materiales.
Se prestará especial atención a los estándares, viendo las diferentes
tendencias existentes en la actualidad en el desarrollo de estándares
en e-learning.
El desarrollo de este módulo se estructura en torno a dos grandes

bloques:
En el primer bloque se describen los componentes básicos de un en-

torno e-learning y se presentan los principales estándares para cada
componente. Este bloque se estructura en los cuatro primeros capí-
tulos. De forma más detallada, en los capítulos 1 y 2 se habla de los
estándares y de las principales organizaciones de estandarización.
En el tercer capítulo se describen los principales componentes de un
entorno e-learning, y en el cuarto se presentan los principales están-
dares para cada componente.
El objetivo de este primer bloque es proporcionar los conocimientos

necesarios para poder afrontar el capítulo 5, que integra el segundo
bloque de este módulo. En este capítulo se verá el proceso de diseño
de unos materiales e-learning en dos partes básicas: el planteamien-
to y el diseño de los materiales. Para la lectura y comprensión del ca-
pítulo 5 será necesario haber comprendido correctamente los 4
ANOTACIONES
capítulos anteriores, que proporcionarán los conceptos básicos para

la lectura del capítulo 5.
Durante el desarrollo de este módulo se presentarán diferentes ejem-

plos, muchos de ellos escritos en lenguaje XML. Este lenguaje es muy
utilizado en este tipo de sistemas, ya que permite un alto grado de
estructuración de los datos. Por esta razón recomendamos la lectura
del apéndice A, el lenguaje XML, antes de iniciar la lectura de este
módulo.
5
1. La importancia de los estándares en el diseño

de un modelo tecnológico de e-learning
1.1. Introducción. ¿Qué es un estándar?
Aunque muchas veces no nos demos cuenta, en nuestra vida cotidia-

na utilizamos los estándares continuamente. Por ejemplo: los CD de
música están registrados en el soporte siguiendo el estándar que
marca el formato, las cintas VHS siguen otro estándar e incluso los
conectadores eléctricos siguen un estándar.
En el campo de la informática, su definición es compleja. Veamos

una definición de la palabra estándar proporcionada por una de las
organizaciones de estandarización.
aa
Según la Organización Internacional para la Estandar-
dización, ISO, los estándares son:
“Acuerdos documentados que contienen las especifica-

Nota
ciones técnicas u otros criterios precisos para ser utili-
ISO, International Organit-
zados como reglas, pautas, o definiciones de zation for Standardization,
características para asegurar que las materias, los pro- http://www.iso.org
ductos, los procesos y los servicios sean convenientes
para su propósito.”
Podemos diferenciar entre dos tipos de estándares, los estándares

ANOTACIONES
acreditados o de jure y los estándares llamados de facto.
Un estándar acreditado o de jure es un estándar aprobado y acredi-

Nota
tado por una organización de estándares, como puede ser, por
IEEE, Institute of Electrical
ejemplo, la ISO o la IEEE. and Electronics Engineers,
http://www.ieee.org
El otro tipo de estándares, los de facto, son aquellos estándares que

no han recibido la acreditación de ninguna organización, pero que,
7
por el contrario, son ampliamente utilizados en el mercado. En algu-

nos casos, dada su amplia utilización, vale la pena plantearse su uso
frente a otros que sí que han obtenido la acreditación de alguna or-
ganización, pero que en cambio no han conseguido el soporte de la
industria informática.
1.2. Estándar frente a propietario.

¿Por qué es importante un estándar?
Hay varias razones que permiten ver la importancia de un estándar. Su-

pongamos que nos disponemos a adquirir un software de e-learning
para nuestra organización. Puede ser, y es fácil que suceda, que in-
teresa que diferentes partes de nuestro sistema sea de proveedores
distintos. De este modo, por ejemplo, nos puede interesar la plata-
forma de gestión de un proveedor A, pero interesarnos la estructura
de los cursos de un cierto proveedor B. Si cada uno de los compo-
nentes implementa el mismo estándar, entonces podemos estar se-
guros de que el intercambio de información y protocolos entre ellos
no presentará ningún problema. De este modo, podemos adquirir
nuestro sistema de e-learning en diferentes componentes o partes,
adquiriéndolas en diferentes proveedores y en diferentes momentos
si ésta es nuestra necesidad. Los estándares se encargaran de velar
para que haya conexión entre los módulos.
Esto proporcionará a nuestro sistema la escalabilidad. Entenderemos

por sistema escalable un sistema compuesto por diferentes módulos
independientes entre sí, de manera que es posible agregar, cambiar
o modificar ciertos módulos sin repercutir en los demás. Esta carac-
terística nos permitirá agregar o cambiar partes del mismo en el fu-
turo sin necesidad de cambiar todo el sistema. De este modo, el
ANOTACIONES
trabajo realizado en el presente podrá ser reutilizado en el futuro,

asegurando que un cambio en una parte no implicará la revisión o
cambio de todo el sistema.
Centrándonos en los materiales, el uso de los estándares nos va a

permitir la importación y exportación de materiales entre varias pla-
taformas, siempre que apliquen los mismos estándares. De este mo-
do, aseguramos la portabilidad y reutilización de los materiales.
8
El coste del sistema también baja al poder comprar los componen-

tes por separado, buscando el componente que mejor se adapte a
nuestras necesidades funcionales y económicas. Si no dispusiéra-
mos de los estándares que se encargaran de la interconexión entre
diferentes componentes, estaríamos obligados a adquirir todo el sis-
tema de e-learning a un mismo proveedor, quedando así a merced
de un único proveedor.
En resumen, los beneficios de un sistema basado en estándares fren-

te a un sistema propietario son los siguientes:
• Libertad de elección.
• Escalabilidad del sistema.
• Portabilidad de los materiales.
• Reutilización de los materiales.
• No dependencia de un proveedor.
1.3. Resumen
En este primer punto se ha definido el concepto de estándar, y se ha

reflexionado sobre las diferencias de un sistema basado en estánda-
res frente a un sistema propietario. Es importante que nos lleguemos
a dar cuenta de la importancia de la reutilización, escalabilidad y
portabilidad en la creación de software de cualquier tipo. Esta nece-
sidad es la que empuja a la utilización de los estándares.
Es importante remarcar que el uso de un sistema basado en están-

dares posibilita la incorporación de cualquier tipo de material desa-
rrollado bajo el mismo estándar. De este modo es posible la
reutilización de los materiales (ya sean cursos completos, módulos o
ANOTACIONES
lecciones) entre diferentes organizaciones.
9
2. Principales estándares para el e-learning
2.1. Introducción
En la década de los ochenta nace el concepto del e-learning en la in-

dustria de la aviación, conocido como CBT (Computer-Based Training),
como consecuencia de las necesidades de este sector de entrena-
miento y mantenimiento de los pilotos.
Después de años de utilización del software y hardware propietario,

Nota
y debido a los elevados costes generados por el uso de dichos siste-
AICC, Aviation Industry CBT
mas, en el año 1988 se crea el AICC. Committee,
http://www.aicc.org
El objetivo de este organismo es reducir los costes de los sistemas de

entrenamiento y mantenimiento de los pilotos. Se crean estándares
hardware y software que permitan la reutilización de los sistemas de
aprendizaje, reduciendo de este modo los costes de dichos sistemas.
El AICC puso las bases del primer estándar en e-learning en el año

Nota
1993, cuando creó un estándar para un sistema de gestión de e-
Servidor web: Máquina que
learning. Se llamó CMI (Computer-Managed Instruction) y fue la pri- ofrece información en for-
mera especificación sobre un sistema de aprendizaje basado en un mato de página web a cual-
computador. Es el precursor de los sistemas actuales. En el año 1998 quier otra máquina que la
solicite mediante una peti-
se revisó dicho estándar y se le dio un enfoque actual, añadiéndole ción a través de red.
el sistema basado en servidor web.
Por otra parte, en 1997 nacen dos grandes grupos para la creación
ANOTACIONES
de estándares de e-learning. El primero nace a partir de un pro-

yecto del Ministerio de Defensa de Estados Unidos para modernizar
el sistema de enseñanza de las fuerzas armadas. Se llamó Advanced
Distributed Learning Iniciative (conocido como ADL) y es el creador
del SCORM (Sharable Content Object Reference Model), uno de los
estándares más populares de la actualidad. Por otro lado, nace el
IMS Project como un proyecto de carácter universitario y de ense-
ñanza en general dentro de Estados Unidos. Al cabo de un tiempo,
pasa a ser el IMS Global Learning Consortium, organismo que ha
11
desarrollado importantes estándares de diferentes tipos, entre ellos

los tests, sistemas de secuenciación y meta-data.
También en el año 1997, el IEEE crea una sección llamada Learning

Nota
Technology Standards Committee dedicada a los estándares en
IEEE, Institute of Electrical
and Electronics Engineers, e-learning.
http://www.ieee.org
Durante estos últimos años han aparecido nuevas organizaciones o

grupos para el desarrollo de estándares en e-learning. Todos juntos
constituyen una gran plataforma de investigación y desarrollo. A
continuación, citamos algunos de los más representativos.
2.2. ADL Initiative
El grupo ADL se encarga del desarrollo de SCORM, que abarca los

Nota
siguientes objetivos:
ADL, Advanced Distributed
Learning,
http://www.adlnet.org • Especificaciones técnicas de diferentes estándares y organizaciones.
• Un modelo de contenido (Content Model).
• Un estándar para un entorno completo de implementación de

e-learning.
El SCORM es un estándar que se basa en muchos otros, incorporan-

do el trabajo de otras organizaciones (por ejemplo AICC, IMS, IEEE
o ARIADNE) reúne diferentes estándares y los integra en un modelo
de implementación.
ANOTACIONES
Podemos encontrar la documentación del SCORM en la página web

de ADL, que se divide en las siguientes tres partes:
• Visión general (The SCORM Overview): proporciona una visión

general de su propósito y estructura.
• Modelo de contenido (The SCORM Content Aggregation Model):

contiene especificaciones para identificar, buscar y mover conte-
nido e-learning.
12
• Entorno de ejecución (The SCORM Run-Time Enviroment): contiene

especificaciones sobre la plataforma de administración y gestión
de un curso. Se especifica, por ejemplo, el lanzamiento del con-
tenido o el seguimiento del estudiante, entre otros, en un entorno
basado en web.
Desde la página web de ADL se ofrece software para

poder testear la compatibilidad de materiales e-lear-
ning con SCORM y versiones de prueba de Learning
Management Systems de SCORM.
2.3. Aviation Industry CBT Committee
El AICC fue el primer grupo centrado en el desarrollo de estándares

para e-learning. Desarrollan el modelo AICC como estándar de un
sistema de gestión de e-learning desde 1998.
También desarrollan guías técnicas conocidas como AGR (pautas y

Nota
recomendaciones de AICC). Por ejemplo, el AGR 010 se encarga de
AGR, AICC Guidelines &
la interoperatividad entre el material de un curso basado en web y el Recommendations
sistema de gestión.
Desde la página web se ofrece software para poder

testear la compatibilidad de materiales e-learning con
los estándares de AICC.
ANOTACIONES
Se puede obtener más información, así como las guías técnicas en la

web de AICC.
2.4. IMS Global Consortium

Nota
IMS:
El IMS define especificaciones para la localización y el uso de conte-
http://www.imsglobal.org
nido e-learning, monitorización del progreso del estudiante, repre-
13
sentación de los informes del estudiante e intercambio de registros

de estudiantes entre diferentes sistemas de gestión.
Dos de sus especificaciones han sido adoptadas por el SCORM, en

su versión 1.2. Éstas son:
• The IMS Learning Resource Meta-Data Specification: define un

método para describir recursos, y de este modo facilitar su bús-
queda.
• The IMS Content & Packaging Specification: define cómo crear

contenidos reusables para poder ser adoptados en diferentes sis-
temas de gestión.
Otras especificaciones están en espera de ser incorporadas total o

parcialmente:
• The IMS Question & Test Interoperability Specification: trata la ne-

cesidad de poder compartir bancos de preguntas y tests entre di-
ferentes sistemas.
• The IMS Learner Profiles Specification: define formas de organizar

la información del estudiante para permitir al sistema de gestión
adaptarse más a las necesidades de cada estudiante.
• The IMS Simple Sequencing Specification: define un método para

la secuenciación de los contenidos dentro de un curso.
ANOTACIONES
2.5. IEEE Learning Technology Standards

Committee
Esta organización, entre otros muchos temas de ingeniería y elec-

Nota
trónica, también desarrolla estándares, guías y software en el
Para más información con-
sultar la página web campo del e-learning. Están centrados en el desarrollo, desplie-
http://ltsc.ieee.org gue, mantenimiento e interoperatividad entre componentes y sis-
temas de e-learning.
14
2.6. Otros estándares
Existen otras organizaciones y muchos más estándares en el entorno

del e-learning. Además, en un entorno en rápida evolución como és-
te, los estándares evolucionan y progresan constantemente dando
lugar a nuevas versiones y especificaciones.
Por lo tanto, a la hora de escoger los estándares y estudiarlos con de-

talle, será muy conveniente asegurarnos de las versiones existentes y
de la opción que se está buscando.
No podemos finalizar este punto sin mencionar, aunque sea de for-

ma breve, la existencia de dos grupos más de gran importancia: el
ARIADNE y la ISO.
ARIADNE se centra en la creación de herramientas y metodologías

Nota
para facilitar la producción, gestión y reutilización de materiales
ARIADNE, Alliance of Remote
e-learning. La ISO, por su lado, creó un comité específico para el Instructional Authoring &
aprendizaje con tecnologías de la información llamado JTC1 SC36. Distribution Networks for
Europe,
http://www.ariadne-eu.org
2.7. Resumen
Nota
ISO, International Organization
for Standarditzation,
Hay una gran variedad de organizaciones que trabajan desarrollan- http://www.iso.org
do estándares para el e-learning, y a su vez, cada una de ellas tra-
baja en varios segmentos dentro de este campo, lo cual puede llegar
a producir desconcierto y una cierta confusión a las personas que se
Nota
inician.
JTC1 SC36, Joint Technical
Committee 1, Sub-Committee
No obstante, es necesario moverse con cierta soltura en este entorno 36, http://jtc1sc36.org
ANOTACIONES
para poder consultar especificaciones y actualizaciones de forma rá-

pida. Esto permitirá estar actualizados en un entorno en plena ex-
pansión, donde las cosas cambian rápidamente.
15
3. Los componentes del modelo tecnológico

del e-learning
3.1. Introducción
En el siguiente esquema se presenta un sistema de e-learning con

sus componentes básicos. El funcionamiento a este nivel de abs-
tracción es el siguiente: tanto los estudiantes como los administra-
dores y los formadores trabajan contra el sistema de gestión e
interfaz. El sistema de gestión e interfaz consulta los cursos y la
base de datos para proporcionar información a los estudiantes,
formadores y administradores sobre los cursos, estudiantes y el
estado de los estudiantes en los cursos.
La base de datos es la encargada de almacenar los datos que ge-

neran los estudiantes sobre cada curso (puntuación de ejercicios,
tiempo empleado, lecciones superadas, estado del curso, etc.).
Esta información es registrada por el sistema de gestión e interfaz
en la base de datos, incluida en el proceso que llamaremos mo-
nitorización o seguimiento del estudiante.
Figura 1. Esquema básico de un sistema e-learning

ANOTACIONES
17
A continuación, se verán los diferentes componentes que interactúan

dentro de este esquema. Será importante tener claros los conceptos
para poder entender el rol de cada uno de estos componentes en el
contexto de los estándares y el e-learning.
Como se puede ver en el anterior esquema, hay tres partes principa-

les y necesarias en un sistema de e-learning. Debe haber un siste-
ma gestor y una base de datos donde monitorizar las acciones de
los estudiantes. Estos dos componentes integran el llamado Learning
Management System (Sistema de gestión del aprendizaje, LMS). El otro
elemento importante es el propio curso. En un sistema de e-learning
un curso está compuesto por varios Learning Objects (Objetos de
aprendizaje, LO). Éstos son objetos con un mínimo de contenido in-
dependiente y la lógica necesaria para comunicarse con el Learning
Mangement System, y que pueden incluir, por ejemplo, textos, imá-
genes o vídeos interactivos.
Figura 2. Esquema básico de los elementos

de un sistema e-learning
ANOTACIONES
En la figura 2 se pueden visualizar los nuevos elementos. Por un lado

se puede ver el curso, formado por un conjunto de Learning Objects,
y por otro lado el Learning Management System, formado por el sis-
tema de gestión e interfaz y la base de datos.
18
3.2. Componentes del e-learning
3.2.1. Learning Management System

(LMS, Sistema de gestión del aprendizaje)
aa
El Learning Management System es un software (gene-
ralmente basado en un servidor web), que proporciona
las funciones necesarias para el tratamiento adminis-
trativo y de seguimiento o monitorización del curso,
como por ejemplo quién tiene acceso, quién utiliza
cada recurso, el nivel de uso de cada recurso o el tiem-
po de proceso de cada estudiante.
Las funciones y características de cada Learning Management System

oscilan de un producto a otro, pero generalmente todos ofrecen las
siguientes funciones y características:
• Funciones administrativas: registro del estudiante, asignación de

curso, informes de los progresos del estudiante, informes del es-
tado de los cursos.
• Interfaz del estudiante: cuando el estudiante accede al sistema a

través de su usuario se le presenta un menú personalizado que le
permite acceder a los contenidos del curso. Usualmente, también
se le permite ver informes sobre sus progresos y su estado actual
en el curso.
Figura 3. Interacción de los distintos perfiles de usuario

con el Learning Management System
ANOTACIONES
19
El Learning Management System será también el encargado de la se-

cuenciación del estudiante en las diferentes lecciones del curso, a tra-
vés del menú personalizado para cada estudiante. Es decir, permite
opcionalmente establecer un orden entre las lecciones o módulos, de
forma que para acceder a una lección o módulo es necesario haber
superado las anteriores.
3.2.2. Learning Objects (LO, objetos de aprendizaje)
aa
Un Learning Object es la unidad mínima de contenido
que tiene sentido por sí misma dentro de un sistema e-
learning.
El tamaño puede variar mucho, pero se considera que cada Learning

Object debe corresponder a un solo objetivo o concepto. Debe ser
independiente, es decir, ser completo sin la necesidad de completar
su significado con otros componentes. Por lo tanto, es una unidad
reusable e intercambiable. Los Learning Objects son las unidades
básicas de los materiales, constituidos como el conjunto de uno o
más archivos (con texto, imágenes, animaciones y otros) agrupados
bajo una sola entidad.
Tal como muestra su definición, el concepto de Learning Object no

es cerrado, y admite un cierto grado de interpretación. Es decir, la
discusión sobre el tamaño y el contenido de un Learning Object no
está cerrada, y en diferentes contextos se pueden presentar ligeras
variaciones en cuanto a tamaño y contenido.
ANOTACIONES
Supongamos que deseamos crear un curso sencillo, con una intro-

ducción, una explicación y un test final. En este caso, podemos plan-
tear la creación de tres Learning Objects, uno para cada uno de los
conceptos descritos. Este planteamiento es correcto, pero no es el
único válido. Por ejemplo, podemos plantear la creación de dos
Learning Objects: por un lado un Learning Object con la introducción
y por el otro lado un segundo Learning Object que contenga la ex-
plicación y el test final. Ambas soluciones son válidas.
20
Un Learning Object está formado por dos bloques básicos:
• La información.
• La lógica de comunicación.
Por un lado encontramos toda la información y su presentación. Ésta

Nota
es la parte que verá el estudiante por medio de su cliente web. Se
Cliente web: También lla-
pueden mostrar varios tipos de formatos, como por ejemplo, texto mado navegador web o
HTML, vídeo, animación Flash, etc. browser. Programa para la
navegación por Internet,
como por ejemplo Internet
Por otro lado, la lógica de comunicación es la parte que se encarga- Explorer o Netscape Navi-
gator.
rá de realizar la comunicación entre el Learning Object y el Learning
Management System, proporcionando la información de las activida-
des que realiza el estudiante al Learning Management System. Este
Nota
bloque no es visible por el estudiante.
HTML, Hypertext Markup
Language. Es el lenguaje
utilizado para dar formato
Figura 4. Los dos bloques principales de un Learning Object gráfico a las páginas web.
Para más información se
puede consultar la página
http://www.w3.org/MarkUp/
Por ejemplo, se puede suponer un Learning Object que sea simple-

mente un texto HTML con imágenes. Por un lado se tiene el texto
HTML y las imágenes, que será la parte que el estudiante verá en su
ANOTACIONES
cliente web. Pero el Learning Object también contendrá porciones de

código en algun lenguaje de programación web que permitirán co- Nota
municar el Learning Object con el Learning Management System Lenguajes de programa-
ción web: Lenguajes de
para intercambiar información.
programación orientados
a la web, que se ejecutan
bajo el entorno de clientes
Ejemplo
web (browsers). Los más
Un ejemplo típico de esta comunicación entre el Learning importantes son JavaScript
y VBScript.
Object y el Learning Management System consiste en
21
enviar información de la cantidad de tiempo que el es-

tudiante ha tenido una página cargada en su cliente
web, para controlar el tiempo empleado por el estu-
diante para leer la página. Esto se controla registrando
el tiempo entre la solicitud de la página y la solicitud de
la siguiente.
3.2.3. Content Structures

(CS, estructuras del contenido)
aa
La unión de diferentes Learning Objects constituye es-
tructuras mayores, organizadas de forma jerárquica,
que también responden a diferentes estándares. El mo-
delo de estas estructuras es lo que llamaremos estruc-
turas del contenido o content structures.
Por ejemplo, un curso se divide en módulos, los módulos en lec-

ciones y las lecciones en capítulos. El objetivo es poder represen-
tar de una forma muy simple una amplia variedad de estructuras.
Se utiliza un archivo especial, llamado hoja de instrucciones (instruction

sheet), que sirve para especificar las dependencias y relaciones
entre los diferentes componentes que integran las estructuras del
contenido.
A continuación veremos el modelo de las estructuras del conte-

ANOTACIONES
nido de los dos principales entándares, el SCORM y el AICC:
SCORM Content Hierarchy (jerarquía de contenido de SCORM),

incluye tres tipos de componentes y una hoja de instrucciones lla-
mada manifest:
• Content Aggregation (CA, Agregación del contenido): se trata

de un grupo de recursos que tiene independencia del contexto.
22
Un curso completo siempre constituye un content aggregation.

Otros bloques de niveles inferiores lo pueden llegar a ser si son
suficientemente independientes.
• Sharable Content Object (SCO, Objetos compartidos de conte-

nido): es el nombre que reciben los Learning Objects en el sis-
tema SCORM, es decir, es el concepto de Learning Object que
utiliza el estándar SCORM. Es el nivel donde el estudiante ac-
túa directamente sobre el contenido y donde el Learning Ma-
nagement System monitoriza los resultados.
• Asset: se trata de un pequeño y simple recurso que puede ser

utilizado en diferentes contextos. Son unidades más pequeñas
que los Sharable Content Object, pero a diferencia de éstos,
no tienen independencia, y por sí mismos carecen de signifi-
cado completo. No tienen capacidad de comunicación con el
Learning Management System. Normalmente, son llamados
por los Sharable Content Object, aunque también pueden ser
llamados por el Learning Management System directamente.
Generalmente, están integrados por contenidos como gráfi-
cos, sonidos, películas o animaciones, aunque no hay restric-
ciones sobre su composición.
A continuación, se ejemplificará la estructura de contenido del es-

tándar SCORM (figura 5).
Un curso completo, dado su grado de independencia, siempre re-

presenta un content aggregation. Dentro de este bloque principal,
encontramos la hoja de instrucciones y un conjunto de sharable
content objects. Este conjunto puede presentar estructuras animadas
de content aggregation, siempre que los sharable content object con-
ANOTACIONES
tenidos en su interior presenten un grado de independencia suficien-

te. El sharable content object, que representa la unidad mínima de
contenido con independencia, puede contener cualquier número de
recursos, los assets, en su interior.
23
Figura 5. Estructura
de contenido básica
de un curso SCORM
AICC Content Hierarchy (jerarquía de contenido de AICC): incluye

tres tipos de componentes y una hoja de instrucciones formada por
varios ficheros de texto:
• Course (curso): es el nivel más alto de la jerarquía. Se trata del

componente que corresponde a un curso completo.
• Instructional Block (bloque instruccional): se trata de un grupo op-

cional de unidades más pequeñas. Se pueden anidar varias ca-
pas para formar una estructura concreta. Están formados por
varios Learning Objects que forman un bloque independiente,
aunque no lo suficiente como para constituir un curso. Estos com-
ponentes intermedios entre el curso y los Learning Objects permi-
ten la creación de jerarquías y subgrupos dentro de un curso,
como por ejemplo módulos o lecciones.
• Assignable Unit (AU, unidad asignable): es el nombre que reciben los

ANOTACIONES
Learning Objects en el modelo AICC. Se presentan como una unidad

de contenido independiente. A veces se pueden presentar como una
lección entera, aunque su nivel de granularidad es muy variable.
Por ejemplo, una posible estructura para un curso que trate sobre
lengua podría ser la siguiente: el curso completo se divide en cuatro
instruccional blocks: el primero explica el sistema de funcionamiento
del curso y del entorno (interfaz, ayuda, etc.) mientras que los tres si-
24
guientes corresponden a una explicación sobre gramática, ortografía

y literatura respectivamente. Cada uno de estos Instruccional Block
contiene uno o más Assignable Units.
de contenido básica
de un curso AICC
3.3. Resumen
Figura 7. Estructura de contenido básica

de un curso AICC
ANOTACIONES
Existen dos grandes bloques en lo que se refiere a componentes de

e-learning. Por un lado se encuentra el material que forma el curso,
25
con todos sus elementos: la estructura del contenido, la hoja de ins-

trucciones y los Learning Objects. Aunque reciban nombres diferen-
tes dependiendo del modelo (AICC o SCORM), los conceptos son
paralelos. Por el otro, se encuentra el Learning Management System,
que integra el sistema de gestión e interfaz y la base de datos.
ANOTACIONES
26
4. ¿Qué estándares? Emparejando estándares

y componentes e-learning
4.1. Introducción
En este punto veremos los principales estándares que se encuentran

en la actualidad para algunos de los principales componentes de un
entorno e-learning.
Figura 8. Esquema de un entorno e-learning
El anterior esquema presenta el resumen de un entorno e-learning,

visto en el punto anterior, donde podemos identificar los principales
ANOTACIONES
componentes.
Veamos el funcionamiento, a grandes trazos, de un sistema de estas

características.
Cuando el estudiante accede al sistema, generalmente después

de validarse, accede a una página inicial de bienvenida. El punto
más importante en esta parte inicial es, sin duda, el menú que nos
27
va a permitir acceder a las diferentes lecciones o módulos del cur-

so. La figura 9a presenta una ampliación de la zona del menú. El
menú suele presentar de forma ordenada un enlace a cada uno
de los Learning Objects que tenemos en el curso. Un módulo puede
presentar diferentes lecciones, cada lección puede presentar dife-
rentes conceptos o explicaciones y cada uno de estos conceptos
suele corresponder a un Learning Object.
Por ejemplo, la figura 9a presenta un menú que contiene siete

enlaces, estructurados de la siguiente forma: el bloque principal
(Inland Rules of the Road) contiene en su interior cuatro enlaces y
un bloque secundario (Steering & Sailing Rules), que contiene tres
enlaces más.
Cada uno de estos enlaces cargará en la parte principal del clien-

te web un Learning Object (Figura 9b). Para realizar dicha acción
el Learning Management System recoge el enlace que ha activado
(pulsado) el estudiante y le manda el Learning Object que corres-
ponde a dicho enlace. El cliente web del estudiante recibe el Learning
Object y lo carga en la parte principal de la ventana (Figura 9c). En
este punto, el Learning Management System y el cliente web del
estudiante están listos para intercambiar información.
Se puede enviar o recibir información cuando el estudiante lo so-

licita explícitamente, por ejemplo, comprobar la respuesta de una
pregunta test. Pero también se realiza el intercambio de informa-
ción de forma transparente al estudiante. Éste sería el caso, por
ejemplo, de informar del momento en que el estudiante ha inicia-
do un Learning Object y el momento en que lo da por finalizado,
es decir, que cambia de Learning Object (Figura 9d).
ANOTACIONES
Toda esta información será monitorizada y registrada en la base

de datos del Learning Management System, de forma que pueda
ser tratada con posterioridad.
28
Figura 9. Proceso de acceso a un Learning

Object desde el cliente web
Una vez visto este primer esquema inicial del funcionamiento de un

sistema e-learning, profundizaremos un poco más en él. A continua-
ción, vemos el mismo esquema que en la figura 8, pero con un nivel
de detalle mayor.
Figura 10. Esquema de un entorno e-learning con más de detalle
ANOTACIONES
En primer lugar observamos que el curso no se compone únicamente

de un conjunto de Learning Objects; aparecen dos nuevos conceptos
ligados al curso:
• El meta-data (MD).
29
• El test/evaluación.
El meta-data es información sobre los contenidos de los Learning

Objects, lecciones, módulos y cursos. Proporciona información descrip-
tiva sobre los contenidos, como por ejemplo un pequeño resumen del
contenido, la categoría, las palabras clave o a quién va dirigido, con la
finalidad de facilitar el intercambio y reutilización de los Learning
Objects, lecciones, módulos o cursos en diferentes ámbitos.
Los elementos de test/evaluación nos facilitarán la evaluación de los

estudiantes mediante un sistema estándar de test, permitiendo incor-
porar en nuestros cursos otros tests. Es posible crear tests a partir de
Learning Objects, utilizando las funciones para la transferencia de in-
formación con el Learning Management System.
aa
Entonces, ¿por qué crear un sistema de tests indepen-
diente?
Este sistema de tests va a permitir la importación o exportación de

tests entre sistemas no compatibles entre sí, y además da la posi-
bilidad de exportar los datos generados por los tests a sistemas ge-
néricos para generar informes o estadísticas. Des esta forma, si
utilizamos un sistema de tests estándar dispondremos de multitud
de herramientas para manipular la información y extraer resúme-
nes o estadísticas.
En el esquema también vemos la incorporación de la estructura de con-

tenido (CS, content structure), que organiza de forma jerárquica los com-
ponentes del curso. Permite, además, que el Learning Management
ANOTACIONES
System importe un curso comprobando las dependencias y reprodu-

ciendo la estructura jerárquica.
Por otra parte, vemos un nuevo intercambio de información entre el

Learning Object del cliente web del estudiante y el Learning Management
System. Este nuevo intercambio de información es la monitoriza-
ción o seguimiento del estudiante, llamada también Data Tracking.
Como hemos visto, este intercambio permite al Learning Management
System obtener información de las actividades que realiza el estu-
30
diante en cada Learning Object. Por ejemplo, permite registrar en

la base los resultados de tests o evaluaciones realizados por cada
estudiante. El Learning Management System también puede pro-
porcionar información al cliente web del estudiante, por ejemplo,
el nombre del estudiante o las lecciones y módulos que tiene ha-
bilitados.
Es decir, la monitorización o data tracking es el intercambio de infor-

mación entre el Learning Object que ejecuta el estudiante en su cliente
web y el Learning Management System. Será, por lo tanto, necesario
que los Learning Object y el Learning Management System imple-
menten el mismo sistema de data tracking para que dicha comuni-
cación sea posible.
A continuación, veremos estos componentes con un poco más de de-

talle y explicaremos algunos de los principales estándares para cada
uno de ellos.
4.2. Estándares para meta-data
4.2.1. Introducción
El meta-data se define como “datos sobre datos”, es decir, informa-

ción que un mismo objeto ofrece sobre sí mismo. En el caso de un
Learning Object, el meta-data proporcionará información de, entre
otros, el título, una descripción de los contenidos, el precio, los tér-
minos de uso o su localización en Internet.
aa
ANOTACIONES
La función básica del meta-data es crear una estruc-

tura de información autodescriptiva para los Learning
Objects, de forma que cada uno pueda ofrecer una
misma información para facilitar su búsqueda. De
este modo, conseguiremos o facilitaremos que los
Learning Objects sean fácilmente compartibles y
reutilizables.
31
El meta-data se muestra en un fichero estructurado de texto, gene-

ralmente agrupado por parejas de etiqueta-valor. Es decir, la etique-
ta indica el tipo de información y el valor especifica dicha
información. La pareja “autor: Manuel Molina Martos” es un ejemplo
de dicha estructura.
Las principales ventajas que proporciona el uso de meta-data en los

materiales e-learning son las siguientes:
• Es una excelente forma de documentar los Learning Objects.
• Es un sistema muy efectivo para crear y gestionar nuestra propia

librería de Learning Objects.
• En el caso de desear vender los Learning Objects, se estará ofre-

ciendo un producto más completo y facilitando su búsqueda a los
posibles compradores.
• IMS y ADL están trabajando juntos para incorporar un sistema en

el Learning Management System que sea capaz de buscar y lanzar
los Learning Objects sobre la base de unos criterios de contenido,
de forma automática.
Ahora veremos las características básicas adoptadas por el IMS Lear-

ning Object Meta-Data Specification (LOM), que es el estándar
adoptado por SCORM.
4.2.2. SCORM meta-data
CORM ha adoptado la especificación de meta-data de IMS, llamada

Nota
IMS Learning Object Meta-Data Specification (LOM). En el modelo LOM
XML (eXtensible Markup
los ficheros del meta-data están escritos en lenguaje XML, dado que este
ANOTACIONES
Language). Lenguaje de
marcas diseñado para la lenguaje es especialmente útil para la estructuración de la información.
estructuración e intercam-
bio de información entre
diferentes sistemas. Para A continuación se presenta un pequeño ejemplo de cómo es un ar-
más información podéis chivo de meta-data.
consultar el apéndice A.
Es importante reseñar que éste es un archivo de ejemplo, no válido

para la especificación por ser incompleto, pero que puede dar una
idea de cómo son estos archivos.
32
<lom>
<general>
<title>Lección 1.1</title>
<catalogentry>
<catalog>Catálogo de cursos</catalog>
<entry>p-006</entry>
</catalogentry>
<description>La literatura en el s.XXI</description>
<keyword>literatura</keyword>
</general>
<lifecycle>
<version>1.0</version>
<status>final</status>
</lyfecycle>
….
</lom>
La etiqueta inicial o principal,<lom>, indica el modelo del meta-

data que estamos utilizando, en este caso el LOM (IMS Learning Object
Meta-Data). A continuación, se presenta la etiqueta <general>, que
contiene información sobre el título, entradas del catálogo, descrip-
ción y palabras clave del material al que acompaña este fichero. Y
para finalizar, se encuentra la etiqueta <lyfecyle> que contiene in-
formación acerca de la versión y de su estado.
4.3. Estándares para evaluación

(Assessment)
ANOTACIONES
Es posible crear tests para la evaluación del estudiante mediante

Learning Objects. Es decir, los Learning Objects tienen suficiente
capacidad para implementar tests. Durante mucho tiempo no
han existido estándares específicos para tests, y éstos se han im-
plementado mediante Learning Objects. Pero recientemente han
aparecido estándares específicos para tests, diseñados para cu-
brir las necesidades específicas de los tests y sistemas de evaluación.
33
Los estándares para evaluación se presentan como una especifica-

ción separada de los Learning Objects porque no sólo sirven para
presentar un test en un Learning Management System, sino que, ade-
más, pueden usarse para importar/exportar librerías, grupos estruc-
turados y tests completos de cuestiones de una forma neutral y
estándar independiente de la plataforma o sistema utilizado. El ob-
jetivo es, por ejemplo, generar los tests bajo un determinado entorno
y visualizar o tratar los datos de informes bajo otro entorno, eso sí,
ambos deberán aceptar este estándar.
Una parte muy importante de un curso reside en el modelo de eva-

Nota
luación, y por ello veremos en este capítulo el principal estándar exis-
QTI, IMS Question & Test
tente para la creación de tests, llamado IMS Question & Test
Interoperation Specification,
http://www.imsglobal.org/ Interoperation Specification (QTI), que detalla el método para com-
question/index.cfm partir tests e informes sobre los resultados.
Actualmente, el ADL está considerando incluir el QTI en su estándar

SCORM.
4.3.2. The IMS Question & Test Interoperability Models

(QTI)
El QTI presenta dos grandes componentes:
• El modelo test-grupo-cuestión (ASI, Assessment-Section-Item), que

especifica el contenido del test, el procesamiento de la respuesta,
la secuenciación de presentación y el resultado global del test.
• El modelo de informes de resultados (Results-Reporting), añadido

al QTI en su versión 1.2, facilita un método estándar para el al-
macenamiento de los resultados y su posterior uso en varios con-
ANOTACIONES
textos. Ofrece unos métodos para analizar la evaluación a

diferentes niveles, permitiendo definir los informes de resultados
a niveles de items, secciones o tests completos.
El modelo ASI define la apariencia y la organización de cuestiones

individuales (items), grupos estructurados de cuestiones (sections) y
tests completos (assessments), organizados en lo que se llama ban-
cos de objetos (objects banks).
34
El item es el elemento análogo al Learning Object para el caso del

QTI. Contiene toda la información referente a una cuestión (visuali-
zación, soluciones, etc.). Las secciones se presentan como grupos de
items y otras subsecciones, a modo de estructurar los tests y facilitar
una secuenciación de las cuestiones. Un assessment se presenta
como un grupo de secciones estructuradas representando un test
completo. Debe ser independiente, de forma que contenga toda la
información necesaria para presentar el test.
Y para finalizar, el object bank es un grupo no estructurado de items

o secciones que sirve para transportar contenido entre diferentes
Learning Management Systems.
Figura 11. Organización de los

elementos de un QTI
Los tests se escriben utilizando el lenguaje XML, que facilita la estruc-

turación de la información y permite una gran portabilidad entre di-
ferentes plataformas.
ANOTACIONES
A continuación veremos un pequeño ejemplo, para una sola cues-

tión (item), que ilustrará el funcionamiento y estructura del sistema
QTI.
Supongamos que queremos preguntar al estudiante la solución a la

operación “(3 x 4) + 7”, ofreciéndole dos respuestas concretas y la
opción de “ninguna de las anteriores”. Además, deseamos que las
respuestas se den en orden aleatorio, excepto la opción de “ninguna
de las anteriores”, que debe permanecer siempre en último lugar.
35
El estudiante, en su cliente web, deberá ver algo semejante a:
Figura 12. Ejemplo de

la visualización de una
cuestión (item)
A continuación mostramos el código necesario para que el estudian-

te pueda leer la pregunta del test. El ejemplo no está completo, pero
nos permitirá ver la estructura básica y las principales partes para
una cuestión (item).


<item title=“Ejemplo 1” ident=“Ejemplo_001”>
<qticomment>
Éste es un ejemplo de uso de una cuestión de selección múltiple
</qticomment>
<presentation label=“Ejemplo 001”>
<flow>
<material>

<mattext>
¿Cuál es la solución a (3 x 4) + 7?
</mattext>

<response_lid ident=“R_01” rcardinality=“single” rtiming=“yes”>

<render_choice shuffle=“yes”>
ANOTACIONES


<flow_label>
<response_label ident=“R_01_A”>
<material>
<mattext>
15
</mattext>
</material>
36
</response_label>
</flow_label>

<flow_label>
<response_label ident=“R_01_B”>
<material>
<mattext>
37
</mattext>
</material>
</response_label>
</flow_label>

<flow_label>
<response_label ident=“R_01_C” rshuffle=“no”>
<material>
<mattext>
Ninguna de las anteriores
</mattext>
</material>
</response_label>
</flow_label>
</render_choice>
</response_lid>
</material>
</flow>
</presentation>

<resprocessing>
<qticomment/>
<outcomes>
ANOTACIONES
<decvar vartype=“Integer” defaultval=“0”/>

</outcomes>

<respcondition>
<qticomment> Puntuación de la respuesta correcta. </qticomment>
<conditionvar>
<varequal respident=“R_01”>R_01_C</varequal>
</conditionvar>
37
<setvar action=“Set” varname=“SCORE”>10</setvar>

</respcondition>
</resprocessing>
</item>
El item empieza declarando un título y un identificador (único) segui-

do de un comentario. El primer gran bloque, <presentation>, co-
rresponde a la visualización de la cuestión, planteando en primer
lugar la pregunta y ofreciendo posteriormente tres posibles respues-
tas. El bloque <resprocessing> nos servirá para procesar la respues-
ta. En este caso, si se ha seleccionado la opción C, se asignará una
puntuación de 10 a esta cuestión. En caso contrario, la puntuación
queda a cero.
4.4. Estándares para estructura

del contenido (Content Structure)
aa
Las estructuras de contenido especifican cómo debe-
mos agrupar los Learning Objects para generar la es-
tructura de los cursos. Esta estructura permitirá la
importación/exportación en diferentes Learning Mana-
gement Systems y el almacenamiento en repositorios de
contenidos para facilitar su búsqueda y acceso.
La estructura de contenido de un curso está formada por tres tipos de

ANOTACIONES
componentes:
• La parte principal, que está formada por los ficheros que contie-
nen los Learning Objects, los tests y los recursos visuales que con-
forman los materiales.
• La hoja de instrucciones (instruction sheet), que incluye descripcio-

nes de los diferentes recursos que forman los materiales, su es-
tructura y las dependencias entre ellos.
38
• La estructura de directorios, que nos facilitará la estructuración de

todos los elementos que conforman el curso.
Si los tres componentes responden a un estándar, será posible que

un Learning Management System lea la hoja de instrucciones y reali-
ce la importación de los materiales.
En esta sección veremos las especificaciones adoptadas por el AICC

y por el SCORM para la importación/exportación de cursos entre di-
ferentes Learning Management Systems.
Ambos estándares comparten, básicamente, el mismo tipo de infor-

mación acerca de los recursos que incluye la estructura de contenido.
Entre la información básica que comparten ambos estándares, po-
demos encontrar:
• El número de versión de la especificación utilizada para crear el

curso.
• Un identificador único para el curso y para cada recurso.
• Un título para el curso y para cada recurso.
• Una descripción para el curso y para cada recurso.
• Una descripción de la estructura del curso completo, especifican-

do las agrupaciones de recursos.
Por otro lado, hay importantes diferencias. El SCORM, por ejemplo,

plantea la transferencia o intercambio de cualquier tipo de conteni-
do, desde un simple Learning Object hasta un curso completo, y bus-
ANOTACIONES
ca en su estructura de contenido la forma de poder importar

paquetes de niveles diferentes.
4.4.2. El SCORM Content Packaging Model
SCORM presenta un modelo de estructura del contenido flexible y

potente, permitiendo la agrupación a varios niveles: desde un único
Learning Object hasta un curso completo.
39
El SCORM contiene dos tipos de especificaciones para la estructura

del contenido:
• Content Package: uno o más assets, Learning Objects o coleccio-

nes completas para transferir entre diferentes Learning Manage-
ment Systems.
• Content Aggregation Package: un grupo estructurado de compo-

Nota
nentes. Es el concepto equivalente de curso para el SCORM.
Asset: Recurso simple usado
dentro de un Sharable Content
Object en el modelo SCORM.
Generalmente, imágenes, grá- Figura 13. Esquema del Content Package de SCORM
ficos, sonidos o vídeos utili-
zados en uno o varios
Learning Objects.
Las dos especificaciones utilizan un archivo llamado manifest que

describe el contenido, la estructura y las dependencias utilizando
ANOTACIONES
el lenguaje XML.
Cualquiera de estos dos tipos de paquetes debe llevar un archivo mani-

fest (imsmanifest.xml) en la raíz del medio de distribución para que un
Learning Management System pueda importar el contenido.
40
Veamos ahora la estructura, a grandes trazos, de un fichero manifest:
• <manifest>: elemento externo que contiene a todos los demás.

– <metadata>: elemento que contiene el meta-data que descri-
be el paquete
– <organitzations>: elemento que contiene una o más estructu-
ras de organizaciones.
<organitzation>: define la estructura del curso.
- <title>: titulo.
- <adl:description>: descripción de la organización.
- <item>: elemento contenedor para un Learning Object
o un bloque.
x Un identificador único en el paquete
x Un título
x Una descripción
x Los prerrequisitos
– <resources>: elemento contenedor de una lista individual de
Learning Objects y assets contenidos en el paquete.
<resource>: elemento contenedor para describir y locali-
zar información sobre un fichero de contenido.
- Un identificador único
- Una descripción del tipo de recurso
- Una URL
4.4.3. El AICC Course Interchange Files
El método de AICC para el intercambio de cursos fue creado antes de

la aparición del XML, por lo que el AICC definió un conjunto de siete
ficheros de texto simple (Course Interchange Files, CIF) para que el
Learning Management System pudiera importar/exportar un curso.
De los siete ficheros, cuatro son obligatorios, mientras que los de-
ANOTACIONES
más contienen información como prerrequisitos y requerimientos

especiales.
Veremos a continuación una descripción muy breve de los cuatro fi-

cheros obligatorios:
• El fichero del curso (.crs): contiene información del curso comple-

to, listando parejas de palabras que forman los atributos y sus va-
lores. Entre otros:
41
– El creador del curso
– Un identificador
– El título
– La versión del AICC con la que ha sido creado
• El fichero del descriptor (.des): proporciona información acerca

de cada AU y bloque de forma individual. Esto incluye:
– Un identificador único dentro del curso
– Un título
– Una descripción
• El fichero AU (.au): contiene la información necesaria para lanzar

un Learning Object y realizar su seguimiento.
• El fichero de estructura del curso (.cst): describe la estructura de

bloques y Learning Objects que forman el curso.
La elección de uno u otro estándar depende, en gran medida, de los

Learning Management System en los que deseemos importar los ma-
teriales. En el caso de desarrollar los materiales para su posterior
venta, será interesante consultar el estado del mercado de los Lear-
ning Management Systems, para buscar compatibilidad con el máxi-
mo de sistemas.
4.5. Estándares para monitorización

(Data Tracking)
ANOTACIONES
La monitorización o Data Tracking define cómo los Learning Objects

se comunican con el Learning Management System para transferir
datos de los estudiantes y su progreso, es decir, realiza un segui-
miento de las actividades de los estudiantes.
42
Figura 14. Esquema del sistema

de Data Tracking
Como se ve en el esquema anterior, el sistema de Data Tracking (DT)

debe estar implementado en los Learning Objects y el Learning Ma-
nagement System. Ambas partes deben implementar el mismo siste-
ma para poder comunicarse de forma correcta. Es decir, un Learning
Object que implemente un sistema de Data Tracking tipo A no podrá
ser cargado y ejecutado en un Learning Management System que no
implemente el Data Tracking tipo A.
Éste es, de hecho, un punto crítico y clave en el desarrollo de un

sistema de e-learning. Se puede decir que se trata del punto de
unión entre el cliente web del estudiante y el Learning Manage-
ment System.
Hasta este momento se han desarrollado dos estándares para el

Data Tracking: el API y el HACP:
1. API (Application Programming Interface, interfaz de programación

de aplicación): elemento de comunicación que proporciona una
ANOTACIONES
serie de funciones en un lenguaje de web para ser usados por los

Learning Objects en su comunicación con el Learning Management
System.
Nota
HTTP (Hypertext Transfer
2. HACP (Http-based AICC CMI Protocol, protocolo de AICC CMI,
Protocol, protocolo de trans-
basado en HTTP): utiliza el método básico de comunicación a tra- ferencia de hypertexto): Pro-
vés de web, el protocolo HTTP. Éste es un método seguro y fiable, tocolo usado en Internet
para la transferencia de do-
pero necesita de una considerable programación en el Learning cumentos HTML.
Object.
43
Figura 15. Esquema de los modelos

HACP y API
4.5.2. El estándar API
Es el método más reciente y que ha experimentado un rápido

avance. Está incluido en los dos principales estándares, el SCORM
y el AICC.
Veremos una descripción a alto nivel del proceso de comunicación

entre un Learning Object y el Learning Management System bajo el
estándar API.
El proceso de comunicación entre un Learning Object y el Learning

Nota
Management System consiste en un pequeño conjunto de funciones
JavaScript: Lenguaje de web
desarrollado por Netscape que son llamadas por el Learning Object y ejecutadas por el Learning
para el tratamiento y ges- Management System. Estas llamadas a las funciones se realizan en
ANOTACIONES
tión de información en en-

tornos de navegadores web. un lenguaje de web llamado JavaScript‚.
La figura 16 muestra el ciclo de vida de un Learning Object. Cuando

un estudiante accede al Learning Object a través de su cliente web se
produce la inicialización de dicho Learning Object. En este proceso
se inicializa el contexto del Learning Object, es decir, se habilitan las
funciones de comunicación con el Learning Management System y se
instancian ciertas variables para la comunicación. El proceso contra-
44
rio, cierre de las comunicaciones y destrucción de variables de comu-

nicación, se produce cuando el cliente web accede a otro Learning
Object y finaliza el actual. Ambos procesos son obligatorios, es decir,
todos los Learning Objects deben realizar estas llamadas al inicio y
al final.
Durante el periodo entre la inicialización y la finalización, los Learning

Objects pueden implementar, de forma opcional, llamadas al Learning
Management Object para leer o escribir valores, como por ejemplo los
resultados de un test.
Figura 16. Esquema de pasos del modelo API
4.5.3. El estándar HACP
El estándar HACP es el método para el intercambio de datos desa-

ANOTACIONES
rrollado por el AICC.
En el proceso de comunicación, durante la inicialización el Learning

Management System envía toda la información disponible sobre el
estudiante y el Learning Object, de forma que a partir de ese mo-
mento sólo el estudiante enviará información opcional mientras el
Learning Object esté activo. Obligatoriamente, el Learning Object
enviará información en el momento de finalizar.
45
Figura 17. Esquema de pasos del modelo HACP
4.6. Resumen
En este capítulo se han visto distintos estándares para los principales

componentes de un entorno e-learning.
Es importante tener muy clara la finalidad de cada uno de estos cua-

tro componentes básicos: meta-data, evaluación, estructura del con-
tenido y Data Tracking, así como los principales estándares
relacionados con ellos.
Los estándares para la creación de meta-data van a permitir docu-

mentar cada uno de los Learning Objects, lecciones o cursos. Asimis-
mo, proporcionan un sistema para la localización y reutilización de
los contenidos.
ANOTACIONES
Para la evaluación se ha descrito el principal estándar que hay ac-

tualmente, el QTI. Pese a que todavía se encuentran pocos sistemas
que implementen el QTI, no cabe duda de su importancia en el fu-
turo, permitiendo el desarrollo y la compartición de tests y resultados
entre diferentes Learning Management Systems.
Otro punto clave es la creación de la estructura del contenido (content

structure). En este sentido, hemos descrito la estructura del contenido
46
de los dos principales estándares en la actualidad: el SCORM y el

AICC.
Para finalizar, se han descrito los dos estándares existentes para el

Data Tracking o monitorización del estudiante, es decir, la comuni-
cación entre un Learning Object cargado en el cliente web y el Learning
Management System. Éstos son los estándares API y HACP.
ANOTACIONES
47
5. Proceso de diseño de unos materiales e-learning
5.1. Introducción
En este punto, se verá, a grandes trazos, el planteamiento para

la implementación de un sistema e-learning y el diseño de mate-
riales.
Ambos son puntos críticos y de gran complejidad. A continuación

se darán unas nociones básicas para ayudar a comprender la en-
vergadura de un proyecto de estas características. Se debe tener
en cuenta que son consideraciones básicas y genéricas, por lo
que pueden diferir de casos concretos según las necesidades es-
pecíficas.
No es lo mismo crear un pequeño curso síncrono en el tiempo y en

el espacio, que desarrollar una plataforma y todos los materiales
para una universidad a distancia. A pesar de haber una gran diver-
sidad en estos procesos, es importante hacer algunas consideracio-
nes básicas.
Este capítulo se divide en dos bloques:
• En el primer bloque se verá el planteamiento general. En él se

tendrán en cuenta consideraciones básicas que se deben defi-
nir antes de iniciar la fase de diseño e implementación, ya sea
ANOTACIONES
adquiriendo productos a terceros o desarrollando productos

propios. El conjunto de estas consideraciones ayudará a definir
un buen sistema para cada entidad.
• En el segundo bloque, se verá mediante un ejemplo el proceso

de diseño de unos materiales. En él se expondrán las pautas
básicas que ayudarán al desarrollo de materiales o cursos
propios.
49
5.2. Planteamiento general
En esta primera fase, el objetivo es definir las necesidades básicas de

nuestro sistema, tales como la estructura básica del curso, los recur-
sos y estándares necesarios.
Más concretamente, los pasos básicos a seguir son:
1. Definición de los objetivos
2. Creación del mapa del curso
3. Análisis de requerimientos y necesidades
4. Recursos disponibles
5. Elección de los estándares
5.2.1. Definición de los objetivos
El primer paso en la creación de un curso, sea o no de e-learning, es

definir unos objetivos, y éstos dependen en gran medida de los estu-
diantes que realicen el curso. Es muy importante que el nivel de los
materiales sea el adecuado para el perfil de estudiante que lo reali-
zará.
No se debería diseñar un curso de, por ejemplo, iniciación al inglés

de la misma manera para niños de cuatro años que para adultos. En
un caso se debería utilizar un entorno más amigable y basado en
gráficos (incluso con la inclusión de algún personaje de dibujos que
nos guíe a través del curso a modo de ayuda), mientras que en otro
sería más conveniente el uso de un sistema gráfico más neutro y for-
ANOTACIONES
mal. Del mismo modo, se debe considerar el grado de conocimiento

en informática, a nivel usuario, por parte de los estudiantes. Princi-
palmente, el sistema de ayuda y todo el conjunto en general puede
ser significativamente diferente en los dos casos.
Se deberán fijar los contenidos del material y realizar la división en

los diferentes módulos, y también especificar en qué puntos se desea
incluir tests o sistemas de evaluación.
50
5.2.2. Creación del mapa del curso
El siguiente paso importante será la creación del flowchart o mapa

del curso. Este mapa nos define la estructura del curso de forma clara
y completa. Se debe incluir en él todos los recursos que vamos a uti-
lizar durante el curso, como por ejemplo, las lecciones, sistema de
ayuda, foro de discusiones, calendario y tests.
Veamos un ejemplo de un flowchart para un curso:
Figura 18. Flowchart o mapa del curso
A partir de un sencillo mapa del curso como el anterior, es posible ha-

cerse una idea, aunque sea muy general, de la estructura del curso.
Ahora se puede especificar con más detalle cuáles son los conceptos
desarrollados en cada uno de los puntos del mapa. Esta especifica-
ANOTACIONES
ción puede resultar muy útil para crear un curso equilibrado, viendo
en cada caso cómo se reparten los módulos y la importancia de cada
una de sus partes.
El siguiente paso consiste en añadir la secuenciación y los prerrequi-

sitos entre los módulos y lecciones. Estos prerrequisitos pueden ser,
por ejemplo, del tipo “haber pasado un test con cierta nota”, “haber
leído un cierto documento” o “haber realizado algún tipo de ejercicio
interactivo con cierta puntuación”.
51
Una vez visto el contenido completo y sus dependencias, es el mo-

mento de decidir si se quiere agregar material de refuerzo o de de-
finir algún material como opcional en el flowchart. Dependiendo del
resultado obtenido por un estudiante en cierto momento, se puede
decidir si es conveniente que complete una lección o módulo de re-
fuerzo antes de pasar al siguiente (obligándole a ello o planteándolo
como opcional); o por el contrario, ofrecerle como opcional el mó-
dulo siguiente si se cree que ya ha aprendido los contenidos y no le
aportará nada nuevo.
Hay que considerar que en la actualidad la mayoría de los Learning

Management Systems no soportan cualquier tipo de secuenciación entre
lecciones o módulos. Es decir, la mayoría de los Learning Management
Systems soportan prerrequisitos del tipo “la lección 2 sólo estará acti-
vada cuando se haya superado la lección 1”, pero no todos soportan
prerrequisitos del tipo “es necesario superar la lección 1 y el test 1 con
una nota superior a 8 para poder activar la lección 2”.
Será necesario, por lo tanto, considerar el tipo de secuenciación y

prerrequisitos que soporta el Learning Management System antes de
definir la secuenciación entre recursos.
Una vez establecidos los recursos que se utilizarán y el esquema ge-

Nota
neral, se debería realizar una planificación detallada a nivel tempo-
Diagrama de Gannt: Plani-
fica a nivel temporal, eco- ral y económico. Por ejemplo, un diagrama de Gannt para la
nómico y de recursos el temporalización y utilización de los recursos en el desarrollo del pro-
desarrollo de un proyecto,
yecto puede ser una inestimable ayuda y buena herramienta para la
facilitando la evaluación de
costes y plazos de finaliza- evaluación del estado actual.
ción de las diferentes partes
del proyecto.
5.2.3. Análisis de requerimientos y necesidades

ANOTACIONES
En esta sección se confeccionará una lista con los requerimientos y

necesidades del sistema que se quiere implementar. Esta lista puede
diferir significativamente de un sistema a otro, dependiendo de las
necesidades de cada uno, pero se deben considerar aspectos como
la evaluación y seguimiento de los estudiantes, los prerrequisitos en-
tre lecciones o módulos, la frecuencia de actualización de los mate-
riales, el número de usuarios del sistema y el tipo de sincronismo en
el espacio y el tiempo.
52
Veamos algunos ejemplos de los requerimientos más genéricos e im-

portantes que podemos encontrar en el diseño de un curso:
1. ¿Los cursos serán a distancia o presenciales? Si se van a realizar

los cursos en un aula presencial con profesor no será necesario,
por ejemplo, incluir ayudas sobre el funcionamiento del software.
El propio profesor puede realizar una explicación del mismo, tan-
teando las habilidades demostradas por cada grupo de estudian-
tes y adecuando el nivel de la explicación a los conocimientos que
demuestren los estudiantes en el manejo de un sistema informá-
tico a nivel usuario. El hecho de dar las clases en un aula presen-
cial también facilita la instalación de software que requiera el
cliente. Se evita la necesidad de proporcionar a los estudiantes el
software, las licencias (si son necesarias) y las instrucciones para
la instalación en sus equipos.
2. ¿Cuántos usuarios deberá soportar el sistema? Es importante que

se intente acotar un rango para el número de usuarios que debe-
rá soportar el sistema, ya que este factor puede determinar el uso
de uno u otro Learning Management System. Los costes de hard-
ware y software no van a ser los mismos para un sistema que
debe soportar más de mil usuarios simultáneos y varios cursos,
que uno que debe soportar un aula de veinte usuarios y un curso.
3. ¿Se deberán actualizar regularmente los módulos? Aunque ya se

ha insistido en el interés de reutilizar los materiales y la convenien-
cia de los estándares, a quien actualice regularmente los materia-
les o cursos se le hace mucho más necesario el uso de estándares
en su sistema.
4. ¿Qué tipo de evaluación del estudiante se utilizará en el curso?

Determinar desde un buen principio el tipo de evaluación que se
usará en los cursos puede ahorrar tiempo y dinero. Por ejemplo,
ANOTACIONES
si se desea un curso con evaluaciones tipo tests, será muy reco-

mendable el uso de un Learning Management System que soporte
el estándar QTI (Questions & Test) para el uso de tests de fácil
creación, reutilización y análisis de los resultados.
5. ¿Qué tipo de seguimiento debe hacerse del usuario? Como se ha

visto durante este módulo existen dos estándares para realizar la
monitorización o seguimiento de los estudiantes (Data Tracking).
Éstos son el estándar API y el HACP. SCORM implementa sólo el
53
estándar API, mientras que AICC implementa ambos. Aun así,

existen varios sistemas comerciales que sólo implementan la parte
obligatoria del estándar, o sólo algunas funciones de la parte op-
cional. En caso de desear alguna función de la parte opcional del
estándar, se debe prestar atención al nivel de implementación de
cada plataforma o material. El tipo de seguimiento será crítico a
la hora de evaluar al estudiante durante el curso (por ejemplo, el
tiempo que necesita cada uno en la realización de los ejercicios o
la nota de éstos).
6. ¿Es necesario implementar un sistema de prerrequisitos entre lec-

ciones? La utilización de dicho sistema de secuenciación no está
soportado por todos los Learning Management Systems. Por lo
tanto, si se desea adquirir un sistema con esta característica, la
cantidad de opciones disponibles se reducirá considerablemente.
7. Otros. En cada caso concreto se pueden encontrar muchos otros

requerimientos que también deberán ser considerados. Por ejem-
plo, si se desea desarrollar materiales utilizando un producto con-
creto (por facilidades de licencias, costes u otros motivos), nos
puede limitar el conjunto de Learning Management Systems que
soporta dicho producto.
5.2.4. Recursos disponibles
Nota Una vez hemos visto los tipos básicos de recursos que se pueden uti-
Applet: Pequeño programa lizar en el sistema, es necesario un planteamiento riguroso y detalla-

creado en Java que se des- do de cuáles de ellos se quieren utilizar.
carga automáticamente a
través de Internet y que se
ejecuta en el cliente web del El tipo de recursos que se decida incluir determinará varios aspectos
usuario.
en el desarrollo y el sistema final que se implemente. Por ejemplo, si
se desea incluir recursos basados en Applets Java dispondremos de
ANOTACIONES
Nota dos opciones: si los recursos deseados existen en la red como recur-
Java: Lenguaje de progra- sos públicos, se pueden usar con el permiso de los autores. En caso
mación creado por Sun contrario, será necesario disponer de un perfil de programador para
Microsystems. Este lengua-
je está muy extendido en la
el desarrollo de dichos componentes. También se deberá informar o
actualidad gracias a su ex- proporcionar a los alumnos el sistema run-time de Java para poder
celente portabilidad y uso a
utilizar dichos recursos en sus clientes web. Esto nos puede determi-
través de redes.
http://java.sun.com. nar el tipo de cliente web (browser) que deberán utilizar los clientes,
ya que puede que no todos los clientes web del mercado ofrezcan so-
porte de Java.
54
Otro ejemplo es el formato de vídeo, en el caso de desear incluir ví-

Nota
deos demostrativos o explicativos, ya que no todos los formatos son
Run-time de Java: Conjunto
reproducibles por cualquier plataforma. Por ejemplo, el vídeo
de los componentes míni-
“.wmv” es propio de sistemas Microsoft Windows, mientras que mos del lenguaje que per-
otros, como por ejemplo el “.avi”, necesitan de codecs especiales miten la ejecución de
programas Java. Este entor-
para poder ser reproducidos, pero son reproducibles en cualquier no no permite el desarrollo
plataforma. de programas, sólo la eje-
cución de los mismos. http:/
/java.sun.com/getjava/.
Otro tipo de recursos, como por ejemplo el uso del QTI (Question & Test)
es determinante a la hora de escoger un Learning Management System,
ya que no todos lo implementan. Nota
Codec: Sistema de codifica-
También es importante plantearse la forma de adquirir los materiales. ción/descodificación de ví-
deo o audio. Por ejemplo, el
Existe la posibilidad de comprar algunos de los recursos o materiales e
codec de AVI permite la re-
incorporarlos en el curso. No es necesario que se desarrolle todo el cur- producción de un vídeo o
so, es muy probable que se encuentren materiales disponibles en el audio de tipo AVI.
mercado para cubrir las necesidades. En este caso se deberá prestar

atención a los estándares que se desea aplicar en nuestro sistema y a
los estándares que utiliza el material que se desea adquirir.
En caso de desarrollar el propio material, será necesario disponer de los

perfiles necesarios en los diferentes ámbitos. Será básico disponer de
uno o varios formadores para la creación del contenido, pero también
puede ser necesario disponer de perfiles técnicos, como programadores
o diseñadores gráficos para la programación y creación de recursos vi-
suales.
5.2.5. Elección de los estándares
Una vez evaluados todos los requerimientos y necesidades comenta-

dos anteriormente y otros en particular, hay que realizar la elección
ANOTACIONES
de los estándares que vamos a utilizar.
Ésta no va a ser una elección fácil, y se deberá valorar cuidadosa-

mente las ventajas e inconvenientes de cada posible elección.
Se debe recordar que el hecho de escoger unos u otros estándares

puede limitar la elección de la plataforma y el uso de material reusa-
ble de ciertos proveedores. Será necesario tener muy presente estos
aspectos.
55
5.2.6. Una mirada al futuro
En todo el proceso es preciso no perder de vista un punto muy im-

portante: éste es un campo relativamente nuevo, que está evolu-
cionando continuamente, y por lo tanto, en constante cambio.
Será una buena opción pensar detenidamente en el futuro de

nuestro sistema. En el caso de que se desarrolle una solución a
corto plazo, es decir, que por ejemplo se desarrolle un curso para
impartir una sola vez, el uso de estándares no es relevante y se
podrán reducir significativamente los costes del desarrollo. En
cambio, si se desea desarrollar materiales de utilidad a largo pla-
zo, con visión de futuro, es importante una buena elección e im-
plementación de los estándares.
Será bueno tener presente temas como la variación de contenido,

que puede obligar a modificar los Learning Objects y la estructura
del contenido, y prestar atención a los cambios implementados
por las organizaciones y productos e-learning. Es decir, qué es-
tándares se están aceptando por parte de la mayoría de desarro-
lladores de materiales o de Learning Management Systems.
Observar estos aspectos puede ayudar a elegir un buen camino

para el desarrollo y mantenimiento del sistema a corto, medio o
largo plazo.
También puede resultar muy importante tener en cuenta cuestio-

nes como la escalabilidad en el momento de crear los materiales
y de adquirir el Learning Management System. Se debe pensar en
la posibilidad de poder adquirir nuevos componentes para nuevas
funcionalidades en un futuro, sin quedar limitados en la funciona-
ANOTACIONES
lidad. Asimismo, es importante poder mantener un amplio grupo

de proveedores compatibles con el sistema.
Otro factor importante es la exportabilidad del sistema hacia

otros, que permitiría poder migrar todo el sistema hacia otra pla-
taforma en caso necesario.
56
5.3. Diseño de los materiales
A continuación, se introducirá el diseño de las principales partes

de un curso de e-learning. Se tratarán los puntos básicos en la
creación de materiales e-learning para proporcionar unas direc-
trices básicas, pero sin entrar demasiado en los detalles.
Durante este proceso se ejemplificarán algunos casos basados en

el sistema SCORM, sólo con el objetivo de facilitar la comprensión
y mostrar algunos detalles interesantes.
Seguidamente se enumerarán, de forma general, los principales

puntos a tener en cuenta en el diseño de materiales e-learning:
1. Creación de los Learning Objects: proceso en el que se crean

los Learning Objects que constituirán los materiales del curso.
Hay dos puntos básicos: la información propia de los materia-
les y el Data Tracking o sistema de comunicación con el Learning
Management System (ver punto 4.5).
2. Creación del meta-data: proceso de creación de la informa-

ción sobre cada uno de los Learning Objects, lecciones, módu-
los y curso entero. Esta información asociada a cada elemento
nos facilitará la localización y el intercambio de materiales.
3. Creación de la estructura del curso y de la secuenciación: pro-

ceso de estructuración de los ficheros que contienen los mate-
riales, y de la hoja de instrucciones (Instruction Sheet). Este
proceso agrupa los materiales para formar un curso en un úni-
co fichero para ser importado en un Learning Management
ANOTACIONES
System.
Se usará un curso básico con una sola lección para ejemplificar el

proceso. La lección contendrá una introducción, una explicación
del contenido en formato texto y un pequeño test para validar los
conocimientos adquiridos por el alumno en este curso.
57
El siguiente esquema muestra la estructura del curso:
Figura 19. Estructura del curso de ejemplo
5.3.1. Creación de los ‘Learning Objects’
En el proceso de creación de los Learning Objects pueden intervenir

personas con perfiles muy diversos: los formadores para el desarro-
llo del contenido del material, diseñadores gráficos para la creación
de recursos visuales, programadores para la implementación del sis-
tema de Data Tracking y otros.
En el caso de nuestro ejemplo se van a crear tres Learning Objects.

Uno para la introducción que será en formato texto HTML, otro para
el desarrollo o explicación del curso que será en formato texto HTML
incorporando gráficos, y el tercer punto será un test para comprobar
los conocimientos adquiridos.
Si bien ésta es una posible solución, no es la única. Como se ha visto,

Nota
el concepto de Learning Object es abierto y admite diferentes solu-
HTML, Hypertext Markup
Language. Es el lenguaje ciones o configuraciones.
ANOTACIONES
utilizado para dar formato

gráfico a las páginas web.
Para más información refe- Por lo tanto, para la creación de este curso de ejemplo se necesitarán
rirse a http://www.w3.org/
conocimientos en el campo del diseño web y en el campo de la pro-
MarkUp/
gramación en JavaScript (para la implementación del sistema de
Data Tracking).
A continuación, veremos con más detalle uno de los tres Learning

Objects creados para el curso de ejemplo.
58
Se ha escogido la explicación del curso, que está formada por texto

HTML, imágenes y el código para la comunicación con el Learning
Management System.
La creación del texto HTML con las imágenes insertadas no difiere de

un proceso de creación de, por ejemplo, una página web. El código
y su estructura es el mismo. A continuación, se deberá añadir el sis-
tema para controlar la comunicación entre el Learning Object y el
Learning Management System, lo que hemos llamado Data Tracking.
Figura 20. Estándar API
Teniendo en cuenta que el estándar SCORM utiliza el estándar API

para el Data Tracking, se debe usar el lenguaje JavaScript para co-
municarnos con la API del Learning Management System. Estas lla-
madas se encuentran dentro del fichero HTML, repartidas en
cualquier punto del código según la función que proporcionan.
De un recurso de texto, que el estudiante deberá leer, se pueden ob-

tener diferentes parámetros. Por ejemplo, en este caso vamos a su-
poner que nos interesan tres valores clásicos: el estado del recurso
ANOTACIONES
(completado o no), el tiempo destinado a él para cada uno de los

alumnos matriculados y el nombre del alumno que accede a él.
Veamos los pasos a seguir para poder realizar dichas tareas:
1. En el momento de acceder al recurso HTML se debe comprobar

el estado del recurso, iniciar un contador de tiempo y acceder al
nombre del usuario.
59
2. En el momento de abandonar el recurso se debe guardar el esta-

do y el tiempo transcurrido.
En resumen, la estructura del recurso HTML quedaría como se des-

cribe a continuación:
<html>
<body onload=“leer estado, iniciar
tiempo” onunload=“guardar esta-
do, calcular y guardar tiempo
transcurrido”>
<script>
Función para acceder al nombre
del usuario y personalizar la bien-
venida
</script>
…
Codigo HTML con imágenes y de-
más recursos
…
</body>
</html>
El tag <html> define el inicio de un fichero HTML. Todo dentro de

un fichero debe estar comprendido entre el inicio y el final de este tag
(<html>…</html>).
El tag <body> define el inicio del contenido HTML, e incluye los atri-
butos ‘onLoad’ y ‘onUnLoad’ que ejecutan código al cargar y descar-
gar, respectivamente, el contenido HTML.
El tag <script> indica al cliente web que debe realizar llamadas

ANOTACIONES
Nota
al lenguaje JavaScript. El código comprendido entre el inicio y el
Para una descripción más
detallada del estándar API,
final realizará varias acciones, pero no se mostrará en el cliente
podéis leer el punto 4.2.2. web.
En el momento en que el estudiante carga el Learning Object en su

cliente web, se ejecuta la función ‘onLoad’. De este modo se obtiene el
estado del Learning Object y se inicializa el contador de tiempo. Luego
aparece la función que se comunicará con el Learning Management
60
System para obtener el nombre del estudiante y mostrarlo en la ven-

tana del cliente web.
A continuación, mostrará el texto e imágenes del material, y cuan-

do se descargue la página, en el evento ‘onUnload’, se ejecutará
otra función y guardará el estado del Learning Object y el tiempo
empleado.
En estos momentos, la estructura del curso es la siguiente:

del curso (1.ª parte)
Un directorio principal (CursoEjemplo) contiene el curso en su interior

(Course01). éste contiene la implementación del estándar API y una lec-
ción (Lesson01), que contiene tres recursos HTML y una imagen. En este
caso los tres recursos HTML corresponden a los tres Learning Objects.
5.3.2. Creación del meta-data

ANOTACIONES
Después de la creación de los Learning Object se está listo para crear

el meta-data. Este proceso, aunque pueda parecer lento, tedioso y
una pérdida de tiempo, acabará repercutiendo positivamente en la
organización al facilitar la reutilización y localización de los Learning
Objects que se van creando.
Se deberá crear el meta-data para cada uno de los Learning Objects,

lección y curso. De este modo el meta-data también forma una es-
61
tructura jerárquica, describiendo desde el curso entero hasta cada

uno de los Learning Objects de forma independiente.
Como vimos en el capítulo anterior, el estándar para meta-data en

SCORM es el IMS Learning Object Meta-Data Specification, llamado
comúnmente LOM.
Veamos la estructura de un fichero de meta-data según la especifi-

cación LOM:
<lom>
<general>
información de carácter general: título, descripción, palabras clave,…
</general>
<lifecycle>
información sobre la versión
</lifecycle>
<metametadata>
información del esquema de datos usado
</metametadata>
<technical>
información sobre el recurso: tamaño, tipo de información (texto, gráfico,…)
</technical>
<educational>
algunos datos sobre su aprendizaje, como por ejemplo el tiempo pensado para completar di-
cho recurso.
</educational>
<rights>
información de los derechos del autor,…
</rights>
<classification>
descripción y palabras clave para clasificar el recurso
</classification>
</lom>
ANOTACIONES
Los ficheros de meta-data son ligeramente diferentes según se refie-

ran a un Learning Object, una lección o un curso. Aunque básica-
mente contienen el mismo tipo de información y utilizan la misma
estructura.
Se encuentra información que describe, por ejemplo, el contenido,

los estándares que se siguen o los derechos del autor. Siempre utili-
zando la estructura de un fichero XML.
62
Después de añadir el meta-data para cada Learning Object, lección

y curso, nos queda la estructura del curso siguiente:

Podemos ver que se trata de la misma estructura de antes, pero a la

que se ha añadido un fichero de meta-data a cada bloque (Learning
Object, lección y curso).
5.3.3. Creación de la estructura del curso

y de la secuenciación
En este punto se dispone ya de los Learning Objects y el meta-data. Se

puede decir que el núcleo del curso está listo, pero aún queda una parte
muy importante para que el curso pueda ser operativo. Hay que agru-
ANOTACIONES
par el curso en la estructura de contenido (Content Structure) para poder

importarlo en un Learning Management System.
Como se ha visto en el capítulo anterior, se debe crear la hoja de ins-

trucciones (instruction sheet) para definir la estructura y las relaciones
entre los Learning Objects. En el modelo del SCORM, la hoja de ins-
trucciones recibe el nombre de imsmanifest.xml, y se debe situar en
el directorio raíz del curso.
63
Puesto que su estructura ya ha sido vista en el punto 4.4.1, pasare-

mos a ver un ejemplo de la hoja de instrucciones para nuestro ejem-
plo. El archivo imsmanifest.xml empieza con la definición del curso,
la lección del curso y los Learning Objects de la lección. Después se
definen cada uno de los recursos de forma individual y se establecen
las dependencias entre ellos.
El esquema es el siguiente:
1. definición del curso

a. definición de la lección
i. definición de los Learning Objects que forman la lección
2. definición de los recursos y las dependencias entre ellos
Vamos a ver con más detalle el Learning Object que se ha desarro-

llado anteriormente a modo de ejemplo del curso.
Se define de la siguiente manera:
<item identifier=“S001_002” identifierref=“R_S001_002” isvisible=“true”>

<title>Explicación</title>
<adlcp:prerequisites type=“aicc_script”><![CDATA[S001_001]]></adlcp:prerequisites>
</item>
Vemos que dispone de dos identificadores, uno para hacer referen-

cia al Learning Object (S001_002) y otro para referenciar sus recur-
sos (R_S001_002). También se detalla el título del Learning Object
(que aparecerá en el menú) y los prerrequisitos para mostrarlo.
Si nos fijamos ahora en sus recursos, dentro del tag <resources> en-
contramos lo siguiente:
ANOTACIONES
<resource identifier=“R_S001_002” type=“webcontent” adlcp:scormtype=“sco” href=“Course01/Lesson01/sco02.htm”>

<metadata>
<schema>ADL SCORM</schema>
<schemaversion>1.2</schemaversion>
<adlcp:location>Course01/Lesson01/sco02.xml</adlcp:location>
</metadata>
<file href=“Course01/Lesson01/sco02.htm”/>
<dependency identifierref=“R_Files_001”/>
<dependency identifierref=“R_Image_001”/>
</resource>
64
Vemos que aquí se declara la posición del fichero HTML en la estruc-

tura y sus dependencias con otros recursos: la imagen que lleva in- Nota
crustada y los ficheros con las funciones para las llamadas a la API Para ver el ejemplo comple-
(que son comunes para la mayoría de Learning Objects). to, en el que se puede iden-
tificar las diferentes partes
que acabamos de ver, de-
Y al final de la estructura localizamos los recursos: béis consultar el apéndice D.
<resource identifier=“R_Files_001” adlcp:scormtype=“asset” type=“webcontent” xml:base=“Course01”>

<file href=“SCOFunctions.js”/>
<file href=“APIWrapper.js”/>
</resource>
<resource identifier=“R_Image_001” type=“webcontent” adlcp:scormtype=“asset” xml:base=“Course01/Lesson01/”>
<metadata/>
<file href=“pics/0011.jpg”/>
</resource>
La estructura completa, incluyendo la hoja de instrucciones, es la si-

guiente:

ANOTACIONES
Nota
Sólo se ha añadido la hoja de instrucciones en la raíz de la estructura. ZIP: Formato de compresión

que permite agrupar varios
ficheros en uno sólo y redu-
Para poder importar el curso, basta con agrupar la estructura com- cir el tamaño del fichero
pleta en un único fichero siguiendo unos formatos concretos (por creado comprimiendo los
datos.
ejemplo, el formato ZIP).
65
5.4. Resumen
En este módulo hemos visto los principios básicos en el diseño de

unos materiales e-learning.
Se inicia el proceso definiendo los objetivos que deben alcanzar los

estudiantes de un curso concreto y las necesidades para realizarlo. A
partir de aquí, se verá el tipo de curso que se debe crear y el tipo de
recursos a utilizar.
Llegado el momento en que se tenga la estructura del curso y los re-

cursos que hay que crear, será el momento de escoger alguno de los
estándares existentes (SCORM o AICC), sobre el cual crear los mate-
riales. En esta decisión será crítica la elección del Learning Management
System.
Cuando ya se disponga de la estructura del curso y del estándar que

se desea implementar, será el momento de consultar la versión es-
pecífica del estándar y sus características. A continuación, se deberá
empezar la creación de los materiales siguiendo las pautas que nos
marcan dichos estándares. Se ha visto un ejemplo de implementa-
ción de un pequeño curso, siguiendo el estándar SCORM.
Una vez escogido el estándar que vamos a implementar, las princi-

pales tareas serán la creación de Learning Objects y meta-data, y la
estructuración y secuenciación del curso.
ANOTACIONES
66
Resumen
1. La adopción de los estándares en la implementación de un siste-

ma proporcionará grandes ventajas: independencia del provee-
dor, reutilización y portabilidad de los materiales, escalabilidad
del sistema y otros.
2. Existen varias organizaciones dedicadas al desarrollo de estánda-

res para entornos e-learning. Algunas de las más importantes son
el ADL Initiative, el Aviation Industry CBT Committee, el IMS Glo-
bal Consortium y otras.
3. Estas organizaciones colaboran entre sí para el desarrollo de dos

principales estándares completos de implementación: el SCORM
y el AICC.
4. Los principales componentes dentro de un entorno e-learning son

tres:
a. El Learning Management System.

b. Los Learning Objects.
c. Las estructuras del contenido (Content Structures).
5. Para el desarrollo de materiales e-learning encontramos cuatro

componentes básicos:
a. Los Learning Objects.

b. El Meta-Data.
c. Las estructuras del contenido (Content Structures).
d. Los sistemas de evaluación y tests.
ANOTACIONES
67
Mapa conceptual
ANOTACIONES
69
Glosario
AICC
Véase Aviation Industry CBT Committee
AICC Content Hierarchy

m Modelo que define la estructura que debe seguir un curso en el modelo
AICC para su correcta empaquetación e importación en un Learning Ma-
nagement System.
API
Véase Application Program Interface
Application Program Interface

m Uno de los dos principales estándares para la monitorización o Data
Tracking (Comunicación entre un Learning Object y el Learning Mana-
gement System). Está implementado en los dos principales modelos:
SCORM y AICC.
sigla: API
Asset
m Recurso simple usado dentro de un Sharable Content Object en el
modelo SCORM. Por ejemplo, una imagen, animación o esquema que
forma parte de un texto o explicación.
Assignable Unit
Es el concepto equivalente a los Learning Objects en el modelo AICC.
Se presentan como una unidad de contenido independiente, aunque su
ANOTACIONES
granulidad es muy variable.
AU
Véase Assignable Unit
Aviation Industry CBT Committee

Uno de los principales modelos completos para implementar entornos
e-learning. Está desarrollado y mantenido por AICC.
71
cliente web
m Aplicación utilizada para acceder y visualizar el contenido de pági-
nas HTML, generalmente a través de Internet. Algunos de los más co-
nocidos son: Microsoft Internet Explorer, Netscape Navigator o Mozilla.
en browser
codec
m Sistema de codificación/descodificación de vídeo o audio. Por ejem-
plo, el codec de AVI permite reproducir un vídeo o audio de tipo AVI.
CA
Véase Content Aggregation
Content Aggregation
m Conjunto de Learning Objects que tienen independencia del contexto
y que pueden ser exportados o importados de forma individual en un
Learning Management System del modelo SCORM.
sigla: CA
Content Structure
Véase Estructura del contenido.
Courseware
m Materiales utilizados en un entorno e-learning. Su tamaño es muy va-
riable, puede comprender desde un Learning Object autocontenido
hasta un curso completo.
estructura del contenido

f Modelo de estructura que define la agrupación de Learning Objects
en lecciones y módulos, y junto con unos ficheros de estructura permi-
ANOTACIONES
ten la exportación/importación de materiales entre diferentes Learning

Management Systems.
en Content Structure
Gannt, diagrama de
m Modelo de diagrama utilizado para el cálculo temporal, económico
y de recursos en el desarrollo de un proyecto.
72
DTD
Véase Document Type Definition
Document Type Definition

m Documento que define la estructura de un documento XML.
sigla: DTD
HACP
Véase http-Based AICC CMI Protocol
http-Based AICC CMI Protocol

m Uno de los dos principales estándares para monitorización o Data
Tracking (Comunicación entre un Learning Object y el Learning Mana-
gement System). Sólo está implementado en el modelo AICC.
sigla: HACP
HTML
Véase Hyper Text Markup Language
Hyper Text Markup Language

m Lenguaje utilizado en las páginas web para mostrar el contenido.
Utiliza los tags o etiquetas para informar al cliente web cómo debe
mostrar la información.
sigla: HTML
HTTP
Véase Hyper Text Transfer Protocol
ANOTACIONES
Hyper Text Transfer Protocol

m Protocolo basado en TCP/IP para la comunicación entre un cliente y
un servidor. Se creó para la transferencia de ficheros HTML a través de
Internet.
sigla: HTTP
73
Instructional Block
m Parte de la estructura del contenido (Content Structure) del modelo
AICC. Permite la creación de estructuras jerárquicas. Por ejemplo, per-
mite agrupar Learning Objects formando lecciones o módulos.
Java
m Lenguaje desarrollado por Sun Microsystems con un claro enfoque a
las comunicaciones a través de redes y con independencia de la plata-
forma utilizada. Es un lenguaje muy utilizado en la creación de Learning
Management Systems. Para más información consultar:
http://java.sun.com.
JavaScript
m Lenguaje desarrollado por Netscape Corporation que se ejecuta
bajo el entorno de un cliente web. Su función básica en el tratamiento
de información en el cliente web. Por ejemplo, una de sus funciones
más típicas es la verificación de los datos escritos por el usuario en un
formulario web antes de enviarlo al servidor. Más información accesi-
ble a partir de: http://devedge.netscape.com.
LCMS
Véase Learning Content Management System
Learning Content Management System

m Sistema que permite a varios autores editar simultáneamente conte-
nido contra un repositorio de Learning Objects. Se utiliza para desarro-
llar y gestionar el contenido formativo.
sigla: LCMS
LMS
Véase Learning Management System
ANOTACIONES
Learning Management System

m Sistema, generalmente basado en servidor web, que se encarga de las
funciones administrativas y de gestión de contenidos en un curso on-line.
Es el sistema que se encarga de proporcionar los contenidos a los estu-
diantes en un entorno e-learning, así cómo de monitorizar su progreso
dentro del curso.
sigla: LMS
74
LO
Véase Learning Object
Learning Object
m Unidad mínima de contenido con independencia del contexto dentro
de un sistema e-learning. Por un lado, incluye la información que se
mostrará al estudiante (por ejemplo, texto, imágenes, vídeos o anima-
ciones) y por el otro incluye la lógica necesaria para comunicar con el
Learning Management System (esta lógica es lo que llamamos monito-
rización del estudiante o sistema de Data Tracking).
sigla: LO
MD
Véase meta-data
meta-data
m Información sobre el tipo de contenido, autor, estándar utilizado,
versión y otros asociados a un Learning Object, módulo, lección o cur-
so. Su finalidad es la de facilitar la documentación, localización y reuti-
lización de los materiales e-learning.
sigla:MD
MySQL
m Sistema gestor de base de datos.
OKI
Véase Open Knowledge Initiative
Open Knowledge Initiative

ANOTACIONES
m Proyecto de colaboración entre diferentes universidades y organizacio-

nes de estandarización y especificación para dar soporte a la tecnología
de aprendizaje en el ámbito universitario. El resultado es una arquitectura
abierta y extensible que especifica cómo los componentes de un software
educacional se comunican entre ellos y con otros sistemas.
sigla: OKI
75
PHP
m Lenguaje de código abierto utilizado en los servidores web para pro-
cesar la información antes de ser enviada al cliente. Por ejemplo, con-
sultar una base de datos para poder enviar los resultados al cliente es
un caso típico de uso del lenguaje PHP.
plugin
m Programa que funciona incrustado en el cliente web para tratar cierto
tipo de información específica. Por ejemplo, para poder reproducir co-
rrectamente animaciones Flash es necesario que el cliente tenga insta-
lado el plugin de Flash en su cliente web.
PostgreSQL
m Sistema gestor de base de datos.
Run-Time, entorno
m Lanzamiento, comunicación y seguimiento de contenido en un entor-
no basado en servidor web. Esta comunicación se realiza entre el Lear-
ning Management System y el contenido e-learning (básicamente los
Learning Objects) a través de un cliente web u otro sistema similar.
SCO
Véase Sharable Content Object.
Sharable Content Object

m Es el nombre que reciben los Learning Objects en el sistema SCORM.
Es el mismo concepto de Learning Object en modelo concreto de
SCORM.
sigla: SCO
ANOTACIONES
SCORM
Véase Sharable Content Object Reference Model
Sharable Content Object Reference Model

m Estándar para un modelo completo de implementación que desarro-
lla el grupo ADL Initiative. Este estándar agrupa estándares de otros
grupos para poder ofrecer un modelo completo.
sigla: SCORM
76
SCORM Content Hierarchy

m Modelo que define la estructura que debe seguir un curso en el mo-
delo SCORM para su correcta empaquetación e importación en un
Learning Management System.
secuenciación
f Define el orden en que se presentarán los contenidos, y las dependen-
cias y prerrequisitos que puedan existir entre ellos.
tag (etiqueta)
f Componente base que define el inicio (<p…>) y el final (</p>) de
un elemento en lenguajes cómo HTML o XML.
Extensible Markup Language

m Lenguaje de marcas utilizado para estructurar e intercambiar infor-
mación entre diferentes plataformas.
sigla: XML
XML
Véase Extensible Markup Language.
XML Schema
m Documento que define la estructura de un documento XML.
XSL
m Lenguaje de marcas utilizado para transformar la información con-
tenida en un fichero XML. Una de sus funciones básicas es dar formato
a dichos datos.
ANOTACIONES
Web Services
m pl Sistema para la comunicación estándar entre diferentes progra-
mas a través de redes TCP/IP, como por ejemplo Internet.
77
Bibliografia
Fallon, C. y Brown, S. (2003). e-Learning Standards. Florida: St. Lucie Press.
Uno de los mejores libros sobre e-learning hasta la fecha. Es muy completo
y documentado. No existe, que sepamos, una traducción al español. En la
primera parte del libro se definen los diferentes componentes del e-learning,
y los estándares asociados a cada uno de ellos. La segunda parte corres-
ponde más a una guía de creación de materiales. Todo el libro en general,
pero sobretodo la segunda parte, resulta bastante técnico. Es necesario un
cierto dominio en la programación web (JavaScript y HTML) y en la progra-
mación en XML para poder aprovechar los contenidos de todo el libro. Muy
recomendable.
W. Allen, M. (2003). Michael Allen’s Guide to E-Learning. John Wiley &

Sons.
Horton, W. (2000). Designing Web-Based Training: How to Teach Anyone

Anything Anywhere Anytime. John Wiley & Sons.
Horton, W y Horton, K. (2003). E-learning Tools and Technologies: A con-

sumer’s guide for trainers, teachers, educators, and instructional designers.
John Wiley & Sons.
M. Alessi, Stephen, R., y Trollip, S. (2001). Multimedia for Learning: Me-

thods and Development, 3d Edition. Needham Heights: Allyn & Bacon.
The Masie Center. (2002). Making Ssnse of Learning Specifications & Stan-
dards: A decisions maker’s guide to their adoption. Saratoga Springs.
ANOTACIONES
El grupo ‘The Masie Center’ distribuye de forma gratuïta este informe reali-
zado por sus expertos en e-learning. Este informe puede constituir un punto
de partida para todos aquellos que se introducen en el mundo del e-lear-
ning. No nos proporcionará una visión detallada de ningún concepto, pero
sí que nos servirá para definir y comprender los conceptos básicos. En él se
habla de las organizaciones y la utilidad de los estándares, de la meta-data
y de los Learning Objects básicamente.
Ostyn, C. (2003). Cooking up a SCORM: A SCORM 1.2 Content Cookbook

for Developers. Bellevue.
79
IBM Mindspan Solutions (2001). The Lotus LearningSpace Family of Pro-

ducts: A Technology Overview. USA.
Longmire, W. y Tuso, G. Learning Without Limits vol. 3: Emerging Strategies

for Effective E-Learning Solutions. San Fancisco: Informania, INC.
Advanced Distributed Learning. (2003). Advanced Distributed Learning. [en

linea] Accesible en: http://www.adlnet.org (Consulta: 11-2003).
AICC. (2003). AICC - Aviation Industry CBT Committee. [en línea] Accesible
en: http://www.aicc.org (Consulta: 11-2003).
WCET. (2003). EduTools - Providing decision-making tools for the E-D-U com-
munity. [en linea] Accesible en: http://www.edutools.info/index.jsp (Consul-
ta: 10-2003).
Éste es uno de los recursos web más interesantes sobre e-learning hasta la
fecha. Una de las partes más interesantes de web trata de los sistemas de
gestión de entornos e-learning (Learning Management Systems, LMS). En-
contramos una gran cantidad de sistemas de gestión, pudiendo obtener in-
formación sobre las características de cada uno de ellos, de forma
individual. Pero además es posible realizar una comparación entre diferen-
tes productos sobre la base de ciertas características que seleccione el usua-
rio. Es un sitio web muy recomendable. Está en inglés.
IEEE Learning Technology Standards Committee. (2003). IEEE LTSC. [en lí-
nea] Accesible en: http://ltsc.ieee.org (Consulta: 10-2003).
IMS Global Learning Consortium, Inc. (2003). IMS Global Learning Consor-
tium, Inc. [en línea] Accesible en: http://www.imsglobal.org (Consulta: 10-
2003).
ISO. (2003). ISO - International Organization for Standardization. [en línea]

Accesible en: http://www.iso.org (Consulta: 10-2003).
ANOTACIONES
Calvet, Vila & Arriaga Consulting. (2003). eLearning WORKSHOPS Co-

munidad de eLearning. [en linea] Accesible en:
http://www.elearningworkshops.com/index.php (Consulta: 11-2003).
Este sitio web es uno de los mejores portales de habla española sobre e-learning.
En él podemos encontrar gran cantidad de recursos disponibles y muy inte-
resantes. Como en la mayoría de los portales, ofrece la posibilidad de darse
de alta de forma gratuita. Así disfrutaremos de los documentos disponibles
que hablan sobre varios temas del e-learning. Encontraremos desde artícu-
los sobre los estándares y organizaciones, hasta artículos para la creación
80
de materiales SCORM. Otra parte muy interesante de este portal es, sin du-
da, sus foros. Disponen de varios foros públicos para dar cobertura a las di-
ferentes partes dentro del e-learning. Se discuten temas muy interesantes y
participan varios profesionales del sector. Es un sitio web muy interesante.
ANOTACIONES
81
Apéndice A: el lenguaje XML
Introducción y principales características
El XML (EXtensible Markup Language) es un lenguaje derivado del Nota

conocido SGML y actualmente está mantenido por el W3C. SGML, Standard Generali-
zed Markup Language: Len-
guaje desarrollado para la
aa estructuración e intercambio
de documentos. Su defini-
El XML es un lenguaje desarrollado con el fin de permitir ción oficial se encuentra en
estructurar, almacenar y enviar la información de forma los estándares internaciona-
que no haya dependencias con ningún tipo de plata- les de las ISO (ISO
8879:1986).
forma o de sistema, creando de este modo un estándar
para el intercambio de información.
Nota
W3C, World Wide Web
Veamos sus principales características:
Consortium: Organización
dedicada al desarrollo de
especificaciones, guias, soft-
• Está diseñado para describir datos.
ware y herramientas para In-
ternet. http://www.w3.org.
• Es un lenguaje de marcas (como el HTML).
• Los tags o etiquetas no están predefinidos.
• Se utiliza el DTD (Document Type Definition) o el XML Schema Nota

para representar la estructura de los datos, de manera que los Tag (etiqueta): Codificación
dos juntos (XML y DTD o XML Schema) sean autodescriptivos. utilizada para representar el
inicio (<…>) y fin (</…>)
ANOTACIONES
de un elemento. Por ejem-

plo, para indicar que un tex-
A veces se confunde el XML con un sustituto del HTML, pero aunque
to aparece en cursiva
puedan resultar parecidos en cuanto a su escritura, sus objetivos son utilizamos el tag o etiqueta
muy diferentes. Son dos lenguajes que pueden complementarse el <i> de la siguiente forma:
<i>texto en cursiva</i>.
uno con el otro, pero de ningún modo sustituir uno al otro.
Como el HTML, el XML es un lenguaje de marcas, pero mientras que

el HTML nos permite dar un formato gráfico a los datos (a través de
tablas, formularios y otros elementos) el XML se centra en estructurar
83
los datos, sin preocuparse de cómo se van a mostrar. En HTML, la

información y la presentación de ésta se encuentran juntos, mientras
que el XML sólo almacena los datos, y no incluye información sobre
el modo de visualización.
Se puede definir como una de las principales, si no la principal, fun-

ción del XML como un estándar para el intercambio de información
entre cualquier tipo de sistema.
Los tags utilizados en XML no están predefinidos. Es el propio usuario

quien define, con la ayuda del DTD o XML Schema, la estructura de
los datos y los tags utilizados.
Para finalizar, comentar que el XML utiliza un tipo de diccionarios de

definición, que nos permiten crear una estructura, en la forma y la
rigidez que deseamos, para hacer que los datos contenidos en el fi-
chero XML cumplan estas características. A continuación, se verán
ejemplos de estos diccionarios de definiciones.
El lenguaje XML está relacionado con otros dos lenguajes:
• Un lenguaje para la definición de su estructura y tipos de datos,

generalmente se utiliza el DTD (Document Type Definition) o el
XML Schema.
• Un lenguaje para convertir los datos almacenados en el XML y

darles un formato para su presentación. En este punto, el XSL
es uno de los más importantes y nos permitirá convertir un do-
cumento XML a cualquier formato deseado, como por ejemplo
HTML.
ANOTACIONES
DTD básico
Como se ha comentado en el apartado anterior, el DTD (Document

Type Definition) es una definición formal de la estructura de un do-
cumento XML. En éste se indica el formato concreto que debe pre-
sentar un fichero XML para poder validar su estructura.
84
En la creación de un DTD intervienen, principalmente, dos tipos de

datos.
Los elementos: servirán para definir los tags o etiquetas válidos en

el documento XML. Podemos especificar el tipo de cada elemento de
dos maneras básicas:
• Como un tipo primitivo del lenguaje. Los dos principales son:

EMPTY, que indica que el elemento no puede contener datos, y
#PCDATA que indica que el elemento contiene datos de tipo ca-
dena de texto.
• Definiéndolo sobre la base de otros elementos que contiene en su

interior. En este caso se dispone de un sistema para determinar el
número de ocurrencias de cada subelemento dentro del elemen-
to. Estos símbolos son los siguientes:
Tabla 1. Tabla de definición del número de ocurrencias de un elemento
? 0 o 1 ocurrencia
* Cualquier número de ocurrencias (0...n)
+ Una o más ocurrencias (1...n)
Se utiliza en una lista de subelementos para indicar que habrá
| una y sólo una ocurrencia de los elementos enumerados. Por
ejemplo (en1|en2|...)
Los atributos: nos sirven para especificar información asociada a un

elemento en particular. Los atributos se encuentran dentro de los
propios elementos, y se debe especificar dos parámetros de cada
atributo: el tipo de datos que contendrá y su valor por defecto.
Para determinar el tipo de los atributos, usamos, entre otros:

ANOTACIONES
Tabla 2. Tabla de tipos de atributos
CDATA Cadena de caracteres
(en1|en2|...) Uno de los valores enumerados en la lista
ID Valor único
IDREF Valor ID de otro elemento
IDREFS Lista de valores ID de otros elementos
85
Y para determinar el valor por defecto de los atributos usamos:
Tabla 3. Tabla de valores por defecto de los atributos
Valor Especificamos el valor por defecto del atributo
#REQUIRED El valor debe estar incluido en el atributo
#IMPLIED El valor no debe estar incluido en el atributo
#FIXED val El valor del atributo esta fijado en val
Vamos a ver un ejemplo en el que deseamos crear una lista donde

podamos almacenar correos electrónicos.
Un ejemplo de posible DTD para describir una estructura sería:
<?xml version=“1.0” encoding=“ISO-8859-1”?>

<!ELEMENT emailList (email)*>
<!ELEMENT email (to, from, head, body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT head (#PCDATA)>
<!ELEMENT body (#PCDATA)>
La primera línea de código (<?xml … ?>) se repite en cualquiera de

los documentos XML, DTD y XSL, y sirve para especificar la versión y
la codificación del documento.
A partir de la segunda línea, se especifica que la raíz del docu-

mento será el tag emailList, formado por un conjunto de 0 a n ele-
ANOTACIONES
mentos tipo email, que a su vez contendrán en su interior una

aparición de los tags to, from, head y body. Éstos serán de tipo
cadena de texto.
Una forma de mejorar el sistema de almacenar correos electróni-

cos sería incluir un id para el correo, así como su fecha de llega-
da. También se puede incluir destinatarios de las copias (CC) y
hacer que el sujeto no sea obligatorio. Del mismo modo, pode-
86
mos incluir enlaces para los ficheros adjuntos. El DTD quedaría de

esta manera:
<?xml version=“1.0” encoding=“ISO-8859-1”?>

<!ELEMENT emailList (email)*>
<!ELEMENT email (to,cc*, from, head?, body, links)>
<!ATTLIST email
id CDATA #REQUIRED
date CDATA #REQUIRED
>
<!ELEMENT to (#PCDATA)>
<!ELEMENT cc (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT head (#PCDATA)>
<!ELEMENT body (#PCDATA)>
<!ELEMENT links (link)*>
<!ELEMENT link (name?, url)>
<!ATTLIST link
id CDATA #IMPLIED
>
<!ELEMENT name (#PCDATA)>
<!ELEMENT url (#PCDATA)>
Los esquemas tipo XML Schema son menos utilizados que los DTD, y
además son algo más complicados de crear. Existen programas para
convertir de un tipo al otro. Veamos el equivalente del primer DTD
en el formato XML Schema:
<?xml version=“1.0” encoding=“UTF-8”?>

<xs:schema xmlns:xs=“http://www.w3.org/2001/XMLSchema” elementFormDefault=“qualified”>
<xs:element name=“body” type=“xs:string”/>
<xs:element name=“email”>
<xs:complexType>
<xs:sequence>
<xs:element ref=“to”/>
ANOTACIONES
<xs:element ref=“from”/>
<xs:element ref=“head”/>
<xs:element ref=“body”/>
</xs:sequence>
</xs:schema>
</xs:complexType>
</xs:element>
<xs:element name=“emailList”>
87
<xs:complexType>
<xs:sequence minOccurs=“0” maxOccurs=“unbounded”>
<xs:element ref=“email”/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name=“from” type=“xs:string”/>
<xs:element name=“head” type=“xs:string”/>
<xs:element name=“to” type=“xs:string”/>
XML básico
Una vez comprendidos el funcionamiento y la utilidad de los DTD,

resulta mucho más sencilla la creación de ficheros XML.
Una vez se tiene creada la estructura que deberá seguir el fichero

XML, sólo se trata de respetar la estructura que nos marca el DTD e
ir introduciendo los datos de la manera adecuada.
A continuación, veremos un ejemplo de cómo podría ser un fichero

XML con la estructura creada en el primer ejemplo de DTD:

<!DOCTYPE emailList SYSTEM “./01.dtd”>
<emailList>
<email>
<to>info@business.net</to>
ANOTACIONES
<from>me@myhouse.es</from>
<head>Información sobre el producto</head>
<body>Desearía recibir información acerca de ...</body>
</email>
</emailList>
Vemos que existen, en esta porción de código, cinco tags diferentes

(email, to, from, head y body).
88
Ahora vamos a construir un XML que siga el formato marcado por la

segunda versión del DTD anterior:

<!DOCTYPE email SYSTEM “./02.dtd”>
<email id=“000001” date=“22/09/2003 15:54:34”>
<to>info@business.net</to>
<cc>other_1@busniess.net</cc>
<cc>other_2@busniess.net</cc>
<from>me@myhouse.es</from>
<body>Desearía recibir información acerca de ...</body>
<links>
<link>
<name>Información 1.doc</name>
<url>http://www.info.com/doc1/</url>
</link>
</links>
</email>
Vemos que es posible incluir cualquier número de ‘cc’ que deseemos

(desde 0 hasta n) y que el ‘head’ del mensaje ya no es obligatorio.
Esta estructura permite una mayor flexibilidad que la que hemos visto
anteriormente.
Procesos de transformación: XSL
Se dispone de un sistema para formatear los datos contenidos en XML

a cualquier tipo de salida. El sistema más popular y usado es el XSL.
ANOTACIONES
Con este lenguaje es posible formatear, ordenar, filtrar y operar con

los datos utilizando una serie de funciones que nos permiten actuar
sobre cada elemento y cada atributo del documento.
El lenguaje XSL está formado, a su vez, por tres lenguajes:
• XPath: lenguaje para definir y acceder a diferentes partes del do-

cumento XML.
89
• XSLT: lenguaje dedicado a la transformación de documentos XML.
• XLS Formatting Objects: dedicado a dar formato a los objetos XML

del documento.
De estos tres, los principales son los dos primeros, que permitirán ac-
ceder a la información y transformarla para darle un formato.
La idea principal en la creación a partir de XSL es sencilla. Se trata

de imaginarnos un diagrama, en donde cada punto es un tag del có-
digo XML, y unir entre los puntos que tienen relación de padre/hijo.
El primer ejemplo XML presentado anteriormente presentaría esta es-

tructura:
Figura 24. Estructura en forma

de árbol de un fichero XML
Más adelante, durante una transformación XSLT, se va recorrien-

do cada uno de los puntos y ejecutando ciertas acciones con sus
datos.
Veamos un ejemplo que pueda facilitar la comprensión del XSL,

ANOTACIONES
que, aunque su programación es más compleja que la del XML o

DTD, puede resultar interesante hacerse una idea de su funciona-
miento aunque no sea competencia de este curso dicha progra-
mación.
<xsl:stylesheet version=“1.0” xmlns:xsl=“http://www.w3.org/1999/XSL/Transform”>

xsl:output method=“xml” omit-xml-declaration=“yes”
<indent=“yes” encoding=“ISO-8859-1”/>
90

<xsl:template match=“/”>
<html>
<body>
<center>
<table border=“1” width=“100%”>

<xsl:apply-templates/>
</table>
</center>
</body>
</html>
</xsl:template>

<xsl:template match=“email”>
<tr>
<td>
<xsl:value-of select=“to”/>
</td>
<td>
<xsl:value-of select=“from”/>
</td>
<td>
<xsl:value-of select=“subject”/>
</td>
<td>
<xsl:value-of select=“substring(./body,0,20)”/>...
</td>
ANOTACIONES
</tr>
</xsl:template>
</xsl:stylesheet>
La idea es sencilla: se definen dos nodos (puntos) especiales, que se-

rán el ‘/’ y el ‘email’. De manera que, cuando el recorrido del XML
encuentre uno de estos nodos, efectuará las operaciones especifica-
das dentro de los templates.
91
Así, en el momento de iniciar el recorrido por el código XML se está

en el punto inicial (llamado root o raíz) y se encaja en el template “/
” (que siempre representa la raíz del documento). A partir de este
momento y hasta finalizar el template, todo el código que se encuen-
tra se va escribiendo en la salida, excepto el que empieza con
“<xsl:...” que realiza operaciones sobre los datos XML.
En este caso, sólo se crea la cabecera de un código HTML y se pre-

para una tabla, que será cumplimentada en las sucesivas llamadas
a los elementos ‘email’.
Bibliografía
• Burke, E. M. (2002). Java y XSLT. Madrid: Ediciones Anaya Multi-

media.
• Rusty H., Elliotte, Scott Means, W. (2002). XML in a Nutshell, 2nd

Edition. O’Reilly.
• T. Ray, E. (2003). Learning XML, 2nd Edition. O’Reilly.
• Refsnes Data (2003). XML Tutorial. [en línea] Accesible en:

http://www.w3schools.com/xml/default.asp (consulta: 10-09-2003)
ANOTACIONES
92
Apéndice B: documentación de los principales

estándares
AICC, Aviation Industry CBT Comitee
• Sitio web: http://www.aicc.org
• Mantiene el modelo de estándar AICC.
• Lista de los AGR (AICC Guidelines and Recomendations) y otros

documentos importantes de AICC:
– AGR 001: AICC publications
– AGR 002: Courseware Delivery Stations
– AGR 003: Digital audio
– AGR 004: Operating/Windowing System
– AGR 005: CBT Peripheral Devices
– AGR 006: Computer-Managed Instruction
– AGR 007: Courseware Interchange
– AGR 008: Digital vídeo

ANOTACIONES
– AGR 009: Icon Standard: User interface
– AGR 010: Web-Based Computer-Managed Instruction
– CMI 001: AICC/CMI Guidelines for Interoperability
– CMI 003: AICC/CMI Certification Testing Procedures
93
ADL, Advanced Distributed Learning
• Sitio web: http://www.adlnet.org
• Mantiene el modelo de estándar SCORM.
• Lista de los documentos principales de SCORM:
– The SCORM Overview
– The SCORM Content Aggregation Model
– The SCORM Runtime Environment
IMS, Global Learning Consortium
• Sitio web: http://www.imsglobal.org
• Mantiene el desarrollo de varios estándares en meta-data, en-

samblado de cursos, secuenciación de materiales y tests.
• Lista de los principales documentos referentes a los estándares

mantenidos:
– IMS Content Packaging Specification
– IMS Meta-Data Specification
– IMS Simple Sequencing Specification

ANOTACIONES
x IMS Question & Test Interoperability
x IMS Question & Test Interoperability Overview
x IMS Question & Test ASI Best Practice Guide
x IMS Question & Test ASI XML Bindind Specification
94
x IMS Question & Test ASI Information Model
x IMS Question & Test ASI Outcomes Processing Specification
x IMS Question & Test ASI Selection and Ordering Specification
x IMS Question & Test Results Reporting Best Practice and Im-
plementation Guide
x IMS Question & Test Result Reporting XML Binding Guide
x IMS Question & Test Results Reporting Information Model
ANOTACIONES
95
Apéndice C: ejemplos comerciales en el entorno

del e-learning
Introducción
En este capítulo se verán diferentes alternativas comerciales para la uti-

lización de Learning Management Systems y herramientas de autor.
El mercado actual ofrece software de dos tipos:
• Software propietario. El software adquirido consta de los ficheros eje-

cutables, sin incorporar los ficheros del código fuente. Sólo se permi-
te ejecutar el software adquirido.
• Software libre. La definición de software libre se basa en cuatro pun- Nota

tos. Un software libre debe permitir: ejecutar el software, acceder al Código fuente: Conjunto de
código fuente, distribuir el software a terceros y publicar nuevas ver- instrucciones que forman un
programa, expresadas en
siones. Las especificaciones concretas de su uso, modificación o re-
un lenguaje de programa-
distribución están especificadas en los términos de la licencia. Para ción que puede ser entendi-
más información, os podéis dirigir a Free Software Foundation. do por las personas. Estas
instrucciones, correctamen-
te procesadas, generan los
Como se ha visto, el e-learning es un campo con gran expansión en la programas.
actualidad donde nacen continuamente proveedores para el desarrollo
de software y materiales. Es importante notar la aparición creciente de
consultorías específicas en el campo del e-learning. Una de sus funcio- Nota
nes principales es orientar a las organizaciones que se quieren introducir Free Software Foundation:
en esta área o evaluar las posibilidades de su introducción en un entor- http://www.gnu.org
no de e-learning.
ANOTACIONES
Plataformas comerciales de e-learning
Introducción y características
En el mercado actual existe una gran variedad de productos comer-

ciales que implementan Learning Management Systems, utilizando
97
diferentes tecnologías e implementando diferentes estándares de los

vistos anteriormente.
Para poder analizar un Learning Management System, será necesa-

rio prestar atención a diferentes criterios de selección. La siguiente ta-
bla nos resume los principales:
Tabla 4. Tabla de criterios de selección
Herramientas de Foros, correo-e integrado, chat, vídeo, pizarra virtual,

comunicación …
Herramientas de Sistemas de ayuda, sistemas de búsqueda, calendario

producción con eventos o planificación, …
Herramientas para
Grupos de trabajo, tests autocorrectivos,
la participación
comunidades virtuales, …
del estudiante
Herramientas de
Sistemas de autenticación y validación
administración
Herramientas de Sistemas de tests y puntuación automáticos, gestión

material del curso del curso, monitorización del estudiante
Gestión de currículum de los estudiantes,

Diseño del
personalización del entorno, reutilización del
currículum
contenido, implementación de estándares, …
Hardware/ Requerimientos del cliente, bases de datos del

Software servidor, software del servidor, …
Coste del sistema, módulos opcionales, open source,

Precio/Licencia
versión del software, …
El mercado comercial
El mercado actual ofrece un gran catálogo de productos para e-lear-

ning, y junto con el uso de los estándares para compatibilizar diferentes
productos, están generando un mercado favorable para las organiza-
ANOTACIONES
ciones que desean adquirir o actualizar sus sistemas de e-learning.
En primer lugar veremos algunos sistemas propietarios, y a continua-

ción presentaremos los sistemas libres.
No se pretende dar, en ningún caso, una guía para la elección entre di-
ferentes plataformas, y sólo se pretende ilustrar con algunos ejemplos la
disponibilidad y situación del mercado actual.
98
Software propietario
A nivel de ejemplo, citaremos los siguientes:
• La compañía Click2Learn ofrece una suite llamada Aspen En-

terprise Productivity Suite. Esta suite incorpora diferentes plata-
formas que proporcionan una gran cobertura en todo el
campo del e-learning. Entre otros, encontramos un Learning
Management System, un Learning Content Management Sys-
tem, sistemas a tiempo real de vídeo y audio, personalización
del entorno, generación de auditorías/informes y otros. En el
caso del Learning Management System (Aspen Learning Mana-
gement) ofrece implementación para los estándares SCORM y
AICC.
• Oracle ofrece una plataforma, llamada Oracle iLearning, que

forma parte de una suite de e-learning. Este producto imple-
menta estándares de SCORM, IMS y AICC. Entre otras intere-
santes características, destaca el uso de web services para la
integración con otros Learning Management Systems.
• La compañía Docent, al igual que los dos anteriores, ofrece la

posibilidad de adquirir una suite completa o adquirirla por
partes, para construir el sistema deseado. La suite, llamada
Docent Enterprise 6.5 incorpora un Learning Management Sys-
tems con soporte de los estándares de SCORM y AICC.
• Saba Enterprise Learning Suite es otra suite desarrollada en el

lenguaje Java que se puede encontrar en el mercado con im-
plementación de los estándares de AICC, SCORM e IMS.
ANOTACIONES
• La compañía americana Sun Microsystems también ofrece una

Nota
plataforma basada en web para e-learning, con implementa-
Web Services: Sistema para
ción de los modelos de AICC y SCORM. la comunicación estándar
entre diferentes programas
o aplicaciones a través de
A continuación se verá una tabla que contiene las direcciones redes TCP/IP, como por
donde se puede encontrar más información sobre los sistemas co- ejemplo Internet.
mentados anteriormente, y otros que pueden resultar también

muy interesantes.
99
Tabla 5. Lista de ejemplos de sistemas propietarios
Producto Proveedor Dirección contacto
Aspen Enterprise
Click2Learn http://www.click2learn.com
Productivity Suite
Oracle iLearning Oracle http://www.oracle.com/ilearning
Docent Enterprise Docent http://www.docent.com
Saba Enterprise
Saba http://www.saba.com
Learning Suite
BlackBoard 6 BlackBoard http://www.blackboard.com
Thinq Thinq http://www.thinq.com
WebCT WebCT http://www.webct.com
LMS·QSTutor QS·media http://www.qsmedia.es
http://www.lotus.com/products/
Lotus learnspace.nsf/
IBM
LearningSpace
wdocs/homepage?opendocument
Será necesaria una precisa e intensa búsqueda para poder determi-

nar cuál de las plataformas que ofrece actualmente el mercado se
adapta mejor a nuestras necesidades.
Software libre
A continuación, veremos algunos ejemplos de software libre que

Nota
existen en el mercado actual. La gran mayoría de estos sistemas
PHP: Lenguaje de código
abierto utilizado en los ser-
están desarrollados en lenguajes libres (por ejemplo, Java o PHP)
vidores web para procesar y para arquitecturas libres (por ejemplo, sistemas operativos Linux,
la información antes de ser
bases de datos MySQL o PostgreSQL, servidores web Apache o
enviada hacia el cliente. Por
ejemplo, consultar una base Tomcat).
de datos para poder enviar
ANOTACIONES
los resultados al cliente es

un caso típico de uso del Muchos de estos proyectos tienen su origen en universidades, donde
lenguaje PHP. se utilizan en sus entornos virtuales de aprendizaje, o bien en proyec-
tos de investigación.
A nivel de ejemplo, se citarán los siguientes:
• Bodington. Desarrollado y usado por la Universidad de Leeds, uti-

lizando el lenguaje Java.
100
• La Universidad de California, Los Angeles (UCLA) presenta el sis-

tema ClassWeb como un entorno para crear clases virtuales.
• La Universidad de Michigan ha desarrollado el sistema CHEF

en lenguaje Java y que soporta la arquitectura Open Knowledge
Initiative (OKI) del MIT (Massachusetts Institute of Technology).
• Claroline es otra opción, en este caso de origen francés, que está

Nota
disponible en español.
Open Knowledge Initiative
(OKI): Proyecto de colabora-
A continuación se verá una tabla que contiene las direcciones ción entre diferentes universi-
dades y organizaciones de
donde se puede encontrar más información sobre los sistemas co- estandarización y especifica-
mentados anteriormente, y otros que resultan también muy inte- ción para dar soporte a la
tecnología de aprendizaje en
resantes. el ámbito universitario. El re-
sultado es una arquitectura
abierta y extensible que espe-
Tabla 6. Lista de ejemplos de sistemas libres
cifica cómo los componentes
de un software educacional
Producto Dirección contacto se comunican entre ellos y
con otros sistemas. Para más
ATutor http://www.atutor.ca información consultar a
http://web.mit.edu/oki/
Bodington http://bodington.org
CHEF http://www.chefproject.org/index.htm
Claroline http://www.claroline.net
ClassWeb http://classweb.ucla.edu
Coursework http://getcoursework.stanford.edu
Fle3 (Future
Learning http://dotlrn.org
Environment)
Uportal http://www.ja-sig.org
Whiteboard http://whiteboard.sourceforge.net
ANOTACIONES
A continuación veremos la plataforma desarrollada por IBM y Lotus

para e-learning con un poco más de detalle. Volvemos a insistir en
que no es objetivo de este módulo el análisis de diferentes sistemas
comerciales, y que se ofrece sólo como información complementa-
ria. Resumiendo, no se pretende mostrar ningún tipo de preferencia
hacia esta plataforma, sólo se pretende mostrar un ejemplo con un
poco más de detalle.
101
Ejemplo: Lotus LearningSpace
Introducción
IBM MindSpan Solutions presenta el Lotus LearningSpace como una

completa familia de productos basados en entorno web para el mun-
do del e-learning.
Ofrece tres tipos de aprendizaje:
• Self-Placed Learning: permite la creación e incorporación de ma-

teriales propios o adquiridos a diferentes vendedores, así como
tests que, junto con el seguimiento del alumno, permitirán evaluar
el progreso del alumno en cualquier momento.
• Collaborative Learning: permite la creación de varios grupos de

discusión (en modo privado o público), compartición de documen-
tos y chats. Con este sistema se facilitan los intercambios (síncronos
y asíncronos) entre miembros de las comunidades e-learning. Será
también un buen entorno, donde el tutor puede plantear cuestio-
nes o ejercicios e inicar debates.
• Real-Time Learning: conocido popularmente como “Virtual class-

room”, este sistema permite las sesiones a tiempo real a través de
audio y vídeo, chats y pizarras compartidas (espacio común don-
de todos escriben o dibujan y son vistos por todos los alumnos del
aula).
La familia Lotus LearningSpace se estructura en tres grandes módu-

los, que dotan al sistema de diferentes opciones y capacidades:
ANOTACIONES
• Lotus LearningSpace Forum: con el foro de Lotus Learning Space

se dota a las clases de independencia del lugar y del momento.
• Lotus LearningSpace 5.0: aplicación basada en servidor web con

dos módulos.
• Lotus LearningSpace Core Module: dota de la funcionalidad en el

modo Self-Paced Learning, proporcionando un Learning Mana-
102
gement System según el estándar de AICC para mostrar los ma-

teriales y realizar el seguimiento de los alumnos.
• Lotus LearningSpace Collaboration Module: amplía la funcionali-

dad del módulo Core para ofrecer los modelos Collaboration
Learning y Real-Time Learning.
Los estándares
Este software sigue las especificaciones de AICC para el desarrollo

de materiales y el seguimiento de los alumnos. Dispone de acredita-
ción por parte de la organización AICC en los estándares AGR 006
versión 2 y AGR 010 versión 1.
De este modo podemos lanzar y realizar seguimiento sobre materia-

les que cumplan la especificación de AICC. También se ofrece sopor-
te a la especificación API utilizada en el Data Tracking de SCORM.
En la actualidad se está trabajando para ofrecer soporte en las nue-

vas especificaciones desarrolladas por el IMS Global Learning Con-
sortium.
La transferencia de vídeo y audio se realiza con el estándar H.323

del ITU-T, que define el envío de audio y vídeo a través de IP sobre
Internet e intranets.
Consideraciones
Una de las características no comentadas hasta ahora y que han he-

cho de Lotus LearningSpace uno de los productos pioneros en el
ANOTACIONES
mercado del e-learning es su alto grado de escalabilidad.
Como ya hemos visto, es posible la adquisición de diferentes módu-

los, y de este modo se puede adquirir un sistema y ampliar sus fun-
cionalidades en el futuro. Además, es posible la instalación de todos
los módulos en un solo computador para pequeños o medianos en-
tornos, mientras que también es posible su instalación distribuida de
cada uno de los módulos en varias computadoras para permitir el
acceso simultáneo de gran cantidad de cursos y estudiantes.
103
De esta manera se consigue un alto grado de escalabilidad del sis-

tema.
Podemos participar en un curso de ejemplo en la dirección:
http://www.elearning.connectria.com/LearningSpace5/
Herramientas de autor (Authoring Tools)
Las herramientas de autor (Authoring Tools) van a permitir la creación o

modificación de material e-learning de una forma cómoda y rápida.
Como se ha podido ver durante este módulo, en el proceso de crea-

ción del material para un curso e-learning intervienen diferentes pro-
cesos: desde la creación de los diferentes Learning Objects que
formarán el curso, la inserción de los meta-data en los diferentes ni-
veles y la creación de la estructura del curso.
Disponemos de un buen número de productos comerciales para fa-

cilitar y agilizar estos procesos. Hay desde herramientas para valida-
ción de meta-data o creación de la estructura de un curso hasta
herramientas completas que permiten el desarrollo de los Learning
Objects, la creación de la meta-data y la creación de la estructura
del curso. Además, cada una de ellas puede implementar uno o más
estándares, existiendo alguna de ellas que incluso permite la trans-
formación semiautomática de un formato a otro.
En esta sección se verán algunas de ellas, aunque es necesario des-

tacar que la finalidad de esta sección sólo es ilustrar con algunos
ANOTACIONES
ejemplos el mercado actual, en ningún caso se puede considerar una

guía de productos o recomendaciones.
Herramientas para Learning Objects
En la creación de los Learning Objects se deben considerar dos

cuestiones fundamentales en lo que se refiere a las herramientas de
autor: el tipo de recurso que deseamos crear (texto, vídeo o anima-
104
ción, sonido, etc.) y la compatibilidad con el Learning Management

System.
En lo que se refiere al tipo de recurso, existe una gran variedad. Por

Nota
ejemplo, podemos crear texto en HTML, PDF o documento de Microsoft
Plugin: Programa que se
Word, y vídeos en AVI, MPEG o WMV. Es necesario considerar que cier- ejecuta bajo el entorno del
tos tipos de recursos obligarán al cliente a tener instalado en su ordena- navegador web.
dor algún tipo de programa o plugin adicional. Éste es el caso, por
ejemplo, de las animaciones Flash o de los applets de Java.
La compatibilidad con el Learning Management System se refiere a la

monitorización del estudiante, que se realizará a través del Data
Tracking. Como ya sabemos, existen dos estándares: el API y el HACP.
Se debe tener en cuenta la opción escogida y el grado de implementa-
ción de cada una de las partes.
Como ejemplos de herramientas para la creación de Learning

Objects se pueden citar, por ejemplo, el Macromedia eLearning
Suite. Este software está formado por los conocidos DreamWeaver,
Flash y AuthorWare en sus versiones MX. Con estas tres herramientas
se pueden crear Learning Objects compatibles con sistemas SCORM.
Además, es posible crear el meta-data y la estructura de contenido en el
formato SCORM. Para más información o especificaciones concretas,
referirse a Macromedia (http://www.macromedia.com ).
Uno de los grandes competidores de Macromedia eLearning Suite es

una herramienta de Click2Learn llamada ToolBook. Este software es ca-
paz de desarrollar Learning Objects en el formato SCORM y AICC.
Para más información o especificaciones, referirse a Click2Learn
(http://www.click2learn.com ).
ANOTACIONES
Herramientas para el meta-data
Una vez creados los Learning Objects, llega el momento de agregar

el meta-data. Puesto que se trata de una tarea lenta y algo tediosa,
a menudo no se realiza, lo cual ya se ha visto que es un error.
Para facilitar este trabajo, existen una serie de herramientas que van
a permitir crear el meta-data de un Learning Object, bloque o curso
entero de manera más ágil y rápida.
105
En primer lugar, es importante resaltar que algunas de las herra-

mientas para la creación de Learning Objects ya incorporan herra-
mientas para la creación de meta-data. Aunque también existen
herramientas para la creación exclusiva de meta-data.
Por ejemplo, Meta-Data Generator es una herramienta desarrollada

por el propio ADL para crear meta-data conforme con las diferentes
especificaciones que incorpora el SCORM. Veamos un screenshot de
este programa que distribuye ADL.
Figura 25. Meta-Data Generator de ADL
Para más información o especificaciones, referirse a ADL (http://

www.adlnet.org ).
Herramientas para la estructura de contenido
Después de la creación de los Learning Objects y el meta-data aso-

ANOTACIONES
ciada a los diferentes niveles (Learning Objects, bloques y curso), se

debe crear la estructura del curso para la importación en el Learning
Management System.
Igual que la creación del meta-data, las herramientas más completas

(como por ejemplo el paquete de Macromedia o de Click2Learn) in-
corporan esta función. También existen utilidades concretas para rea-
lizar esta función.
106
A continuación presentamos algunos ejemplos:
• Microsoft LRN Toolkit, que proporciona soporte para la creación

de paquetes compatibles con SCORM.
Figura 26. Microsoft LRN Toolki
• Click2Learn Single Item Packager for SCORM 1.2, que ofrece fun-
cionalidad para crear la estructura de un solo item en formato
SCORM.
• Click2Learn SCORM 1.2 Package Aggregator, que nos permite

crear estructuras compatibles con el formato SCORM.
• Reload Editor, que permite la creación de estructuras SCORM

compatibles y también la creación del meta-data en éstos.
Figura 27. Reload Editor

ANOTACIONES
107
• AICC File Editor, que permite la manipulación de los ficheros des-

criptivos de las estructuras AICC.
Figura 28. File Editor
Herramientas para QTI

Existen muchas herramientas para la creación de test QTI. Aunque
por el momento son pocos los Learning Management Systems comer-
ciales que implementan la especificación QTI, veremos que existen
varias herramientas para producir tests en formato QTI.
Algunas de las herramientas son:
• IMS Assesst Designer

• QuestionMark Perception
• Riva e·Test
• Can Studios Ltd. Canvas Learning
Figura 29. IMS Assesst Designer

ANOTACIONES
108
Apéndice D: estructura del curso de ejemplo del

capítulo 5
A continuación, se presenta el código completo que define la estruc-

tura del curso de ejemplo desarrollado en el capítulo 5.
<?xml version=“1.0”?>
<manifest>
<metadata/>
<organizations default=“B0”>

<organization identifier=“B0”>
<title>Curso Ejemplo - UOC</title>

<item identifier=“B0_001” isvisible=“true”>
<title>Lección 1</title>

<title>Introducción</title>
</item>
<title>Explicación</title>
</item>
<title>Evaluacion</title>
<adlcp:maxtimeallowed>0001:00:00.00</adlcp:maxtimeallowed>
<adlcp:timelimitaction>continue,no message</adlcp:timelimitaction>
ANOTACIONES
<adlcp:masteryscore>75</adlcp:masteryscore>
</item>
<metadata>
<adlcp:location>Course01/Lesson01.xml</adlcp:location>
</metadata>
</item>
109
<metadata>
<adlcp:location>Course01.xml</adlcp:location>
</metadata>
</organization>
</organizations>
<resources>
<resource identifier=“R_S001_001” type=“webcontent” adlcp:scormtype=“sco”
href=“Course01/Lesson01/sco01.htm”>
<metadata>
</metadata>
</resource>
<resource identifier=“R_S001_002” type=“webcontent” adlcp:scormtype=“sco”
<metadata>
</metadata>
<dependency identifierref=“R_Image_001”/>
</resource>
<resource identifier=“R_S001_003” type=“webcontent” adlcp:scormtype=“sco” </manifest>
<metadata>
</metadata>
ANOTACIONES
</resource>
<resource identifier=“R_Files_001” adlcp:scormtype=“asset” type=“webcontent”
xml:base=“Course01”>
<file href=“SCOFunctions.js”/>
<file href=“APIWrapper.js”/>
110
</resource>
<resource identifier=“R_Image_001” type=“webcontent” adlcp:scormtype=“asset”
xml:base=“Course01/Lesson01/”>
<metadata/>
<file href=“pics/0011.jpg”/>
</resource>
</resources>
ANOTACIONES
111

Fundamentos Del Diseñoi Learning PDF

Cargado por

Información del documento

Título original

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

Fundamentos Del Diseñoi Learning PDF

Cargado por

Copyright:

Formatos disponibles

Fundamentos del diseño

Jordi Casas Roma

Responsable de autoría: Josep Prieto (Universitat Oberta de Catalunya)

1. La importancia de los estándares en el diseño

2. Principales estándares para el e-learning ................ 11

3. Los componentes del modelo tecnológico

3.3. Resumen .............................................................. 25

4. ¿Qué estándares? Emparejando estándares

4.3. Estándares para evaluación (Assessment) ............... 33

5. Proceso de diseño de unos materiales e-learning .... 49

Mapa conceptual ............................................................ 69

Apéndice A: el lenguaje XML ......................................... 83

Apéndice B: documentación de los principales

Apéndice C: ejemplos comerciales en el entorno

Apéndice D: estructura del curso de ejemplo

En este módulo se proporcionará al estudiante una visión general del

El desarrollo de este módulo se estructura en torno a dos grandes

En el primer bloque se describen los componentes básicos de un en-

El objetivo de este primer bloque es proporcionar los conocimientos

capítulos anteriores, que proporcionarán los conceptos básicos para

Durante el desarrollo de este módulo se presentarán diferentes ejem-

1. La importancia de los estándares en el diseño

1.1. Introducción. ¿Qué es un estándar?

Aunque muchas veces no nos demos cuenta, en nuestra vida cotidia-

En el campo de la informática, su definición es compleja. Veamos

“Acuerdos documentados que contienen las especifica-

Podemos diferenciar entre dos tipos de estándares, los estándares

acreditados o de jure y los estándares llamados de facto.

Un estándar acreditado o de jure es un estándar aprobado y acredi-

El otro tipo de estándares, los de facto, son aquellos estándares que

por el contrario, son ampliamente utilizados en el mercado. En algu-

1.2. Estándar frente a propietario.

Hay varias razones que permiten ver la importancia de un estándar. Su-

Esto proporcionará a nuestro sistema la escalabilidad. Entenderemos

trabajo realizado en el presente podrá ser reutilizado en el futuro,

Centrándonos en los materiales, el uso de los estándares nos va a

El coste del sistema también baja al poder comprar los componen-

En resumen, los beneficios de un sistema basado en estándares fren-

En este primer punto se ha definido el concepto de estándar, y se ha

Es importante remarcar que el uso de un sistema basado en están-

lecciones) entre diferentes organizaciones.

2. Principales estándares para el e-learning

En la década de los ochenta nace el concepto del e-learning en la in-

Después de años de utilización del software y hardware propietario,

El objetivo de este organismo es reducir los costes de los sistemas de

El AICC puso las bases del primer estándar en e-learning en el año

de estándares de e-learning. El primero nace a partir de un pro-

desarrollado importantes estándares de diferentes tipos, entre ellos

También en el año 1997, el IEEE crea una sección llamada Learning

Durante estos últimos años han aparecido nuevas organizaciones o

2.2. ADL Initiative

El grupo ADL se encarga del desarrollo de SCORM, que abarca los

• Un modelo de contenido (Content Model).

• Un estándar para un entorno completo de implementación de

El SCORM es un estándar que se basa en muchos otros, incorporan-

Podemos encontrar la documentación del SCORM en la página web

• Visión general (The SCORM Overview): proporciona una visión

• Modelo de contenido (The SCORM Content Aggregation Model):

• Entorno de ejecución (The SCORM Run-Time Enviroment): contiene

Desde la página web de ADL se ofrece software para

2.3. Aviation Industry CBT Committee

El AICC fue el primer grupo centrado en el desarrollo de estándares

También desarrollan guías técnicas conocidas como AGR (pautas y