Evaluación. Estrategias

Modelo de docap basado en Calc y OOo Basic.

Aunque se mantienen muchos de los planteamientos que permitieron el desarrollo de soportes para la evaluación, incluyendo el uso del servicio Calc como recurso básico y el desarrollo del proceso en tres fases, la introducción de script OOo Basic permite dotar a los recursos actuales de una serie de funcionalidades que difícilmente se podrían logar con los medios anteriores, basado en las funciones Calc. La superación de esas limitaciones es la que nos permite denominar a los nuevos soportes como docap, esto es, como documento-aplicación.

Investigar

El objetivo de esta entrada es exponer el procedimiento de trabajo que conlleva generar estos docap. Para ello, en primer lugar crearé un soporte de ejemplo, ajeno a la batería WISC-R que empleé como ejemplificación del procedimiento primitivo. No tiene mucho sentido trabajar sobre esa batería, dado que no podemos hacer uso de ella como tal al estar obsoleta. Esto no implica que no podamos hacer uso de algunos de sus test para evaluaciones específicas, aunque la antigüedad del baremo nos obliga tomar determinadas precauciones (1). 

Hemos constatado que los soportes-Hc se diferencian tres fases de desarrollo y se emplean diferentes componentes. De las fases de desarrollo ya hablamos [con anterioridad], pero no hemos prestado especial atención a esos componentes, y es necesario hacerlo ahora, ya que, aunque con cambios, también en esto un docap hereda de los soportes-Hc lo fundamental de los elementos que los constituyen. Entre ellos destacaremos los siguientes:

• Un sistema recogida de datos, que puede ser desde detalle (puntuación directa de cada ítem) hasta genérico (valores índice) (2)
• Un sistema de procesamiento de datos, principalmente basado en el uso de fórmulas propias del servicio.
• Un procedimiento de almacenamiento de los datos y del resultado de ese procesamiento
• Funcionalidades de análisis de resultados 
• Y funcionalidades de generación de algún tipo de expresión de dicho análisis en formato de texto (informe de resultados) (3)

Pretendo esta entrada crear un modelo de docap que contenga estos cinco componentes, lo que implica  que cumpla los criterios de un docap complejo que utilice el servicio Calc como soporte principal o Gestor (4) y el servicio Writer como soporte para la generación del informe (Informe de resultados)

Respecto a la recogida de datos las opciones disponibles son varias, pero me limitaré ahora a la recogida de las puntuaciones de cada ítem.  La forma que puede adoptar el procedimiento también es variada:

• Anotación de datos directamente sobre las celdas de Calc
• Uso de controles de formulario
• Uso de controles de diálogo

En este caso, la primera opción puede ser satisfactoria y hasta recomendable en determinadas circunstancias (5), por ejemplo cuando el número de ítem es elevado y el coste de generar controles también lo es; pero no en la mayoría de los casos. No considero conveniente utilizar cuadros de diálogo en un soporte Calc, ya que el formulario se adapta mejor a este servicio y resulta más sencillo de implementar. No obstante, es posible utilizar cuadro de diálogo como medio auxiliar.

En consecuencia mi opción actual es implementar controles de formulario, los cuales se pueden asociar directamente a celdas de la Hc. Esto nos permite diferenciar el procedimiento de entrada de información (mediante controles de formulario) y el subsiguiente procesamiento de los datos. Éste, a su vez, puede resultar del uso de uno u otro procedimiento o de la combinación de ambos:

• La aplicación de funciones Calc
• Y/o el uso de script OOo Basic

Esta decisión está en función del procesamiento a realizar, pero es de prever que la opción que se adopte con más frecuencia sea el uso combinado de ambas posibilidades (6)

El paso siguiente es decidir cómo y en que soporte vamos a concretar el almacenamiento de datos, incluyendo en esta decisión qué datos almacenar.

