Experiencias en el

desarrollo de
productos de software
educativo
Eugenio Jacobo Hernández Valdelamar
jack_hv@yahoo.com

Octubre, 2007
Agenda
 ¿Qué es el software educativo?
 ¿Cómo se hace el software educativo?
 Hacia una fábrica de software educativo
 Casos de estudio
 “Remake” de una idea ya existente
 Evolución de una idea ya existente
 Metamorfosis de un concepto previamente planteado
 Proactividad interna
 La madre de todas las normalizaciones
 Los deseos del cliente
 Para reflexionar
¿Qué es el software
educativo?
 ¿Qué tipo de software es el
software educativo?
Diseñado para realizar una Software
función específica para el
usuario
Software de aplicación Software de sistema

Ofimática

Comunicaciones

Negocios Software educativo:

Los programas para computadora
Multimedia
creados con la finalidad específica de
Analítico ser utilizados como medio didáctico, es
decir, para facilitar los procesos de
Colaborativo enseñanza y de aprendizaje.

Bases de datos

Otros Educativo
 Exposición Proceso de
enseñanza

Evaluación Guía
• Presentar información
• Plantear ejemplos
• Exponer reglas

Práctica
• Guiar al estudiante
Obtener información del • Formular preguntas
nivel, calidad y necesidades • Analizar respuestas
de la enseñanza/aprendizaje

• Ejecución de acciones
• Supervisión de actividades
• Corrección de errores
• Repetición de actividades
Recursos educativos
 Libros
 Radio
 Cine
 TV
 Computadoras

 Siguiendo los pasos de Gutenberg:

 conservación y transmisión del conocimiento
+
 exploración + creación
 Roles de la computadora
en la educación
La computadora expone contenidos,
propone prácticas y ejercicios, evalúa
y retroalimenta al usuario.

La computadora se convierte La computadora personificada

en calculadora, simulador, por un avatar hace lo que
reproductora de videos, el usuario le indica; puede
medio de comunicación, etc.
Tutor calcular, dibujar,
ejecutar algoritmos, etc.

Herramienta Aprendiz
¿Cómo se hace el
software educativo?
¿Quién lo hace?
 Grupo multidisciplinario
 Responsables del contenido
 Diseñadores de interfaces y diseñadores gráficos
 Especialistas en producción de medios (audio, video,
etcétera)
 Ingenieros de software
 Editores
 Psicólogos y Pedagogos
 Desarrolladores ?
 Diseñadores =
 Profesores entusiastas
¿Cómo se hace?: enfoques
 El software educativo es software, por lo que
debe hacerse como cualquier
proyecto/producto de software (n procesos aka
RUP, Agile, etc.).
 El software educativo es un ente multimedia,
así que hay que hacerlo como se hacen los
productos multimedia (planeación, diseño,
producción y validación).
 El software educativo es un objeto de
aprendizaje, así que hay que hacer mapeo de
información, diseño instruccional y después que
se hagan los contenidos y la presentación.
 Factor clave: creación del
concepto
 En el contexto del ciclo de vida del Mantenimiento
software hay 3 etapas críticas que definen
Operación
el éxito de un sistema:
 Planeación, donde se establecen las Pruebas
metas del sistema Integración
 Análisis de requerimientos, donde se
Construcción
transforman las metas en las operaciones
que realizará el sistema y se analizan los Diseño
requerimientos de información del usuario Requerimientos
 Diseño, donde se describen a detalle las
Planeación
características y operaciones del sistema
(interfaz, reglas, procesos, etc.)
 ¿Cómo lograr un mejor
aprendizaje?
 Uso de metáforas para
la enseñanza-
aprendizaje
 Aprendemos mejor con
ejemplos del mundo
real.
 La computadora es un
medio excepcional
para implementar
metáforas interactivas.
 Metáforas y roles

Centro de
Laboratorio Explorador Vivero
Ecosistemas Medicina
solar geográfico electrónico
Deportiva

•Estación espacial •Zona de •Estación •Reserva •Enfermería

