El paradigma del cambio de tecnología en plataformas de educación a distancia

Reflexiones académicas

Share on FacebookShare on Google+Tweet about this on TwitterEmail this to someonePrint this page

El paradigma del cambio de tecnología en plataformas de educación a distancia

M. en C. César Sánchez Vázquez del Mercado*
Ing. Sarah Hernández Pérez**

Resumen

La construcción de plataformas de educación en línea
representa un reto para todas las instituciones educativas que se han
aventurado a construir y liberar una. La problemática principal se
centra en la importancia de una buena comunicación y el trabajo
integrado entre la infraestructura tecnológica y la académica.
Presentamos la experiencia de la Coordinación de Bachillerato a
Distancia de la UNAM, en la implementación de su propia plataforma, el
crecimiento de ésta y en la problemática que se está resolviendo para la
migración y la actualización tecnológica constante, a fin de mantener
su nivel de calidad y producción en un ambiente flexible y utilizando
metodologías ágiles de desarrollo multidisciplinario.

Palabras clave: Migración
tecnológica, Plataformas, LMS, metodologías ágiles.

 

Abstract

Building platforms for online education constitutes a challenge for all institutions that have chosen that endeavor. The main issue is to have good communication and an integrated work between the academic and technological teams. In this text we present the experience at UNAM’s Coordinación de Bachillerato a Distancia while implementing and evolving its own platform. It includes a description of the process to migrate and permanently update it in an effort to preserve its quality and production capabilities with flexibility and using agile, multidisciplinary, development methodologies.

Key words: technological migration, platforms, LMS, agile methodologies.

 

Planteamiento: Problemática de la tecnología
en la educación en línea

Cuando se planea, desarrolla e implementa la
infraestructura  para construir una plataforma para educación en
línea  se enfrenta la alternativa de dar más peso a la parte
académica o a la tecnológica. Hacer una evaluación correcta 
resulta complejo,  pues no existen fórmulas probadas, pero
comúnmente se tiende a resolver todo por el camino de la
tecnología  en primer lugar.  Entonces, se selecciona la mejor
calidad en equipos de cómputo,  se contrata el mejor enlace a
Internet; al equipo de ingenieros más capacitado y se adquiere el
software de última generación o el que ha funcionado mejor en 
experiencias similares. Se integra en las mejores instalaciones, y sin
embargo, no se logra lo esperado o, a veces, ni siquiera puede arrancar
el proyecto.

En otro extremo, puede optarse por darle el mayor peso
al desarrollo académico a distancia dejando en segundo término la
cuestión del hardware, software e Internet, asumiendo que son sólo
servicios de apoyo en torno a la generación de contenidos en línea.
Aquí, la formación de profesores, la producción de materiales y la
administración escolar  forman el primer plano para la construcción
de la llamada plataforma. Como consecuencia,   en
algún momento,  a corto o mediano plazo se creará un abismo
operativo entre la administración académica y la infraestructura
tecnológica: los académicos exigirán seguir haciendo las cosas como las
planearon, mientras los expertos en tecnología no podrán ofrecer
soluciones, porque hay conflictos con los sistemas  y  el
peligro del colapso aparece.

Las tendencias de desarrollo de sistemas pueden ser
inflexibles ante la necesidad de generar modelos para la educación en
línea. De la misma forma, no es posible bosquejar todo el esquema de
operación, planeación, y administración de la educación y el
conocimiento en un ámbito escolar,  sin una adecuada evaluación
de alcances y necesidades  tecnológicas. Aquí es donde debería
quedar clara la magnitud del concepto plataforma de educación en
línea y a distancia:
no es un grupo de servidores, ni el programa
instalado para impartir materias e inscribir alumnos; no es un portal
de acceso, tampoco la plantilla de usuarios, ni los contenidos
elaborados, ni los profesores conectados, ni los alumnos. Una plataforma es el concepto integrador que debe incluir estas dos partes sin
conficto: infraestructura tecnológica e infraestructura 
académica. 

El presente artículo habla de la experiencia que se ha
tenido en el Bachillerato a Distancia de la UNAM (B@UNAM) para lidiar
con esta dificultad, desde el punto de vista de los responsables de
tecnología y cómo se está reconformando la operatividad para lograr una
mejor planeación, integración y, por consiguiente,  mayor éxito
en su implementación al conceptualizar de manera integral 
la  plataforma educativa.

La infraestructura tecnológica en el
Bachillerato a Distancia de la UNAM 