También disponemos de varias opciones para cada una de las decisiones a tomar, incluyendo aunar en un único proceso el almacenamiento con la generación del informe (7), aunque ésta no sea una opción muy recomendable si nos interesa realizar un análisis de resultados del acumulado de aplicaciones de la prueba. Por mantener este objetivo como posibilidad en el futuro es por lo que, como modelo, éste que presento diferencia la fase almacenamiento de las que restan, además de concretar también el soporte de dicho almacenamiento en una Hc Calc, dado que permite una fácil recuperación de la información y un ulterior tratamiento de la misma sin comprometer la forma en que ese análisis se pueda concretar.

Por motivos de facilidad de creación, la opción preferente sería utilizar la misma Hc-soporte como medio de almacenamiento. Se crearía en ella una hoja específicamente destinada a este fin y se trasladarían los datos, creando una tabla con función de BD simple. Al optar por un SoporteBd diferenciado del gestor damos a éste una función específica y diferenciada del resto de documentos que componen el docap.

La opción contraria, aunque tiene ciertas ventajas en cuanto a simplificación del procedimiento, también tiene inconvenientes para el manejo del recurso y sobre todo para el posterior análisis de resultados. Por ello opto por crear un soporte-Calc específico para el almacenamiento de los datos (SoporteBd). La elección del servicio Calc para esta función está justificada por las limitaciones de la alternativa Writer, pero más aun por las ventajas del servicio Hc, entre las que se incluye disponer de funciones propias que nos permiten el análisis cuantitativo y cualitativo de los datos.

Una vez resuelto el tema del almacenamiento nos enfrentamos a la siguiente fase: el análisis de los resultados. Esta (y la siguiente) no es obligatoria, pero sí conveniente, ya que su ausencia repercute negativamente en la funcionalidad del docap. La automatización del análisis, que es necesariamente limitada, no exime al profesional de realizar su propio análisis, pero le facilita la tarea, al menos en lo que se refiere a la descripción de la prueba y de los resultados observados. Es posible adelantar también determinadas relaciones causales derivadas de los propios datos, así como formular hipótesis a las que posteriormente responderá el profesional. Esto implica un importante ahorro de trabajo para éste y podemos aspirar incluso a proporcionarle un marco de referencia sobre el que realizar su propio análisis (8).

Y aquí tenemos descrito el objetivo que perseguimos con esta fase de análisis: crear lo nuclear del contenido del informe individualizado con el que pretendemos concluya nuestro docap. Hemos dicho que debe aportar al menos dos bloques de contenido: 

• Uno de carácter descriptivo y de identificación: descripción de la prueba, identificación del sujeto (alumno) y exposición de los resultados
• Y otro de carácter analítico básico: implicaciones fundamentales de lo que deriva de los resultados en términos valorativos y de posible causalidad (9).

El informe que resulta de ese análisis podemos realizarlo mediante funciones Calc, pero usando OOo Basic podemos obtener mejores resultados y de forma más sencilla.

Para finalizar propongo generar un informe técnico personalizado. Este informe puede ser creado sobre la misma Hc Gestor y exportarlo después en formato texto (Writer o .pdf) para su posterior entrega a los destinatarios de la evaluación y archivo en el expediente del alumno; pero de nuevo el uso de OOo Basic nos ofrece una solución muy superior y mucho más funcional: crear  el propio documento-soporte en formato Writer mediante código.

Esto hace más complejo el docap, pero tiene ventajas importantes; entre ellas permitir diferenciar el Gestor del propio informe, lo que facilita el posterior manejo de ambos.

Paso a continuación a ejemplificar lo anterior en una propuesta de docap-modelo, docap complejo formado por tres documentos que creados sobre dos servicios: SoportePrueba, BDPrueba (ambos Calc) e Infoprueba (Writer). La primera funciona como Gestor, segunda como sistema de almacenamiento de datos (Bd) y la tercera, el informe individualizado, se genera automáticamente desde el código. Este sería el esquema del docap:

Todo el código se ubica en Gestor, aunque sería posible crear código complementario de análisis en BDPrueba y de formateo de los documentos InfoPrueba que se creen (9). Ambas posibilidades no se consideran en esta propuesta, por lo que contamos con nueve script y un diálogo auxiliar, tal y como se puede ver accediendo al IDE desde SoportePrueba.ods.

