Este documento presenta la definición de alcance de un proyecto llamado Desire 2.0. Se discuten temas como los requisitos del sistema, las bases de datos, la estructura del sitio web, los usuarios, los estándares, y más. Se asignan responsabilidades específicas a miembros del equipo para cada tema. El objetivo general es catalogar y mejorar la presentación de objetos de aprendizaje de diversas fuentes para su uso en la enseñanza.

1. Definición de alcance
notas para una reunión web

2. Grabando, grabando
En la pizarra notas
claras
Si no tenéis permiso
no levantéis la
mano, chatead
Configura la cámara
(ojito de la barra)
Configura el
micro (entrada de
audio)Levanta el
micro para hablar
y ciérralo al
terminar

3. DEFINICIÓN DE ALCANCE DESIRE 2.0
Asunto Expone
Propósito general y justificación del proyecto Koldo
Sobre alcance Koldo
Los requisitos del sistema Alberto
Bases de datos /Módularización David
Estructura del sitio Carlos
Usuarios Mising
Estandares, estados de objetos y visores Carlos/Fernando
Interoperatividad David
Accesibilidad Carlos
Diseño y usabilidad Alberto
Arquitectura tecnológica e Implantación Alberto/Fernando
Catálogo Marisa
Dimensión social (ó 2.0) Carlos
Formación asociada. Carlos
Identificación de los participantes Koldo
Necesidades y expectativas Resume Maite
Entregables
Planificación de hitos
Resumen del presupuesto
Indicadores de desarrollo
Temas pendientes de esta
Gestión de riesgos y retrasos reunión
Evaluación y momentos de realización
GLOSARIO

4. Propósito general y justificación del proyecto
• Catalogación de objetos de aprendizaje reutilizables procedentes de
diversas fuentes, en especial los realizados en acciones
complementarias 2008.
• Mejora de formularios para etiquetar e incorporar los objetos
Revisión de sistemas de búsqueda y presentación de los objetos
(aquí interviene el visor)
• Implementación de un sistema de descarga seguro y eficaz para
objetos “pesados”
• Creación de una comunidad de práctica, desarrollando acciones
para la ampliación de la dimensión social del sitio
• Puesta a punto de los instrumentos de evalución del proyectoPor
último,empaquetado del sistema completo (y del código) para su
distribución en el dominio público

5. Sobre
alcance
• Documento:
– Los requerimientos generales del sitio
– Los requisitos de las bases de datos y el manejo de Amplitud/Calidad
usuarios
– Aspectos relacionados con la interoperabilidad, la
modularidad y la integración entre aplicaciones
– Aspectos sobre la accesibilidad y usabilidad
– Estándares de uso
– Formación asociada del equipo
– La metodología de trabajo
– Los métodos de evaluación
– Los requisitos para plantear cambios
– La gestión del riesgo y los retrasos

6. Los requisitos del sitio
• Instalación de Drupal, con posibilidad de
integración con una plataforma que cumpla los
estándares. Usaremos Moodle
• El sitio ofrecerá la posibilidad de
personalización
(apariencia, permisos, integración)
• Las funcionalidades del Repositorio se
integrarán en un módulo Drupal una vez
testadas
• La integración con Plataformas de Gestión de
Cursos (LMS) sin nuevo registro. Debe integrar
los cursos catalogados en el repositorio
• Debe integrarse un sistema de búsqueda
semántica dentro de los objetos para calidad
de etiquetas
• Gestión del ciclo de publicaciones y
autorizaciones para su engarce con el visor de
objetos
• El control del uso de objetos, y el ciclo de vida
de los recursos debe registrarse
• La comunicación con los usuarios debe
realizarse por un gran número de canales

7. Bases de datos y modularización
• El diseño de la Base de Datos tendrá en
cuenta la necesidad de adaptación de una
Objetos
Campos o
como BBDD existente con datos sobre el
nodos
atributos
con CCK
BD CNCP(BBDD Maestra) y su actualización.
cualificacion
• Compatibilidad con sistemas de
Metadatos
con modularización Drupal
taxonomía
• Compatibilidad con visor de objetos
Modulo Objetos LOM
Visor
(servicio web)
Clasificación Listado recurso Tipo recurso