Los contenidos del Bachillerato en Línea de la UNAM,
B@UNAM fueron liberados por primera  vez en 2007.  La primera
generación atendida  constaba de 19 alumnos. En su planeación se
decidió darle la mayor importancia a la formación docente y a la
calidad en  la producción de contenidos,  mientras que las
soluciones de servidores, software e Internet eran servicios prestados
por la Coordinación de Educación Abierta y a Distancia de la UNAM
(CUAED), en tanto la demanda no creciera demasiado. 

Además de de contar desde el principio  con
servidores de buena capacidad y un enlace a Internet con velocidad
suficiente, había que seleccionar un software. Esto es lo que de manera
incorrecta se denomina plataforma pero cuyo nombre genérico
para el área educativa es LMS (por sus siglas en inglés: Learning
Management System
). Para lograr una implementación así  se
manejan dos tendencias opuestas: asignar a un grupo de programadores la
construcción de una plataforma ad hoc al modelo curricular
diseñado, o bien seleccionar entre las plataformas existentes –libres o
comerciales-  alguna que pueda ajustarse lo mejor posible a las
necesidades académicas. 
Las experiencias en trabajo con LMS en la UNAM han sido
las siguientes:

a) El desarrollo de un LMS a la medida para el
plan curricular y los contenidos.
Se han tenido experiencias
previas, tanto en el ámbito de innovación tecnológica de CUAED, como en
casos de estudio en escuelas y facultades de la UNAM, Los recursos
humanos asignados a la arquitectura de la plataforma no lograron la
interacción adecuada con los diseñadores del plan curricular que debido
a su dinamismo exigía frecuentes cambios en el software. 
Como  los cambios eran tantos,  resultaba  imposible
lograr una versión estable. Además, cuando  se lograba, el costo
era alto, o el tiempo de desarrollo largo. Esto ocurría, entre otras
razones, porque un programador  por sí solo no tiene la capacidad
tecnológica para  diseñar un sistema de esta magnitud; para ello
se requiere del apoyo de líderes de proyecto que puedan hacer una
arquitectura e integración correcta y también un pronóstico para darle
un tiempo de vida y actualización adecuado al software, a medida que las
condiciones de los usuarios van cambiando con los años. Sin embargo,
por su costo, esta opción resultaba   poco viable.

b) El uso de un LMS prefabricado. Existen
numerosas compañías que ofrecen soluciones  de este tipo. Si una
herramienta resulta equivalente al modelo que se pretende implementar
será la mejor opción, aunque la inversión sea alta. Finalmente todas
las instituciones educativas le asignan intrínsecamente un alto valor a
la educación.  No obstante, en B@UNAM, dada la hiperactividad de
sus académicos en la conformación de los planes de estudio,  fue
imposible encontrar una propuesta comercial que se ajustara a dichas
necesidades, y además no queríamos pagar el alto costo inicial y a
futuro. Se eligió, entonces,  el camino del software libre, con
el que se tenía la libertad de modificar el código para personalizarlo a
la medida, con menor costo. Los recursos humanos requeridos,
comparados con empezar desde cero, resultaban  significativamente
menores.
De esta manera,  siguiendo la tradición del uso
de software libre que tiene la UNAM, se decidió incorporar como
plataforma base el sistema Moodle.

Así, se liberó la primera versión en línea del modelo
curricular de B@UNAM, con contenidos de alta calidad, haciendo una
modificación de la versión 1.6.4  de Moodle de  junio del
2006,  en torno a un intenso trabajo académico y de producción,
con excelentes resultados, como lo son el uso óptimo para el modelo que
fue implementado en ella, capacidad para actualización constante de
contenidos,  un adecuado soporte técnico y inicio de su uso en
masividad. Además de un alto índice de aprobación en los alumnos, y la
capacidad de soportar toda la infraestructura de gestión académica que
la caracteriza.

 

Análisis de alcances del desarrollo de un LMS
ajustado a B@UNAM

