En el trabajo anterior he anotado algunas ideas sobre:
- Cuándo se justifica crear un nuevo software educativo.
- La importancia de una metodología para ese desarrollo. Y,
- Las diferentes etapas y actores del proceso.
Ahora me enfocaré en algunas reflexiones sobre los costos y la metodología del desarrollo de software educativo.
Antecedentes.
El desarrollo de software educativo es una solución a un “problema” o “área de oportunidad” en un proceso de aprendizaje. Este desarrollo es recomendable, cuando no tenemos otro recurso o recursos que pueda darnos el resultado deseado. Lo es también cuando contamos con las condiciones para intentar ese desarrollo, entre otras, el tiempo, la expertez, el presupuesto y el equipamiento.
Conviene recordar que el desarrollo va más allá de la programación, pues no es sólo hacer que eficientemente una computadora nos responda ante un programa, sino que dicho programa sea pertinente para alcanzar los objetivos educativos que lo motivan. Gándara hace hincapié en que “el proceso de creación de software” (esto es, de programas nuevos), incluye no solamente la programación (cuando ésta es necesaria), sino la selección de contenidos, estrategias de uso, e incluso la documentación de los programas.» (Gándara 1994a:2). Y sin embargo, esta programación puede no ser siempre indispensable en el desarrollo de nuevas soluciones con software educativo, pues muchas ocasiones con lo ya existente podemos innovar una solución a nuestra problemática.
Etapas.
Un proyecto para el desarrollo de software es finalmente un “proyecto” y por lo mismo su administración sigue las reglas de éste.
1. La planeación es la etapa más importante. Algunos escritores han dicho que el tiempo invertido en una buena planeación se recupera en 10 veces en la ejecución.
Lo primero que tenemos que hacer es Definir el Proyecto. ¿Cuál es el objetivo por el cual lo vamos a desarrollar? ¿Qué queremos alcanzar? ¿Quién o quienes lo van a utilizar? ¿Cuándo lo van a utilizar? En el caso de los proyectos de software a esta etapa se le denomina DISEÑO, y consiste en un documento que describe los objetivos educativos, el usuario y contexto; las herramientas de desarrollo incluyendo la plataforma en la que se trabajará no sólo el desarrollo sino principalmente ya la aplicación.
2. A partir de saber con toda claridad pedagógica e informática adonde queremos llegar, principia el DISEÑO (Planeación). La planeación nos ofrece herramientas que la hacen más clara: Mapas mentales, diagramas y a través de ellas podemos identificar los componentes de la solución definida y sobre todo fijar las ESPECIFICACIONES para cada uno. Estas especificaciones cubren: las de calidad de ese módulo o componente; el tiempo en el cual se deberá alcanzar dicho resultado, el costo del mismo y el responsable o responsables de dicho logro.
En la etapa de planeación, podemos auxiliarnos de herramientas como las gráficas de Gant, el PERT o la Ruta Crítica; que son representaciones que nos auxilian a visualizar con más claridad y uniformidad la secuencia adecuada de las actividades que habremos de seguir para alcanzar nuestro objetivo.
Aquí cabría hacer un comentario sobre la técnica VAN DER MOLLEN GÁNDARA. Ésta es una especie de aplicación de mapas mentales al diseño de software. Se inicia con una “lluvia de ideas” que permite clarificar el proyecto y contar con elementos de planeación y resulta estimulante ya que no hay mapas “correctos” o “incorrectos”. Se puede revisar y repetir cuantas veces sea necesario. Es similar a otras técnicas (B. PAPER, TKJ, etc.) que utilizan papel para escribir ideas o problemas que se van conjuntando en la pared.
Una aportación importante es que evita la crítica prematura de las ideas y para cada ítem hay tiempo límite (3 – 5 minutos como máximo por etapa). Permite 1° Registrar las ideas, 2° Evaluar y seleccionar esas ideas y 3° Detallar para poder costear y calendarizar el proyecto.
En cuanto a los datos generales podemos utilizar el Modelo NOM para enmarcar el proyecto y después detallar cada ítem. La forma de trabajo de esta técnica es atractiva por su lógica, ya que de un tema central, determinamos subtemas o aspectos del tema central y los proyectamos en líneas, como ramas, nombrando cada rama. Después estos subtemas los volvemos a subdividir, limitándonos en inicio a tres niveles para ver el tema en su conjunto; pero dejando la oportunidad de seguir subdividiendo para llegar a todos los niveles significativos en cada rama.
Para cada elemento del mapa (sub-subtema), se define qué medio se empleará y se pone su inicial a un lado. Por ejemplo: T = Texto, M = Música, S = Sonido (narración o efectos), G = Gráfico (imágenes fijas), N = Animación, V = Video; y se determinan en qué ramas o subrayas va a participar el usuario y el tipo de participación y se anota C, para indicar que se requiere un Código en ese lugar.
Algo interesante que enfatiza esta técnica es distinguir cuando se cuenta con los insumos, definiendo entonces el lugar del que se recabarán; o cuando no se cuenta con ellos. Otra ventaja que presenta es llevarnos a identificar la complejidad de desarrollo de las diferentes ramas y señalar tanto la más sencilla como la más compleja. A partir de esta reflexión nos pide identificar cuál es la rama más atractiva no sólo para el desarrollador sino especialmente para el financiador.
En materia del presupuesto nos lleva a dos escenarios: uno óptimo y otro mínimo, restando a las inversiones o gastos aquellos insumos con los que ya cuenta la institución (Y yo agregaría y de los que podemos disponer). Nos lleva también a una fase indispensable: la reconsideración del presupuesto. Para ello, sugiere regresar al mapa mental y determinar si se puede reducir en ambición o alcance el proyecto, ajustándolo a los recursos disponibles y sobre todo a no desanimarnos. El objetivo del ejercicio es prever para evitarse luego sorpresas y desilusiones, en el peor de los casos, pensar en etapas.
Abundando sobre el tema del presupuesto, comparto que uno de los secretos que he encontrado, para contar con un presupuesto correcto es el de identificar, en cada módulo, las actividades con las que se alcanzará el objetivo del mismo. Muchas veces he visto cotizar equipo y software, dejando de lado aspectos indispensables para cumplir una actividad, como la capacitación necesaria, el “site prep” (preparación del lugar en el que se trabajará). Quedando algunas veces con tiempo y capacidad ociosa; o por el contrario, peleándose los diferentes desarrolladores por los recursos y atrasando el avance por una mala planeación basada en “equipos o fierros” y no en actividades integrales.
A partir de revisar diferentes modelos de planeación (administración por objetivos, planeación estratégica, planeación operativa, marco lógico, etc.),he desarrollado un sistema lógico propio. He encontrado que la planeación tiene un sentido sistémico y que depende el corte de la realidad que se haga, la aplicación de los nombres para cada nivel de la taxonomía; pero simplificándolo lo presento de la siguiente manera para sustentar la aplicación del presupuesto.
Así, una vez contando con el:
OBJETIVO, (Qué) éste lo descomponemos en:
METAS, (Qué y cuando) que son partes del objetivo que alcanzaremos en un tiempo determinado. Una vez teniendo éstas, identificamos las:
ESTRATEGIAS, (Cómo) y dependiendo de la complejidad del proyecto, puede haber Políticas, Líneas de Acción u otras categorías dentro de este apartado, que básicamente me dice como alcanzar las metas de mi objetivo.
ACTIVIDADES, (Qué voy a hacer).
En una forma matricial, cada uno de estos elementos, tiene especificaciones, de calidad, tiempo y costo; así como un responsable.
Mientras que las especificaciones de calidad son definidas en un orden descendente, es decir la suma de metas me debe dar el objetivo; la suma de estrategias me debe dar la meta; y la suma de actividades me dan la estrategia. El tiempo y costo, se trabajan de forma ascendente. La suma de los tiempos de las actividades me dan el de la estrategia; la suma de los tiempos de las estrategias, me dan el de la meta y la suma de los tiempos de las metas me dan el del objetivo, salvo por las actividades realizadas en paralelo (en cuyo caso podemos utilizar la ruta crítica).
Algo similar ocurre en el presupuesto: la suma de los costos de las actividades me dan el costo de la estrategia; la suma de los costos de las estrategias me dan el costo de la meta y la suma de los costos de las metas me dan el del objetivo.
Por ello, para poder contar con un presupuesto realista, debemos ubicarnos en nuestra realidad y evitar las dos tentaciones al planear. Considerar que contamos con más de lo que en realidad tenemos o partir de que nada tenemos.
Ambos casos son engañosos. No podemos decir que “contamos” con algo que tiene nuestra Institución, hasta no aclarar que verdaderamente lo podremos utilizar y por la otra parte, la forma más sencilla de que un tomador de decisiones nos diga que no, es pretendiendo quese nos dote de todo para un proyecto. No cabe duda de que presupuestar adecuadamente es también un reto a la inventiva del desarrollador. ¿Con cuántos insumos podremos contar aunque no se nos asignen? ¿Cómo ganarnos la confianza con nuestros resultados para que cada vez sea menor el desgaste de la negociación?
Ya en la realidad de la presupuestación, yo recomiendo elaborar una matriz. En una entrada (filas) tener todas las actividades con sus especificaciones, y en las columnas abrir los rubros de gasto.
Conviene reflexionar, al hacer el estimado de costos, que casi siempre estamos sólo considerando los directos adicionales; y que no repercutimos la parte alícuota de alquiler, teléfono, comunicaciones, servicios generales, etc.
Tratándose de un proyecto de cómputo educativo, es muy importante que los expertos en didáctica vayan detallando lo que se espera que el programa haga. Esto lo pueden hacer en un lenguaje coloquial, es decir, como si lo platicaran. A esto se le llama pseudocódigo.
3. Ya contando con nuestra planeación a detalle, viene la etapa del Desarrollo. Es decir, llevar a cabo lo que se planeó. Nuestra planeación nos debe dejar un documento tan detallado como sea posible sobre lo que vamos a hacer, cómo lo vamos a hacer y cómo lo vamos a evaluar
Contando con el pseudocódigo, el programador puede pasarlo a un conjunto de instrucciones, rutinas o procedimientos, descripción de objetos, propiedades, mensajes y eventos, que ya son entendibles para el software que opera en la computadora.
La codificación es un elemento muy importante, pero debemos contar en paralelo los insumos didácticos previstos: ilustraciones, videos, textos, reactivos, etc. Una parte importante es cuando integramos los elementos que fueron elaborados por separado y los convertimos en una unidad y evaluamos el funcionamiento del protocolo, primeramente y del programa en su totalidad, más adelante.
En un proyecto informático, que bien lo debería ser en los de todo tipo, resalta la importancia de contar con un prototipo. Al usar el prototipo se puede evaluar el diseño, incorporar cualquier cambio en un siguiente prototipo, y eventualmente, refinar el diseño para la aplicación o sistema final.» (Bauersfeld 1994: 155)[1].
El prototipo es una forma en la que se obtiene una idea global de la funcionalidad entera del programa (aunque ninguna de las funciones opere todavía en detalle); y simultáneamente, permite ver el funcionamiento a fondo de algunos módulos representativos del desempeño del conjunto. Después de ver funcionar nuestros prototipos podemos terminar o ajustar nuestra planeación con la elaboración final de los requerimientos.
Dice Gándara: “La versión final deberá ser no solamente eficaz y correcta, sino fácil de usar, amigable; la amigabilidad se evalúa por referencia a la facilidad de aprendizaje, la retención de lo aprendido, el número de errores en la ejecución sucesiva por parte del usuario, y la experiencia subjetiva de uso (que debe ser agradable y no tensa y frustrante). Todos estos criterios pueden evaluarse formal e informalmente, mediante procesos de observación directa (o «etnográficos»), por encuestas y cuestionarios estadísticamente significativos, mediante simulaciones de uso y «protocolos» de observación/ejecución - a veces apoyados por dispositivos como cámaras de video o grabadoras de audio ante las cuales los usuarios comentan y describen lo que están haciendo. Independientemente del procedimiento, lo crucial es reconocer que, a final de cuentas, es la opinión del usuario la vale, independientemente de lo que nosotros u otros «expertos» opinen”[2].
4. Entrega y evaluación. Si hemos seguido fielmente nuestra planeación y hemos aprovechado la retroalimentación de los usuarios con el prototipo, la liberación del programa se convierte en algo de rutina.
Conclusiones.
Desafortunadamente eso no es lo común. Una mala o incompleta planeación, actividades que nos brincamos o requerimientos siempre dinámicos de los usuarios, llevan a que esta etapa se alargue más de lo debido. Por ello, enfatizaremos que una planeación adecuada que nos permita acordar un objetivo con especificaciones que realmente resuelven el problema detectado, manejadas sistemicamente a través de sus especificaciones en los diferentes niveles que lo componen; permitirán un éxito de nuestro desarrollo. En caso contrario podemos enfrentarnos a un desaliento, desperdicio de recursos y “vacunación” en contra del desarrollo de software educativo.
[1] Citado por Manuel Gándara Vázquez,. LOS USOS EDUCATIVOS DE LA COMPUTADORA. CISE/UNAM. México. 1994. Págs.: 159-178.
[2] Gándara Vázquez Manuel. Materiales de reforzamiento de la Unidad 13.