Podemos diferenciar tres tipos de script:

• El script principal (Main), en el que es que desarrolla lo nuclear del algoritmo y dos subrutinas asociadas: AccesoBD(), para el almacenamiento de datos, e InfoIndiv(), para la creación y escritura del informe individualizado.
• Un script para acceder al diálogo auxiliar (dlgTexto): VerTexto, que facilita su visualización (10)
• Y cinco script auxiliares, incluyendo uno de trabajo con macros (ParaMacros), tres para el manejo de las hojas en que se divide el Gestor: IrCuestionario, PasoHoja y VerHoja (11) y uno para borrar los datos (BorrarDatos)

Explicaré primero el funcionamiento observable del docap, que se corresponde en líneas generales con el desarrollo de la fase input o de recogida de datos.

Aunque el documento Gestor (Hc SoportePrueba.ods) consta de tres hojas (DatosId, Cuestionario y Datos), al inicio del proceso y tras su finalización, el usuario sólo tiene a la vista la primera, permaneciendo ocultas las otras dos. En ella visualiza un formulario con campos (controles) para la introducción de datos de identificación y dos botones de comando: Leer el texto, que da acceso al diálogo en el que se muestra el texto que debe leer el alumno, y Borrar datos, que permite restablecer Gestor a su estado inicial (12).

Al finalizar la introducción de datos se espera que el usuario haga clic en Leer el texto, lo que activa el script VerTexto que permite visualizar el diálogo dlgTexto...

... que consta de una etiqueta (que contiene el texto informativo) y un botón de comando que activa el script IrCuestionario (13) que cierra el diálogo, oculta la hoja DatosId y posiciona al usuario en la hoja Cuestionario.

La tercera parte de este proceso consiste en la introducción de respuestas a los ítem, los cuales se presentan en el formulario situado en la hoja Cuestionario...

... que consta de 10 controles de formulario (uno por ítem de la prueba) para la entrada de las respuestas a los ítem, un texto informativo escrito sobre celdas y el comando Finalizar prueba, desde el que se lanza el script principal (Main) y, en consecuencia, las dos subrutinas asociadas al mismo (AccesoBD  e InfoIndiv)

Antes de pasar a explicar el contenido del script Main, para que se entienda correctamente cómo se desarrolla la fase Procesamiento de datos, es necesario exponer lo siguiente:

• Todos los controles de los dos formularios, a excepción los botones de comando, están asociados a celdas de la hoja Datos: los del formulario ubicado en la hoja DatosId a las celdas Datos.B1:B6 y los del formulario de la hoja Cuestionario a las celdas Datos.C7:C16.
• La puntuación de los ítem (PD) (celdas Datos.B7:B16) se realiza mediante la función Calc SI(C7=D7;1;0) ubicada en cada una de esas celdas.
• El cálculo de la PD total se realiza también mediante una función Calc en la celda Datos.B17 (SUMA(B7:B16))
• La valoración de los resultados se ubica en la celda Datos.B18 y se utiliza la función Calc SI(B17>=9;1;0)

De este modo, todo el procesamiento se realiza mediante funciones Calc. generando como resultado un registro en formato de tabla simple, que es la forma que adopta la hoja Datos. En ésta se registran todos los resultados de la aplicación individual de la prueba, por lo que, de archivarse Gestor  con un identificador de alumno, Datos queda disponible para posterior consulta. De optar por esta forma de registro NO se deberá utilizar el comando Borrar datos de hoja DatosId y es necesario visualizar la hoja Datos, dado que permanece oculta por defecto.

Volviendo  al funcionamiento de Datos, concentrar todos los datos que resultan de aplicar la prueba en Datos simplifica el funcionamiento del script principal (Main), el cual comentamos a continuación.

Sub Main

Dim oHoja As Object, oCelda As Object

Dim i As Integer

Dim mDatos(17) As Variant

'Acceso a los datos del alumno

oHoja = ThisComponent.getSheets().getByName("Datos")

'Paso de datos a matriz de resultados

For i = 0 To 17

