EL SOFTWARE EDUCATIVO

 

Caracterización del Problema

Cronograma del Primer Lapso

Estimados Alumnos, al saludarles quisiera animarles una vez más a hacer de esta asignatura, un motivo que nos impulse a construir un conocimiento provechoso para nuestra labor educativa; en tal sentido, y como quiera que esta última estaría desenfocada si no ponderamos las implicaciones de cada una de nuestras acciones, la reflexión pues, resulta obligada a fin de descubrir los presupuestos de nuestros propósitos y métodos de enseñanza.

Como quiera que nuestro primer compromiso gira en torno a la conceptualización, clasificación, evaluación, selección y diseño de software educativos, he tenido a bien facilitarles algunas lecturas que nos permitirán abonar el terreno en el que han de florecer las reflexiones que, de forma deductiva, permitirán adentrarnos poco a poco en el apasionante mundo del multimedia.

Para comenzar, quisiera se leyeran el siguiente material y tratasen de anticipar algunas implicaciones que para el software educativo se deriven de la misma; me explico, dado que el presente es un material que reseña algunos presupuestos filosóficos que subyasen a la concepción del software en general, qué advertencias descubren en él que han de tomarse en cuenta a la hora de estudiar el software educativo en particular.

Sus apreciaciones pues, serán el tema de discusión de nuestro próximo encuentro.

 

Caracterización de un Modelo General de Desarrollo de Software

Los primeros desarrollos de software surgieron muy ligados al aspecto hardware, básicamente el software –como se dijo en la introducción- era un apéndice del hardware. Así, la producción de software surge como un símil del proceso productivo dominante.

Es claro que la noción de producción que existía y que se mantiene hasta el día de hoy es la instaurada por siglos de producción de artefactos manufacturados o productos agroindustriales en esquemas de producción que va desde la producción artesanal hasta montajes en serie, estos últimos instaurados por Henry Ford con la producción en cadena del modelo Ford-T, en las primeras décadas de este siglo.

Independiente de lo que se quiera producir, el proceso básico de producción consiste en tres pasos fundamentales: análisis, diseño y producción propiamente tal.

Análisis: corresponde a buscar la respuesta a la pregunta de ¿qué producir?. Pregunta fundamental a la que se enfrenta toda persona al momento de decidir invertir algún capital o, básicamente, subsistir.

Diseño: corresponde a responder la pregunta de ¿cómo lo que se quiere producir se va a producir?, esto influye tanto al producto en sí, como a la forma concreta de producir ese producto. El diseño desde esta perspectiva busca definir tanto el producto como la forma de producirlo.

Producción: en llevar a cabo, en forma concreta, los lineamientos definidos en el diseño, tanto para la cadena de producción –cuando se trata de un producto de consumo masivo- como del producto mismo.

No se ha incluido en este esquema la cadena de distribución y ventas, que completa el ciclo, ya que el proceso que nos interesa analizar es el de producción propiamente tal.

Veamos que significa esto desde la perspectiva del producto. El producto surge como respuesta a una necesidad real o determinada por el mismo producto –qué producto no es a su vez catalizador y paliativo de una necesidad. La determinación de la necesidad o del nicho que permite la creación de ella es parte del análisis; la observación del mercado, la determinación de problemas, la respuesta a requerimiento, etc. son tareas que se consideran en el análisis y que buscan perfilar las características básicas que tendrían los productos que requiere el mercado, o solucionan el problema, o satisfacen los requerimiento, etc. El diseño o la Fase de Diseño tiene más relación con la especificación de los elementos que podrían componer el producto definido en el análisis, ya se piensa en las características concretas que ese producto tendrá, el material, la forma, el estilo, la cantidad, la calidad, etc. son características que surgen en esta etapa. En ese sentido tanto una producción agroindustrial, como una obra de arte consideran etapas de diseño, independiente de que las motivaciones sean distintas. La producción corresponde a la etapa de la acción, en la cual se aplican los resultados del diseño, tanto para el producto –qué tipo de maíz sembrar- como para la cadena de producción –cómo sembrar ese maíz.

La producción de software no está ajena a esta noción de producción y su origen, muy ligado al hardware, no permitía que se pensase en el software como un producto de naturaleza diferente a la de todo los productos. Y en alguna forma aquello es muy cierto, pero creemos que esta visión de "producto de software" no es la única.

Es claramente factible considerar como producto a aquel software que está muy ligado a la máquina, como son los Sistemas Operativos, o a aquellos software que apoyan procesos de carácter general o específico que se encuentran muy consolidados –por años de trabajo- o en los cuales el software ha creado la necesidad. Como ejemplo de los primeros se puede ver a las planillas de cálculo, los editores de texto, los sistemas de diseño industrial, la automatización de procesos productivos, etc. Los segundos tienen su máxima expresión en los compiladores, los juegos de video y otros productos que buscan nuevas formas de configurar el mundo aprovechando las potencialidades de la máquina. Los primeros son modelos del mundo, mientras que los segundos los podemos ver como elementos con una sola existencia cibernética, sin referente en el mundo.

Esta noción de producción se desprende claramente de la definición de Ingeniería de Software. Veamos las citas sobre lo mismo hechas en el libro "Ingeniería de Software" de Richard Fairley. Cita el autor:
 

De acuerdo con Boehm, la ingeniería de Software incluye la aplicación práctica del conocimiento científico en el diseño y construcción de programas para computadoras y la documentación asociada requerida para desarrollarlos, operarlos y mantenerlos. Otra definición de Ingeniería de Software es la entregada en el libro de IEEE titulado "Standar Glossary of Software Engineering Terminology", en el cual se define como el enfoque sistemático para el desarrollo de operación, mantenimiento y eliminación del software donde software se define como aquellos programas, procedimientos, reglas y documentación posible asociada con la computación, así como los datos pertenecientes a la operación de un sistema de cómputo. Richard Fairley, Ingeniería de Software, p.6. Pero también se hacen algunos alcances, ya que según se puede desprender de las definiciones dadas:
  La Ingeniería de Software es una disciplina pragmática que confía en las ciencias de la computación para obtener los fundamentos científicos de la misma manera que las ramas de la ingeniería tradicional, como las ingenierías eléctrica y química se valen de la física y de la química. Richard Fairley, Ingeniería de Software, p.7. Esto lleva también al autor a expresar sus reservas frente a la posibilidad de correspondencia absoluta entre la ingeniería tradicional y la ingeniería de software:
  La ingeniería de software comparte, junto con las otras ramas de la ingeniería el enfoque pragmático para el desarrollo y mantenimiento de artefactos tecnológicos; existen, sin embargo, diferencias significativas entre esta ingeniería y las otras, siendo la fuente principal de dichas diferencias la falta de leyes físicas para la programación, la inteligibilidad del producto y lo oculto de las interfaces entre los diversos módulos de programación... El diseño de programas es comparable con el diseño arquitectónico de edificios en ausencia de gravedad, de tal suerte que tener grados excesivos de libertad tiene tantos pros como contras para un ingeniero de programación. Richard Fairley, Ingeniería de Software, p.8. De lo expresado en los párrafos anteriores quedan dos sensaciones, primero que el software se busca construirlo desde la perspectiva de la ingeniería tradicional, esperando que existiese un acabado conjunto de teorías científicas que apoyen el desarrollo de métodos y procedimientos precisos para la construcción de productos de software exitosos, que resuelvan eficaz y eficientemente cualquier problema que pueda ser resuelto bajo la premisa del software. Pero esto no es directo, por un lado las Ciencias de Computación no han logrado dar con leyes que puedan ser aplicadas sistemáticamente mientras que, por otro lado, la amplitud del espectro de problemas posible de ser apoyados mediante un software es de tales dimensiones -y a cada avance de la capacidad de cómputo de las máquinas este espectro se amplía y se hace cada vez más complejo-, que no ha resultado tampoco un medio fácil de caracterizar, ya no tendría la estabilidad necesaria para poder intentar siquiera caracterizarlo a través de leyes generales.

Pero independiente de la posibilidad de existencia o no de leyes generales, el software se produce y es, en un importante porcentaje, un producto que funciona eficaz y eficientemente en su ambiente. Pero también mucho software producido es algo que va a dar al tacho de la basura. Se ha desarrollado una variedad de métodos empíricos que han reportado importantes avances en relación a la posibilidad de producir software adecuado; pero, por otro lado, la utilización de estos métodos no ha asegurado, en un porcentaje considerable de los casos, el éxito del producto.
 

Crisis del Software como crisis del Modelo General de Desarrollo de Software

Pero, independiente de cuales sean las características de la producción de software y de los productos software que se considere, no se puede  desconocer que existen grandes problemas en este escenario. Por ejemplo Pressmann describe estos problemas como "La crisis del software".
 

...continúa intensificándose la crisis del software. Por ahora podemos describir la crisis del software de la siguiente forma:

1.- La sofisticación del hardware ha dejado atrás nuestra capacidad de construir software que pueda explotar el potencial del hardware.

2.-Nuestra capacidad de construir nuevos programas no puede descansar, debido a la demanda de nuevos programas.

3.-Nuestra capacidad de mantener los programas existentes está amenazada por el mal diseño y el uso de recursos inadecuados.

Como respuesta a la crisis del software, muchas industrias están adoptando prácticas de ingeniería de software. Roger Pressman, Ingeniería de Software, p.14.

 Y esta no es la única opinión al respecto, o la única evidencia de la existencia de esta crisis, de hecho el surgimiento de la Ingeniería de Software obedece a la necesidad de responder a esta crisis. Veamos otras referencias a lo mismo:
  Experiencias en desarrollo de software de gran tamaño durante los años 60, mostraron que los métodos existentes no eran suficientemente buenos. Las técnicas aplicadas durante el desarrollo de programas pequeños no eran escalables al desarrollo de sistemas mayores. Era frecuente que estos últimos se atrasaran años, costaran más que lo que originalmente se predijo, no eran confiables, difíciles de mantener y su eficiencia en tiempo de ejecución era pobre. Era claro que se necesitaban nuevas técnicas para controlar la complejidad inherente a los sistemas grandes de software.  Roger Pressman, Ingeniería de Software, p.14. En la actualidad, la "crisis del software" aún no ha sido solucionada. Aunque han existido mejoras reales de importancia en técnicas y métodos de Ingeniería de Software, en herramientas para el desarrollo de sistemas y en las habilidades del equipo de desarrollo, la demanda de software aumenta a mayor velocidad que las mejoras en la productividad de software. En 1987, el U.S. Government Accounting Office reportó sobre el destino de los proyectos de desarrollo de software. Un porcentaje muy pequeño del software fue utilizado como fue entregado. Más del 90% de los proyectos fueron abandonados, entregados pero no utilizados o pagados pero no entregados. Fundamentos y técnicas modernas de programación, J. Navón, D.Fuller, I.Casas, Ediciones Universidad Católica de Chile. El punto de vista de la ingeniería pone énfasis, para graficar la crisis, en la idea de un aumento de la demanda de software. Pero quizá esta necesidad de software sea la respuesta adecuada a una nueva forma de configuración empresarial, en que el computador y, sobre todo, el software no puede ser visto como una máquina que mejora el producto, a diferencia de los cosechadores, telares, tornos, fresadoras y hasta los robots industriales de última generación; sino como una máquina que modela lo más profundo de la organización, su sentido. Sentido que configura y define el espectro de posibilidades que una organización es.

Ahora, si se acepta el cambio de perspectiva para entender lo que es el software y, además de considerarlo un producto, se privilegia la visión del software como un elemento que configura y modela una realidad organizacional, entonces es posible pensar en que la "Crisis del Software" es una crisis del modelo de desarrollo de software como producto y que una forma de superarla está en la reformulación del problema, ampliando sus posibilidades de solución.
 

El modelo, el producto y el software

Para entender la forma en que se puede ampliar las posibilidades de solución de la "Crisis del Software" es bueno revisar las características que tiene el trabajo de desarrollo de Software.

En apartados anteriores en este apunte se cita lo siguiente:

El diseño de programas es comparable con el diseño arquitectónico de edificios en ausencia de gravedad, de tal suerte que tener grados excesivos de libertad tiene tantos pros como contras para un ingeniero de programación. Richard Fairley. En relación a una comparación entre la Ingeniería Tradicional y la Ingeniería de Software.

Pero la diferencia anterior habla de un principio de distinción, pero no precisa las consecuencias pragmáticas que esta distinción tiene. Por ejemplo, al pensar en la construcción de una casa es posible anticipar hasta el más mínimo detalle las características que esta casa tendrá. Cualquiera sabe que antes de empezar a hacer los primeros trabajos de preparación de suelo, es posible tener un diseño a escala –una maqueta- de la casa, es posible, por lo mismo, determinar claramente en que lugar va cada elemento de cada uno de los componentes de la construcción y el costo de que cada uno de esos elementos vaya en ese lugar. En este caso hay una diferencia clara entre el modelo –la maqueta- y el producto, la casa.

La construcción de una casa, como la de un puente, un automóvil, etc. responde al patrón básico de análisis, diseño y producción; en el cual están claramente definidas y diferenciadas tanto la producción y como el uso del producto.

Luego de la inauguración del puente este entra en fase de uso y las modificaciones que se le haga son mínimas y se deben, principalmente, al desgaste que puede sufrir. Con la casa ocurre algo similar, el aseo, la pintura, uno que otra remodelación, etc. son aspectos mínimos de construcción que emergen en la fase de uso de la casa.

Para el caso del software la distinción entre el modelo y el producto no es tan clara. Y, por lo mismo la distinción que se hace entre una fase producción y una de uso tampoco lo es.

Esto lleva a cuestionarse la visión como producto que se hace del software, existen algunos software que sí corresponden a la visión clásica de lo que es un producto, por ejemplo: Sistemas Operativos, Compiladores, Editores de Texto, Planillas, etc. Pero, para ciertos tipos de software, esta visión no sería la más adecuada y, por lo mismo, su aplicación en el desarrollo de aquellos no asegura su éxito posterior.

Típicamente al software que tiene esa particularidad es aquel que se desarrolla "a la medida" para alguna organización, en este tipo de problemas el modelo clásico de producción no asegura que el software construido como resultado de este modelo, resuelve el problema para el cual se propuso como solución, y las razones de esta desvinculación hay que buscarlas desde otra perspectiva.
 

Antecedentes sistémicos y una caracterización alternativa del Problema del Software.

Quizá la razón básica de por qué ocurriría esta desvinculación total o parcial entre el software y el problema que quiere dar solución esta en que de partida existen dos interlocutores, un experto en la programación o codificación y, por otro lado, un usuario, quien sería el experto en el problema a quien se debe satisfacer mediante la codificación de la solución, o programa.

La especialización y la complejidad asociada al desarrollo de software hace que este modelo Usuario-Desarrollador sea el pilar de cualquier producción o desarrollo que se haga. Independiente de que tipo o clase de software se desarrolle, la imagen de usuario real o ficticia siempre está presente en el desarrollador.

Lo anterior nos lleva, también, a la idea de iteración: esta desvinculación entre el origen del problema y la solución imprime en los métodos de desarrollo la idea de retroalimentaciones que permitan aproximar la distancia entre los ámbitos. Esta idea de distancia quizá quede más claro en el siguiente extracto del libro de R.Farley:

En el sentido real, el ingeniero de programación crea modelos de situaciones físicas en un programa. La correspondencia entre el modelo y la realidad modelada se ha considerado como la distancia entre el problema y la solución computacional del problema. Un principio fundamental de la ingeniería de programación es diseñar productos que minimicen la distancia intelectual entre el problema y la solución. Richard Farley, Ingeniería de Software, p.14. Y pese a que hay claridad en el problema -minimizar la distancia intelectual entre el problema y la solución- no existiría aún un método que permita asegurar aquello, por ejemplo, revisemos lo que continúa, en el libro de R. Farley: ...empero, la variedad de enfoques en el desarrollo de programas está limitado únicamente por la creatividad e ingenio del programador; no siempre se encuentra con claridad el enfoque que minimice esta distancia, e incluso diferentes enfoques minimizan distintas dimensiones de la distancia. Richard Farley, Ingeniería de Software, p.14. Así, el problema del desarrollo de software quizá no se necesariamente un problema técnico, que pueda ser resuelto afinando o mejorando los métodos existentes o creando nuevos métodos en que esta distancia se siga manteniendo.

Un enfoque alternativo es pensar en que esta distancia se podría eliminar. Es radical, es cierto, pero puede servir de punto de partida a un análisis distinto del problema. Para ello es necesario pensar en que es lo que produce esta distancia.
 