Metáfora •Estación terrestre exploración climática ecológica •Gimnasio
•Observatorio •Taller de mapas •Vivero
solar

Geógrafo, Geógrafo, Agrónomo, Biólogo , Médico ,

Roles viajero cartógrafo campesino Zoólogo, entrenador
ecologista
 Modelos de interfaz clave
Modelo
s de los Modelo de Modelo de
usuario diseño implementación
s

Entidad Entidad

Entidad

•Creencias
•Cosas •Estructuras de datos
•Metas
•Apariencias •Algoritmos
•Emociones
•Interacciones •Librerías
•Supersticiones
 Meta
Modelo conceptual Modelo conceptual
Modelo de diseño

= Mercado Comerciante =
deduce deduce

Mercancía

Usuario Usuario

Observa Observa
Hacia una fábrica de
software educativo
 Visión 2003
Especificaciones

Programas Área de desarrollo

académicos de software educativo
Prototipos

Versiones
liberadas

Centros Galileo
Instituciones
educativas
 Proceso de desarrollo de software
educativo
(propuesta 2003)

Producto
(sw, manuales)
Prototipo(s)

Especificación

Modelo Interfaz

Evaluación

Entorno
Estimación
educativo
 Organización del área de desarrollo
de software educativo

Equipo Delphi Equipo .Net

•Elementos de UI
•Imágenes
•Ilustraciones
•Audio (locuciones)
•Animaciones
Equipo de •Presentaciones
producción de •Videos
contenidos
 Cronología del proyecto
Normalización
(4 meses)

CMD LE

A-3D VE EEQ

CMD ECO MP MP KMX

CP KMX EEQ ECO PG

MM LFv3
LE PG LEn
LE LGA LEn Electro
TES
VE
C64 TEG CMD LF LFv2 VSE

Marzo, Septiembre, Noviembre, Noviembre, Noviembre, Enero, Diciembre,

2003 2003 2003 2004 2005 2007 2007

Java / EJS VS 6 VS .Net

Prototipos Galileo/ILCE Galileo Pepsico Productos: 12

2003-2005
 Factor clave: comprensión
del contexto
 El factor que más importante en el desarrollo de una
solución exitosa es la comprensión del contexto del
problema.
 En el caso del desarrollo de productos educativos de
software, el contexto se amplía en dos direcciones:
 el área de conocimiento y los temas específicos para los
cuales el sistema debe proveer una solución de cálculo y
visualización;
 los aspectos pedagógicos que deben implantarse en el
sistema para promover observaciones, actividades y
experimentos que tengan sentido para los que aprenden
y les permita generar nuevos conocimientos.
 Solución propuesta
 Inducción del equipo de
 Desarrollo y aplicación de un método que
trabajo al contexto
pedagógico
 Marco teórico de referencia:
 Proceso educativo
 Teorías del aprendizaje
 Teorías de la instrucción
 Diseño curricular
 Diseño instruccional
 Fundamentos de la
tecnología educativa
 Desarrollo de instrucción
basada en computadora
 Desarrollo de recursos
multimedia
EISE
permita definir los requerimientos de
dominio a manera que la especificación
pueda plasmar:
 La estructura del área de conocimiento a
explorar.
 La estructura de los planes de estudio del
área de conocimiento del nivel
académico correspondiente.
 Las actividades que estudiantes y
profesores realizan.
 Los materiales instruccionales de soporte
existentes y los que se tendrán que
desarrollar.
 Los conocimientos previos del
estudiante.
 El planteamiento de una metáfora.
 La aplicación de patrones pedagógicos y
estrategias de aprendizaje.
 Aplicando EISE

EISE

EISE
2005
Casos de estudio
 “Remake” de una idea ya
existente (1)
 Al principio del proyecto, se optó
por retomar algunos de los
productos que se hicieron en el
proyecto Galileo I.
 El proyecto insignia fue Mosaicos
Mágicos, cuya metáfora se basa
en los hornos donde se hacen los
mosaicos en las alfarerías y con
estas pequeñas piezas se arman
murales.
 La última versión de este