8. Estructura del sitio (1)
Ultimos objetos
- Estructura limpia
- 5 regiones como tope máximo : tratar de simplificar a 3
• Encabezamiento : cuatro o cinco entradas de acceso directo y cuadro de búsqueda
• Pie: información institucional y tipo licencia
• Contenido : últimos objetos de aprendizaje incluidos en el repositorio
- Público y privado : por defecto todo público (incluido los recursos sin revisar)
Privado : acceso para subir recursos y consultar los accesos, descargas y comentarios a recursos

9. Estructura del sitio (y 2)
• Queremos que Desire 2.0 forme parte del entorno
personal de aprendizaje de nuestros profes y de
nuestros alumnos
• 1. Briefing: Sumario con la definición de requisitos del
diseño (ancho fijo o líquido, lineas curvas o
rectas, agresivo/docil, serio/joven, etc..) aportado por
el equipo de definición de alcance al diseñador. Guia
de requisitos" dónde se incluyan estos
requisitos(previo consenso, obviamente).
• 2. Bocetos: una serie de bocetos aportados por el
diseñador y discutidos por el equipo. Entiéndase un
boceto como un deseño esquemático, presentado en
forma de imagen o pdf, nunca en html. En estos
bocetos se puede discutir tanto el diseño, como la
maquetación y ubicación de bloques. Me parece
acertada tu reflexión. Idem con el tema de
guia, establecer un número de bocetos en base los
esquemas y tomar una decisión.
• 3- Diseño CSS: traduciendo el diseño aprobado a
css, pero nunca tocando las plantillas. Las plantillas
tienen php, y deben de ser editadas por un
desarrollador, abajo la demanda y la supervisión del
diseñador.

10. Usuarios
• En la etapa anterior de Desire 1.0 se ha prestado muy poca
atención al usuario...¿realmente Desire 1.0 es “usable”? No
• Qué servicios ofrece/ cómo se relacionan con las estructuras.
• ¿Cómo se facilita el trabajo de los editores/revisores y se
evita que se desorienten?
• ¿Cuándo es necesario registro?. Solo para descargas, entradas
de blog y subir objetos pero no para ver
• Los usuarios deben tener datos en su perfil suficientes para
permitir su integración como usuarios del Moodle del
proyecto mediante un LDAP u otro sistema.
• Tener datos de usuarios representa disponer de un servidor
seguro para la gestión. Estudiaremos costes de
VeriSign(SecureSite) que parece la opción más razonable, es
reconocido y aumenta la confianza del usuario.
• El usuario editor/revisor tendrá acceso a un número limitado
de funciones: entradas de blog, trabajo con objetos y poco
más.
• El panel de control se reserva a administradores, solo técnicos
(los de esta reunión más diseñador y coordinador de
proyecto).
• Nuevas incorporaciones requieren un estudio de la necesidad

11. Estandares, estados de objetos y visores
• Deberán considerarse, al menos, los estándares
SCORM, IMS, LOM-ES, en sus últimas versiones aplicables.
• Importante : aclarar conceptos y definir con qué estamos
trabajando : OA, objeto de aprendizaje, recurso, recurso
didáctico, etc.
• Concepto : Recurso empaquetado
– OA u Objeto de Aprendizaje
– Estándar LOM : revisión de campos
– SCORM : garantiza transferibilidad (preferentemente)
• Pero los objetos a integrar deben ser variados, no obligados a
estándares, de forma que se permita la participación de la
mayoría de los profesores.
• Figura del editor como valor añadido ‘institucional’, en Desire 3.0
debería de desaparecer.
– - pendiente de revisar por Editor
– - revisado por editor
– ¿Catalogado?
– - Relación con Dimensión Social (o 2.0)

12. Interoperatividad
Entre
De contenidos
plataformas
Acreditación Uso de sistemas
compartida 2.0 y visores
Canales de
Servicios web información (RSS,
boletines…)
La interoperatividad es la condición mediante la cual sistemas heterogéneos pueden
intercambiar procesos o datos. La palabra interoperabilidad es un anglicismo