La relación explicación y uso desde la hermeneutica

Para comprender que se entiende en forma general por hermenéutica veamos la explicación que dan F. Flores y T. Winograd:
 

La hermenéutica comenzó como la teoría de la interpretación de textos, particularmente los de tipo mitológico y sagrado. El problema central de la hermenéutica corresponde a caracterizar cómo las personas encuentran el significado en un texto que existe desde hace varios siglos y se entiende de forma diferente en épocas distintas. Hacia la comprensión de la Informática y la Cognición, F. Flores, T. Winograd, Ed. Esada. Es importante para las reinterpretaciones de la hermenéutica que nos interesan, observar las posturas filosóficas que la componen: Dentro de la hermenéutica ha existido un debate permanente entre aquellos que sitúan el significado dentro del texto y aquellos otros que perciben el significado ligado a un proceso de comprensión en el que juegan papeles vitales tanto el texto en sí, como su producción e interpretación.

Para la escuela objetivista de la hermenéutica el texto debe tener un significado que existe independiente del acto de interpretación. Para esta corriente el objetivo de una teoría hermenéutica es el desarrollo de métodos por los cuales nos liberamos de todo tipo de prejuicios, siendo posible producir un análisis objetivo de lo que existe allí realmente. El ideal es "descontextualizar" totalmente el texto.

La aproximación opuesta, formulada claramente por Gadamer toma como eje primario el acto de interpretación y la comprensión como una interacción entre el horizonte proporcionado por el texto y el horizonte que el interpretador trae consigo. Gadamer insiste en que cada lectura o escucha de un texto constituye un acto de dotación de significado a través de la interpretación... Cualquier individuo al comprender su mundo se haya involucrado de modo continuado en actividades de interpretación. Esta interpretación se haya basada en el prejuicio (o la pre-comprensión) el cual incluye suposiciones implícitas en el lenguaje que utiliza la persona. Este lenguaje, por otro lado, se aprende por medio de actividades de interpretación. El individuo cambia por medio del uso del lenguaje, y el lenguaje cambia a través de su uso por el individuo.
...
La aproximación de Gadamer acepta la inevitabilidad del círculo hermenéutico. El significado del texto para un individuo es contextual, dependiendo del momento de la interpretación y del horizonte traído hacia él por el intérprete. Pero dicho horizonte es a su vez producto de una historia de interacciones en el lenguaje, interacciones que representan por sí mismas textos (hablados o escritos) que deben ser entendidos a la luz de la pre-comprención. Aquellos que entendemos se basa en lo que ya conocemos y lo que ya conocemos proviene del ser capaz de entenderlo. Hacia la comprensión de la Informática y la Cognición, F. Flores, T. Winograd, Ed. Esada.

 Esta corriente no objetivizante, comenzada por Heidegger y continuada por Gadamer, rechaza la filosofía del sentido común racionalista que objetivizaría nuestra percepción del mundo al plantear la existencia de "un mundo real objetivo" como base incuestionable del razonamiento filosófico, situación que se traduce en la aceptación de la existencia de dos dominios separados de fenómenos, veamos: Esta comprensión... incluye una clase de dualismo mente-cuerpo que acepta la existencia de dos dominios separados de fenómenos, el mundo objetivo de la realidad física y el mundo subjetivo mental que atiende a los pensamientos y sentimientos del individuo. Dicho simplemente descansa sobre varios supuestos:
  Hacia la comprensión de la Informática y la Cognición, F. Flores, T. Winograd, Ed. Esada. Heidegger considera que la filosofía al optar por estos principios ha equivocado su camino, no tanto en el sentido que sean principios básicamente errados, sino más bien en la insistencia de buscar las pruebas que los validen una y otra vez: Heidegger alega que "el escándalo de la filosofía" no es el que esté pendiente todavía el aporte de pruebas sino más bien que se espere y se intente obtener dichas pruebas una y otra vez. Hacia la comprensión de la Informática y la Cognición, F. Flores, T. Winograd, Ed. Esada. La distinción entre mundo físico (objetivo) y mundo mental (subjetivo) no tiene sentido según Heidegger, aduce que la separación entre sujeto y objeto niega la unidad más fundamental de estar-en-el-mundo (Dasein). Heidegger rechaza tanto la estancia objetiva simple (donde el mundo físico objetivo es la realidad primaria) como la estancia subjetiva simple (donde mis pensamientos y sensaciones son la realidad primaria) arguyendo en su lugar que es imposible que una exista sin la otra. El interpretador y lo interpretado no existen independientemente: la existencia es interpretación y viceversa. El prejuicio no es una condición en la que el sujeto es conducido a interpretar falsamente el mundo, sino que es la condición necesaria para tener un trasfondo para la interpretación (y por ende el Ser). Hacia la comprensión de la Informática y la Cognición, F. Flores, T. Winograd, Ed. Esada. Desde la perspectiva que nos interesa –reformular el problema del desarrollo de software- el trabajo de Heidegger es fundamental pero no por ello menos complejo y en ese sentido hemos aprovechado las apreciaciones del F. Flores y T. Winograd en tal sentido ya que resumen los elementos centrales de su filosofía que están relacionados directamente con la comprensión del "ambiente" en que el desarrollo de software se da.

Algunos puntos centrales de la filosofía de Heidegger, y de los cuales daremos una breve explicación, son los siguientes:

 

No todas las creencias y suposiciones implícitas pueden explicitarse.

Nuestra existencia, como decía Gadamer se da en un círculo hermenéutico inevitable, e.d. "Aquello que entendemos se basa en lo que ya conocemos y lo que ya conocemos proviene del ser capaz de entenderlo" y, desde la perspectiva de Heidegger, nada puede hacerse para evitar este círculo, con lo cual no sería posible alcanzar un punto de vista neutral que permita ver las creencias y suposiciones como objetos que puedan, por eso mismo, se explicados o explicitados. Siempre existirán elementos implícitos –otras creencias- que sustentan y determinan tales explicaciones.
  La comprensión práctica es más fundamental que la comprensión teórica que se pueda deducir. Este punto esta muy ligado al anterior, en el sentido que una comprensión teórica es una suerte de explicitación de la comprensión, lo que involucraría a su vez la existencia de supuestos que sustentan esta explicitación, los cuales contribuyen tanto a aclarar el fenómeno como a obscurecerlo, esto último desde el prejuicio dado por los supuestos. Heidegger considera que la comprensión está más ligada a la condición de lanzabilidad, en que la comprensión ocurre al encontrar nuestras acciones alguna resonancia o efectividad en el mundo.
  No nos relacionamos primariamente con las cosas por medio de la representación de ellas. Este punto se desprende de los dos anteriores, en el sentido que Heidegger rechaza las representaciones mentales. Por ejemplo, al dirigir un clavo con un martillo (en oposición a pensar sobre el martillo), no es necesario hacer uso explícito de la representación del martillo. La habilidad para actuar proviene de la familiaridad con el hecho de martillear, no con el conocimiento sobre el martillo.
  El significado es, fundamentalmente, social y no puede reducirse a la actividad de dotación de significado de los sujetos individuales. Heidegger considera que el fundamento último de la inteligibilidad es la actividad social. Una persona no es un sujeto individual, sino una manifestación del estar-en-el-mundo (Dasein) en un espacio de posibilidades dado por ese mundo y por una tradición.

 

 Existe dos aspectos del pensamiento de Heidegger que son relevantes al momento de entender el medio en que el software es producido y utilizado: lanzabilidad y disponibilidad a la mano. En ambos casos lo que se busca ilustrar son reinterpretaciones del mundo de lo cotidiano desde lo cotidiano. La primera está relacionada con el hombre como un actor en un medio en que no controla –por imposibilidad- todas las variables, el segundo concepto, de disponibilidad a la mano, explica la relación que establece en hombre con los instrumentos que usa, dándole a esta relación la doble dimensión de uso y explicación.
 

Lanzabilidad

La lanzabilidad la explican Flores y Wynograd en base a una serie de conceptos relacionados con la escenificación del actuar inevitable que uno, como persona, realiza en el mundo. Aunque básicamente la noción de lanzabilidad está relacionada, en general, con el estar "lanzado" en vivir situaciones que no dependen completamente de la persona, este concepto se puede desmenuzar en varias puntos:
 

No se puede evitar el actuar

En cualquier situación que se viva, el "no actuar" es, sin embargo, actuar. Es una cuestión inevitable el que si se está arrogado o lanzado a una situación las acciones que se realicen en esa situación siempre son parte del actuar, aún la quietud más absoluta.

 

 No se puede volver atrás y reflexionar sobre las actuaciones Cualquier persona luego de estar en una situación, ha sentido con posterioridad el "debería haber dicho..." o "no debería haber puesto esa cara de...", situación que se hace patente en el ejemplo de que la situación involucra a esa persona que tanto a uno le gusta y que le dirige la palabra por primera vez... las reflexiones culpables duran semanas. Los autores dicen: "Ante la necesidad de responder inmediatamente a lo que se dice y hace es imposible tomar tiempo para analizar las cosas de modo explícito y escoger el mejor camino para actuar". Nuevamente uno está lanzado, confiando en sus instintos tratando cualquier cosa que venga.

 

 Los efectos de las actuaciones no pueden predecirse Es imposible saber como los propios actos van a afectar a las otras personas. Lo anterior se ejemplifica claramente en los temores que acarrea el abordar a aquella desconocida o desconocido que provoca tantas sensaciones, si supiéramos de ante mano como va a reaccionar, entonces no se tendría tanto "susto".

 

 No se tiene una representación estable de la situación. Esto tiene que ver básicamente con el escenario en que se da la situación, es un escenario que cambia constantemente, por un lado, y al cual hay que ir replicando en el momento, por otro. Al final, fuera ya de la corriente de los acontecimientos se puede hacer un análisis más "en frío" en el cual algunos aspectos de todo eso se han decantado. Este análisis posterior puede entregar claridades con respecto al desinterés absoluto que la otra persona tiene por uno, por ejemplo. Situación que por el nerviosismo del momento ni siquiera percibimos.

 

 Cada representación es una interpretación Por ejemplo, si en la situación que analizamos hemos sido acompañados en nuestra aventura por un amigo, la impresión que el tenga de todo puede ser, por ejemplo, lo opuesta a la que uno tiene. "Ni te pescaron" puede ser una opinión que cae como balde de agua fría, ya que uno estaba convencido que había "matado" en el encuentro. En todo caso, los autores reavivan nuestras ilusiones al decir: "No existe modo definitivo para determinar que cualquiera de las interpretaciones es verdaderamente correcta o equivocada e incluso que las personas cuya conducta se halla cuestionada puede muy bien no estar en sintonía con sus profundas motivaciones propias."

 

 El lenguaje es acción Los autores dicen: "Cada vez que usted habla, usted está haciendo algo bastante diferente al simple establecer unos hechos ... en muchos casos esta creando una situación que antes de hablar no existía". Por ejemplo, al articular "podríamos juntarnos a conversar sobre aquello" estamos creando una posibilidad de acciones futuras, de la misma manera que una respuesta de la forma "claro, cuando tu quieras" la potencia y permite la incorporación de nuevas posibilidades más concretas.

 

 Según los autores, "las interacciones que se establecen con otras personas y con el mundo inanimado en el que habitamos nos coloca en una situación de lanzabilidad para la cual esta metáfora del encuentro o de la conversación es mucho más adecuada que la metáfora de un científico que realiza observaciones, formula hipótesis y escoge conscientemente una línea de acción racional". La vida cotidiana, en ese sentido, sería más interacción y diálogo que análisis y retórica.

 

Disponibilidad a la mano

El segundo aspecto de la teoría de Heidegger que resulta de vital importancia para esta reformulación del fenómeno del desarrollo de software es lo que los Flores y Wynograd llaman "Rompimiento y disponibilidad a la mano" que consiste en que al utilizar los objetos del mundo estos son "transparentes" a quién los utiliza y adquieren "contenido" sólo cuando no están presentes.

En ese sentido, los autores describen el ejemplo simple de un martillo que es utilizado por alguien que intenta golpear un clavo. Para la persona que está accionando el martillo, este no existe como tal. Forma parte del trasfondo de de disponibilidad a la mano que se da por descontado sin reconocimiento explícito o identificación del objeto, del martillo en este caso. Así, el objeto martillo es parte del mundo de los que martillean pero no está presente al igual que no lo están los tendones del brazo del que golpea.

Los autores continúan: "El martillo se presenta como tal solamente cuando se produce algún tipo de rompimiento o de indisponibilidad la uso inmediato. Su característica de martillo emerge si se rompe o se suelta de la mano o machaca la madera, o bien hay un clavo que hay que clavar pero no se encuentra el martillo... Como observadores podemos hablar acerca del martillo y reflexionar sobre sus propiedades , pero para la persona involucrada en la lanzabilidad de un martilleo, este no existe como entidad, es transparente".

La importancia que tiene este aspecto para el desarrollo de software radica en la posibilidad de redefinir los criterios de diseño, en el sentido de privilegiar aspectos como el de la transparencia anticipando los quiebres o rompimientos que hacen emerger las características del software por sobre las característica de la tarea que se está realizando. Los autores usa el siguiente ejemplo para graficar esta situación:

Si uno se sienta a redactar un informe en un procesador de textos, se está en la misma situación de el que golpea con el martillo. Más bien se piensa en las palabras o frases que aparecerán en la pantalla. Existe una red de equipamiento que incluye los brazos y manos, un teclado, y muchos dispositivos complejos que median entre ellos y una pantalla. Ninguna parte de este equipo está presente delante de uno excepto cuando se produce un rompimiento. Si una letra falla en aparecer delante de la pantalla, el teclado puede surgir con propiedades del tipo "teclas estropeadas". O bien uno puede descubrir que el programa fue construido, en efecto, a partir de componentes separados tales como el "gestor de pantalla" y el "manipulador de teclado" o que ciertas clases de errores se pueden atribuir al manipulador de teclado. Si el problema es serio podemos estar forzados a presentar una red completa de propiedades que reflejan el diseño del sistema y los detalles del equipo y de los programas. Hacia la comprensión de la informática y la cognición, F.Flores y T.Wynograd, Ed. Esada. Es más, estos principios de diseño pueden ser considerados al nivel de la administración. Flores desarrolla un ejemplo más extenso que involucra soluciones de la forma de anticipación de estos quiebres, veamos: Considere la siguiente situación en una oficina: se le pide que haga 10 copias de un documento, siguiendo ciertas instrucciones que son, ..., sólo especificaciones parciales de lo que usted tiene que hacer. Su trabajo es una interpretación de las instrucciones. Usted está trabajando con un terminal de computador conectado a un servicio de tiempo compartido. Usted está familiarizado con el trabajo en el terminal, escribiendo y corrigiendo textos, usando un programa llamado el editor.... Mientras trabaja sus manos son "transparentes" y hace ciertos tipos de errores de ortografía que corrige automáticamente. No está pensando que trabaja con el editor o qué está mirando, etc., hasta que surge algún problema... Repentinamente los últimos 10 caracteres que usted tecleó no aparecen en la pantalla. Usted no se preocupa, pues su experiencia previa le dice que estará trabajando de nuevo en 5 minutos más... Regresa 10 minutos más tarde y encuentra que el sistema todavía no responde. Llama al operador. El ingeniero dice que esta es una falla no usual... la reparación podría demorarse unas 4 horas. Entonces usted decide llamar a su supervisor... le explica lo sucedido y le pide instrucciones. Su supervisor le dice: "Por favor, venga inmediatamente a mi oficina. Puede dictarle el informe a mi secretaria. Es importante para la reunión de mañana". Usted sale. En el pasillo ya se ha olvidado del computador y ahora su único interés, por lo que acaba de saber, es la reunión que se llevará a efecto mañana. Inventando la Empresa del Siglo XXI, Fernando Flores. Ed. Hachette, 1993. Esta es una situación similar a la descrita en el ejemplo anterior con la sola diferencia que acá se resuelve el problema con la intervención del Supervisor. Veamos que significa esto para Flores: La conversación del trabajador con su supervisor también ilustra un punto importante acerca de la naturaleza de la supervisión. El supervisor responde inmediatamente, ofreciendo los servicios de su secretaria y de su equipo para terminar el informe. El no tuvo que evaluar todas las alternativas aun cuando su decisión requería reorganización de la oficina. Ser un supervisor es tener la capacidad de hacer frente a los quiebres. Pero ¿de donde viene esta capacidad. Ella proviene de dos fuentes. La primera la llamaremos entendimiento: la habilidad de anticipar de una forma tal que a uno le permite ver inmediatamente lo que es posible hacer. La segunda fuente la llamaremos estado de ánimo, o el modo particular que tenemos de estar situados en el mundo. Estado de ánimo es algo que somos, que creamos con nuestra presencia. Inventando la Empresa del Siglo XXI, Fernando Flores. Ed. Hachette, 1993. En la capacidad que se tenga de anticipar los quiebres –evitando que ocurran- o en responder activamente a ellos –como en el caso del supervisor del ejemplo- radicaría uno de los aspectos principales del concepto de diseño que propugna Fernando Flores, tema que recogeremos más adelante en este apunte.

 