producto era para PCs 8086, y se
rehizo para computadoras
actuales (Windows).
 Mosaicos

Mosaicos Mágicos:
 Manipulación de objetos
geométricos sencillos
 Formas generales: Triángulos,
rectángulos, rombos,
hexágonos, líneas y círculos
 Subconjuntos de las formas
generales y colores.
 Creación de mosaicos con los
objetos
 Construcción murales con los
mosaicos
 “Remake” (2)

 Aunque la idea, la metáfora y todo

estaba listo, el problema fue crear
una interfaz de usuario que
convenciera.
 La vista de interfaz que más cambios
sufrió fue la pantalla de inicio, pues
al principio no tenía;
 luego se propuso que fueran los
edificios de un pueblito los elementos
de selección a las salas.
 Y luego se propuso que fuera la
entrada de una galería modernista.
 Evolución de una idea ya
existente
 Uno de los proyectos que se
transformaron totalmente de su versión
original fue el ahora Laboratorio Espacial.
 La interfaz de usuario, los instrumentos y
el alcance del simulador, limitados por la
tecnología de su tiempo, se transformaron
radicalmente para ofrecer una experiencia
mucho más completa.
 Aquí el dolor de cabeza fue la
dependencia del área de diseño con
respecto a los detalles de interfaz. El
mínimo cambio de color o tamaño,
implicaba mover elementos a tiempo de
diseño del programa, y a veces esto
causaba problemas.
 Incluso meses más tarde se descubrieron
limitaciones en el soporte de formatos de
imágenes de VB6, que causaba que los
JPGs causaran caídas del programa sin
razón aparente en sistemas con Win 95 y
98.
 Evolución (2)

 De hecho, el LE fue junto con

Mosaicos, de los primeros
programas que se retomaron de
manera informal antes de que
TEG iniciara operaciones.
 El primer prototipo se hizo con
Excel. Ya que se afinó el modelo
de simulación, el primer prototipo
funcional se hizo con Java.
 Metamorfosis de un concepto
previamente planteado

 Uno de los programas que se

quiso rehacer fue el Sistema
Cardiovascular.
 Pero al evaluar la metáfora y el
modelo se replanteó el contexto, y
en lugar de un entorno de
laboratorio, se opto por
relacionarlo con el deporte y el
cuidado médico.
 La metáfora principal sigue siendo
“jugar al doctor”
Metamorfosis (2)
 Uno de los principales retos de este
programa fueron la interacción y una
visualización que resultara atractiva y
entretenida.
 Por primera vez se tuvieron que producir
animaciones (primero 2D y luego 3D).
 Fue el primer sistema en adoptar videos
como complemento a los conceptos
planteados. Ese solo hecho represento el
desarrollo de soporte para la reproducción
de formatos AVI y MPEG.
Proactividad interna
 3 de los productos han surgido
de esfuerzos internos. Los
laboratorios de funciones y
geometría analítica y el
planetario de Galileo.
 Funciones surgió a partir de un
prototipo que se hizo para
cálculos internos del modelo del
CMD.
 Geometría analítica surgió de
una charla, y con la
infraestructura de funciones se
hizo.
Proactividad (2)
 El planetario surgió por un modelo de física
que se estaba probando, que se conjunto
con unas pruebas de 3D que hacíamos con
DirectX.
 Al final el producto se hizo con OpenGL,
gracias a las pruebas de concepto
realizadas para el Explorador Químico
(modelos atómicos).
 No siempre funciona: Teselmania se
planteó como un producto promocional,
pero el regalar software “NO es parte de la
filosofía de la empresa”.
La madre de todas las
normalizaciones
 En 2006, se nos planteó el reto de hacer nuevas
versiones de los productos desarrollados durante 2004
y 2005.
 Las directrices de este esfuerzo fueron:
 Unificar los elementos de UI, de manera que el
