Evaluación

Memoria

ENFEN. Fluidez verbal (II)

El análisis que de ENFEN-Fluidez realizamos en la entrada anterior es justificación suficiente para el desarrollo de este DocAp, aunque no condiciona el modo en que se concrete. Explicarlo es el cometido de esta entrada.

Como recurso de evaluación, sitúo ENFEN-Fluidez en el segundo nivel de intervención dentro del proceso de evaluación; aquel que implica la intervención individualizada con el alumno, por contraposición al primer nivel o de evaluación de base grupal y/o del alumno en el contexto del aula. Cierto que la simplicidad de la aplicación de esta prueba no impide radicalmente su aplicación en el grupo, pero parece más apropiado aplicarla como parte de la evaluación individual.

Otra cosa es si podemos pensarla dentro de un contexto de colaboración con servicios clínicos externos, lo cual es perfectamente factible, pero realmente esa es una cuestión secundaria: aplicar ENFEN-Fluidez está suficientemente justificada por si misma en función de lo que aporta para la identificación diferenciada de dificultades de aprendizaje, por lo que aporta respecto a la evaluación de las capacidades de memoria verbal, y por lo que aporta para la identificación de posibles dificultades de naturaleza escolar y la incidencia en que ellas tienen factores ambientales y/o del desarrollo de procesos básicos de aprendizaje.

Aunque ambas cuestiones no dejan de tener interés para el diseño de la intervención, lo cierto es que en términos operativos, ahora resultan poco relevantes, dado el objetivo de la entrada. Corresponde, eso sí, explicar en qué consiste el DocAp.

Lo primero es decir, precisamente, que se trata de un Docap; esto es un recurso que integra una serie de procesos (que veremos después) basándose en los servicios de LibreOffice, y que es posible gracias al empleo del lenguaje OOo Basic.

Como DocAp se puede calificar como DocAp complejo dado que requiere de la intervención de dos servicios, aunque tal y como se configura podríamos identificarlo como DocAp simple, puesto que la versión que aquí presento no se ha desarrollado del todo, por lo que sólo se hace uso de Calc, quedando Writer como soporte complementario, únicamente "a modo de prueba".

La automatización es, pues, parcial, aunque lo es por motivos que explicaré en su momento; no precisamente por carecer de los medios técnicos para alcanzar niveles óptimos de desarrollo como DocAp: no culminar la lógica implícita (de automatización) es una decisión tomada conscientemente, a pesar de disponer de los medios para hacerlo. Nos quedamos a las puertas de automatizar la generación del informe de resultados (1) para dedicar una entrada específica a tratar este tema en el marco del análisis las opciones disponibles, concretamente de la viabilidad de lo que podríamos llamar de forma un tanto grandilocuente modelo experto de automatización (2).

Por eso, hasta aquí me limito a presentar en esta entrada la automatización de la aplicación y la puntuación del test, quedando pendiente el análisis de resultados y la generación del informe individualizado. Todo ello se concreta un soporte Calc que deriva de otro utilizado hace tiempo para digitalizar y recoger datos de la escala ENFEN al completo (no exclusivamente de las pruebas de fluidez). En el original no existía prácticamente automatización, pero en el actual sí, heredando en ello el modelo aplicado en una antigua versión Filemaker que sí automatizaba la puntuación, un somero análisis de los datos y la emisión de un breve informe personalizado de resultados.

El DocAp actual consta formalmente de tres hojas (Id, Pruebas y Datos), de las cuales sólo la primera está visible al abrir el documento. Pero la complejidad real del DocAp está en el código, responsable de su funcionamiento, visible desde el IDE y que contiene lo siguiente:

Como ves, se diferencian 6 módulos y 22 script. Este conjunto de elementos hace posible que se desarrollen los procesos de automatización del DocAp y que explicaré resumidamente en base a lo que la visualización de la interface permite entrever.

En hoja Id encuentras un formulario basado en celdas, destinado a recoger los datos de identificación del alumno, y lo que es la síntesis de resultados de la aplicación del test.

Además tienes dos comandos: uno (APLICAR TEST) para continuar con la aplicación de la prueba y otro (BORRAR) para borrar el contenido antiguo, si es que está aun visible. Como sabes, ambos están asociados a la ejecución de sendos script.

La segunda hoja queda accesible al activar el botón APLICAR TEST y contiene, como cabe esperar, el sistema de recogida de datos y el de puntuación del test. Ambos funcionan mediante los comandos respectivos: Contador F1 Y Contador F2 para capturar las respuestas (el número de respuestas) y PUNTUAR para realizar la puntuación del test en función de los estadísticos de la prueba.

En este caso sí me interesa detenerme en la explicación del funcionamiento de estos comandos, ya que presenta cierta diferencia respecto a los procedimientos conocidos de puntuación de la ejecución. Esto es así porque en estas pruebas de fluidez lo que nos interesa es capturar el número de respuestas correctas que emita el sujeto, y nada más. De ahí que hayamos ideado un procedimiento de contador de aciertos que se concreta en dos script, uno por cada prueba (Fonológica - Semántica) asociados a sendos comandos (aquí el script del contador F1)...

Sub ContadorF1

Dim oHoja As Object, oCelda As Object
Dim i As Integer

'Acceso a la hoja Pruebas
oHoja = ThisComponent.getSheets().getByName("Pruebas")

'Acceso a la celda contador
oCelda = oHoja.getCellRangeByName("G2")
i = oCelda.getValue

i = Contador(i)

oCelda.setValue(i)

End Sub

... y ambos script a la función Contador()

Function Contador(i As Integer) As Integer

Contador = i + 1

End Function

El comando PUNTUAR presenta un código más complejo, que conforma los tres script (un script y dos subrutinas) que contiene el módulo ModPuntuar, al que te remito: básicamente consiste en lo siguiente:

• El comando PUNTUAR permite acceder al script PuntuarPrueba, el cual captura el valor del contador de las celdas F1 (G2) y F2 (G12) y se lo pasa a sendas subrutinas, una para puntuar cada una de las pruebas atendiendo a la edad del niño y a los datos estadísticos de los respectivos baremos.
• Finalmente traslada los datos resultantes también a la hoja Datos.

Dada la extensión de estos script, remito al IDE para su lectura y análisis. La explicación que sea pertinente para retomar la actualización del soporte se realizará en ese momento.

Para finalizar ahora esta entrada, sólo resta señalar que la hoja Datos contiene una sencilla tabla de datos con los de identificación y los resultados de ambos test.

A partir de estos datos será posible crear una base de datos acumulativa, y desarrollar un modelo de informe de resultados, única fase de la automatización de este test que aunque ha sido desarrollada, no se muestra accesible mediante un botón de comando.

No obstante, si lo deseas y a modo de borrador, puedes generar un modelo de informe sobre Writer activando directamente el script DocumentosExternos ubicado en el módulo ModExternos.

Documento. Descarga del DocAp de la prueba

Notas:

¹ En realidad también queda pendiente la generación de la base de datos, pero en este caso es más una cuestión de simplificación del procedimiento, mucho menos justificable que lo anterior.
² Tiempo habrá de bajar expectativas, pero lo cierto es que, en esencia, es precisamente de lo que se trata aquí: ¿es posible diseñar contantemente alternativas de automatización basadas en el conocimiento (teóricamente) del experto?. ¿cuáles son realmente las alternativas disponibles?. Se comprenderá que, así presentada la cuestión, sea conveniente abordar este tema de forma específica. Bien vale una entrada... cuanto menos.