Lanzabilidad y Disponibilidad a la Mano en el desarrollo de Software

Aceptar la interpretación hedeiggeriana del mundo abre una nuevo espacio de posibilidades de acción en el Desarrollo de Software, por ejemplo, esta distinción que hace en relación al uso de una herramienta por una persona y la explicación que de ella se puede hacer, resulta del todo significativa para el tema del Desarrollo de Software. Existirían desde esta perspectiva dos dominios en que uno se relaciona con las cosas, aquel que surge cuando los objetos son usados en el hacer cotidiano y existen en la medida que son "transparentes" y posibilitan este hacer. El otro dominio es el dominio de la explicación, en el cual uno reflexiona sobre un objeto, se describe, se observa como objeto con propiedades propias.

Heidegger considera que la comprensión práctica es más fundamental que la comprensión teórica y ello, en el caso de los dominios anteriores, nos remite a una suerte de incompletitud del dominio de la explicación. Esto quiere decir que cualquier explicación o reflexión que se haga sobre un objeto o una situación nunca podrá ser un correlato vívido y certero de la situación práctica o del objeto, siempre hay supuestos que sustentan aquella explicación, trasfondo que hace de esta última una imagen distorsionada producto de los prejuicios dados por ese trasfondo.

Una situación típica de desarrollo de software a la medida, especifica la existencia de estos dos dominios en el dominio del usuario. Generalmente lo que se pretende desarrollar es una herramienta que tendrá por misión apoyar el trabajo que el usuario lleva a cabo, si el usuario es una persona experimentada en su quehacer entonces ese quehacer será transparente para él, cuando realiza su trabajo generalmente no reflexiona sobre lo que hace en los términos que son necesarios para realizar desarrollo de software. Claro, para hacer desarrollo es necesario que la reflexión que se haga sea del tipo explicativo y, cuando se está frente a una situación de trabajo la transparencia de la misma no permite ver más allá y, si esa transparencia se pierde, entonces ya no se está en la situación de trabajo que se desea apoyar sino sobre el dominio de la explicación, la que por su trasfondo explicativo –sesgado por la necesidad dada por el desarrollo de software- no permite un conocimiento de primera mano de la situación de trabajo.

La situación anterior puede describir una de las vertientes del uso de prototipos en el desarrollo de software, el prototipo se puede ver como una forma de aproximar estos dos dominios dentro del usuario. La explicación, que da como resultado el prototipo, es validada en el uso por el mismo "explicador", la idea básica detrás de esto es aproximar el lenguaje que el usuario usa en la explicación al lenguaje del desarrollador.

Así, el círculo hermenéutico de Gadamer confluye dentro del software, en el sentido que este sería significación y contexto de la actividad del usuario de este software. F.Flores y T.Wynograd dicen: "aquello que entendemos se basa en lo que ya conocemos y lo que ya conocemos proviene de ser capaz de entenderlo"

El análisis que se puede hacer con respecto a la lanzabilidad en el desarrollo de software es similar a descrito para el disponer a la mano, y en ese sentido el software también involucra aspectos situacionales, ya sea en su uso como medio –el eMail, por ejemplo- o en su construcción como reflejo de comunicaciones usuario-desarrollador.

 

La relación Desarrollador y Usuario desde el Constructivismo Radical.

La raíz del constructivismo radical está en la concepción del observador, en el sentido que cualquier explicación sólo puede ser hecha por un observador desde su propio dominio de observación: "todo lo dicho es dicho por alguien" H.Maturana y F.Varela.

Para efectos de entender las implicancias de la mirada constructivista, revisaremos los elementos básicos y atingentes de la teoría biológica del conocimiento que H.Maturana y F.Varela proponen.

Básicamente, la estructura del sistema nervioso está compuesta, en general, por una red de neuronas interconectadas, cuyo mecanismo clave y mediante el cual expande el dominio de interacciones de un organismo es: acoplar las superficies sensoriales y motoras mediante esta red neuronal cuya configuración puede ser muy variada.

Si bien, este mecanismo clave llevaría a preveer la certeza de las nociones de estímulo y respuesta, como conceptos fácilmente asociables a la idea de superficie sensorial y motora respectivamente, desde la perspectiva de H.Maturana esto no es tan directo. Por ejemplo:

Así, el sistema nervioso contribuye o participa en el operar de un metazoo al constituirse, mediante múltiples circuitos entreverados, en un mecanismo que conserva las constancias internas que son esenciales para la mantención de la organización del organismo como un todo. H.Maturana, F.Varela. El árbol del conocimiento, p.110 La importancia de lo anterior radica en que se cambia la mirada, obviando el esquema tradicional de estímulo-respuesta y reinterpretándolo desde una perspectiva dada por la conservación de las constacias internas o como podría ser más claro: ...la percepción se debe estudiar desde dentro más que desde fuera, mirando las propiedades del sistema nervioso como generador de fenómenos y no tanto como un filtro sobre el mapa de la realidad.

Maturana describe el sistema nervioso como una red cerrada de neuronas que actúan de tal modo que cualquier cambio en el estado de actividad relativa de una colección de neuronas conduce a un cambio en el estado de actividad relativa de la misma o de otra colección de neuronas. F.Flores, T.Winograd, Hacia la Comprensión..., p.72

 La importancia de esta reinterpretación radica en que ahora el sistema nervioso opera cerrado sobre sí mismo: Desde este punto de vista el sistema nervioso no tiene "entradas" ni "salidas". Se puede perturbar mediante cambios estructurales en la propia red, lo cual afectará a su actividad, pero la secuencia de estados del sistema se genera por relaciones de su actividad neuronal, tal como está determinado por su estructura. F.Flores, T.Winograd, Hacia la Comprensión..., p.72 Lo anterior es central, pues permite revisar críticamente las precomprensiones de las cuales se hablaba, un ejemplo es el siguiente: Junto con esta nueva comprensión de la percepción, H.Maturana arguye contra lo que él llama la falacia de la interacción instructiva. El término interacción instructiva señala la creencia,..., que en nuestras interacciones con el entorno adquirimos una representación directa de él; estas propiedades se plasman (...) sobre estructuras del sistema nervioso. El argumenta que, debido a que nuestra interacción se produce a través de la actividad del sistema nervioso total, los cambios no están en la naturaleza de la descripción. Estos son los resultados de patrones de actividad los cuales, aunque disparados por cambios en el medio físico, no son representaciones de él. F.Flores, T.Winograd, Hacia la Comprensión...,p.73 Esto postula que existiría una imposibilidad estructural en "captar completamente" el medio y, más aún, lo que se capte no existiría como una representación en el sistema nervioso, es decir no existirían elementos estructurales específicos -dentro del sistema nervioso- que den cuenta de lo percibido, de manera que se pueda correlacionar uno a uno lo "percibido" y lo "almacenado". Es importante tener claro este punto, por ello lo siguiente: No tenemos hoy día una pintura clara de cuáles son con precisión los cambios estructurales del sistema nervioso...Sin embargo, cualesquiera que sean los mecanismos precisos que intervienen en esta constante transformación microscópica de la red neuronal durante las interacciones del organismo, tales cambios no pueden ser nunca localizados ni vistos como algo propio de cada experiencia, es decir, no pueden ser nunca de tal naturaleza que uno pueda encontrar "el" recuerdo de su nombre en algún lugar de la cabeza del perro. H.Maturana, F.Varela, El árbol del conocimiento,p.113. Con ello, los autores aportan claridad desde el dominio biológico para confirmar la imposibilidad que se almacenen representaciones de la realidad. Por otro lado, desde la perspectiva de la "imposibilidad estructural de captar completamente el medio": ...este constante darse cuenta de que al fenómeno del conocer no se le puede tomar como si hubiera "hechos" u objetos allá afuera, que uno capta y se los mete en la cabeza. La experiencia de cualquier cosa allá afuera es validada de una manera particular por la estructura humana que hace posible "la cosa" que surge en la descripción... esta inseparabilidad entre ser de una manera particular y como el mundo nos parece, nos dice que todo acto de conocer trae un mundo a la mano. H.Maturana, F.Varela, El árbol del conocimiento, p.13. O, para ser más claro en relación a esto: El que los seres vivos sean sistemas determinados estructuralmente tiene las siguientes consecuencias: 1.- que su estructura determina lo que ocurre en ellos en cada instante, 2.- que su estructura determina qué admiten como una perturbación o como una interacción destructiva y, 3.- que un agente externo sólo puede desencadenar, gatilla, en ellos un cambio de estado o una desintegración que está determinada en su estructura... No es la luz lo que determina lo que pasa en el ojo, es el ojo lo que determina lo que es la luz y lo que pasa con la luz... todo lo que ocurre en nosotros ocurre determinado por nuestra estructura bajo condiciones de continuo cambio estructural. H.Maturana, Revista de Tecnología Educativa, 1983, p.131. Así, para dejar en extremo claro lo que esto significa: La estructura del organismo determina en cualquier momento un dominio de perturbaciones; un espacio de posibles efectos que el medio podría poner sobre la secuencia de estados estructurales que podrían suceder... F.Flores, T.Winograd, Hacia la Comprensión...,p.73. Como se ha podido apreciar, las referencias exhautivas dejan translucir la importancia de lo que se quiere sintetizar.

Primero, la noción de clausura operacional que impide las "interacciones instructivas" y esto lleva a cuestionar la comunicación como "transmisión de información" –lo que se describe en la introducción a este apunte-, donde existiría un "algo" que se comunica, y lo comunicado es parte integral de aquello. Así, el fenómeno de la comunicación no depende de lo que se entrega, sino de lo que pasa con el que recibe o percibe el "gatilleo" de la comunicación.

La importancia que esto tiene para el desarrollo de software radica en que sería imposible que un usuario pueda comunicar claramente una necesidad a un desarrollador, ya que al ser individuos distintos, con historias de vidas distintas, tienen, necesariamente, estructuras distintas; lo que relacionándolo con lo que acabamos de decir, impediría que esta necesidad pueda ser "transmitida" sin que lo que se llegue al interlocutor no dependa de la estructura de éste.

Es decir, habría una imposibilidad de fondo de resolver completamente el problema clave del desarrollo, la brecha que existe entre los dominios de usuario y del desarrollador no es posible salvarla de ninguna manera. Es posible reducirla, por ejemplo, mediante especificaciones informales o formales y mediante aquel mecanismo iterativo -que da origen a la idea de prototipo-, pero hacerla desaparecer, nunca.

Ahora, antes de seguir profundizando esta imposibilidad, es necesario detenerse en la idea de dominio. Un dominio -en el ámbito de este apunte- es, antes que nada y sobre todo, un espacio determinado por una distinción que hace en el lenguaje un observador, especificando, por lo mismo, un dominio lingüístico.

Aquí hay que irse con cuidado. Primero, la idea de observador requiere algo de explicación y para ello recurriremos a Flores y Winograd, quienes citan a H.Maturana:

Un observador es un ser humano, una persona, un sistema vivo que puede hacer distinciones y especifica qué es capaz de distinguirse como una unidad... y es capaz de cooperar como si fuera externo a (distinto de) las circunstancias en las cuales el observador se encuentra a sí mismo. Todo lo que se diga se hace desde un observador a otro observador, que puede ser el mismo. H.Maturana, Biology of language, p.31; citado por F.Flores, T.Winograd, Hacia la Comprensión...,p.81. La profundización en lo que significa lenguaje en Maturana se realizará más adelante, ahora sólo se dirá que su función básica corresponde a la de un sistema orientador del comportamiento en base a la creación de dominios consensuales de conducta y no a la de ser un transmisor de información o un mecanismo para dar cuenta de una realidad objetiva independiente del observador.

Entonces asumiendo la condición que el ser humano es un observador del fenómeno de interacción Usuario/Desarrollador es posible distinguir dos dominios disjuntos: el del usuario, por un lado, y el del desarrollador, por otro. Cosa que implícitamente ya se había señalado y que además justificaba la imposibilidad de la cual se hablaba. Esto remite entonces nuevamente al escenario que se había dejado pendiente y que consistía en analizar la raíz de los métodos de desarrollo que buscan aproximar estos dos dominios.

Por una parte, la especificación formal de requisitos -se ha obviado la informal pues tiene al menos los mismos problemas que la formal-, busca aproximar los dominios que se ha distinguido mediante el uso de un lenguaje formal, uno que permita restarle ambigüedad a los hechos y conceptos que caracterizan el dominio del usuario, para que así puedan "aparecer" o "surgir" en el dominio del desarrollador -note que se ha hablado de aparecer o surgir con objeto de salvar el problema de "transmitir información"-. Pero esta técnicapresenta algunos problemas, por ejemplo, necesariamente el usuario debería saber expresarse en este lenguaje formal, si eso ocurre, es probable que un gran espectro de problemas no pueda ser expresado en esos términos del lenguaje –por ejemplo, la categoría de problemas tipo A de M.Lehman-; además, siempre va a ser incompleto, es decir, siempre habrá al menos un problema que no pueda ser expresado en términos de ese lenguaje formal. Por último, si bien la distancia conceptual entre los dominios se ha reducido, siempre serán dominios disjuntos y en ese sentido siempre estarán sujetos a diferencias de interpretación aún para los términos de este lenguaje formal.

Por otro lado, la otra vertiente que se plantea como solución consiste en un proceso de iteración en que las especificaciones se irán retroalimentado de las anteriores y haciendo surgir otras nuevas y esto se repetirá hasta que se llegue a un estado en que exista un acuerdo consensual entre las dos partes y que generará eventualmente una especificación en términos de un prototipo, pese a que también los métodos formales o informales podrían tener un componente iterativo. La ventaja de un prototipo del sistema, es que busca el consenso en base a un lenguaje cercano a la implementación -el prototipo-, con lo que se superan algunas limitaciones de descripción del lenguaje formal, pero limitan, por otro lado, la posibilidad de participación del usuario en la elaboración de las especificaciones -el prototipo-. Si bien, los dominios seguirán siendo disjuntos, esta idea de iteración, ahora basada en un prototipo, es más adecuada que la idea de especificaciones sobre lenguajes formales o informales aún si esto se hace iterativamente. Para entender aquello se debe revisar nuevamente a Maturana y la definición que él hace de lenguaje:

El lenguaje como fenómeno biológico consiste en un fluir en interacciones recurrentes que constituye un sistema de coordinaciones conductuales consensuales de coordinaciones conductuales consensuales... De esto resulta que el lenguaje como proceso no tiene lugar en el cuerpo (sistema nervioso) de los participantes en él, sino que en el espacio de coordinaciones conductuales consensuales que se constituye en el fluir de sus encuentros corporales recurrentes. H.Maturana, Ontología del Conversar, Revista Terapia Psicológica, 1988, p.16. Con la definición anterior se da cuenta de la existencia de un nuevo dominio, aquel que se establece entre los individuos participantes de la conversación. Es un dominio consensual que surge en el espacio de las interacciones recurrentes de los participantes: Las fuentes de perturbación para un organismo incluyen a otros organismos de igual y diferente clase. En la integración entre ellos, cada organismo sufre un proceso de acoplamiento estructural debido a las perturbaciones generadas por los otros. Este proceso mutuo puede conducir a modelos de conducta entrelazados que forman un dominio consensual. F.Flores, T.Winograd, Hacia la Comprensión...,p.79 Así, según lo anterior, existirían en este problema a lo menos tres dominios, el del usuario, el del desarrollador y, finalmente, el conformado por la conversación entre estos dominios, o como Maturana lo llama, un dominio consensual. Y la implicancia que esto tiene es que tanto el prototipo como las especificaciones pertenecen a este dominio y no al dominio del usuario o al del desarrollador. Son así producto de un consenso entre estos dominios disjuntos más que un reflejo de los requerimientos del usuario, independiente de la visión que tenga éste como observador del dominio consensual, quien si podría observar este reflejo de sus requerimientos.