Para operar la plataforma en el modelo del
bachillerato a distancia diseñado por el grupo académico de la UNAM fue
necesario ajustar una serie de alcances no presentes en la versión
original de Moodle:

  • Rediseño de interfaces: la versión
    natural 1.6  se  presenta al usuario como un área dividida en
    tres secciones: un encabezado,  barras de herramientas laterales,
    y un área central, dividida en secciones que bien pueden representar
    semanas o temas. Cada sección contiene “contenidos” o “actividades”,
    pueden ser  materiales que se van a revisar o tareas variadas que
    generarán calificaciones que van a ser administradas por el LMS. 
    Como los contenidos de cada asignatura fueron hechos ex profeso, era
    necesario ocultar este escritorio y mostrar sólo el diseño del
    contenido del programa didáctico de cada curso, elaborado en html y
    flash,  utilizando  únicamente cuatro de las nueve
    actividades existentes en esa versión: carga de archivo,  examen,
    chat y foro. Entonces, fue necesaria una reconstrucción que permitiera
    subir todo este material e integrarlo en un escritorio de tres niveles,
    iniciando con el portal, que sería operado como si así hubiera sido
    diseñado de origen.
  • Implementación de ponderación de
    calificaciones;
    fue  necesario recalcular cada calificación
    administrada por el LMS con un peso diferido, que representara
    una fracción porcentual, de  manera que el conjunto de
    calificaciones no fuera promediado con base en el total, sino
    multiplicarlo por una fracción decimal que sumara 100 o bien que no
    valiera  nada (al multiplicar el resultado por 0).
  • Tabla general de calificaciones: para que
    los coordinadores, asesores y tutores pudieran trabajar mejor y
    realizar el seguimiento de los alumnos,  era fundamental  que
    cada perfil (véase siguiente punto)  tuviera en una sola
    pantalla la matriz que presentara a cada usuario, cada actividad y cada
    calificación; además de promedios y estatus. también era indispensable
    que cada intersección contuviera un vínculo que le permitiera hacer
    modificaciones, como agregar comentarios o asignar calificaciones. Esta
    tabla implicó grandes retos, pues exigía un número exponencialmente
    creciente de consultas a la base de datos. Esto  la hizo poco
    práctica cuando el volumen del  proyecto creció.
  • Roles específicos: se crearon los roles
    de alumno, oyente, asesor, tutor, coordinador y administrador escolar.
    Como la versión natural de Moodle sólo manejaba los roles de alumno,
    invitado, profesor y administrador, que no cumplían con las necesidades
    de B@UNAM,  ni tenían el acceso que se requería fue necesario
    hacer cambios. Al modificar roles, también hubo que solicitar 
    interfaces modificadas para cada uno de ellos.
  • Versiones y asignación de exámenes: la
    versión natural de Moodle 1.6 no maneja el concepto de examen final que promedie su calificación con el resto de los 
    promedios. Por ello, se propuso la modificación de la ponderación
    mencionada en párrafos anteriores, asignándole un valor uniforme a
    todos los exámenes finales de 40% con respecto a la calificación final.
    Dada la preocupación de que los alumnos pudiesen copiar durante la
    aplicación de exámenes presenciales que se realiza en las computadoras
    de las sedes, se solicitó a la parte de sistemas y desarrollo hacer
    versiones con asignación aleatoria.  Dicha solución se implementó
    de manera parcial y muy insegura, puesto que requirió darle un
    tratamiento especial a los archivos que explotaban actividades del LMS y
    tuvieron permanentes conflictos con otras modificaciones como la tabla
    de avance, ponderaciones y los roles. No era posible ocultar los
    URLs  de los exámenes asignados en el navegador, lo que
    permitía  predecirlos y abría  un severo problema de
    seguridad.

A pesar de los conflictos que representó para la parte
de sistemas y desarrollo, la operación de esta versión de LMS, muy
modificada  y  alojada en las instalaciones de CUAED, ha
sido  productiva y exitosa durante sus inicios  por las
siguientes razones:

La plataforma propiamente dicha tiene dos grandes
áreas de competencia que lograron operar en sincronía. Por un
lado,  la parte académica  mantiene un esquema constante y de
alta calidad de retroalimentación de los asesores, modificando
contenidos, ajustándolos, formando profesores y manteniendo un esquema
administrativo impecable.  Por el otro, la parte tecnológica tuvo
la flexibilidad  para ajustarse a las exigencias curriculares,
con costos razonables. Además  se contó  con  la
infraestructura de servidores y de soporte técnico bien definida 
de la  CUAED, así como con una buena elección de las opciones de
LMS  y  la continuidad de los  programadores que
hicieron la modificación a partir del Moodle natural. Todo esto nos
permite comprobar que ha sido un gran acierto seleccionar el uso de
software libre y con licencia   para usos académicos, pues
permitió reducir costos sin mermar estabilidad y eficiencia.

 

Situación actual