oCelda = oHoja.getCellRangeByName("B" & i+1)

mDatos(i) = oCelda.getString

Next

' Acceso a base de datos

AccesoBD(mDatos())

'Creación de informe individualizado

InfoIndiv(mDatos()) 

 

'Movimiento a la hoja DatosId

vHoja(0,True)

PasoHoja(0)

vHoja(1,False)

End Sub

En Main se diferencian cinco subprocesos:

• Primero. Acceso a la hoja, asignando este objeto a la variable-objeto oHoja (oHoja = ThisComponent.getSheets().getByName("Datos"))
• Segundo. Mediante un bucle For recorremos el intervalo de celdas B1:B18 (For i = 0 To 17), accedemos a su contenido que asociamos a la variable-objeto oCelda (oCelda = oHoja.getCellRangeByName("B" & i+1)) y trasladamos su contenido a la matriz mDatos() (oHoja = ThisComponent.getSheets().getByName("Datos"))
• Tercero. Pasamos los valores de mDatos() a la subrutina AccesoBD() para trasladarlos al documento-Bd BDPrueba.ods, proceso del que se encarga dicha subrutina.
• Cuarto. Pasamos los valores de mDatos() a la subrutina InfoIndiv() para crear un documento Writer como soporte para la escritura del informe. De este subproceso se encarga InfoIndiv() (14)
• Quinto. Realizamos cambios en la visualización de Gestor, mostrando la hoja DatosId, nos posicionamos en ella y se oculta la hoja (Cuestionario) (15)

No me voy a detener en explicar las dos subrutinas que se citan en los pasos tercero y cuarto, ya que esta explicación ya ha sido realizada en otras entradas (ver nota 14), pero sí me interesa hacer un par de comentarios:

• Ambas subrutinas se crean como forma de simplificar el contenido del script Main, dentro de un planteamiento de programación modular, pero constituyen dos fases diferenciadas del algoritmo que forman parte de su núcleo o eje principal de funcionamiento. Por relevancia ambas podrían desarrollarse dentro del script principal.
• Existe una diferencia entre ambas subrutinas, al margen de las que se derivan del trabajo con una Hc Calc y un Documento Writer. Esta diferencia implica dos modos distintos de trabajar con archivos externos: Mientras que en AccesoBD() se trabaja con un documento ya creado, al que se debe acceder, en InfoIndiv() se crea un documento nuevo. Ambos procedimientos implican utilizar expresiones OOo Basic distintas.