13. Accesibilidad
ACCESIBILIDAD: Al hablar de accesibilidad Web se
está haciendo referencia a un diseño Web que va a
permitir que estas personas puedan
percibir, entender, navegar e interactuar con la
Web, aportando a su vez contenidos. (W3C)
• El sitio debe ser accesible, no sólo por
motivos normativos, sino de estricta
justicia social. Las pautas de diseño
seguirán las normas de accesibilidad
W3C y los estándares WAI 1 en todos
sus apartados.
• Diseño pensando en el usuario ->
Relación con la estructura del sitio

14. Diseño y usabilidad
USABILIDAD: “FACILIDAD DE USO DE UNA APLICACIÓN O PRODUCTO INTERACTIVO”
“GRADO EN EL QUE TODAS LAS PERSONAS PUEDEN VISUALIZAR UN OBJETO”
“PROCESO PREVIO DE CONFIGURACIÓN MENTAL”
• Desarrollar/diseñar la web para el usuario.
• Interactuación cómoda e intuitiva.
• Evitar el diseño enfocado a la tecnología.
• Evaluar la usabilidad:
• Taxonomía: La taxonomía en Drupal es un concepto
fundamental. El contenido del sitio debe ser
accesible, por lo tanto debe estar correctamente
ordenado y clasificado
• LOM aporta ya muchas taxonomías. ¿Son
suficientes? ¿Hay que añadir alguna que sea
compatible?
• Evaluación heurística.
• Pruebas de usabilidad.
• Seguimiento visual (eye tracking)
• Otros (encuestas p.e)
• Feedback miembros del proyecto y usuarios :
¡explotemos la inteligencia colectiva!.
• Mejoras en la navegacuión y en el uso de términos
no comunes

15. Arquitectura tecnológica e implantación (1)
• Crecimiento : Debemos contemplar el crecimiento sitio como un
objetivo fundamental. Drupal es muy flexible en este aspecto gracias a
los módulos. Los módulos son pequeñas porciones de código que
añaden funcionalidades no integradas
– Evaluación de las necesidades (incluído en fase de análisis y planificación)
– Búsqueda de los módulos(incluído en fase de diseño)
– Estudios del caso y evaluación de la calidad del módulo (incluído en fase de
diseño)
• Fase de pruebas (después de la fase de implementación, y antes del
mantenimiento) Antes de instalar un módulo o cualquier funcionalidad
en el sitio, se probará en un plataforma especialmente dedicada al
desarrollo y experimentación. Un error cometido en la versión 1.0 del
proyecto, ha sido no contar con una plataforma de testing desde el
momento arranque del proyecto.
• Fase implementación. Tras la elección del módulo, la verificación del
funcionamiento en la fase de pruebas, se procederá a la
implementación en en sitio de producción.
– retroalimentación: como se va a realizar la comunicación entre las partes del
equipo, si existen jerarquías o no, y como se configura la cadena de mando y
las responsabilidades
– asignación de tareas: A quien compete, herramientas a usar (collabtive?)
– flujo de trabajo: Como se implementan las tareas, quien las cierra (el propio
desarrollador asignado?) y supervisa.
– Sistema de control de versiones: Cual usar y porqué. Quien lo usa y como.
– documentación del trabajo realizado: quien y como
• Fase de mantenimiento: La instalación de un módulo requiere un
mantimiento del mismo, sin olvidar el Core y el resto de los módulos
instalados.

16. Arquitectura tecnológica e implantación (y 2)
Transferencia: CMS / LMS
Este punto nos referimos a la transferencia
entre el CMS y LMS, es decir, cómo y cuándo
los objetos de aprendizaje estarán disponibles
en el LMS.[Fernando – David – Alberto] .
En este punto debemos también tener en
cuenta al usuario/docente/miembros del
proyecto, su experiencia como usuarios
• Debemos tener en cuenta, la
implementación “un sistema de descarga
seguro e eficaz para obxectos....”
Documentación técnica
siempre disponible
Distribución de resultados