usuario de productos Galileo no tuviera que
reaprender el uso de ciertas funciones comunes.
 Agregar soporte de inducción al producto.
 Agregar soporte de contenidos adicionales.
 Unificar documentación y ayudas.
 Unificar el look & feel de las aplicaciones.
 Mejorar algunos aspectos de cada uno de los
productos.
Normalizaciones (2)
 El proceso de normalización incluía:
 10 productos desarrollados en 2004
 4 productos desarrollados en 2005

 Todo debía estar terminado en 10 meses.

 A tomar en cuenta:
6 productos hechos en Delphi
 1 en C++
 5 en VB6
 2 en VB .net
Normalizaciones (3)
 Decisiones importantes:
 Unificar plataforma de desarrollo (.Net =
mejora en mantenimiento)
 Unificar elementos de interfaz (framework UI
= no mas pleitos con los diseñadores)
 Unificar infraestructura de ejecución (MVC =
simplificación en el desarrollo)
 Pruebas de funcionalidad básica (1 vez =
mejoras permeadas a todas las
aplicaciones)
 Revisión, pruebas y ajustes de
los productos de software
educativo
Criterios de
normalización Nuevo
UI mapa de UI

Sw

Mapa de UI
y casos Cambios UI Aplicar
Revisión
de uso modificaciones

Pruebas

Casos de Listo para

pruebas Pruebas Cambios revisión de
para el aceptación
producto

Aceptación
Karel MX: transformación
v.1 a v.2
Los deseos del cliente
 Vive Saludable Escuelas nació por el interés de
Pepsico en el trabajo de Galileo.
 Primero se ofreció una versión modificada del CMD (el
cliente quería algo así, pero no exactamente eso).
 El equipo se apropió del concepto y necesidades del
cliente, y se creó el primer EDUTAINMENT Galileo.

 Solución= Juego + Simulación

 La meta fue hacer un juego educativo, y se logró 

Modelo del sistema

•Edad
Condiciones •Altura
Entradas
iniciales •Peso
•Condición física
(resistencia) Alimentación

Cálculo de la
asimilación
de energía

Cálculo del
consumo
de energía

Actividad
•Peso física
•Energía Interactúan:
•Resistencia -Experimentando
•Balance energético
-Midiendo
-Planeando
-Consultando
Simulador
 Software Vive Saludable Escuelas: Mecánica
Estudiante Nutrín
-Le da un nombre
-Define sus características:
-Edad
Crea personaje -Peso
virtual -Altura

Procura:

-Alimentarlo
Juega (experimenta)
-Mantenerlo activo
-Llevarlo al médico

Información nutricional bajo el Promoción de actividades Retroalimentación del estado físico del
concepto de “El Plato del Bien Comer” recreativas y deportivas personaje y el impacto de sus actividade
Para reflexionar
Tantos detalles y tan poco
tiempo
 Plataformas de desarrollo
 Escritorio
 Web
 Entorno de ejecución
 Objeto de aprendizaje aislado
 Integración de objetos de aprendizaje
 Contenidos
 Texto vs video - el dilema del ancho de banda
 Temáticas
 Oficiales – aceptado por la hegemonía
 Alternativas – lo que en realidad necesitamos saber
 El modelo de negocio
 Economía de intercambio
 Cajas para todos. Software monousuario, de plataforma específica,
empaquetado. Para usarlo hay que activarlo.
 Venta en línea. Se ahorra en el empaque pero se invierte en el
servicio de venta y postventa en línea.
 “Economía del regalo” (gift economy)
 El software se regala.
 El negocio está en los servicios y productos alternos (memorabilia,
versiones especiales).
 La comunidad se involucra en el desarrollo
 Software como servicio (SaaS)
 Acceso web
 Venta de subscripciones
 El usuario puede probar a usar todo lo que hay, no solo un
producto.
 Solo se paga por el tiempo que se usa, no una licencia eterna.
 Se mejora el mantenimiento y la calidad.
En conclusión: hacer realidad una idea es
difícil, pero no imposible; y que además
permita aprender, implica vencer un nivel
más de complejidad.