En la actualidad,  el proyecto de B@UNAM 
sigue operando con los mismos alcances con los que fue liberado en
2007. Sin embargo, han cambiado tres condiciones que ya amenazan al
éxito de la  plataforma:

  • Primera: un proyecto masivo para el Gobierno del
    Distrito Federal, y alojado por el momento en CUAED, que soporta ya a
    más de seis mil alumnos en los Cursos propedéuticos, y cinco  mil
    en asignaturas de manera simultánea.
  • Segunda:  dado el volumen y el éxito que ha
    tenido el Bachillerato, el plagio de contenidos y exámenes ya
    representa una fuerte amenaza para la evaluación escolar.
  • Tercera: a dos años de haber iniciado, ya se están
    cursando las 27 asignaturas y cinco optativas de los cuatro bloques del
    currículo, lo que hace muy intensivo el proceso de actualización y
    retroalimentación de contenidos.

A continuación describimos las acciones que se han
tomado para enfrentar estas problemáticas: 

  • Masividad. La problemática comenzó hace año
    y medio aproximadamente, al empezar a tener momentos de falla de
    servicio en los portales. No se trataba  de  llevar a cabo
    una simple acumulación de servidores, pues  aún con 
    equipamiento más potente el el problema no se resuelve del todo. 
    Entonces, el LMS, y la base de datos  se empezaron a  a
    manejar a través de  balanceadores de carga. Esto es, se
    instalaron cuatro servidores idénticos, sincronizados, que se repartían
    entre ellos a los usuarios y su carga, dando la imagen de que era uno
    solo para todos. Un análisis más profundo y una proyección a futuro nos
    hizo concluir que es una solución adecuada, pero  la
    problemática real es   que con las modificaciones hechas al
    LMS hace dos años ya no es  capaz de soportar más crecimiento.
  •  Actualización de contenidos. El
    esquema con que actualmente se trabaja, actualizando y diseñando
    contenidos de manera directa  y única con académicos, ya no
    está  siendo óptimo al atender  el total de las asignaturas
    del plan de estudios, más las materias optativas, nuevos cursos y
    tutoriales.  Además de los proyectos masivos como el GDF, se
    atienden a otros 18 proyectos más. Con el anterior esquema de trabajo
    era imposible mantener todas las asignaturas actualizadas y sin
    errores. Debido a que los contenidos requieren ser revisados y
    actualizados constantemente, se ha generado un conflicto severo con la
    integración en los servidores, al no contar con estándares como la
    nomenclatura de archivos, el control de versiones, el control de
    calidad, los respaldos y la integración al LMS de manera sistemática.
  • Seguridad.  Dado que el factor humano
    se encuentra muy involucrado, ésta resulta la variable más compleja de
    resolver. Se ha  propuesto  la incorporación de exámenes
    aleatorios, pero no versionados, con un banco de reactivos extenso e
    independiente del LMS. Ya se tienen trabajando cuatro propuestas con
    resultados variados. Se tendrá una versión productiva en julio de 2010

 

Experiencia en las implementaciones
tecnológicas en B@UNAM

Una de las condiciones que ha garantizado el éxito en
los programas de B@UNAM es la adecuada intercomunicación y la
flexibilidad en la operación entre los equipos de trabajo. El análisis
concreto de las problemáticas, a partir de que fueron detectadas, ha
permitido ir ajustando las dinámicas de operación de manera gradual y
bien dirigida. Se ha visto que las condiciones que determinaron el
éxito y permitieron aprovechar las oportunidades de nuestro programa
han estado cambiando, pero aunque  existen amenazas,  ahora
tenemos capacidad de acotarlas.  Era evidente la necesidad de un
cambio y mejora tecnológica para todo el proyecto, de tal manera que
para el área tecnológica de BUNAM se propusieron  las siguientes
soluciones:

a) Masividad: el  balanceo de
servidores ha probado ser una herramienta determinante en la mejora del
servicio. Junto con ello, es necesario actualizar el  LMS, y no
hay razones para dejar de pensar en Moodle como la mejor opción,
considerando que la problemática que en su momento resolvimos ya fue
incorporada a las nuevas versiones, en especial, la optimización de
bases de datos, la ponderación  de exámenes y la creación dinámica
de roles.

b) Diseño y actualización de contenidos: ha
sido preciso cambiar la mecánica de trabajo entre la integración,
actualización y  migración de contenidos, así como la forma de
detectar y corregir fallas. Esto ha dado lugar a la planeación de una
línea de producción que seguiría bajo la coordinación de los académicos
pero con control y seguimiento sistematizado por parte del área
tecnológica.