sRuta = ConvertToUrl("D:\Pruebas\BDPruebas.ods)

oBD = StarDesktop.loadComponentFromURL(sRuta, " blank",0,mArg(())

... código de la subrutina AccesoBD() que nos permite acceder a un documento ya creado, previo acceso a su ubicación ([ver aquí]), mientras que...  

sRuta = "private:factory/swriter"

oNuevoDoc = StarDesktop.loadComponentFromURL( sRuta, "_default", 0, mArg())

... código de InfoIndiv() nos permite crear un documento nuevo (en este caso del servicio Writer) ([ver aquí])

Documentos

• Hc Gestor
• Hc Bd

NOTAS

(1) Esa antigüedad de los referentes normativos de la batería no implica que determinados test carezcan de utilidad. El hecho de estar descatalogada facilita el uso de libre de los materiales y la existencia de nuevas baterías que la sustituyen y actualizan nos permite cubrir adecuadamente con estos nuevos recursos los propósitos de evaluación que en su tiempo resolvíamos con WISC-R. Esto hace que no tenga sentido generar un docap sobre ella, pero sigue siendo de interés emplear parcialmente y con objetivos limitados (y más cercanos a la intervención educativa) algunos de sus materiales, los cuales ahora están plenamente disponibles sin que su uso resulte perjudicial para intereses de terceros. 

(2) El nivel de especificidad de este componente será tratado en una próxima entrada. En ella expondré los motivos que, a mi juicio, justifican tomar una decisión u otra. 

(3) Como mínimo para el desarrollo de los dos primeros (recogida de datos y su primer procesamiento) y el cuarto (el análisis de datos). Respecto al tercer componente se pueden manejar dos opciones: desarrollarlo sobre la misma Hc (Gestor) o bien sobre una Hc específica (BD). En este caso opto por la segunda posibilidad.

(4) Especialmente cuando el soporte-Calc no es muy elaborado. De hecho es la forma que se adopta en la mayoría de los soportes-Hc que conozco.

(5) Lo que nos interesa ahora es saber que disponemos de ambas, y no es necesario renunciar a una en beneficio de otra.

(6) De tomar esta decisión es obvio que, en orden lógico, ambos se sitúan como uno sólo al final del proceso, ya que la creación del informe requiere del análisis de los resultados. Esa unificación tiene una segunda consecuencia: se requiere decidir sobre qué servicio se va a concretar. Considero que la mejor opción sigue siendo Writer, aunque conlleva importantes limitaciones para un posible posterior análisis de los resultados. Esta limitación es, a su vez, una de las variables a considerar en la toma de decisiones sobre almacenamiento y publicitación de resultados individuales (informe)

(7) Más aun cuando aspiramos a que sea el propio OE quien desarrolle herramientas docap como las que proponemos en este blog.

(8) Esta segunda parte no siempre es posible ni conveniente, y la prueba la tenemos en los informes individualizados que emiten las plataformas de corrección on-line de las editoriales especializadas. Considero, no obstante, que debería estar presente siempre que las circunstancias lo permitan; esto es: cuando contemos con bases suficientemente contrastadas para formularla. De nuevo el hecho de que sea el propio OE quien elabore sus recursos presenta una ventaja evidente en cuanto a la posibilidad de automatizar la generación de  análisis de este tipo.

(9) El código de gestión de la Bd estaría dirigido al trabajo con la base de datos y podría implementarse directamente sobre la Hc. El código de formateo de InfoPrueba debería ubicarse dentro de IDE, en Mis macros y diálogos. Otra opción sería incluirlos dentro del propio documento, pero en este caso habría que modificar el algoritmo original para acceder a un documento creado en lugar de crearlo mediante código.

(10) El código para cerrar el diálogo  (oDialogo.EndExecute()) se ubica dentro del script IrCuestionario, que se activa desde el cmdCuestionario, posicionado en el propio diálogo. Ese script incluye otras instrucciones, por lo que se considera parte del tercer bloque de script.

(11) Además, para el funcionamiento de los script secundarios se requiere la declaración de tres variables públicas: dos para el código-macro (document  y dispatcher) y una para el manejo del diálogo (oDialogo). En lo que resta de entrada me limitaré a explicar los script principales. Únicamente haré referencia a los secundarios como parte del funcionamiento del docap.

(12) Esto supone implícitamente una forma de uso del docap: utilizarlo en formato de evaluación individualizada, de modo que el mismo documento Gestor sirve para múltiples usos. Implica también renunciar a recuperar los datos de un alumno concreto, aunque sí se conservan en forma de registro en la base de datos (BDPrueba.ods) y como informe individualizado. El usuario también tiene la opción de utilizar el Gestor como plantilla y archivar (y por tanto conservar) la ejecución de cada alumno; para ello NO deberá usar Borrar datos, al menos no antes de haber renombrado y guardado el documento SoportePrueba.ods.

(13) Desde este script se ejecuta la instrucción de cierre del diálogo (oDialogo.EndExecute) y se llama a tres subrutinas de manejo de las hojas del Gestor.  

(14) En [esta entrada] se explica el procedimiento de escritura en un documento Writer empleado código OOo Basic. La creación de un documento nuevo desde otro (en este caso SoportePrueba.ods) [se explica aquí]

(15) Estos cambios se realizan utilizando los scritp-subrutinas vHoja() y PasoHoja(). La primera se emplea dos veces: en la primera para mostrar la hoja DatosId y la segunda para ocultar la hoja Cuestionario. Ver esta subrutina en el IDE. La subrutina PasoHoja() se ha creado transformando el código de una macro, de ahí que incluya el script ParaMacro.