Así, el aporte de la visión constructivista está dada por la imposibilidad de que un usuario pueda "transmitir información" sobre sus necesidades a un desarrollador en el proceso de desarrollo de software -necesidades que quizá no están tan claras, viéndolo desde la perspectiva hermenéutica.

 

El Sistema Social luhmanniano

El software es desarrollado a la medida, generalmente para satisfacer las múltiples necesidades de manipulación de datos que tiene una organización productiva, y en ese sentido el software tiene una dimensión social, independiente de otras que desde otras miradas pueden resultar importantes.

En un sentido general, el software sería en parte el resultado de una decantación, en su estructura, de las acciones, conversaciones, decisiones, etc. que conforman lo social de una empresa, generalmente se dice metafóricamente que contienen las decisiones estructuradas de la organización.

Ésta característica de ser un decantador de procedimientos, procesos, decisiones, etc. que tiene el software se debería, en parte, a que lo que se refleja en el software no serían las necesidades particulares de los usuarios, sino, más que eso, se reflejaría la empresa como sistema social, independiente de las personas que la componen como miembros.

La existencia de dos dominios -del usuario y del desarrollador- entre los cuales no eran posibles las transferencias de información al ser cerrados, hace surgir un tercer dominio, el que H.Maturana llama el dominio consensual, que se puede visualizar -esquemáticamente- entre los dos anteriores y corresponde a las coordinaciones consensuales que permiten aproximar los dominios iniciales. Este tercer dominio se da en el lenguaje, al cual H.Maturana llama recursivamente, sistema de coordinaciones conductuales consensuales de coordinaciones conductuales consensuales.

Es el dominio del sistema social. Los sistemas sociales son interesantes ya que se está trabajando con la hipótesis de que el software es un reflejo, más que de las actividades de usuarios particulares, de la organización en que estos usuarios participan como miembros. Y, es en este sentido que el software no puede ni debe ser visto como un producto.

El sistema social surge, según Maturana, en el lenguaje y como un reflejo de las interacciones recurrentes entre dos o más individuos que van configurando al sistema social con sus acciones y su conducta. Para H.Maturana es constitutivo de un sistema social el que sus componentes sean seres vivos ya que sólo se constituye al conservar estos su organización y adaptación en él, en el proceso de integrarlo (Citado por D. Rodríguez, Estudios Sociales, 1986).

Según lo anterior, el tercer dominio y las personas que lo constituye serían, para Maturana, el Sistema Social. Y en este mismo sentido, el sistema social se constituiría por el amor, que sería la emoción básica que permitiría la conservación en el tiempo de la recurrencia de las interacciones que resultan de la coordinación conductual de sus miembros (D.Rodríguez, Estudios Sociales, 1986). Además, al definir Maturana el sistema social como un sistema formado por seres humanos que se aceptan mutuamente, lo obliga a aceptar que puede haber relaciones que no cabrían en su concepto de lo social, por ello el establece que las empresas no serían sistemas sociales sino sistemas productivos, sustentados en relaciones productivas o de trabajo, que no suponen la aceptación del otro, sino su negación y el intento de controlarlo (D.Rodríguez, Estudios Sociales, 1986).

Finalmente, para H.Maturana el sistema social humano constituido por seres humanos es alopoiético. Se encuentra formado por elementos que son autopoiéticos y lo que le interesa mantener es la autopoiésis de esos elementos (D.Rodríguez, Estudios Sociales, 1986).

De la perspectiva de Maturana el sistema social no tendría la autonomía que, implícitamente, se le ha conferido al describirlo como un tercer dominio que surge entre dos o más personas que se relacionan recurrentemente. Pero, esa perspectiva es limitante.

Las limitaciones que tiene la teoría de Maturana en relación a sus consideraciones sobre los sistemas sociales está relacionadas primero, con la diferenciación que se hace entre sistema social y sistema productivo -por dar algún ejemplo; aquello parece válido para la sociedad actual diferenciada, pero no significa que las emociones surjan y se mantengan constituyendo un sistema en su estado puro, el emocionar no sería una fuente de constantes que signifiquen la constitución de sistemas, por ejemplo, en una empresa familiar el sistema social estaría tan imbricado con el sistema empresarial -cuando funciona en el patio de la casa-, que no se podría distinguir lo uno de lo otro, lo que, en un extremo, haría necesario una nueva distinción para decir que este es un sistema socio-empresarial. Por otra parte, no parece ser muy clara la razón de la consideración de los seres humanos como pertenecientes al sistema, lo que lo hace alopoiético, ya que, en ese sentido, es válida la crítica anterior, por ejemplo las preguntas serían: ¿cómo distinguimos que una persona está en un sistema u en otro?, ¿mediante qué criterio se puede distinguir si una persona está realizando con su conducta el sistema social o el sistema productivo?

La noción de sistemas autopoiéticos propugnada por H.Maturana ha significado una profunda revisión de los elementos de la Teoría de Sistemas, en tal sentido se habla de que los sistemas autopoiéticos serían un nuevo paradigma que viene a extender el paradigma anterior de von Bertalanffy, aquel que explicaba los sistemas abiertos. Así, la noción de autopoiésis resulta emblemática en este repensar de la Teoría de Sistemas y esto avala la creencia que otros sistemas, además de los seres vivos, pueden tener organización autopoiética.

Así, el sistema social desde la perspectiva limitante de Maturana, se explica más bien como un intento de preservar la noción de autopoiesis como la distinción que caracteriza a los seres vivos, más que de dar cuenta de una nueva clase de sistemas, los sistemas autopoiéticos.

Independiente de las otras teorías que buscan explicar lo social -incluida la de Maturana- éste punto se organiza, para estos fines, alrededor de la teoría de Niklas Luhmann.


Los sistemas sociales como sistemas autopoiéticos de comunicaciones.

El trabajo teórico de Niklas Luhmann es impresionante en términos del volumen en su producción y, primordialmente, de potencialidad para entender lo social, y, más concretamente, como es el caso de esta tesis, aprovecharlo.

No se pretende profundizar teóricamente en los múltiples tópicos que significa el trabajo de Luhmann, sólo se explicará lo que es útil para los fines buscados y cómo eso permite replantear el trabajo de desarrollo de software en una organización.

A diferencia de H.Maturana, Luhmann si considera que el sistema social es un sistema autopoético, con todas las características de éste, y lo articula como un sistema basado en el sentido:

Los sistemas sociales son sistemas autorreferenciales, que se diferencian respecto a un entorno. Los elementos del sistema social son comunicaciones que van encadenándose unas a otras y generando -y siendo generadas por- un sentido intersubjetivo, que establece los límites del sistema. Los sistemas sociales no tienen límites físicos, sino límites de lo que puede ser relevante en términos de sentido. D.Rodríguez, citando a Luhmann, Estudios Sociales, 1986. Con lo anterior, los seres humanos quedan fuera del sistema social, formando su entorno. El sentido es lo que permite determinar si algo pertenece al sistema social o a su entorno, con ello se supera la necesidad de una emocionalidad constituyente y así todo sistema puede referirse a sí mismo para constituirse, deja de ser alopoiético desde esta perspectiva. El que Luhmann diga que un sistema social es un sistema autopoiético constituido y constituyentes de sentido, cuyos elementos son las comunicaciones; no remite a la importancia de liberar a la autopoiésis del contexto de los seres vivos.

Una comunicación, para Luhmann, es distinta de una acción. Así, de la misma forma que los seres humanos quedan fuera del sistema, también las acciones quedan fuera, ya que son elementos subjetivos asimilables a las personas. Pero, la tematización de la acción, por otra parte, sí puede pertenecer al sistema, ya que en ese sentido es una conmunicación. Aclaratorio de lo anterior resulta lo siguiente:

...para Luhmann... La unidad elemental del sistema social autopoiético es la comunicación y no la acción (Luhmann, 1986c), puesto que la comunicación es siempre necesaria e inherentemente social y la acción no. La acción social,..., involucra la comunicación... la comunicación tiene un significado mayor que la pura expresión y envío de un mensaje. La comunicación consumada requiere comprensión y la comprensión no es parte de la actividad del comunicador ni puede ser atribuida a éste... aunque los sistemas sociales no se componen de acciones ni tampoco de "acciones comunicativas" (como diría Habermas), requieren la atribución de acciones para continuar la autopoiesis... Esto significa que esta atribución es la que permitiría a la comunicación hacerse reflexiva: comunicar acerca de la comunicación. Sólo cuando se sabe quién dijo qué es posible hacer esta reflexión... Esto quiere decir que la comunicación sólo es posible como proceso autorreferente. Cada nueva comunicación será utilizada para comprobar si se ha entendido o no la comunicación previa. D.Rodríguez, M.Arnold, Sociedad y Teoría de Sistemas, pp. 116-117. La acción pertenece al sistema cuando es tematizada por el sistema, es decir, cuando se habla de la acción, entonces en ese momento esas unidades de conversación que describen una o un conjunto de acciones, pasan a ser del sistema social y es en este sentido que los procedimientos y políticas de una empresa son tratados por la teoría propuesta por Luhmann. Además, en la referencia anterior, se da cuenta de la justificación dada para la autorreferencialidad del sistema, en términos de comunicaciones, dejando de lado, definitivamente, las acciones. Que las comunicaciones puedan provocar acciones, nadie lo discute, sólo que estas acciones no pertenecerían al sistema social.

También, es importante la noción de tematización, es claro que este proceso determina lo que pertenece o no al sistema, o como es posible incorporar elementos al sistema. Por ejemplo:

...se podría decir que los sucesos externos pueden afectar al sistema: una tempestad, por ejemplo, puede ser tematizada en el lenguaje y la comunicación, pero no puede -sin más- entrar con sus ruidos a formar parte del sistema comunicativo...si hay una tempestad y la gente continúa hablando, esta tempestad no constituye información. Si, en cambio, es tematizada, entonces es información, porque al ser hecha en la conversación, ha pasado a formar parte de la comunicación. D.Rodríguez, Estudios Sociales, 1986. Se entiende por información el de perteneciente al sistema, todo lo que pertenece al sistema es información para el sistema, desde el mismo sistema. Por la clausura operacional que éste sistema de comunicaciones tendría, se considera que una comunicación que pertenece a un sistema no podría ser transmitida tal cual a otro sistema social, las diferencias de sentido obligan a que esa comunicación sea tematizada por el otro sistema para que pase a formar parte de él. Lo que lleva a la manifestación de la autopoiesis sistémica, comunicaciones que generan comunicaciones.

El surgimiento del sistema social, según Luhmann, esta condicionado a la doble contingencia, si no existiese la doble contingencia, no existirían los sistemas sociales. Contingente es aquello que no es necesario ni imposible; algo que puede ser como es, pero que también podría ser de otra forma (Luhmann, 1984. Citado por Rodríguez). Así, la doble contingencia surge cuando existen dos sistemas que se identifican como sistemas que manejan contingencia, por ejemplo:

La doble contingencia constituye un problema en la construcción del sentido. La generación de un sistema social supone la restricción de las posibilidades de ego (uno) y de alter (otro). Por consiguiente, condiciona el surgimiento de sistemas sociales. El sentido, al constituirse intersubjetivamente, supone la complejidad y la contingencia de ambos sistemas-sujetos y la emergencia del sistema social a partir de la selectividad compartida y definitoria de lo propio de ese sistema (Rodríguez, 1985, p.25)...Un sistema experimenta la contingencia de otros sistemas como inseguridad de expectativas; la propia contingencia, en cambio, es experimentada por el sistema como alternativas de elección (Willke, 1982, p.29)... Podemos definir sentido, entonces, como "la forma común de identificación de objetos, hecha por diferentes sujetos, en relación con su aproximación a la meta, mediante la reducción de complejidad, e.d., las formas comunes de selección que se producen a pesar de la diferencia entre los sujetos" (Hejl, 1974, p. 198). D.Rodríguez, M.Arnold, Sociedad y Teoría de Sistemas, p.105 La contingencia es propia de los sistemas, y lo que buscan los sistemas sociales es disminuirla. La doble contingencia es constituyente del sistema social, ya que es lo que le provee sentido, este sentido es lo que podemos relacionar con las coordinaciones consensuales mutuas que para H.Maturana existen como lenguaje.

Luhmann, por otra parte, hace notar que hay una diferencia de complejidad entre el sistema y su entorno, dice que el entorno siempre será más complejo que el sistema, entendiéndose complejidad como la cantidad de elementos y relaciones que existen entre ellos. El sistema busca reducir la complejidad del entorno, actuando selectivamente con las multiples alternativas que se le presentan en el entorno y en esta selección el sentido se vuelve central.

Una consideración en la teoría de Luhmann, entre muchas, es la importancia del tiempo, independiente que considere que los sistemas autopoiéticos sean no teleológicos y que existen en el presente, el tiempo para Luhmann es la base para la presión de selección en sistemas complejos, puesto que si hubiera un tiempo ilimitado disponible, podría ser todo armonizado con todo. Además, para Luhmann, la diferencia de complejidad también está en el tiempo, sólo se puede producir una diferencia de complejidad entre sistema y entorno cuando surge tiempo propio del sistema el que a su vez, debe adecuarse al tiempo del mundo. Por último:

...cada unidad comunicativa tiene una dimensión temporal, cada unidad se encuentra sometida a la irreversibilidad del tiempo. Cada unidad comunicativa, cada suceso debe conectarse con otros sucesos para que el sistema continúe existiendo: el sentido permite mantener la identidad del sistema, en una constante inquietud, en un cambio permanente de sucesos que pueden variar, negar lo anterior o repetirlo. Gracias a esta constante generación de sucesos, a esta inquietud sistémica permanente, es posible que el sistema permanezca, se regenere, se adapte a un entorno que también se encuentre en constante vibración. D.Rodríguez, Estudios Sociales, 1986, pp 24-25. Lo que confirmaría la improbabilidad de la estabilidad social. La autopoiesis del sistema obliga a que se esté modificando constantemente la estructura, ya sea para confirmarla como para adecuarla a nuevas situaciones.

La contingencia trae de la mano la noción de posibilidad, para Luhmann un hecho es contingente cuando es visto como selección entre otras posibilidades, las que, a pesar de la selección, de alguna forma permanecen en cuanto posibilidades (D.Rodríguez, M.Arnold, Sociedad y Teoría de Sistemas, p.104). La doble contingencia también puede ser vista como selección entre posibilidades; de la misma forma que la selección se puede ver como la negación de posibilidades, actualizando una única, la doble contingencia implica a esta capacidad de negar en el hecho que dos sistemas dotados de ella puedan ir adecuando mutuamente sus selecciones, conformando un dominio de recurrencias. Así, el espacio de posibilidades es importante ya que se traduce en el grado de selectividad que posea el sistema, y cada selección de posibilidades que se haga, negaría a las otras, pero no la eliminaría; así, se puede negar la negación y reactualizar esas posibilidades. Además, al actualizar una posibilidad se modifica el espacio de posibilidades del sistema, en el sentido que algunas posibilidades serían más atingentes que otras. Finalmente, las posibilidades aunque se nieguen siguen existiendo como posibilidades y lo único que elimina una posibilidad es el tiempo, por ejemplo:

La negación no es eliminación sino un modo de mantenimiento del sentido (...) Esto significa que, cambiando el sentido, sería posible actualizar otra de las posibilidades que habían sido negadas, salvo los casos en que el tiempo ya las haya dejado no disponibles: "Sólo el tiempo, no la negación, elimina definitivamente las posibilidades" (...). D.Rodríguez, M.Arnold, Sociedad y Teoría de Sistemas, p.112. Así, para Luhmann, el tiempo tiene la propiedad de ser lo único que elimine las posibilidades no actualizadas. Lo que significaría que, si el sistema requiere un espacio de posibilidades actualizadas, periódicamente tiene que volver y reconstituir las posibilidades como posibilidades, de forma similar como las comunicaciones se mantienen reflexionando y produciendo comunicaciones.

Por último, la relación que existe entre el sistema social y los seres humanos está dada por una imbricación existencial estrecha, en el sentido que es necesario que existan los sistemas psíquicos para que el sistema social exista, lo que también es válido en el sentido contrario, aunque no tan evidente.