17. Catálogo (1)
La catalogación de objetos de acciones complementarias 2008-
2009 Es la base del proyecto, la razón por la que nos ha sido
concedido.
Debe estar rematada a finales de julio, aunque seguiremos
aportando materiales de otras procedencias
El grupo de trabajo está coordinado por Marisa, y lo compone:
Loli, Tino y Marcos. Se agradecen las aportaciones de todos los
participantes en el proyecto.
Catalogación de materiales y objetos: tareas a realizar
• Recopilar materiales Xunta: Contamos con 8 paquetes de
Materiales aportados por la Consellería de Traballo. faltan
dos ó tres
• Buscar otros materiales En realización
• Crear tabla estructura materiales En realización
• Proponer nuevas etiquetas para repositorio 15 de Abril
• Etiquetar y subir objetos 30 de Abril
• Revisar y aprobar objetos 5 de Mayo
• Proponer una estructura para OA convocatoria 2009 15
Mayo
• Aplicar evaluaciones de calidad de metadatos Septiembre

18. Catálogo (2)
Catalogo General Vocabulario controlado?
Familia
Cualificación
Characterstring 1000
Characterstring 1000
• Se ha consensuado una ficha básica inicial
Unidad Competencia
Título
Characterstring 1000
Langstring 100
para analizar los materiales de AACC09
Idioma
Descripción
Characterstring 100
Langstring 2000
basada en los datos del estándar LOM,
Ciclo de Vida utilizados en el repositorio actual,
Entidad Characterstring 1000
Técnica seleccionando aquellos que nos permitan
Formato (Lanzador)
Characterstring 500
MIME conocer el contenido del material, su
Tamaño (byte-Mb)
Estructura de archivos
Characterstring 30
Abierta
formato…. con el fin de poder tomar
Uso didáctico
decisiones al respecto sobre:
Vocabulario LOM-ES:
Tipo recurso
Media// Sistema de representación de
información y/o conocimiento//
• Necesidad de solicitar a las entidades, el
Aplicación informática// Servicio//
Contenido didáctico. material en otros formatos.
Destinatario
Vocabulario LOM-ES:
Tipo de aprendiz//agrupamiento de
• Validez del material actual para
los alumnos//educador//expertos
etiquetación y subida posterior al
Material
Complementario repositorio.
Estructura Abierta
Formato Abierta
Tipo abierta

19. Catálogo (y 3)
Simultáneamente:
• Continuaremos con la búsqueda de aquellos materiales que
den efectiva respuesta a nuestros requisitos, es decir, que
podamos asociarlos a una o más unidades de competencia del
catálogo de cualificaciones.
En adelante:
• Seleccionados los materiales definitivos, elaboraremos un
"mapa" de los recursos válidos obtenidos. S
• e trataría de elaborar una tabla que contemple las diferentes
familias profesionales, las cualificaciones correspondientes y
asociaríamos a estas las unidades de competencia vinculadas
a los objetos seleccionados.
• Posteriormente iniciaríamos el proceso de catalogación
procediendo a etiquetar los materiales disponibles en base al
modelo LOM
• Al tiempo se estudiaría la propuesta de nuevas etiquetas que
contribuyeran a mejorar la búsqueda semántica del citado
objeto y en consecuencia, mejorase su localización efectiva.
• Una vez definidos los metadatos definitivos a utilizar, revisado
y catalogado el OA, se procedería a su publicación en el
repositorio.
• Dejaríamos para una última fase la evaluación de los
metadatos en función de los indicadores definidos

20. Dimensión social ó 2.0 (1)
Media is not social. It becomes social as we use it to form and create connections. George Siemens
• No hay tradición ni existen sistemas específicos para generar
una verdadera red de conocimiento en formación para el
empleo.
• En una red lo importante son los nodos, el espíritu de
competencia entre entidades e, incluso, entre los docentes
de una organización limita el intercambio de información.
• La tarea debe abordarse estudiando los grupos socialmente
relevantes en una red social como ésta:
– Docentes cercanos
– Docentes de otras entidades
– Las propias entidades separando entre con y sin ánimo de lucro
– Las editoriales implicadas: Ideas propias, Adams, Cefiasa...
– Las diferentes administraciones laborales y educativas (estas
últimas no siempre tienen interés en el desarrollo de la
formación para el empleo).
• Existen conflictos de intereses entre todos estos actores y
hay que intervenir sobre ellos. Para la creación de
comunidad de práctica se trata de difundir el meme:
"cuando trabajas en Formación para el empleo trabajas en
una Comunidad“