c) Seguridad: debido a su filosofía de
diseño, Moodle no le da la importancia a la normatividad educativa
nacional en materia de exámenes, por eso es preciso definir una serie
de herramientas autónomas para manejar bancos de reactivos de manera
aleatoria y taxonómica. Aunque, por necesidades de sus usuarios, 
Moodle ofrece ya algunas de estas herramientas,  existen otras más
que pueden aportar comunicación transparente con nuestra plataforma en
general. En este caso, es necesaria la actualización de versiones de
Moodle, sin embargo, resulta  problemática debido a que la
versión  que está operando  ya no tiene nada que ver con la
original, por lo tanto,  ya no puede hacerse de manera natural.

 

Cómo se hizo el proceso de actualización
tecnológica

Para iniciar la migración tecnológica se hizo un
comparativo de alcances entre la versión operativa Moodle-B@UNAM y la
versión actualizada 1.9.3, a fin de conocer con exactitud con qué
prestaciones contábamos y con cuáles ya no.
Los resultados se presentaron ante el grupo académico. A
la fecha, tenemos ya  más del   90% de
prestaciones  implementadas; con las funcionalidades restantes y
con base en la experiencia y ya operando el bachillerato en la versión
actual, se acordó hacerlo en sentido inverso al inicial: ajustar la
operación académica al modelo, y no al revés. Desde luego, se
definieron  los casos excepcionales y mínimos en los que no se iba
a poder.

Fueron tres alcances los que no se pudieron ajustar de
manera idéntica a los requerimientos iniciales en la versión 1.9:

a) Los contenidos: La capa de diseño gráfico de los
materiales de estudio en línea cubre la interfaz natural de la
plataforma, y muestra las actividades que se han de evaluar a través e-frames diseñados para tal efecto. Esto requiere hacer algunos ajustes mínimos
sobre los elementos que han de mostrarse. En la versión 1.9 existen más
opciones de configuración y botones. Además de que algunas actividades
como foros, wikis y talleres, ya tienen más funcionalidades. Muchas de
estas opciones fueron usadas tal y como están. El alumno no percibe
cambios. Pero los demás usuarios tienen más opciones y tienen acceso a
la interfaz natural.

b) Roles: En la versión inicial, se tenían
contemplados siete perfiles de usuarios: Alumno,  Oyente, 
Asesor, Tutor, Coordinador, Administrador Escolar, y Diseñador Gráfico.
La versión natural 1.6 no los contemplaba con todos los requerimientos
del Bachillerato. Para la versión 1.9  ha sido posible ajustar
los roles de manera dinámica, permitiendo mayor flexibilidad, y sin
modificar el código base del LMS.

c) La parte más compleja de resolver ha sido la
aplicación de exámenes  en  línea. Para muchas teorías sobre
la evaluación del aprendizaje el someter a los alumnos a sesiones donde
deban responder una serie de reactivos es  criticado,  pues
consideran que  no aportan una medida real de las competencias o
conocimientos que van adquiriendo. También se señala que es una
herramienta de la educación presencial, que se ha forzado hacia la
educación en línea y que es un lastre para la innovación, entre otras
cosas, aunque la legislación educativa en los sistemas nacionales lo
requiere. Está,  finalmente, la cuestión de la seguridad y la
confiabilidad del instrumento, que además de incluir variables numéricas
de confianza, requiere medidas para evitar plagios, copia y falta de
control.

La realidad es que la evaluación del aprendizaje
usando esta herramienta tiene mucho trabajo detrás, buscando 
determinar  no sólo la capacidad memorística del alumno, sino su
capacidad de análisis, síntesis y abstracción, que permite 
someterlo  a escenarios donde la resolución es controlada y
rápida. Para esto, los reactivos que integran un examen deben someterse
a constantes ponderaciones estadísticos, revisiones y ajustes. Un buen
examen requiere calibración constante y activa por parte de los
creadores y administradores del mismo.