Luhmann sostiene que los sistemas psíquicos y los sistemas sociales han surgido coevolutivamente. Sin embargo, como ambos tipos de sistemas son autopoiéticos, clausurados operacionalmente y autorreferentes, no es posibles reducirlos uno a otro en su reproducción ni en sus unidades elementales. Se trata de una "diferencia autopoiética", y no existe un supersistema autopoiético que pudiera integrar como unidades a estos dos sistemas. Esto significa,..., que la conciencia no pertenece ni ingresa en la comunicación, y que tampoco la comunicación pertenece o penetra en la conciencia (Luhmann, 1984a, p.367) ...El sentido es el logro de esta coevolución que se expresa en que, tanto el sistema psíquico de conciencia como el sistema social, utilizan el sentido como estrategia selectiva que permite destacar la alternativa escogida de las otras posibilidades no actualizadas, haciendo uso de la negación y de la negación reflexiva.... La relación entre el sistema social y el sistema psíquico no solamente se refiere al sentido. Se trata de una relación de acoplamiento estructural en que ambos sistemas conservan la adaptación... la comunicación continúa o termina y esto depende de la estructura de la comunicación, pero si continúa es porque está adaptada a los sistemas de conciencia de quienes, con sus comunicaciones, constituyen el sistema social. D.Rodríguez, M.Arnold, Sociedad y Teoría de Sistemas, pp. 121,122. Es así, como Luhmann da cuenta del tercer dominio que surge entre un usuario y un desarrollador, el dominio de las comunicaciones, que sería a su vez cerrado. Esto no tiene tanta importancia si se remite la discusión al ámbito de un usuario y de un desarrollador, pero sí cobra una gran importancia al ver la empresa como un sistema autopoiético de comunicaciones, en ese sentido el dominio particular del usuario tiene una importancia menor frente a este nuevo dominio, el cual sería el que necesariamente debe ser representado, descrito, etc., si se quiere desarrollar un software "a la medida".

No tiene sentido, para los objetivos de este apunte, profundizar en la teoría de Luhmann más allá de lo que se ha bosquejado. Lo importante es tener claro que este análisis teórico nos ahonda el problema que arrastran los métodos tradicionales, la Ingeniería de Software obliga a los desarrolladores, producto de sus métodos, a ser observadores de la observación que hacen otros del sistema empresa, lo que significaría una doble distorsión que determina distancias conceptuales importantes entre lo que se quiere y lo que realmente se puede. Eso, dejando de lado la distinción entre los dominios del hacer y del diseñar que hemos detectado en un usuario, que si bien pueden ser fuertemente imbricados, los métodos de la Ingeniería de Software profundizan la distinción, haciendo que los ambientes de trabajo y de diseño sean distintos: no es posible ver una entrevista de análisis de requerimientos como formando parte del sistema de trabajo que se quiere modelar.

Antes de construir un escenario para la solución que se propugna a este dilema, es necesario ver la aplicación de la teoría de Luhmann a los sistemas organizacionales. Al igual que Maturana, Luhmann hace una distinción entre el sistema social y el sistema organizacional. Así, las particulares implicancias que tiene la teoría para este tipo de sistemas pueden ser revisadas.


Los sistemas organizacionales como sistemas autopoiéticos de decisiones.

La distinción que hace Luhmann entre los sistemas sociales y los sistemas organizacionales radica en la naturaleza de los elementos que hacen posible la autopoiesis, para los primeros son las comunicaciones, para los segundos son las decisiones.

Luhmann define la organización como un sistema social constituido por decisiones interrelacionadas. En otras palabras, los elementos constituyentes de un sistema organizacional son las decisiones...Un sistema complejo formado por decisiones, supone que éstas servirán como premisas para otras decisiones. Además, la selección entre alternativas significa que se elige una de entre varias alternativas y que -con esta selección- se producen y se impiden relaciones con otras decisiones (Luhmann, 1978). Citado por D.Rodríguez, Revista de Ingeniería de SIstemas, Junio de 1990, p.45. Los sistemas organizacionales, como se ve, tienen las mismas características que los sistemas sociales, pero se diferencian en los elementos constituyentes: las decisiones. En el caso de las organizaciones, las decisiones -en cuanto elemento constituyente- sólo pueden descomponerse en decisiones y sólo pueden mejorarse mediante decisiones, dado que los sistemas no pueden cambiar el nivel de emergencia de sus elementos... D.Rodríguez, Revista de Ingeniería de SIstemas, Junio de 1990, p.45. Así, todo lo que puede ser tematizado como una decisión pertenece al sistema organizacional, lo que no, entonces no pertenece. Por ejemplo, los miembros de una organización no pertenecen a esta por el hecho de estar en ella físicamente o realizando las acciones que se supone componen el hacer de la organización, sino que necesariamente deben ser incorporados como decisiones. La organización,..., adopta decisiones respecto a sus miembros, y las actuaciones de éstos sólo tendrán un sentido organizacional si pueden ser conceptualizadas, a su vez, como decisiones: de participar, de aceptar las reglas, de no participar, de retirarse, de exigir cambios, etc. Toda acción que no se conceptualice como decisión no tendrá efecto organizacional alguno, porque el sistema organizacional de decisiones es cerrado operacionalmente y se encuentra determinado estructuralmente, es decir, sólo puede recibir perturbaciones que conduzcan a cambios de estado determinados en la misma estructura de decisiones de la organización. D.Rodríguez, Revista de Ingeniería de SIstemas, Junio de 1990, p.46. Lo que constituye el sistema organizacional, las decisiones, hace necesario que la definición del entorno de la organización también se haga en esos términos, de manera que sean comprensibles para ella, por ejemplo: los clientes deciden comprar o no hacerlo, los eventuales proveedores deciden vender o no; el gobierno decide elevar o reducir los impuestos, etc.

Por todo lo anterior, si se desea intervenir una organización, esto necesariamente debe quedar subordinado a la autopoiésis sistémica, esto quiere decir que una acción no perteneciente a la organización no puede pasar a formar parte del sistema organizacional, pero puede provocar decisiones que lo alteren. Ahora, esto necesariamente deberá implicar un cambio en el sentido, esto es, en la forma que se define lo que pertenece y lo que no pertenece a la organización. Con lo anterior se está diciendo que el cambio está incorporado en la definición misma del devenir organizacional. Las organizaciones se encuentran en una constante modificación y no es posible comprenderlas ya como un ente estático.

Por otro lado, las intervenciones externas deben ser conceptualizadas en términos del sentido de la organización, pero esto sólo puede hacerse desde el mismo interior de la organización, no es posible cambiar el sentido mediante intervenciones externas. Por ejemplo, como se observaba en párrafos anteriores, cambiando el sentido, sería posible actualizar otras posiblidades que habían sido negadas y ello no podría ser al revés, actualizar una posibilidad, entonces, no podría cambiar el sentido de la organización, por que actualizarla significaría que el sentido ya ha cambiado.

Es posible intervenir en la organización, pero siempre es necesario tener presente que la intervención constituye un factor ajeno a la autopoiesis del decidir organizacional y no es parte de ella. Esto quiere decir, en otras palabras, que la relación de la organización con sus miembros, la de la organización y sus proveedores, la de la organización y sus clientes, etc., no podrá ser mejorada a través de la simple buena intención o de informes más o menos concienzudos hechos por los agentes de cambio. La única posibilidad efectiva de hacer intervenciones en una organización consiste en la alteración del sentido organizacional, esto es, de las premisas aceptadas como válidas en el decidir dentro de la organización y esta alteración deberá estar dentro de las posibilidades de la organización. Nadie puede cambiar a una organización, es la organización que cambia. Rodríguez, Revista Ingeniería de Sistemas, Junio de 1990, p.48. La opinión anterior es de tener en cuenta en el área de desarrollo de software, independiente de cualquier consideración, el software, como está planteado en la actualidad, es una intervención en la organización, que por la forma en que es desarrollado tiene muchas posibilidades de no corresponder completamente al sentido de la organización, lo que justificaría, desde otra perspectiva la primera ley de Lehmann, en relación al cambio que significa la construcción e instalación de un software "a la medida" para una organización, al incorporarlo produciría problemas. Probablemente existan -dentro del software- elementos que no correspondan con el sentido de la organización y que podrían llevar a crisis de sentido o a la necesidad de modificar el software.

Este vistazo general, nos permite plantear un nuevo escenario para el desarrollo de software.

Un primer bosquejo de una solución al problema estaría dado por aceptar que las conversaciones son constituyentes en la organización, ya sea desde el punto de vista de H.Maturana -que utiliza F.Flores, con en beneplácito de éste- o desde el punto de vista de Luhmann, que por ser más radical y sin ningún compromiso con la noción original de autopoiesis permite el desarrollo de una teoría que resulta quizá más exacta en su intento de explicar el fenómeno.

Primero, aceptar el rescate de las comunicaciones, en general, como unidades mínimas constituyentes de la organización, por sobre otro tipo de particularizaciones como la acción, o las conversaciones para la acción o las decisiones, aunque estas últimas, como se vio, serían una subclase de las comunicaciones que tienen sentido en una organización. Así, el software debe reflejar, principalmente comunicaciones, es decir, debería ser un vehículo que apoye las comunicaciones que constituyen la totalidad o parte de la organización. Eso por una parte.

En segundo término, el software debe ser flexible, el apoyar las comunicaciones que componen una organización debe permitir que estas se desarrollen sin limitaciones de ningún tipo. En este sentido, debería ser considerado más un apoyo a la conversación y al devenir organizacional que un elemento que interviene la organización. El software debe ser considerado como la organización misma o como parte de ella, debe ser, necesariamente parte del esquema de tematización de las conversaciones. Si, el software debe apoyar los procesos de tematización y de autopoiésis del sistema, uno que permita incorporar observaciones y el otro que permita crear nuevos elementos organizacionales a partir de los anteriores.

Por último, el software no puede ser controlado por un desarrollador ajeno a la constitución del sistema organizacional, independiente si es miembro o no de la organización. En este sentido lo más adecuado es que el propio usuario, de la misma manera que participa en la creación y el mantenimiento de las comunicaciones, debería participar en la creación y el mantenimiento del software.

SUBIR
 

Conceptualización del Software Educativo


Lo forman los programas educativos y programas didácticos creados con la finalidad específica de ser utilizados como para facilitar los procesos de enseñanza y de aprendizaje.

Son interactivos, contestan inmediatamente las acciones de los estudiantes y permiten un diálogo y un intercambio de informaciones entre el computador y los estudiantes.

Individualizan el trabajo de los estudiantes ya que se adaptan al ritmo de trabajo de cada uno y pueden adaptar sus actividades según las actuaciones de los alumnos.

Son fáciles de usar. Los conocimientos informáticos necesarios para utilizar la mayoría de estos programas son similares a los conocimientos de electrónica necesarios para usar un vídeo, es decir, son mínimos, aunque cada programa tiene unas reglas de funcionamiento que es necesario conocer.

Estructura Básica de los Programas Educativos


La mayoría de los programas didácticos, igual que muchos de los programas informáticos nacidos sin finalidad educativa, tienen tres módulos principales claramente definidos: el módulo que gestiona la comunicación con el usuario, el módulo que contiene debidamente organizados los contenidos informativos del programa y el módulo que gestiona las actuaciones del computador y sus respuestas a las acciones de los usuarios.

El entorno de comunicación o interfaz


La interfaz es el entorno a través del cual los programas establecen el diálogo con sus usuarios, y es la que posibilita la interactividad característica de estos materiales. Está integrada por dos sistemas:

Las bases de datos


Las bases de datos contienen la información específica que cada programa presentará a los alumnos.

El motor o algoritmo


El algoritmo del programa, en función de las acciones de los usuarios, gestiona las secuencias en que se presenta la información de las bases de datos y las actividades que pueden realizar los alumnos.

Categorización de los Programas Didácticos

Según su naturaleza infomática, los podemos categorizar como:

De consulta

como por ejemplo los atlas geográficos y los atlas biológicos

Tutoriales


Son aquellos que transmiten conocimiento al estudiante a través de pantallas que le permiten aprender a su propio ritmo, pudiendo volver sobre cada concepto cuantas veces lo desee.

Ejercitación


Permiten al estudiante reforzar conocimientos adquiridos con anterioridad, llevando el control de los errores y llevando una retroalimentación positiva. Proponen diversos tipos de ejercicios tales como "completar", "unir con flechas", "selección múltiple" entre otros.

Simulación


Simulan hechos y/o procesos en u entorno interactivo, permitiendo al usuario modificar parámetros y ver cómo reacciona el sistema ante el cambio producido.

Lúdicos


Proponen a través de un ambiente lúdico interactivo, el aprendizaje, obteniendo el usuario puntaje por cada logro o desacierto. Crean una base de datos con los puntajes para conformar un "cuadro de honor"

Micromundos


Ambiente donde el usuario, explora alternativas, puede probar hipótesis y descubrir hechos verdaderos

Funciones del Software Educativos


Los programas didácticos, cuando se aplican a la realidad educativa, realizan las funciones básicas propias de los medios didácticos en general y además, en algunos casos, según la forma de uso que determina el profesor, pueden proporcionar funcionalidades específicas.

Funciones que pueden realizar los programas

Función informativa


La mayoría de los programas a través de sus actividades presentan unos contenidos que proporcionan una información estructuradora de la realidad a los estudiantes.


Los programas tutoriales y, especialmente, las bases de datos, son los programas que realizan más marcadamente una función informativa.

Función instructiva


Todos los programas educativos orientan y regulan el aprendizaje de los estudiantes ya que, explícita o implícitamente, promueven determinadas actuaciones de los mismos encaminadas a facilitar el logro de unos objetivos educativos específicos.


Con todo, si bien el computador actúa en general como mediador en la construcción del conocimiento y el metaconocimiento de los estudiantes, son los programas tutoriales los que realizan de manera más explícita esta función instructiva, ya que dirigen las actividades de los estudiantes en función de sus respuestas y progresos.

Función motivadora


Generalmente los estudiantes se sienten atraídos e interesados por todo el software educativo, ya que los programas suelen incluir elementos para captar la atención de los alumnos, mantener su interés y, cuando sea necesario, focalizarlo hacia los aspectos más importantes de las actividades.

Función evaluadora


La interactividad propia de estos materiales, que les permite responder inmediatamente a las respuestas y acciones de los estudiantes, les hace especialmente adecuados para evaluar el trabajo que se va realizando con ellos.

Función investigadora


Los programas no directivos, especialmente las bases de datos, simuladores y micromundos, ofrecen a los estudiantes, interesantes entornos donde investigar: buscar determinadas informaciones, cambiar los valores de las variables de un sistema, etc.


Además, tanto estos programas como los programas herramienta, pueden proporcionar a los profesores y estudiantes instrumentos de gran utilidad para el desarrollo de trabajos de investigación que se realicen básicamente al margen de los computadores.

Función expresiva


Dado que los computadores son unas máquinas capaces de procesar los símbolos mediante los cuales las personas representamos nuestros conocimientos y nos comunicamos, sus posibilidades como instrumento expresivo son muy amplias.

Función metalinguística


Mediante el uso de los sistemas operativos (MS/DOS, WINDOWS) y los lenguajes de programación (BASIC, LOGO...) los estudiantes pueden aprender los lenguajes propios de la informática.

Función lúdica


Trabajar con los computadores realizando actividades educativas es una labor que a menudo tiene unas connotaciones lúdicas y festivas para los estudiantes.

Función innovadora


Aunque no siempre sus planteamientos pedagógicos resulten innovadores, los programas educativos se pueden considerar materiales didácticos con esta función ya que utilizan una tecnología recientemente incorporada a los centros educativos y, en general, suelen permitir muy diversas formas de uso. Esta versatilidad abre amplias posibilidades de experimentación didáctica e innovación educativa en el aula.


 
  SUBIR

Tipos de Software Educativos

Se define como cualquier programa computacional cuyas características estructurales y funcionales sirvan de apoyo al proceso de enseñar, aprender y administrar.

Otro concepto lo define como aquél material de aprendizaje especialmente diseñado para ser usado por un computador en los procesos de enseñar y aprender.

CLASIFICACIÓN DE LOS SOFTWARE EDUCATIVOS.

Según la forma como se articulan con el aprendizaje y nivel cognitivo.

· Software de Presentación

Programa que presenta información y conocimientos bajo un modelo Tutorial de aprendizaje, don de usualmente la modalidad de interacción con el usuario se basa en un ciclo contenido – preguntas – presentación – preguntas.

· Software de Representación