21. Dimensión social ó 2.0 (y 2)
Docentes cercanos
• Daremos de alta al usuario de forma automática : ‘Este es tu
almacén de recursos’
• Crearemos un sistema de reputación o reconocimiento :
etiquetas ‘Me gusta’ o ‘Favorito’
• Aportaremos la posibilidad de comentar por parte de los
usuarios
• Creación y envío periódico de boletines
• Convocatoria de concursos accesibles para ellos
• Acceso a una plataforma de práctica por familia profesional
• Comunicaciones frecuentes con noticia de eventos y
concursos
• Sesiones formativas
Otros agentes
• Contenido en página, más artículos imprescindibles como el
de Siemens, conferencias web de expertos reconocidos con
una colección de grabaciones....
• Presentar siempre el repositorio como una ventaja para
todos los agentes, que lo es.
• Integrar a los actores reticentes

22. Formación asociada
• Formación en Web 2.0
(referencia : proyecto
Hardware: Software: TACCLE)
Ferramentas de autor, aulas virtuais,
Encerados dixitais interactivos,
servidores, equipos persoais,
conexión permanente…
xestores de contidos, editores de
video… • Baño WEB 2.0 :
Moi asequible e baixando de prezo.
Manexo máis sinxelo, máis
variedade, moitos de libre – Que és: paradigmas
– Para que me sirve: funciones
distribución
– Como la utilizo:
Formación 2.0 herramientas
A web das persoas, polas persoas,
• Secuencial, primero
para as persoas e, sobre todo...
entre as persoas... O aprendizaxe
cooperativo na súa máxima
Competencia
expresión...
Obxectos de miembros del
docente aprendizaxe proyecto, segundo docentes
Cambios culturais: da competencia Inexistentes en especialidades sen
demanda masiva, dispersión de
propios, luego hacia fuera
• Incidiremos en plugin y
a cooperación, o docente como
mediador, aprendizaxe informal, esforzos, necesidade de
conectivismo…. estandarización
gadgets que facilitan la vida
del formador 2.0

23. Identificación de los participantes
Contenidos comunicaciones
y Webinars.
Koldo, todos
Presentación y
Funcionalidades gestión de objetos en
Koldo repositorio y aula
Alberto Maite
David Carlos
Fernando Julio
Luis
Catalogación y búsqueda de materiales
Diseño gráfico Marisa
Jose y todos Tino
Marcos
Loly

24. Necesidades y expectativas (1)
Empresa negociada
Responsabilidad mutua
Interpretaciones
Ritmos
Respuesta local
Empresa
conjunta
Diversidad de compromiso
Relatos, estilos, artefactos,
Acción conjunta
instrumentos, acciones,
Relaciones
eventos históricos, conceptos,
Complejidade social
discursos…
Mantenimiento de comunidad
Compromiso Repertorio
mutuo compartido

25. Necesidades y expectativas (y 2)
Limpieza del sitio
Facilidad de uso
Feedback constante
Experiencia de usuario
Evaluar todo
Experiencia piloto
Enseñar a compartir
Repertorio de frases
CREAR LA COMUNIDAD
Cada uno a su ritmo
No hay objetos, hay recursos
No hay repositorios, hay catálogos
No hay metadatos, hay etiquetas

26. Asuntos pendientes
Para definir después de esta reunión
Entregables
Planificación de hitos
Resumen del presupuesto
Indicadores de desarrollo
Gestión de riesgos y retrasos
Evaluación y momentos de realización
GLOSARIO

27. Indicadores de desarrollo (en desarrollo, valga la…)
• Desarrollo plataformas
• Alcance
• Migración de contenidos y
• Requisitos de diseño
usuarios
Análisis Implementación
• E/R actual vs E/R nueva
• Modelo recurso didáctico • Optimizar código
• Diagrama de clases (¿Simpletest?)
• API servicio Web • Optimizar BD (¿Devel?)
• Plan de implementación • Encuestas
• Bocetos diseño • Piloto
Diseño • Plan de actualización Pruebas • Bocetos modificaciones

28. Evaluación y momentos de realización
Cienciométrica
Informétrica Webométrica
Ciencias de la
información
Recuperación
Learnométrica
de información
Análisis Modelos Comprensión
Datos (obxectos,
LOM, CAM,
SCORM) Métricas Aplicación