Todos estos elementos deben estar conformados en un
modelo de datos, capaz de ponerse en línea   y  ser
integrados de manera natural con nuestra versión de Moodle, con los
siguientes elementos:

  • Contar con un banco de reactivos dinámico y
    confidencial,  con posibilidad de ser revisado por los autores y
    administradores;
  • Tener flexibilidad para que este banco genere de
    manera aleatoria y calibrada por niveles de confiabilidad,
    discriminación y dificultad exámenes en línea integrados a la
    plataforma;
  • Contar con un examen que, una vez aplicado, regrese
    la calificación a las tablas de actividades, en este caso de Moodle;
  • Asegurar que, además de calificaciones, retorne
    datos estadísticos de uso y calidad del reactivo, para seguir ajustando
    el banco; y
  • Tener evidencia de que sea razonablemente seguro,
    protegido contra plagio, suplantación y ataques.

 

Aunque Moodle en sus versiones más actualizadas cuenta
con una herramienta significativamente robusta para lograr todos estos
requisitos, aún se evalúan  opciones comerciales y desarrollos
locales específicos, para dar mayor validez al instrumento que los
estándares actuales, dada la importancia y el peso que la parte de
administración escolar da a este tema  en los sistemas nacionales.

Nuestra primera migración tecnológica ya ha sido
puesta a prueba en un curso en producción,  con pocos 
usuarios y  está operando con éxito.
 
Todo este trabajo de integración y actualización
tecnológica ha requerido una reconformación de los criterios de
comunicación,  retroalimentación y seguimiento del trabajo de
producción de contenidos entre los grupos de diseño gráfico y diseño
instruccional de B@UNAM, que normalmente tenían contacto solamente con
la parte académica. De todo esto se ha generado la documentación
pertinente, para cumplir con la presentación de manuales operativos,
que  permitan oficializar  nuestros cambios de estándares y
ajustes.

Finalmente,  hemos utilizado para ello
metodologías ágiles, en particular la denominada SCRUM,  que nos
han permitido avanzar y desligarnos de la versión 1.6  y sus
problemáticas en año y medio. Podremos hacer el reemplazo de tecnología
a todos los proyectos que operamos antes de que finalice 2010 y
gracias a  una adecuada documentación, migrar con agilidad a las
versiones que se vayan liberando, por lo menos una vez al  año en
menos de 15 días por evento. Hemos logrado reformular nuestra operación
y mejor integración con el área académica, abriendo oportunidades para
más innovación, desarrollo  e Implementación de tecnologías
adicionales.

 

Conclusión

Es todo un reto  diseñar la fórmula más
equilibrada, económica y eficiente para iniciar y mantener con éxito un
proyecto tecnológico de educación en línea. Una vez que se ha puesto
en marcha y se obtienen los primeros productos, resulta una experiencia
sumamente satisfactoria.

Para asegurar la permanencia y el crecimiento del
sistema, no hay que perder de vista que la tecnología, el manejo del
conocimiento  y las tendencias sociales cambian de manera muy
dinámica y,  en el campo tecnológico,  cualquier solución
que aprovecha una oportunidad,  en cuestión de meses  puede
ser el pivote que nos enfrente a una amenaza. Hay que estar preparados
con un área de tecnología que sea institucional y siga lineamientos
organizacionales, pero con la suficiente flexibilidad para ajustar
implementaciones tecnológicas de manera documentada y con seguimiento
formal,  pero sobre la marcha.  La llamada ingeniería de
sistemas por análisis y diseño estructurado
, genera conflictos en
este campo en particular entre los usuarios no familiarizados con el
cómputo. Y se ha probado que no es la mejor herramienta para implementar
sistemas tecnológicos en educación en línea. Para ello, como hemos
relatado, en el Bachillerato a distancia de la UNAM adoptamos las 
llamadas metodologías ágiles. Éstas permiten  perfiles
humanos con  formación multidisciplinaria que pueden manejar este
tipo de proyectos e integrar lenguajes entre ingenieros en sistemas,
gestores de la educación, cuerpos gubernamentales, académicos e incluso
estudiantiles.

Finalmente,  el uso de una plataforma con
resultados exitosos, pero que con el cambio del entorno genera
problemáticas, no implica haber errado el camino,  desmantelar
todo y volverlo a construir. Nos muestra, más bien, que toda planeación
tecnológica debe considerar que  el proceso de implementación y
liberación de un sistema en educación tiene una fecha de inicio, una de
liberación, pero en ningún momento se debe de concluir su desarrollo y
que siempre hay que tener  recursos disponibles para 
cambiar el rumbo rápida y libremente, paro mantener el éxito.

 

* Es  Jefe de Tecnología en el Bachillerato a
Distancia de la UNAM, cvm@unam.mx
** Participa en el  Área de Tecnología en el
Bachillerato a Distancia de la UNAM,  Sarah.@alive.com.mx