Trata la información y conocimiento de la misma forma como éstos hipotéticamente se organizan y representan en las estructuras mentales de los usuarios. (su navegación y la interacción con el usuario intentan imitar la forma como se almacenaría la información en la memoria).

· Software de Construcción

Está centrado en el aprendiz y entrega herramientas, materiales, elementos y estrategias para que este construya y reconstruya su conocimiento.

Según sus características fundamentales se clasifican en:

· Ejercitación

Programas que intentan reforzar hechos y conocimientos que han sido analizados en una clase expositiva o de laboratorio.

· Tutorial

Presentan información que se plasma en un diálogo entre el aprendiz y el computador.

· Simulación

Son modelos de algunos eventos y procesos de la vida real, que proveen al aprendiz de medios ambientes fluidos, creativos y manipulativos.

· Juegos Educativos

Es similar a las simulaciones, la diferencia radica en que incorpora un nuevo componente: la acción de un competidor, el que puede ser real o virtual.

· Material de Referencia

Usualmente presentado como enciclopedias interactivas. (Encarta 2000)

· Edutainment

Software que integra educación y entretenimiento, en el cual cada uno de éstos elementos juega un rol significativo y en igual proporción.

· Historia y Cuentos

Presentan al usuario una historia multimedial, la cual se enriquece con un valor educativo.

· Editores

No dan respuestas a preguntas del usuario, sino da un marco de trabajo donde el usuario pueda diseñar, crear y experimentar libremente en un dominio gráfico o similar.

· Hiperhistorias

Software donde a través de una metáfora de navegación espacial se transfiere una narrativa interactiva.

· Otros.

ANALIZANDO SOFTWARE EDUCATIVOS.

ABRAPALABRA.

Software para ser usado por usuarios entre los 4 a 8 años de edad, para el sector de Lenguaje y Comunicación.

Su navegación es secuencial o lineal, guiada o libre y complementada por íconos. El programa está estructurado en 70 unidades de aprendizaje, conformado por 160 ejercicios.

Está planteado en la categoría Autoría y Juegos.

El software está destinado al desarrollo de habilidades relacionadas con el aprendizaje de la lectura para los niveles de apresto, lectura inicial y comprensión lectora.

Requerimientos técnicos: Windows, Procesador 486, 8 MB de memoria RAM, 10 MB de memoria en disco duro, lector de CD, parlantes o audífonos, monitor color.

FINE ARTIST.

Software destinado a usuarios entre los 8 y 14 años, está compuesto por una amplia gama de herramientas organizadas en una barra de botones, las cuales permiten realizar diferentes trabajos como crear dibujos, tiras cómicas, realizar proyectos de pintura, etc.

Las herramientas que presenta este software están constituidas por 72 tipos de pinceles, alrededor de 100 dibujos predeterminados (pegatinas). Paletas de colores, diseños y texturas diferentes.

Fine Artist resulta apropiado para ser trabajado en dos áreas del aprendizaje: Lenguaje y Comunicación y Artes.

Está planteado en la categoría de Editores.

JUEGA CON LAS MATEMÁTICAS.

Software destinado a usuarios entre los 7 y 11 años para el sector Matemáticas.

Su navegación se realiza a través de botones. Desde una máquina del tiempo el usuario viaja a antiguas civilizaciones(Imperio Azteca, Atlántida, Grecia, Egipto) donde debe resolver problemas aritméticos para desarrollar los hábitos del cálculo numérico, trabajar con formas geométricas y aprender a medir y ordenar. Permite a los usuarios trabajar en forma grupal e individual y de acuerdo a los ritmos de aprendizaje de estos.

Subsector: Matemáticas. Categoría: Autoría y Juegos.

LA MÁQUINA DE HACER TAREAS.

Software destinado a usuarios de Educación básica, contiene 12 discos compactos y su navegación se realiza mediante botones.

Al acceder a cada disco, se entra en una pantalla, común a todos. Permite realizar actividades como copiar, pegar, recortar, importar y exportar, hacer, guardar, imprimir y presentar fichas, con la información que hay en los contenidos.

Disco 1:”El espacio”: Sistema Solar, Universo y cuerpos celestes.

Disco 2:”Planeta Tierra”: Tierra y coordenadas geográficas.

Disco 3:”Cuerpo Humano”: Sistema del Cuerpo Humano.

Disco 4:”Mamíferos”: Seres Vivos”: características.

Disco 5:”Historia”: Prehistoria, Culturas de América Precolombina.

Disco 6:”Aves”: Características y hábitos.

Disco 7:”Geometría”: Figuras geométricas y aplicabilidad.

Disco 8:”Insectos”: Insectos y Arácnidos.

Disco 9:”Árboles y Plantas”: Partes y función, clasificación.

Disco 10:”Océanos y Mares”: Características, movimientos, relieve.

Disco 11:”Dinosaurios”: Origen, época, características, clasificación.

Disco 12:”Música”: Instrumentos, compositores y elementos de música.

UN SOFTWARE EDUCATIVO INTERESANTE DE TRABAJAR.

PAINTBRUSH.

Incorpora todas las características de interfaz gráfico de Windows. Presenta los siguientes elementos:

· Área de dibujo: Es el espacio donde se realizan los dibujos con el paintbrush.

· Caja de herramientas: Contiene las herramientas que se pueden usar para crear dibujos. Se pueden dibujar líneas, círculos, cuadrados, polígonos, llenar un área con un color, pintar como si se manejaran brochas o un vaporizador.

· Paleta: Contiene los colores y tramos de dibujo que se pueden usar.

· Ancho de línea: Contiene diferentes anchos de línea disponible para el lápiz, las líneas y bordes de círculos y polígonos.

· Spray: Se usa como un spray de pintura.

· Texto: Permite escribir texto en el área de dibujo.

· Goma de borrar: Permite eliminar los puntos de color al pasar por encima de ellos.

· Pincel: Permite dibujar a mano alzada formas y líneas.

SUBIR

 
  Modelo para el Desarrollo de Software Educativo

Modelo para desarrollo de software educativo:
Gratuito y en la red
Alfredo Campos Enríquez
Estudiante de Ciencias de la Computación. BUAP
Puebla, México
freddy@cs.buap.mx


En el presente artículo se exponen los motivos por los cuales el autor considera que debería hacerse desarrollo de software educativo enfocado hacia su libre acceso y distribución mediante la red.

El software educativo. ¿Qué es y para qué?
Podemos decir que en general se trata de cualquier pieza de software que tiene como objetivo final el de agregar conocimientos cierto grupo de individuos o a uno en particular.
En este sentido se sobreentiende que dicho software educativo debe estar adecuado en cuanto a su estructura, contenido y presentación sobre todo al sector social al que se pretenda llegar. No es lo mismo crear un programa para enseñarle el sistema solar a un niño de diez años que a un estudiante de licenciatura.

Lo anterior implica que debe tenerse cuidado al diseñar los contenidos, la presentación y muy especialmente, se debe poner atención en el modo de interacción que este software tendrá con el usuario final.

El Software educativo gratuito
En general en cualquier parte se entiende que el software en cualquier de sus presentaciones es de tipo comercial, o sea, que debemos pagar alguna cantidad de dinero para poder tenerlo, instalarlo y ejecutarlo, pero sin adquirir el derecho de prestárselo a alguien para que lo ejecute en su computadora. Esto vendría a ser un agravio a las leyes.
Parece un poco contradictorio esta concepción de la piezas de software, el educativo en particular ya que se supone que la educación y el acceso a los conocimientos debiera estar al alcance de todos y sin restricción alguna.

De este modo, tomando en consideración el modelo de desarrollo y distribución de la licencia GNU, se plantea la necesidad de crear software educativo gratuito, al cual pueda tener acceso un amplio sector poblacional.

Pero aún existirían ciertos inconvenientes, uno de ellos es el hacer que más gente tenga acceso a dicho software.

Software educativo en la red
En los párrafos anteriores se planteó la necesidad de hacer software educativo gratuito, y ahora se desarrollan algunas ideas a fin de proponer un método para su difusión y libre acceso.

Una vez que contamos con las piezas de software necesarias podrían colocarse en sitios web, los que brindarían el servicio de acceso a ellas en dos modos principalmente:

Servicio de descarga, mediante el cual, cualquier usuario puede hacerse de una copia del software para ejecutarla a su conveniencia en su propia computadora

Servicio de ejecución en línea, por el cual cualquier usuario que lo deseara podría ejecutar e interactuar con el sistema educativo de manera inmediata y sin necesidad de descargar nada en su disco.

Ésto puede sonarle muy utópico al lector pero puede visitar en la red varios sitios que demuestran los esfuerzos que se hacen en este sentido, por ejemplo el sitio de Open Class Room (http://www.openclassroom.org/) dedicado a integrar software educativo gratuito (GPL) a plataformas Linux, o un ejemplo un poco más modesto puede ser el del proyecto KoalAst ( http://www.cs.buap.mx/~freddy/KoalAst) que tiene un applet que recorre el sistema solar mediante imágenes.

Lamentablemente no todo es miel sobre hojuelas y todo este planteamiento tiene sus inconvenientes, entre los más grandes está el de que no toda la gente tiene acceso regular a la Internet, sobre todo las personas de escasos recursos económicos.

A modo de final se le propone al lector que de ser posible, lleve a cabo algún esfuerzo para poner al alcance de más gente los conocimientos, ya sean científicos, tecnológicos y/o culturales. Pues si este modelo de desarrollo se hace más común, entonces podremos alcanzar un par de metas específicas:

Involucrar en la divulgación a mucha más gente, que sólo los científicos

Lograr que la red se convierta en un espacio de aprendizaje y no solamente de entretenimiento.

SUBIR

EL PSICÓLOGO, COMO MIEMBRO DEL EQUIPO DE DISEÑO DE SOFTWARE EDUCATIVO

Por

VILMA A. SILVERA C.
mailto:vsilvera@keops.utp.ac.pa?subject=Comentario sobre artículo

RESUMEN


--------------------------------------------------------------------------------


En este artículo deseo ofrecerles mis impresiones sobre el papel que desempeña el psicólogo dentro del equipo de personas que participan en el diseño de software educativo. Todo software necesita de ciertas características de ingeniería de software, pero, me dedicaré a resaltar los aspectos psicopedagógicos y de diseño del sistema de comunicación entre hombre y máquina, aspectos éstos donde el psicólogo puede contribuir más, a fin de obtener un producto que reúna las mejores características para el proceso enseñanza-aprendizaje que los software apoyan.

--------------------------------------------------------------------------------

I- INTRODUCCIÓN

De acuerdo a Sánchez Ilabaca, software educativo es cualquier programa computacional cuyas características estructurales y funcionales le permiten servir de apoyo a la enseñanza, el aprendizaje y la administración educacional.

El software educativo es uno de los recursos más interesantes, necesarios y motivadores que se pueden utilizar para ayudar al desarrollo del proceso enseñanza-aprendizaje. Al introducir las computadoras en la educación, se produjo una forma más amena de aprender, logrando además la retención a más largo plazo del aprendizaje. Se han desarrollado una gran variedad de software educativos, pero aún queda mucho por hacer, sobretodo en países como el nuestro, donde la mayoría de ellos son importados. Entre los tipos de software educativos que existen en el mercado mundial, tenemos los siguientes: de ejercitación y práctica, tutoriales, juegos educativos, simulaciones y tutor inteligente.

En este artículo, resumiré los aspectos más relevantes del aporte del psicólogo educacional en el desarrollo y diseño de software educativo como son: las teorías de aprendizaje que sustentan el diseño de software educativo, las características del usuario y los aspectos motivacionales.

II- TEORÍAS QUE SUSTENTAN EL DISEÑO DE SOFTWARE EDUCATIVO

Los psicólogos, ayudarán a explicar la teoría que sustenta el software educativo y los aspectos psicopedagógicos que contiene. Los software educativos se fundamentan en una teoría de aprendizaje que puede ser conductista, cognoscitiva o constructivista. El diseño de software adoptado, condiciona una cierta forma de aprendizaje, debido a que la organización del contenido, actividades y formas de interacción están previamente establecidas.

Las teorías conductistas aportan ciertos principios a los programas actuales, como son:
descomposición de la información en pequeñas unidades
el diseño de actividades que requieren unas respuestas del usuario, y
la planificación del refuerzo

Uno de los aportes principales de la teoría cognoscitiva a los software educativos, es que ofrece pautas específicas y estrategias didácticas para su construcción Los psicólogos cognoscitivos al presentar la información insisten en que se realicen asociaciones globales que les permita procesar la información por su cuenta.

Las teorías constructivistas especifican el tipo de entorno de aprendizaje necesario para la construcción de software educativos. Los aspectos principales son: flexibilidad cognoscitiva (los hipertextos poseen esta característica, ya que su información se organiza de manera no lineal por lo que permite navegar; a través de la información), aprendizaje a través de actividades significativas, aprendizaje activo y el concepto de que los errores son fuente de aprendizaje.

III- IMPORTANCIA DEL DISEÑO DE INTERFAZ DE COMUNICACIÓN

El interfaz es la zona de comunicación entre el usuario y la máquina, de allí su importancia para la educación. Si los mensajes no lo comprende el usuario o no se adaptan a sus características especiales, por ejemplo, en este caso a los niños del nivel pre-escolar de la educación formal, el software no será muy adecuado para su uso. Los dispositivos de entrada y salida, las zonas de comunicación (menús, texto, apoyo gráfico, colores, balances de las figuras en la pantalla), van a contribuir a mejorar el entendimiento del usuario y la máquina, o al contrario, ser un obstáculo. La percepción influye también en esta comunicación, ya que el usuario de acuerdo a sus propias características perceptivas, prestará atención a una cosa u otra. El tipo de letra, velocidad con que pasan los párrafos, los sonidos, afectarán también a la comprensión del material. En resumen, el diseño de la interfaz en el software educativo va a contribuir a la motivación, interacción, eficiencia y comprensión del material educativo con el que se aprende o trabaja.

IV- CARACTERÍSTICAS DEL LAS EDADES DE 4 A 6 AÑOS (etapa pre-operacional)

Los niños manifiestan capacidad para el pensamiento operacional a los 5 a 6 años, pero muy rara vez dominan las destrezas de esa etapa (o sea, el uso constante del pensamiento operacional) antes de los 7 u 8 años. Las dos variedades de aprendizajes más importantes de esta etapa son la exploración y manipulación de objetos concretos; el aprendizaje verbal mecánico; la práctica física de las letras, números, sonidos, palabras y cálculo aritmético; el dominio de la escritura y el trazo de la letra script. Casi todas estas habilidades se aprenden de forma aislada, debido a que le es más fácil adquirir destrezas o conocimientos asilados, por ello se da poca transferencia entre uno y otro aprendizaje. Los niños de esta etapa necesitan una instrucción directa por parte del maestro. Necesitan además la demostración y que produzcan respuestas para comprobar si realmente entienden los conceptos. Hay que corregirlos, cuando sea necesario, y proseguir ejercitación hasta que dominen a la perfección los conceptos fundamentales.

Los software educativos a estas edades se deben diseñar tomando en cuenta que el tiempo dedicado a la informática dentro del currículo escolar será de una hora semanal. Esto es así debido a que el niño tendrá que realizar otras actividades como son los ejercicios físicos para mejorar su coordinación muscular, actividades de apresto para la lectura y escritura, tiempo para jugar con otros niños lo cual contribuye a ayudarlo en su socialización y sentido de cooperación, además las actividades culturales y otras tareas , más el tiempo dedicado al descanso (dormir).

V- CONCLUSIONES

Al diseñar software educativo es importante considerar que no existe una teoría de aprendizaje que sea mejor que la otra. Si existen, teorías de aprendizaje que se aplicarán mejor a unos tipos de software educativos que a otros.

Así encontramos que los software de práctica y ejercitación se relacionan más con los principios conductistas, a los programas tutoriales se aplican más los principios cognitivistas, y los juegos educativos, simulaciones e hipertextos se ejemplificarán mejor por los principios constructivistas.

En la actualidad la mayoría de los software educativos siguen los postulados cognoscitivos, aunque existe la tendencia cada vez mayor de diseñar software educativos, con las características de los principios constructivistas.

Al diseñar y desarrollar software educativos para el nivel pre-escolar, éstos deben estimular la creatividad e imaginación del niño, ayudarlos a desarrollar la sociabilidad y cooperación al trabajar en el software con otros niños y prepararlos para el desarrollo del pensamiento lógico, necesario en las etapas posteriores de su desarrollo.

REFERENCIAS BIBLIOGRAFICAS

GOOD, T.L. / BROPHY J.E. Psicología Educacional. Editorial McGraw Hill. México, 1993
GROS, BEGOÑA Diseños y Programas Educativos. Editorial Ariel S.A. Barcelona,1997

SUBIR

METODOLOGÍA PARA LA ELABORACIÓN DE SOFTWARE EDUCATIVO

Pere Marquès (1995)

En Software Educativo. Guía de uso y metodología de diseño. Barcelona: Editorial Estel

1.- INTRODUCCIÓN


Para facilitar el proceso de diseño y desarrollo de software educativo, a continuación se propone una metodología que contempla 11 etapas, cada una de las cuales se puede dividir en fases más específicas. Estas etapas principales son:

- Génesis de la idea.

- Prediseño o diseño funcional.

- Estudio de viabilidad y marco del proyecto.

- Dosier completo de diseño o diseño orgánico.

- Programación y elaboración del prototipo alfa-test.

- Redacción de la documentación del programa.

- Evaluación interna.

- Ajustes y elaboración del prototipo beta-test.

- Evaluación externa.

- Ajustes y elaboración de la versión 1.0

- Publicación y mantenimiento del producto.

No obstante hay que destacar que el proceso de elaboración del software educativo no es un proceso lineal, sino iterativo: en determinados momentos de la realización se comprueba el funcionamiento, el resultado, se evalúa el producto... y frecuentemente se detecta la conveniencia de introducir cambios. Como dice N. Wirth, creador del lenguaje PASCAL, " la construcción de programas consiste en una secuencia de pasos de perfeccionamiento". Desde otra perspectiva, Jean Michel Lefèvre afirma: "escribir un programa didáctico es como tener una aventura: generalmente conocemos el punto de partida, más o menos sabemos donde queremos ir, pero desconocemos con exactitud lo que pasará por el camino".

2.- LA GÉNESIS DE LA IDEA-SEMILLA

La elaboración de un programa educativo siempre parte de una idea inicial que parece potencialmente poderosa para favorecer los procesos de enseñanza/aprendizaje y que va tomando forma poco a poco; una idea que configura unas actividades atractivas para el alumno que potencialmente pueden facilitar la consecución de unos determinados objetivos educativos. Sus autores casi siempre son profesores y pedagogos, diseñadores de software educativo.

La idea inicial de un programa constituye una intuición global de lo que se quiere crear, contiene la semilla del QUÉ (materia y nivel) se quiere trabajar y del CÓMO (estrategia didáctica), y se irá completando y concretando poco a poco a medida que se elabore el primer diseño del programa: el diseño funcional. Su génesis puede realizarse: por libre iniciativa de los diseñadores o por encargo.

- Por libre iniciativa de los diseñadores. Las ideas-semilla, que llevan el germen de un buen programa didáctico, pueden ser fruto de la libre iniciativa de profesores y pedagogos y, aunque pueden surgir casualmente, generalmente aparecen en diversas circunstancias:

- Reflexionando sobre la propia práctica docente delante de los alumnos.

- Comentando con otros profesores experiencias educativas o hablando de los problemas de los alumnos y de las soluciones posibles.

- Hablando con los alumnos de sus problemas en la escuela y de sus opiniones de las asignaturas, o haciendo un sondeo sistemático sobre sus dificultades.

- Buscando nuevas formas de ejercitar técnicas que exigen mucha práctica.

- Buscando nuevas formas de representar un modelo con más claridad.

- Buscando formas globalizadoras y multidisciplinares de tratar los contenidos curriculares.

- Detectando deficiencias del sistema: demasiados alumnos por clase, niveles no homogéneos, dificultades para el tratamiento de la diversidad, poco interés de los estudiantes, etc.

- Visualizando programas educativos o utilizando otros medios didácticos.

- Buscando aspectos susceptibles de tratamiento en programas didácticos donde el ordenador pueda aportar ventajas respecto a los otros medios didácticos.

Los profesores intelectualmente sensitivos delante de los problemas, con un carácter abierto y curioso y con espíritu de investigación, están más predispuestos a generar este tipo de ideas creativas que sirven de punto de partida para la elaboración de programas educativos.

- Por encargo. Estas ideas también pueden originarse a partir del encargo de una editorial de software educativo o de una administración pública. En este caso, los clientes que hacen el encargo acostumbran a proporcionar a los diseñadores un marco, unas especificaciones centradas en aspectos pedagógicos y político-comerciales, que la idea resultante deberá respetar.

A partir de estas especificaciones, los diseñadores pueden ver de adaptar alguna de las ideas que tengan recogidas de tiempo atrás (por libre iniciativa) o de las que obtengan haciendo un análisis sistemático de actividades educativas susceptibles de ser informatizadas.

En los módulos de diseño de software de los cursos de postgrado sobre Informática Educativa para maestros y licenciados, se suele estimular la génesis de estas ideas entre los asistentes proponiendo que, en pequeños grupos, elaboren dos listas de objetivos curriculares: una con objetivos que piensen que se pueden alcanzar más fácilmente mediante el uso de determinados programas didácticos conocidos, y otra con objetivos que consideren que podrían conseguirse mejor si existiesen determinados programas que, en este caso, deberán inventar. Estas listas se comentan y valoran posteriormente entre todos.

3.- PRE-DISEÑO O DISEÑO FUNCIONAL

Elaborado a partir de una idea inicial (idea-semilla), el prediseño (diseño funcional) constituye un primer guión del programa que pondrá la énfasis en los aspectos pedagógicos del proyecto: contenidos, objetivos, estrategia didáctica, etc. En caso de que se elabore por encargo o por iniciativa empresarial, este primer guión servirá para presentarlo al jefe del proyecto y a los clientes para que lo sometan a un test de oportunidad y determinen su conformidad o disconformidad con el diseño. En todo caso, el diseño funcional también podrá distribuirse a otros profesores, buenos conocedores de los alumnos a los que se dirige el material, para que aporten su opinión y sus sugerencias.

Frecuentemente el diseño funcional de los programas lo realiza una única persona, generalmente un profesor, pero resulta recomendable que intervenga un equipo de especialistas, el equipo de diseñadores pedagógicos, integrado por:

- Profesores con amplia experiencia didáctica en el tema en cuestión y que puedan proporcionar conocimientos sobre la materia del programa, sobre los alumnos a los cuales va dirigido el material y sobre las posibles actividades de aprendizaje.

- Pedagogos o psicopedagogos, que proporcionen instrumentos de análisis y de diseño pedagógicos.

- Algún especialista en Tecnología Educativa, que facilite la concreción del trabajo y la coordinación de todos los miembros del equipo.

En la elaboración de este diseño se pueden utilizar diversos instrumentos:

- Técnicas para el desarrollo de la creatividad, como la técnica del "brainstorming", que puede facilitar al equipo de diseño la búsqueda de nuevas ideas sobre el QUÉ y el CÓMO del programa que se pretende elaborar. Se tendrán en cuenta las posibilidades de los ordenadores (sin profundizar en aspectos técnicos) y se considerarán muy especialmente aspectos pedagógicos y funcionales:

. Las motivaciones, el por qué conviene elaborar este nuevo material.

. Las primeras reflexiones sobre los contenidos y los objetivos.

. Las posibles actividades interactivas.

. El primer borrador de las pantallas y del entorno de comunicación en general.

Estas sesiones de "brainstorming" pueden alternar momentos de creatividad totalmente libre, donde se aporten ideas generales sobre el programa, con otros momentos donde la actividad creadora se vaya concentrando en la concreción de las características específicas que configurarán el diseño funcional.

- Bibliografía sobre diseño de software educativo, que permitirá definir una metodología de trabajo adecuada a las características del equipo y considerar más recursos materiales y técnicos que pueden ayudar en el desarrollo del proyecto.

- Bibliografía sobre la temática específica que se piensa tratar en el programa. La recopilación de información variada sobre el tema y la lectura de textos con diferentes enfoques didácticos puede ser una fuente importante de nuevas ideas.

- Software educativo cercano al que se quiere hacer, que puede proporcionar diversas conceptualizaciones útiles: aspectos positivos que se pueden imitar, aspectos negativos que hay que evitar, etc.

- Plantillas de diseño, que ayudarán en el proceso de concreción del proyecto. Como ya se ha indicado en la presentación de este capítulo, el proceso de diseño de los programas educativos no es lineal, es más bien concéntrico, de manera que resultará más conveniente rellenar las plantillas en sucesivas revisiones para afinar cada vez más el contenido de sus puntos que no procurar cumplimentarlas meticulosamente punto por punto. En los anexos de este libro se incluye una plantilla para el prediseño de programas educativos elaborada a partir de los aspectos que se analizan en los próximos apartados.

A lo largo del proceso de diseño se realizan aproximaciones descendentes (a partir de la idea global se analizan sus elementos y posibilidades) y ascendientes (se integran actividades y elementos simples en módulos más complejos). Cuanto más técnico y más estructurado sea el tema que se quiere tratar, más fácil resultará trasladar la idea a un formato de software educativo; en cambio, los temas difíciles de estructurar y de desglosar en apartados requerirán mucho más esfuerzo.

Finalmente, el diseño funcional se concretará en un proyecto de unas 10 ó 15 páginas que incluirá:

- Una presentación.

- La concreción de los aspectos pedagógicos.

- Esquemas sobre los aspectos algorítmicos.

- La definición de las formas de interacción entre los alumnos y el programa.

- Un primer guión sobre el manual del programa.

3.1.- PRESENTACIÓN.

La presentación del proyecto consistirá en una breve exposición general del programa que se piensa desarrollar (ocupará una o dos hojas) y tendrá en cuenta los siguientes aspectos:

- Descripción sintética del programa y de sus objetivos.

- Rasgos más característicos:

. Tipología del programa (constructor, simulador, base de datos, tutorial...)

. Concepción del aprendizaje (conductista, constructivista...)

. Otras características generales.

- Motivación:

. Razones para desarrollar este proyecto.

. Aportaciones que supone para el mundo educativo.

. Ventajas que ofrece respecto a otros medios didácticos existentes.

- Guión general. Un resumen de las actividades previstas para el programa y de su estrategia didáctica (en 1 ó 2 párrafos).

- Hardware y software necesario. Tipo de ordenador, sistema operativo, periféricos y otros materiales necesarios (impresora, placa de sonido, vídeo, etc.).

La presentación del prediseño proporcionará a los lectores una primera idea global del material que se pretende elaborar.

3.2.- ASPECTOS PEDAGÓGICOS.

En este apartado se definirán los objetivos, los contenidos, los alumnos destinatarios del programa y la estrategia didáctica que se piensa utilizar. Esta última comprenderá aspectos como: actividades que hay que proponer a los alumnos, el tratamiento de los errores, los elementos motivadores, los posibles caminos pedagógicos...

La concreción de estos aspectos constituye una de las fases más importantes en el diseño de los programas educativos, ya que su calidad didáctica depende en gran medida del hecho que se encuentre la necesaria coherencia entre el objetivo que se quiere alcanzar, los contenidos que se tratarán, las actividades mentales desarrollarán los alumnos y las actividades interactivas que les propondrá el programa. Así pues, en el apartado de aspectos pedagógicos se determinarán:

- Objetivos educativos. Especificación de los objetivos que se pretenden, y que detallan las capacidades que los alumnos habrán adquirido o reforzado después de interactuar con el programa. Se tratará de objetivos relevantes en el currículum de los estudiantes (conocimientos, destrezas, valores...), expresados en forma de aprendizajes que sean descriptibles, observables y, si es posible, cuantificables. Estos objetivos permitirán:

. Evaluar la eficacia del programa, al comparar los aprendizajes realizados por los estudiantes mediante este material con los objetivos previstos.

. Racionalizar la organización de los contenidos, ya que a partir de los objetivos se deducirán los contenidos a tratar para alcanzar las metas deseadas.

No es conveniente pretender abarcar muchos objetivos educativos en un mismo programa. Es mejor centrar los esfuerzos en el alcance de uno, o de unos pocos objetivos principales y, cuando el diseño ya este bien consolidado, ver que otros objetivos podrían trabajarse con la inclusión de nuevas actividades y pequeñas modificaciones del guión.

- Alumnos destinatarios del programa. Concretamente, aquí se determinará:

. Edad, nivel de desarrollo cognoscitivo (nivel de madurez).

. Conocimientos previos y capacidades generales que han de tener: nivel educativo, conocimientos relacionados con la temática del programa, estructura cognoscitiva.

. Capacidad intelectual (nivel de inteligencia general y factorial).

. Actitudes, intereses, hábitos de estudio y organización.

. Discapacidades o deficiencias.

En el momento de diseñar un programa siempre se piensa en unos alumnos determinados que tienen unas características y unas necesidades concretas. Inicialmente hasta incluso interesa que este conjunto de posibles destinatarios no sea demasiado amplio, ya que así se facilita la concreción y la coherencia del proyecto. Más tarde se verá como simplemente añadiendo algunas opciones al programa base se puede ampliar considerablemente el abanico de usuarios.

- Contenidos. Los contenidos (conceptuales, procedimentales y actitudinales) que han de trabajar los alumnos se analizarán para descomponerlos en unidades mínimas de presentación, organizarlos y jerarquizarlos en función de su lógica interna, de los niveles de los destinatarios y de los objetivos que deben alcanzar.

Esta organización de la materia que, especialmente en los programas tutoriales, determinará la estructura modular y la secuenciación de las actividades, deberá facilitar a los alumnos un aprendizaje significativo y permitir diferentes formas de adquisición de la información. En este sentido convendrá organizar los contenidos:

. De los aspectos más fáciles y concretos a los más complejos y abstractos.

. De los elementos conocidos por los alumnos a los que les son desconocidos.

. De las presentaciones globales o sintéticas a las visiones analíticas.

. De las visiones episódicas a las sistemáticas.

. De los que requieren el uso de habilidades globales a los que implican el uso de habilidades específicas.

. Destacando las relaciones interdisciplinarias, ya que la enseñanza de la aplicación de una ley o procedimiento de un área a otras facilita la transferencia de los aprendizajes.

. Contemplando niveles de dificultad, para facilitar que el alumno escoja el nivel que le interesa y posibilitar que el programa se adapte al nivel de los usuarios.

Algunos de los programas no tutoriales además exigirán concretar otros aspectos relacionados con la organización de la materia:

. Si es un programa tipo base de datos: la estructura de las bases de datos, las interrelaciones entre ellas, las formas de acceso a los datos (búsqueda, ordenación, clasificación, captura... )

. Si es un simulador: los modelos que presentarán y la organización de los conceptos ( que deberán resultar claros y adecuados al nivel de abstracción de los alumnos), las variables con que se trabajará (variables dependientes e independientes) y las interrelaciones entre las variables que se podrán representar internamente por medio de fórmulas, con tablas de comportamiento, mediante grafos, etc.

. Si es un constructor: los elementos que contemplará y las propiedades o los comportamientos que tendá cada elemento.

- Actividades mentales que los alumnos desarrollarán delante del ordenador. Aquí la pregunta clave es: ¿qué actividades intelectuales hay que suscitar en el alumno para que alcance los objetivos de una manera duradera y con un máximo de posibilidades de que se produzca la transferencia a nuevas situaciones?


A veces se pasa por alto este estudio y los diseñadores, una vez fijados los objetivos y los contenidos, se dedican a reflexionar directamente sobre la forma que tendrán las actividades interactivas que propondrá el programa. Es una mala práctica: la identificación previa de estas operaciones mentales que interesa que realicen los alumnos contribuirá a aumentar la calidad didáctica de las actividades interactivas que se diseñen a continuación.

Entre las actividades mentales que los alumnos pueden desarrollar al interactuar con los programas, que por cierto son las mismas que pueden poner en práctica trabajando con cualquier otro medio didáctico, se destacan:

. Exercitar habilidades psicomotrices.

. Observar. Percibir el espacio y el tiempo y orientarse en ellos.

. Reconocer, identificar, señalar, recordar.

. Explicar, describir, reconstruir.

. Memorizar (hechos, datos, conceptos, teorías...)

. Comparar, discriminar, clasificar.

. Conceptualizar (conceptos concretos y abstractos). Manipular conceptos. . Relacionar, ordenar.

. Comprender. Interpretar, representar, traducir, transformar.

. Hacer cálculos mecánicos.

. Resolver problemas de rutina.

. Aplicar reglas, leyes, procedimientos, métodos....

. Inferir, prever.

. Buscar selectivamente información.

. Sintetizar, globalizar, resumir.

. Analizar (pensamiento analítico)

. Elaborar hipótesis, deducir (razonamiento deductivo).

. Inducir, generalizar.

. Razonar lógicamente (Y, OR, NOT...)

. Estructurar.

. Analizar la información críticamente. Evaluar.

. Experimentar (ensayo y error)

. Construir, crear (expresión creativa, pensamiento divergente

. Transformar, imaginar (asociaciones, cambios de entorno)

. Expresar, comunicar, exponer estructuradamente.

. Negociar, discutir, decidir.

. Resolver problemas inéditos, que implican la comprensión de nuevas situaciones.

. Planificar proyectos, seleccionar métodos de trabajo, organizar.

. Investigar.

. Desarrollar, evaluar necesidades, procesos y resultados.

. Reflexionar sobre los mismos procesos mentales (metacognición).

. Intuir.

Como se ha comentado en el capítulo primero de este libro, los programas educativos pueden tener diversas funciones: se pueden usar como medio de transmisión de ciertas informaciones, como un experto que facilita la adquisición de conocimientos, como un medio de desarrollar estrategias de razonamiento y capacidades cognitivas en general, o como un simple instrumento de trabajo. Los programas que dan preferencia a la materia y a su aprendizaje procuran trabajar sobre todo actividades de memorización, mientras que los programas que buscan el desarrollo cognitivo de los alumnos procuran que los estudiantes razonen, estructuren mejor su conocimiento y lo apliquen a nuevas situaciones.

En esta sociedad postindustrial, donde la velocidad con que se generan los nuevos conocimientos sobrepasa la capacidad del cerebro y de los métodos tradicionales de tratamiento , pero en la que tenemos un fácil acceso a todo tipo de información (TV, libros...), lo que interesa no es una enseñanza memorística, sino dar una sólida formación de base y desarrollar las capacidades cognitivas de los alumnos para que puedan: localizar y procesar información, aplicarla a la resolución de problemas, razonar y comunicarse.

- Actividades interactivas que debe proponer el programa. A través de ellas se realiza el intercambio de informaciones entre los alumnos y la máquina que permite que las acciones de los estudiantes puedan ser valoradas y tratadas por el programa. Se diseñaran según una determinada estrategia educativa y teniendo en cuenta los objetivos, los contenidos, los destinatarios y las operaciones mentales que tienen que desarrollar los alumnos. Para definirlas habrá que decidir los siguientes aspectos:

. Naturaleza de las actividades educativas: exposición de información, preguntas, resolución de problemas, búsqueda de información, descubrimiento guiado, descubrimiento experimental...


. Estructura: escenario, elementos relacionados con el contenido, interrelaciones entre ellos.

. Acciones y de respuestas permitidas al alumno.

. Duración. Conviene que sea ajustable y no exceda de la capacidad de atención de sus destinatarios . Una sucesión de etapas cortas, con objetivos y contenidos bien definidos, hace que la labor sea más agradable.

. Tipo de control de la situación de aprendizaje que tendrá el alumno. Las actividades que facilitan diversos accesos al mismo material estimulan al alumno a pensar con flexibilidad.

Estas actividades interactivas deberán de promover en los alumnos actividades cognitivas que favorezcan la asimilación significativa de los nuevos conocimientos en sus esquemas internos y que permitan el desarrollo de estrategias de exploración, de aprendizaje a partir de los errores y de planificación de la propia actividad. Así los estudiantes podrán construir su propio conocimiento.

En este sentido, y para asegurar la significabilidad y la transferibilidad de los aprendizajes, las actividades también procurarán desarrollar en los alumnos formas adecuadas de representación del conocimiento: categorías, secuencias, redes conceptuales, representaciones visuales...

- Caminos pedagógicos. El programa tiene que prever bifurcaciones que permitan seguir diferentes itinerarios pedagógicos a los alumnos y que faciliten: la elección de los temas y de las actividades, la reformulación de los conceptos, el cambio de la secuenciación de los contenidos, el retorno sobre puntos mal comprendidos, la selección del nivel de dificultad, repasar, profundizar, ver ejemplos... La determinación de estos recorridos se puede hacer de dos maneras: .

. De manera explícita: Por libre decisión de los alumnos, que disponen de posibilidades de control directo sobre el programa.

. De manera implícita: En función de las respuestas de los alumnos (tratamiento de los errores y de los aciertos propio de los programas tutoriales).

El análisis de las respuestas de los alumnos es una de las labores más difíciles y meticulosas de los diseñadores, ya que deben prever el mayor número posible de respuestas y, además, tener prevista una "salida" para respuestas imprevistas. Se pueden distinguir los siguientes tipos de tratamiento de los errores:

. Según el tipo de refuerzo o de corrección:

.. Corrección sin ayuda. Cuando tras detectar el error se da directamente la solución a la pregunta, a veces con comentarios explicativos.

.. Corrección con ayuda. Cuando presenta alguna ayuda y permite un nuevo intento al estudiante. La ayuda puede consistir en la presentación de la ley que se debe aplicar, la visualización de diversas respuestas posibles entre las cuales se debe escoger una, etc.

. Según la valoración que haga del error:

.. Valoración mediante mensajes, que pueden ser: positivos (dan ánimos, consolidan los aciertos) o negativos (evidencian los errores)

.. Valoración por medio de elementos cuantitativos: puntos, trayectorias...

.. Valoración mediante efectos musicales y visuales: músicas, explosiones... .

. Según la naturaleza del error. Cada tipo de error requerirá un tratamiento contextualizado y diferenciado. Así hay que distinguir: errores de conocimiento, errores de comprensión, errores de análisis, errores de procedimiento y errores de ejecución.

- Elementos motivadores. .Su importancia es grande, ya que la motivación es uno de los grandes motores del aprendizaje y un buen antídoto contra el fracaso escolar, donde, como sabemos, convergen la falta de aprendizajes y de hábitos de trabajo con las limitaciones en los campos actitudinal y motivacional. Además de la personalización de los mensajes con nombre del estudiante, los elementos motivadores más utilizados en los programas didácticos son:

. Elementos que presentan un reto. Este tipo de elementos lúdicos (puntuaciones, cronómetros, juegos de estrategia) pueden contribuir a hacer más agradable el aprendizaje, no obstante hay que tener en cuenta que algunas personas prefieren un enfoque más serio y abstracto del aprendizaje y que en algunos casos el juego puede hacer que el alumno olvide que lo esencial es aprender.

. Elementos que estimulan la curiosidad o la fantasía, como mascotas, elementos de juego de rol, intriga, humor....

. Elementos que representan un estímulo o una penalización social, como los mensajes "muy bien" e "incorrecto" que pueden ir acompañados de diversos efectos sonoros o visuales.

. Ritmo variado y progresivo del programa.

Conviene utilizar los elementos motivadores de manera intermitente, ya que un uso continuado puede hacer disminuir rápidamente su poder motivacional.

- Integración curricular. Un último aspecto pedagógico que hay que tener en cuenta en el diseño funcional es su futura integración curricular. La consideración de sus posibles formas de uso proporcionará nuevas ideas para ajustar el diseño del programa.

Teniendo en cuenta las características de sus alumnos destinatarios y los objetivos curriculares del programa se analizarán:

. Formas de organizar su empleo según el tipo de aula y los ordenadores disponibles.

. Momentos idóneos para su utilización.

. El papel de los alumnos y del profesor durante las sesiones de trabajo con el programa.

. Tareas que se tienen que realizar antes de la utilización del programa, durante su utilización y después de la sesión.

La definición de estos aspectos pedagógicos sobre el programa que se quiere elaborar determinará en gran medida su estructura, que es el tema que se analiza a continuación.

3.3.- ASPECTOS ALGORITMICOS Y ESTRUCTURALES.

Los aspectos algorítmicos y estructurales reflejan una primera aproximación a la estructura del programa, y se concretaran en diversos gráficos y diagramas comentados:

- Diagrama general del programa. Reproduce la estructura básica de su algoritmo. Se acostumbra a representar en forma de diagrama de flujo, y debe de ir acompañado de una breve descripción de los módulos globales que lo integran:

. Módulos de presentación y de gestión de menús. Comprenden las pantallas de presentación y despedida del programa y las pantallas de gestión de los menús principales.

. Módulos de actividades interactivas. Contienen las diferentes actividades educativas que el programa puede presentar a los alumnos.

. Módulos de ayuda. Gestionan las ayudas a los alumnos. Hay que determinar las formas de acceso a estas ayudas, que pueden ser:

. Ayudas sobre el funcionamiento del programa.

. Ayudas didácticas, sobre los contenidos.

. Módulos de evaluación. Gestionan el almacenamiento de información sobre las actuaciones de los alumnos y la posterior presentación de informes. Habrá que determinar las informaciones que son relevantes, cómo se accederá a ellas y cómo se presentarán.

. Módulos auxiliares. Por ejemplo: gestión de posibles modificaciones de parámetros, utilidades para los alumnos (calculadora, diccionario...), etc. -

- Organización de los menús. Tras determinar si los menús estarán organizados según un entorno tradicional o según un entorno windows y en forma de menús desplegables (top down), se diseñará el árbol de las opciones que el programa ofrecerá a los usuarios.

- Parámetros de configuración del programa. La posibilidad que los profesores y los alumnos puedan adaptar algunos aspectos del programa a sus circunstancias concretas es una característica cada vez más valorada en los programas. Así, hay bastantes programas que permiten:


. Conectar o desconectar los efectos sonoros, que no agradan a todos.

. Cambiar el color de algunos elementos de la pantalla.

. Ajustar el tiempo de respuesta (en los programas que fijan un tiempo para responder o hacer una actividad).

. Fijar el nivel de dificultad de las actividades.

. Elegir el tema (hay programas que pueden gestionar actividades con diversas bases de datos)

- Esquema de los principales caminos pedagógicos. Representa la secuencia en que se presentaran las actividades y sus posibles bifurcaciones en función de los comportamientos (acciones, errores, etc.) de los usuarios. Se procurará dejar el máximo control posible al alumno.

- Otros aspectos estructurales. Como por ejemplo: las principales variables que se deben usar, la estructura de las bases de datos (tipo y soporte de cada una), posibilidades de modificación de las bases de datos por los usuarios (bases de datos abiertas), etc.

Una vez concretados los aspectos pedagógicos del programa, que incluyen los contenidos, y después de determinar los aspectos algorítmicos, ya sólo falta definir el tercero de los elementos esenciales que configuran estos materiales: el entorno de comunicación entre el programa y los alumnos.

3.4.- ENTORNO DE COMUNICACIÓN

Por medio del entorno de comunicación (interfície), que deberá ser lo más ergonómico posible, se realizará el diálogo entre los estudiantes y el programa. Para su concreción se considerarán tres apartados:

- Primer diseño de las pantallas. El primer diseño de las pantallas más significativas del programa se acostumbra a hacer sobre papel o bien en soporte magnético mediante un editor gráfico (a veces incluso se prepara una presentación interactiva -story board-). Incluirá ejemplos de las pantallas de los diferentes módulos del programa (presentación, gestión de menús, ayuda...), pero sobretodo mostrará las que se refieren a las actividades interactivas del programa.

En general, al diseñar las pantallas se determinarán zonas que realizarán funciones específicas y que se repetirán (si es posible) en todas las pantallas del programa. Por ejemplo:

. Zona de comentarios. Normalmente consiste en unas líneas o una ventana donde el programa comenta las actuaciones de los alumnos. Muchas veces es el mismo espacio donde aparecen los mensajes de ayuda.

. Zona de órdenes. En esta zona, que también vendrá definida por unas líneas o por una ventana, el programa indica a los alumnos lo que pueden hacer, las opciones a su alcance. Puede incluir líneas con las opciones disponibles (menús) o un espacio donde pueden escribir libremente las órdenes y respuestas.

. Caja de herramientas. Esta zona realiza una función complementaria de la zona de ordenes. Se encuentra frecuentemente en programas que tienen algoritmos del tipo entorno y facilitan herramientas a los alumnos para que procesen con una cierta libertad la información que aparece en las actividades.

. Zona de trabajo. Ocupa la mayor parte de la pantalla. Es la zona donde aparece la información principal que proporciona el programa y donde se desarrollan las actividades educativas. En estas actividades conviene que las preguntas, los comentarios y la zona de respuesta estén en una misma pantalla para facilitar la comprensión a los estudiantes.

- Uso del teclado y del ratón. Interesa crear un entorno de comunicación con el programa que resulte muy fácil de usar y agradable al alumno. Para conseguirlo se debe establecer una sintaxis sencilla e intuitiva y prever un sistema de ayuda para el manejo del programa, determinando las principales teclas que se utilizarán, las funciones básicas de los botones del ratón y la forma de comunicación de las acciones y respuestas por parte de los alumnos, que puede ser:

. Por selección de entre las opciones que ofrece el programa por la pantalla.

.. Preguntas del tipo sí/no

.. Cuestionarios de respuesta múltiple (que suelen tener 4 ó 5 alternativas). .. Menús de opciones (convencionales o desplegables)

. Con producción de respuesta, donde el estudiante debe crear su orden o respuesta. Su actuación puede ser:

.. Mover algún elemento por la pantalla: cambiar un objeto de lugar, trazar una trayectoria...

.. Establecer correspondencias entre listas, asociaciones, ordenar palabras...

.. Elaborar una respuesta libre: completar mensajes, rellenar espacios en blanco, localizar errores en un mensaje, respuesta abierta... Se acostumbran a tolerar pequeñas diferencias entre las respuestas de los alumnos y las que se tienen como modelo (mayúsculas/minúsculas, acentos, espacios en blanco, etc.). Esta interacción, basada en respuestas construidas libremente por el alumno, es la más rica pedagógicamente, pero resulta muy difícil de controlar.

- Otros periféricos. Se describirá la función de los diferentes periféricos complementarios que se utilicen:

. Impresora. Puede proporcionar fichas de trabajo, informes, gráficos...

. Teclado conceptual. Facilita la comunicación con el ordenador, especialmente a los más pequeños y en algunos casos de discapacidad.

. Lector de tarjetas. Transforma las tarjetas que introducen los alumnos en las ordenes o respuestas. Este sistema facilita, por ejemplo, que los párvulos que aún no conocen las letras puedan comunicarse con el ordenador mediante unas tarjetas que codifican su significado por medio de colores y dibujos.

. Micrófono, reconocedor de voz, vídeo, CD-ROM, lápiz óptico, pantalla tactil, módem, convertidores analógico-digitales, etc.

Con la definición del entorno de comunicación que tendrá el programa que se tiene que elaborar prácticamente acaba el proceso de creación que implica el diseño funcional de un programa; ya se dispone de toda la información necesaria para redactar el proyecto. No obstante conviene analizar aún un último aspecto antes de dar por acabada esta fase de prediseño: la documentación que acompañará al programa.

3.5.- DOCUMENTACION DEL PROGRAMA.

El diseño funcional incluirá también un esquema con una primera aproximación al formato y al contenido de la documentación que acompañará al programa. Esta documentación debe contemplar los apartados siguientes:

- Ficha resumen Consiste en una ficha sintética que recoge las principales características del programa. Permitirá al lector obtener rápidamente una idea global del contenido y de las posibilidades educativas del programa.


- Manual del usuario. Debe de explicar todo lo que necesita saber un usuario del programa para utilizarlo sin problemas y sacar el máximo partido de sus posibilidades.

- Guía didáctica. Esta dirigida a los profesores (aunque también podrá ser de utilidad a los alumnos autodidactas). Ofrece sugerencias sobre la integración curricular del programa , sus formas de uso, actividades complementarias, estrategias para evaluar el rendimiento de las situaciones educativas que genera el programa, etc.

La documentación del programa se debe de hacer con tanto cuidado como el mismo producto informático, ya que constituye un elemento indispensable para que los usuarios puedan obtener el máximo rendimiento de las prestaciones que ofrece el material.

4.- Y EL PROCESO SIGUE...

Finalizada la etapa del diseño funcional del programa, el equipo pedagógico (profesores, pedagogos y otros especialistas) hace llegar el diseño al coordinador del proyecto que, con el adecuado asesoramiento técnico, pedagógico y comercial, dictaminará su viabilidad y, en caso favorable, establecerá el marco para el desarrollo del proyecto (presupuesto, personal, plan de trabajo, etc.). Habrá llegado el momento de confeccionar el dosier completo de diseño... y el proceso sigue (ver introducción).

SUBIR