Evaluación. Modelo básico

Modelo básico de docap

Calificar de básico a este modelo equivale a decir concreción del tipo 2 visto en [esta entrada] y decir docap incide en lo mismo, especificando que nos vamos a limitar en la presente al uso de OOo Basic como lenguaje de referencia.

Me limito a desarrollar como docap-modelo el de tipo 2 por ser el de uso más frecuente en el posible desarrollo de herramientas de evaluación y también por facilitar el desarrollo de una alternativa en Python, así como por similitud con el soporte básico de recogida de datos en la sección Análisis. Esto no quiere decir que no vaya a crear docap de tipo 1, pero como éstos están ligados estrechamente al contenido de aprendizaje, no parece conveniente extenderse en estos momentos en explicar algo que va a sufrir tantas modificaciones como deriven de los contenidos concretos con los que se vaya a trabajar.

Entrando ya en materia y completando lo indicado en la entrada citada al inicio de ésta, el docap-modelo que presento ahora no se diferencia demasiado del presentado [en esta entrada] respecto al trabajo con documentos. Salvando algunas diferencias (que puede haberlas), la mayor y más significativa es que el docap actual añade una base de datos a los componentes de ese docap; el resto de componentes no tiene por qué ser diferente, aunque sí lo será el procedimiento de análisis. No obstante, como este proceso no será desarrollado en esta explicación por los mismos motivos (más otros añadidos) (1) que en aquel caso, las diferencias reales entre ambos en términos de programación se reducen significativamente. Por estos motivos, no resultará demasiado complicado explicar y entender lo que a continuación voy a exponer: en gran medida será suficiente con repetir lo ya visto.

Para concretar un docap-modelo de evaluación se debe primero especificar en que nivel se recoge la información, ya que es posible diferenciar tres: respuestas del alumno, puntuaciones obtenidas por ítem y puntuación total de la actividad o prueba. Considero que para que resulte realmente operativo (en términos de automatización) se debe contemplar como nivel básico al menos el segundo, pero en función de la característica del docap, desarrollaré el primer nivel: recogida de las respuestas, que implica que la puntuación de las mismas se resuelve mediante código.

Una segunda cuestión, aunque afecta al análisis y dije antes que en esto no iba a entrar, es con qué referentes se van a calificar los resultados. Esta cuestión requiere aclarar previamente qué tipo de evaluación se propone: normativa, criterial o mixta. Estas cuestiones no corresponden a esta entrada, ya que es necesario clarificar el significado concreto de esos conceptos y sus implicaciones, por eso opto aquí por una solución de compromiso muy simplificada, como corresponde a un docap básico (2).

La primera fase del proyecto es, como en los modelos documentales, el trabajo con la hoja de cálculo, empezando por la creación del formulario (hoja Form) (3). Este podría ser el resultado:

No he pretendido hacer nada sofisticado, por lo que es mejorable, pero sirve para el objetivo de este docap-básico. Contiene algunas diferencias con el docap-básico de trabajo con documentos, que explico a continuación:

• En el formulario se diferencian tres partes, frente a las dos de los modelos anteriores: a parte de los botones de comando, los controles de entrada se diferencian por su función: los tres primeros son para datos de identificación y los restantes para la recogida de las respuestas de los ítem.
• Esta diferencia se reproduce en la asignación de esos controles a celdas: los controles de datos de identificación se asocian a tres celdas de la columna I, y los de los controles de ítem a siete celdas de la columna J.
• Esta diferenciación por columnas puede no ser necesaria, pero sí va a serlo la diferenciación en el acceso a cada uno de los dos tipos de datos, como veremos en el código correspondiente. Después explicaré el motivo.

Además, y esa es la principal diferencia con los docap-modelo documentales, deberemos crear una segunda hoja (Datos) donde crearé la tabla de datos, concretamente los encabezamientos de las columnas que sirven para identificar sus campos.

Una vez preparado el documento Calc, corresponde desarrollar el código que nos permita acceder a los datos introducidos por el usuario. Para ello declaro las variables (4) y accedo al documento y a la hoja Form, siguiendo el procedimiento ya conocido...

Dim oHoja As Object, oCelda As Object

Dim mDatosper() As String, mCeldasi() As String

Dim mResp() As String, mCeldasj () As String, mAcierto() As String

Dim mPtos() As Integer, PD As Integer

Dim n1 As Integer, nj As Integer

Dim i As Integer

Dim Md As Single, Dt As Single, Pz As Single, Pc As Single

Dim mDatos() As Variant

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

Observa que he declarado dos matrices para contener los datos (mDatosper() y mResp()), ya que me interesa trabajar de forma independiente con cada uno de los dos bloques de datos. Como dije antes, esta diferenciación obedece al diferente tratamiento que tendrán los datos de identificación y los datos de respuestas a los ítem: los primeros no presentan novedad respecto a otras ocasiones, pero los segundos sí: sobre ellos realizaremos operaciones específicas, como tendremos ocasión de ver en su momento. Repito: con los datos personales nos limitamos acceder a ellos, pero los datos de respuesta a los ítem serán usados para generar los elementos de la tercera matriz (mPtos()), que contendrá las puntuaciones de los ítem resultante de la corrección de la prueba, las cuales están contenidas en una cuarta matriz (mAcierto()).

Por ello, el acceso a las respuestas del alumno, con la que finaliza la primera fase del script principal Main se resuelve de forma similar a cómo se resolvió el acceso a los datos personales, esto es: mediante un bucle For (For i = 0 To UBound(mResp()))

ni = 2

ReDim mDatosper(ni)

mCeldasi= Array("I1","I2","I3")

For i = 0 To UBound(mDatosper())

oCelda = oHoja.getCellRangeByName(mCeldasi(i))

mDatosper(i) = oCelda.getString()

Next

A continuación entramos en la segunda fase de Main, en la que nos corregimos las respuestas dadas por el alumno. En este caso el sistema es muy sencillo, pero puede ser mucho más laborioso, lo que hace recomendable la diferenciación que antes expliqué entre datos de identificación y datos de respuestas. 

Para realizar esta corrección damos contenido a la matriz que contiene las respuestas correctas (mAcierto() = Array("A","B","C","D","E","F","G")) y mediante un nuevo bucle (For i = 0 To  UBound(mResp())) y un condicional (If mResp(i) = mAcierto(i) Then) recorremos la matriz mResp() y comparamos su contenido con el esperado (mResp(i) = mAcierto(i)), asignando la puntuación que corresponde a cada ítem según se cumpla o no dicha condición. Aprovecho este mismo bucle  para calcular el sumatorio de las puntuaciones del alumno (PD = PD + mPtos(i)), lo que supone entrar en la tercera fase del script.

mAcierto() = Array("A","B","C","D","E","F","G")

For i = 0 To  UBound(mResp())

If mResp(i) = mAcierto(i) Then

mPtos(i) = 1

Else

mPtos(i) = 0

End If

PD = PD + mPtos(i)

Next

Como dije, este sumatorio constituye el inicio de la tercera fase, la cual está dedicada a realizar los cálculos que nos permitirán calificar los resultados que obtiene el alumno: el porcentaje de aciertos, en función del tamaño del test y su puntuación directa (Pc = (PD/(nj+1))*100), y la puntuación típica (Pz = (PD - Md)/Dt), en función de supuestos valores de media (Md = 5.38) y la desviación típica (Dt = 0.47) (5).

A continuación se desarrolla la cuarta fase del script principal (Main) que tiene como objetivo construir con los datos parciales anteriores una matriz única de datos con la que trabajaremos en las subrutinas a las que se llama al final de Main (PasarDatos(mDatos()) y Info(mDatos())) (quinta fase). 

Aunque podríamos ahorrarnos esta cuarta fase, por los motivos que dije en su momento puede no ser la mejor opción; pero, en todo caso, sí es conveniente crear una matriz única con todos los datos necesarios, ya que será muy útil para el correcto funcionamiento de las subrutinas que veremos más adelante. 

Para crear esta matriz-síntesis recurriré de nuevo a los bucles como medio para automatizar la asignación de contenidos, aunque algunos de ellos es necesario asignarlos de forma directa, como se puede observar en el código:

ReDim mDatos(19)

For i = 0 To UBound (mDatosper())

mDatos(i) = mDatosper(i)

Next

For i = 0 To UBound( mResp())

mDatos(i+3) = mResp(i)

Next

For i = 0 To UBound(mPtos())

mDatos(i+10) = mPtos(i)

Next

mDatos(17) = PD

mDatos(18) = Pc

mDatos(19) = Pz

Primero redimensionamos la matriz-resumen (ReDim mDatos(19)) y después vamos asignando los datos, empezando por los personales (mDatos(i) = mDatosper(i)), siguiendo por las respuestas del alumno (mDatos(i+3) = mResp(i)), después los resultantes de la corrección de la prueba (mDatos(i+10) = mPtos(i)), finalizando con los datos-resumen, resultantes de los cálculos (vg. mDatos(17) = PD) (6).

Paso ahora a explicar los dos procedimientos que restan y que se ejecutan de forma independiente del script principal, mediante subrutinas: 

• La primera (Sub PasarDatos(Datos() As Variant)) está pensada para construir la base de datos, trasladando los datos de la matriz-resumen (mDatos()) a la tabla creada en la hoja Datos.
• La segunda (Sub Info(Datos() As Variant)), ya conocida de [esta entrada], para crear el informe.

Estas subrutinas constituyen una especie de "externalización de procedimientos" del algoritmo, pero esto, además de ejemplificar el uso del principio de la programación modular, resulta necesario más que meramente conveniente, dada la relativa complejidad de ambos subprocesos y su independencia respecto al objetivo principal del script Main. 

Dado que la segunda ya es conocida desde la publicación de [esta entrada], me limitaré a explicar la primera. Con ella automatizamos la creación de la tabla o base de datos, dotando a nuestro docap de un potencial muy interesante: recopilar los resultados de las aplicaciones individuales de una prueba, lo que facilita el posterior análisis de dichos datos (7).

Sub PasarDatos(Datos() As Variant)

Dim oHojaBD As Object, oCeldaInicio As Object, oCeldaNuevoRegistro As Object, oCeldaId As Object

Dim i As Integer, a As Integer, b As Integer, c As Integer, d As Integer

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

c = 1000

For i = 0 To c

oCeldaInicio = oHojaBD.getCellRangeByName("A" & CStr(i+2))

If oCeldaInicio.getValue() = 0 Then

a = i + 2

d = i + 1

Exit For

End If

Next

MsgBox "Id de la nueva entrada: " & d

'Escritura de los datos en el registro vacío

oCeldaId = oHojaBD.getCellRangeByName("A" & CStr(a))

oCeldaId.setValue(d)

For b = 0 To UBound(Datos())

oCeldaNuevoRegistro = oHojaBD.getCellByPosition(b+1,a-1)

oCeldaNuevoRegistro.setString(Datos(b))

Next

End Sub

Esta subrutina cuenta con un argumento que remite a la matriz-resumen (PasarDatos(Datos() As Variant)) de los datos del script principal Main, resultando ahora evidente la necesidad de su creación: gracias a ellos se simplifica la escritura de esos datos en la tabla.

Pero antes de dar ese paso debemos acceder a la hoja Datos (oHojaBD = ThisComponent.getSheets().getByName("Datos")) y posicionarnos adecuadamente en la primera fila no escrita (8) mediante un bucle condicionado

For i = 0 To c

oCeldaInicio = oHojaBD.getCellRangeByName("A" & CStr(i+2))

If oCeldaInicio.getValue() = 0 Then

a = i + 2

d = i + 1

Exit For

End If

Next

Cuando encontramos la celda de la columna A (oCeldaInicio = oHojaBD.getCellRangeByName("A" & CStr(i+2))) que cumple la condición (oCeldaInicio.getValue() = 0) asignamos el valor de inicio a la variable-contador que nos van a permitir recorrer las diferentes columnas de la tabla (a = i + 2) y de captura el valor Id de la fila A que precede a la que no cumple el criterio del condicional (d = i + 1). Después interrumpimos el bucle.

Después volvemos a posicionarnos en la celda de la columna A localizada mediante el bucle anterior (oCeldaId = oHojaBD.getCellRangeByName("A" & CStr(a))) y escribimos en ella el valor Id que corresponde (oCeldaId.setValue(d)) y de nuevo, mediante un bucle dimensionado en base a la matriz-resumen (For b = 0 To UBound(Datos())), recorremos ahora las columnas (campos) que se corresponden con la fila (oCeldaNuevoRegistro = oHojaBD.getCellByPosition(b+1,a-1)) y trasladamos a cada celda los datos de la matriz (oCeldaNuevoRegistro.setString(Datos(b))).

Documento. Desde [este enlace puedes acceder a DocapBaseEval.ods]

NOTAS

(1) Si en el caso de los docap-documento el tema del procesamiento remitía a las dificultades para tratar de forma simplificada el problema del procesamiento, en el caso de los docap-evaluación la problemática se acentúa, ya que de una prueba de evaluación se derivan muchos más datos cuantitativos y de categorización que requieren procesos de análisis de la bifurcación de mayor complejidad. No obstante el tratamiento de la opcionalidad en el caso de los contenidos textuales es realmente más complejo, ya que se ajustan en menor medida que los datos de un test a un planteamiento de tipo algorítmico.

(2) Por lo que no resulta satisfactorio desde ninguna de las perspectiva de análisis, pero tiene la ventaja de incluir referencias a ambos modelos (y al mixto). Además, y es lo que importa, evidencia los mecanismos básicos del análisis desde ambas perspectivas (la normativa y la criterial), aunque de forma muy simplificada.

(3) Dado que el informe se crea sobre un documento en blanco, no es necesario crearlo. También es posible utilizar un documento previamente creado y formateado, con lo que implica de trabajo previo y de modificación del código de acceso. Ver al respecto el modelo básico 2 de docap de documento en [esta entrada]

(4) Incluyendo las que serán necesarias para el procesamiento posterior y que explicaré en su momento.

(5) Ambos valores sirve únicamente a efectos del funcionamiento del docap, pero no reflejan valores reales de ninguna prueba en concreto.

(6) Puedes apreciar que los tres primeros bloques se ejecutan mediante bucles (reajustando los valores de los índices de la matriz-resumen) y en los últimos la asignación se realiza de forma directa.

(7) Este análisis es anticipatorio pero diferentes del que nos planteamos en la sección Análisis del Blog. También lo es este docap del que podemos crear dentro de ese campo de trabajo.

(8) Recuerda que una fila de una tabla equivale a un registro en una base de datos. Las columnas de la tabla equivalen a los campos de la base de datos y serán tratadas como variables en el análisis de datos.

Evaluación.

Docap para la evaluación (b)

Esta segunda entrada complementa [la anterior], de la que es continuación. En ella explicaré el funcionamiento básico del modelo de docap para la creación de recursos de intervención y evaluación.

Universidad de Murcia

Tomaré como referencia el docap de tipo 1, del que hablé en [otra entrada], más que nada porque es el más completo de los dos y porque implica también el docap tipo 2, de modo que así quedan explicados los dos.

Como dije en la entrada anterior, el soporte para la presentación de los materiales (Prueba) será una hoja Calc (1). Esta decisión facilita unificar Prueba y Gestor, transformando éste en el mecanismo de acceso a la matriz de datos que genera la actividad del alumno en su interacción con los ítem de las actividades que se le presenten. Calc permite la inclusión de imágenes y su posicionamiento en pantalla, incluyendo la conversión de éstas en comandos a los que asociar código. También permite incluir controles de formulario que se asocian fácilmente a celdas. Obviamente es posible la combinación de ambas fórmulas y, en cualquier caso, usar Calc simplifica al tratamiento de los datos y el acceso a otros documentos (Writer, para el output del Informe. Un ejemplo del uso de Calc como soporte para la ejecución de actividades por parte del alumno la tienes [en esta entrada] y en el docap que se vincula a ella (2).

Cuando no existe Prueba y directamente trabajamos sobre Gestor (docap tipo 2) generalmente lo que se nos va a presentar es un formulario sobre el que volcar los datos individuales del alumno evaluado. Los controles de este formulario se asocian con una columna de celdas y es desde ellas desde las que accedemos a la matriz de datos mediante código. Hasta ese punto lo que hacemos es uso de las funcionalidades de Calc (concretamente del uso de formularios), simplificando así el desarrollo del docap. Esta asociación puede crear algún inconveniente relativo al tipo de variable (alfanumérica vs. numérica) que deberemos resolver mediante código, pero esto no presenta mayor problema (3).

Esta presentación mediante formulario constituye el input del algoritmo aunque no esté basada en código, y no es realmente muy diferentes del modelo que pudiste observar en el ejemplo del enlace anterior, ya que éste también usa controles de formulario, siendo éstos los que determinan la constitución de la matriz de datos mediante su asociación a celdas.

Llegados a este punto, lo que sigue es el proceso de análisis o procesamiento de los datos obtenidos, el cual se realiza mediante código, resultando de él un texto (informe) que se deberá volcar en un documento que constituye el sistema de output del docap. Obviamente el modo en que se concrete este análisis va a depender de cada tarea o prueba concreta (4), pero el resultado será, invariablemente, la elaboración del informe individual, soportado sobre un documento Writer (5).

Queda por hablar del sistema de almacenamiento de datos en formato tabla o matriz. Este sistema no compete en sentido estricto a un docap de evaluación como el descrito, ya que éste es de naturaleza individual, pero lo incorporo "de serie" para enlazar con la tercera pata del banco de este blog: el análisis de datos (6). Para hacer posible dicho análisis es necesario acumular resultados al menos en dos fases: en un primer momento se limita a los resultados de la aplicación a nivel grupal (evaluación referida a norma grupal) y la segunda amplia este horizonte en función de una recogida de datos más amplia (evaluación referida a norma local/sectorial) (7).

Para hacer esto posible es necesario desarrollar el código que traslade los datos individuales a una tabla o base de datos, la cual se materializa sobre el mismo documento Calc. Será esta base de datos sobre la que se desarrollarán los subsiguientes análisis, sean estos de tipo "normativo" o de naturaleza estrictamente analítica (valga la redundancia), incluyendo los estudios de las actuaciones y/o de los instrumentos de intervención. Ambos requieren contar con datos suficientes y estas bases de datos acumulativas cumplen esta función (8).

NOTAS

(1) Ya advertí de posibles docap en los que excepcionalmente use como soporte una presentación Impress. En este caso es necesario generar sobre la presentación un script que acceda a los datos generados en la presentación y acceda al Gestor, que se basará en Calc.

(2) En este caso, la combinación del docap con una presentación no es plenamente equiparable al modelo que se indica en la nota 1. En este caso la presentación es un auxiliar informativo para el posterior desarrollo de las actividades sobre Calc. Esta es, pues, una variación sobre el modelo integral (tipo 1) que se describe en esta entrada.

(3) Aunque hay que tenerlo en cuenta para no llevarnos sorpresas de errores de funcionamiento en la fase de procesamiento de los datos mediante código.

(4) Y dentro de ello, la naturaleza normativa vs. criterial sobre la que se sustenta la evaluación propuesta.

(5) Esto implica que el código debe contar con un procedimiento de acceso o creación de dicho documento, además de los procedimientos de escritura correspondientes.

(6) Que de hecho se desarrolla como sección diferenciada en [Análisis], siendo un contenido de ésta que sirve de puente entre ambas, ya que aunque remite al desarrollo de procedimientos de análisis de datos, en sentido estricto y en el caso de pruebas o actividades diseñadas por el SEO (vs. comerciales) requiere aplicar procedimientos de análisis de los resultados grupales y/o de muestra, incluso para la propia elaboración del informe individual.

(7) No corresponde aquí detenerse en explicaciones al respecto, aunque será necesario abordar el tema en otro momento. El uso del término "norma" (grupal y/o local/sectorial) no implica reducir el procedimiento a criterios normativos, pudiendo aplicarse también procedimientos de evaluación criterial, que, de considerarse de referencia, constituirían el verdadero primer nivel de referencia para la elaboración del informe. En cualquier caso, aunque se trabaje sobre la base de la evaluación criterial, siempre que sea posible (y lo debe ser al menos a nivel grupal) dicha referencia debería complementarse con una referencia al criterio "norma grupal".

(8) Lo que no supone descartar la posibilidad de crear sistemas de gestión de bases de datos específicamente diseñadas para cubrir las necesidades que deriven de las actuaciones que contemplamos dentro de la sección Análisis, pero esta es una cuestión que no afecta al tema que estamos exponiendo ahora.

Evaluación.

Contenidos de la sección

En esta sección trataré cuestiones relativas a la construcción de pruebas de evaluación y actividades de aprendizaje, sin una diferenciar explícitamente entre ambas en cuanto tales (1) no sólo por comodidad (que sí) sino también por considerar que esa diferencia es más de uso que de estructura y contenido. Eso por lo que se refiere a los materiales concretos de intervención.

Aunque ese apartado será posiblemente el más extenso de la sección, no será el único. Y en algunos de ellos es posible que esa diferenciación sea evidente, pero no en el primero.

Inicio la sección con este relato de fundamentos, aclaraciones, terminologías y clasificaciones, para pasar, en segundo lugar, a presentar lo que se puede considerar la célula básica de una prueba o actividad: el ítem y su tipología, donde también expongo los procedimientos específico que permiten construir cada uno de ellos.

La tercera parte de la sección la dedico al análisis de pruebas o test de evaluación; pruebas comercializadas, de uso frecuente en la evaluación psicopedagógica y fundamentadas en el enfoque de la evaluación normativa, por oposición a la evaluación criterial. En este caso se trata fundamentalmente de un análisis, aunque limitado a la estructura y objetivos de la prueba (2) puede ser que vayan acompañadas con la presentación de un docap de tipo 2, según se describe en [esta entrada], aunque lo común será que esta cuestión se trate de forma diferenciada, a fin de dar detalles de su elaboración y funcionamiento.

La parte cuarta de la sección estará dedicada, como dije, a la presentación de los instrumentos propiamente dichos, haciendo distinción (eso sí) a aquellos que se basan en fundamentos normativos vs. criteriales, así como a cuales pertenecen al modelo Tipo 1 y Tipo 2 respectivamente.

NOTAS

(1) Salvo por alguna posible indicación en el enlace que se muestre en la página Evaluación y lo que derive del título de la entrada.

(2) En algunos casos, este análisis se puede complementar con el de resultados obtenidos. Pero este segundo tipo de análisis no pertenece a esta sección, sino a la específicamente denominada [Análisis]

Evaluación.

Docap para la evaluación (a)

Atendiendo al marco de trabajo delimitado en la [entrada anterior], y con independencia de que se incluya en esta sección la exposición del proceso seguido hasta este momento, al menos en lo que se refiere a la presentación de materiales-modelo o como se les quiera llamar, me basaré en lo que a OOo Basic se refiere, en un modelo que ha resultado del citado proceso. Este procedimiento básico se expresará en sus dos vertientes: como soporte de análisis de resultados y como recurso de trabajo. Adelanto que se basará en el servicio Calc y en el uso de script OOo Basic. Ambos han demostrado ser los medios más efectivos para el objetivo que me planteo en esta sección del blog.

Universidad de Murcia

El objetivo de esta entrada es exponer el procedimiento básico de trabajo que ha derivado del proceso primero de digitalización y después de informatización de los recursos de evaluación.  

Diferencio entre ambos porque, al igual que sucede en la informatización de la documentación, también aquí parto de un proceso previo, desarrollado en la práctica a lo largo de los años de trabajo como orientador. Dicho proceso se inicia como digitalización de los recursos y culmina en el presente en la elaboración de un docap complejo (1).

Aunque el proceso en si mismo es ilustrativo de los planteamientos y de la evolución de los procedimientos, dejaré acaso este tema para tratarlo en el apartado Análisis de esta sección. Ahora me centraré en explicar en qué consiste su conclusión en el presente, el docap complejo, incluyendo, a modo de síntesis, ambos tipos de soporte: el de recursos para el uso directo con el alumnado y el de registro y evaluación de los resultados de la aplicación individual (2).

El docap-modelo se basa en el uso de dos servicios: un soporte de aplicación (en su caso) y recogida de datos basado en Calc y un soporte para la generación del modelo de informe individual de resultados basado en Writer. Ocasionalmente puede incluir un soporte de presentación de los ítem basado en Impress cuando el contenido gráfico de los ítems así lo aconseje, pero no será este el modelo dominante.

Esta estructura de soportes facilita hacer uso de las funcionalidades de los servicios específicos (fundamentalmente de Calc), reduciendo la carga de codificación que supondría basar el docap únicamente en Writer y el uso de formularios. No obstante, el núcleo principal del docap es el código OOo Basic.

Es este código el responsable del acceso a los datos, de su análisis y del acceso al documento Writer, receptor del informa resultante.

El manejo del documento Writer presenta las misma dos posibilidades que vimos en el trabajo con documentos: elaborar el informe sobre un documento en blanco o trabajar con un documento-soporte previamente formateado. Esta segunda opción será excepcional, ya que incrementa el nivel de dificultad de la creación del docap, y se opta por ella cuando las características del modelo de informe a elaborar así lo requiera.

Dicho informe se debe considerar como una expresión del principio de semi-automatización (vs. automatización), por lo que queda abierto a ser matizado, modificado y complementado por el profesional, incluyendo el posible añadido de gráficos cuando así lo considere necesario (3) 

El docap modelo resultante consta pues de los siguientes componentes identificados en términos de funcionalidad:

• Un procedimiento de presentación del contenido a evaluar accesible al alumno o facilitador de la interacción del profesional con el alumno (4). Este componente se basa en Calc (excepcionalmente en Impress) y es propio de los soportes tipo 1. A este recurso le llamaremos directamente Prueba.
• Un sistema recogida de datos, que puede ser de detalle (puntuación directa de cada ítem) o genérico (valores índice) (5). Este componente se basa en una hoja Calc. En caso de soporte tipo 2, este soporte puede denominarse Gestor. Cuando hablamos de soportes de tipo 1, generalmente este subconjunto de procedimientos estará incluido en Prueba, pero cabe la posibilidad (cuando el contenido en imágenes es de mucho peso o cuando, por ese mismo motivo, se opta por presentar el documento al alumno en formato Impress) de que se diferencien ambos soportes. En este caso también se identificará como Gestor. 
• Un primer procesamiento de los datos basado en el uso de funcionalidades de Calc (formularios y fórmulas principalmente).
• Un segundo procedimiento orientado al almacenamiento de los datos y del resultado de ese procesamiento anterior, desarrollado en OOo Basic.
• Código generador del análisis de los resultados individuales basado en algoritmos creados con OOo Basic.
• Y código OOo Basic para el volcado del análisis anterior a modo de informe en un documento Writer. Este documento (informe individual) constituye el output del docap.

Dedicaré la [entrada que sigue] a explicar con más detalle alguno de los componentes de este esquema de contenidos. 

NOTAS

(1) Por docap complejo entiende aquel que implica el uso de al menos dos servicios LO. Normalmente serán dos: Calc y Writer.

(2) El análisis de los resultados grupales cae dentro de la sección [Análisis]

(3) Este mismo principio rige también para la hoja de cálculo, por ejemplo creando manualmente y a posteriori los gráficos estadísticos que se consideren necesarios. No obstante existe una diferencia de base entre el soporte-Calc y el soporte-Writer: el primero constituye también la base de datos sobre la que es posible desarrollar, mediante procedimientos específicos, el análisis de los resultados grupales que se van obteniendo a lo largo de la historia de uso del recurso (para este planteamiento ver nota 2); el segundo es finalista y está pensado para incorporar al expediente SEO individual del alumno, aunque cabe un segundo procedimiento de almacenamiento pensando en ese posterior análisis grupal (copia del informe por tipo de prueba en subdirectorio específico). 

(4) Caben varias opciones de concreción de este componente, ya que no es lo mismo que se oriente al uso directo por parte del alumno, que deba servir al orientador/profesor para la interacción individual con él. En el primer caso, la carga que implica el uso de gráficos es un factor a tener en cuenta a la hora de decidir si interesa informatizar esta fase del procedimiento de evaluación, aunque no debe ser el único ni el más determinante, [según expuse aquí].

(5) Este es el componente primero en los soportes tipo 2, ya que obviamente carecen del anterior. El grado de detalle en la recogida de datos depende del grado de detalle del análisis de los resultados individuales a realizar, pero también del interés por complementar ese análisis con otro de tipo grupal (de nuevo, ver nota 2)

Evaluación.

Tipos de pruebas. Implicaciones para su informatización.

Entre los diferentes criterios que podemos aplicar para diferenciar los diferentes tipos de pruebas que se emplean para la evaluación, el que interesa desde la perspectiva de este blog es que diferencia entre soportes para la aplicación y soportes para la evaluación. No es una distinción común dentro del campo, pero tampoco lo es el objetivo que aquí perseguimos: automatizar la aplicación de recursos para la evaluación y la intervención (1).

Universidad de Murcia

En el trabajo con los documentos, en cuanto a su automatización la diferencia principal radica en que el referente sea un documento en blanco o un documento-modelo. En la evaluación esta diferenciación se traslada al objetivo: crear un soporte para aplicar y utilizar directamente con el alumno (tipo 1) o crear un soporte que facilite la corrección y la evaluación de los resultados (tipo 2). Según la opción elegida, así el proceso a seguir.

El primero incluye al segundo, por lo que éste resulta de una delimitación del objetivo que nos planteamos con el soporte. La causa de esta delimitación (o simplificación, si se prefiere, porque lo es) es tanto de economía como de interés o planteamiento; pero también de limitación impuesta. Me explico.

Si somos capaces de crear pruebas (actividades, ejercicios...) con las que puede trabajar el niño, ¿por qué limitarnos a crear soportes que únicamente ayuden en la corrección y/o evaluación de los resultados?. Las respuestas son varias, y están en función de motivos y condicionamientos.

• En el uso de test comercializados, la creación de un soporte para aplicar puede entrar en conflicto con los derechos de autor. Únicamente si la prueba está descatalogada y ya no se comercializa es posible utilizar los materiales para crear un soporte que pueda emplear directamente el alumno. Sin embargo, en este caso, desarrollar un instrumento que nos facilite la corrección y/o el análisis y la evaluación de los resultados no entra en contradicción con esa limitación.
• El uso de un soporte informático no es necesariamente una solución mejor y preferible al uso de otro tipo de soportes y materiales: el uso de materiales manipulativos, la aplicación de las pruebas y ejercicios en papel, incluso la copia de los enunciados en la libreta pueden aportar mucho más al proceso de enseñanza-aprendizaje y a la evaluación que lo que aportan los recursos informatizados. En todo caso, parece conveniente combinar diferentes materiales, ya que la sustitución de lo analógico por lo digital no es necesariamente progreso, ni añade nada especialmente relevante al proceso educativo (2).
• El coste en tiempo y esfuerzo que conlleva generar soportes informatizados no siempre se ve compensado por las supuestas o reales ventajas que puede implicar su uso; y lo que siempre falta al profesorado y a los orientadores es tiempo. Sin embargo, si ese material se va a emplear ampliamente y es de esperar que también a lo largo del tiempo, crear soportes para la recogida de datos y su evaluación sí puede implicar una ventaja añadida, reduciendo los tiempos y el esfuerzo que supone obtener datos definidos como relevantes por parte del propio profesional (docente u orientador).

El resultado de todo esto es que me centraré en la creación de docap pensados para la recopilación de datos, su análisis y la evaluación de los resultados. Los procedimientos implicados en este tipo de soportes se implementarán también en los docap de aplicación, los cuales se limitarán, en lo fundamental, a concretar propuestas de actividades simples de aprendizaje.

Con estas últimas pretendo modelar procedimientos de trabajo que implican el proceso e-a en su conjunto sin entrar en cuestiones que afectan más al diseño de instrucción que a la elaboración de instrumentos de intervención-evaluación. Me evito así el riesgo de entrar en terrenos cuya complejidad supera los objetivos de este blog (3).

NOTAS

(1) Incluyo el término intervención por dos motivos: el primero porque no existe una diferencia radical entre ejercicio o prueba de evaluación y ejercicio para el refuerzo del aprendizaje. El segundo porque no me limitaré en esta sección a trabajar exclusivamente con recursos pensados para la evaluación psicopedagógica. No entiendo la intervención del orientador reducida a la evaluación, sino como colaborador del profesorado en la intervención educativa.

(2) De hecho hoy en día parece claro que incluso puede suponer un retroceso y una limitación en lo que se refiere al desarrollo de ciertas habilidades.

(3) Esta omisión es en realidad un reconocimiento de la complejidad del diseño de instrucción, cuestión esta sujeta, además, a controversias en las que no pretende entrar. No al menos en esta sección del blog.

Evaluación. Ítem.

Ítem de opción (b1). Varias opciones. Forma simple.

Otra forma en que se puede presentar un ítem es cuando debemos elegir una entre varias opciones. En este caso no se trata de señalar si el enunciado es correcto o no, como en el caso de la [entrada anterior], sino de elegir cual de las respuestas que se presentan como posibles (normalmente cuatro o cinco) es la correcta o, en algunos casos, la mejor de las opciones. En este tipo de ítem también es adecuado usar el control Botón de opción, ya que sólo se puede optar por una de las opciones. 

Este tipo de ítem también es frecuente (incluso más que el de V/F) en las pruebas y ejercicios de comprensión lectora (1). Normalmente se plantea una pregunta a la que se dan una serie de alternativas de respuesta. Una de ellas es correcta y el resto son falsas (distractores).

Los planteamientos de trabajo suelen ser de dos tipos básicos: o bien se trata de una respuesta literal (está expresada como tal en el texto con el que se trabaja) o requiere algún tipo de inferencia, bien lingüística o bien de tipo lógico. Dentro de las inferencias se pueden diferenciar dos niveles: las inferencias que se realizan a partir de la información explicitada en el texto y las que requieren hacer uso de conocimientos previos, sin que sea suficiente el mero conocimiento del contenido textual.

A su vez los distractores también pueden ser analizados en cuanto a la información que contienen: pueden ser distractores cuyo contenido carecen de relación con la pregunta que se formula o distractores con un mayor o menor nivel de similitud con la respuesta correcta. En este segundo caso también podemos formular distractores próximos al contenido textual o al recursos a algún tipo de inferencia.

Ambas dimensiones del ítem, y el uso estratégico que se haga de ellas, hacen que una prueba basada en este tipo de ítem sea muy interesante para evaluar no sólo el nivel de comprensión lectora, sino también el tipo de estrategias que emplea el alumno en ese proceso. Y para ello puede ser el útil el análisis de los aciertos y también el de los errores.

Aunque estas cuestiones son de gran interés para la formulación de pruebas y los procesos de análisis de los resultados, en lo que a esta entrada se refiere, lo que aquí nos interesa son las implicaciones que este tipo de ítem tiene para la elección del control de formulario y el modo de análisis de los resultados que derivan de su uso.

Desde esta perspectiva cabe decir que, además de que es conveniente utilizar botones de opción como control-input, su implementación es diferente a la que se usa en ítem V/F, pero más en lo formal que en el procedimiento a seguir. Veámoslo mediante un ejemplo: 

Puedes comprobar que se trata del mismo texto que empleamos en la entrada en la que se explica el uso de ítem V/F, pero que ahora cambia el estilo y tipo de las preguntas y, lo que es aquí más definitorio, el modo en que se presentan los controles-opciones de respuesta:

•  Las opciones se escriben "dentro" del control, mediante su funcionalidad Etiqueta (Propiedades |General | Etiqueta)
• Cada botón tiene su propio nombre (Propiedades |General | Nombre) que componemos con un valor numérico sucesivo para facilitar su posterior manejo mediante código (btn1... btnZ)
• Cada conjunto de botones se establece como tal en relación al ítem mediante el mismo identificador en Nombre del grupo (Propiedades |General | Nombre del grupo)
•  Cada botón se asocia a una celda diferente pero que mantiene cierta afinidad con las del resto de los botones del grupo (Propiedades | Datos | Celda enlazada). De esta forma es posible eliminar las activaciones de los botones mediante código, una vez resuelta la actividad. 

De este proceso garantizamos el correcto funcionamiento de los botones como opción alternativa en función del ítem, así como su posterior manejo mediante código (2).

Una vez que hemos implementado los controles en el formulario, deberemos concretar la forma en que se van a analizar las respuestas, ya que en función de la opción que se elija, así se concretará el modo en que se aborde el proceso mediante código.

La primera y más simple de las opciones de análisis es limitarse a identificar al acierto vs. error en cada uno de ellos. En este caso no nos interesa que opción incorrecta haya tomado como cierta el alumno, sino únicamente el hecho de que sea o no sea la opción predefinida como correcta (3). Pero si nos interesa analizar el error, y no sólo conocer el nivel de acierto, entonces el planteamiento anterior resulta insuficiente e inadecuado. Pero vayamos por partes.

En el primer caso, cuando sólo queremos realizar un análisis a partir del número de aciertos en la prueba, es suficiente con conocer cual es la respuesta correcta en cada caso y, en función de ello, establecer la puntuación que recibirá cada uno de los ítem. Dado que ese conocimiento es previo, la solución informática puede ser muy simple, aunque el nivel de automatización del proceso sea bajo y, en consecuencia, el código poco eficiente, pero también bastante simple.

Supongamos el ítem anterior, en el que la respuesta correcta es la primera opción. Conocida ésta y centrándonos en el análisis de la puntuación, el script podría ser el siguiente:

Sub Item1

' --  VARIABLES  -------------------------------------------------------

'Variables para acceso al formulario

Dim oHojaActiva As Object

Dim oPaginaDibujo As Object

Dim oFormularios As Object

Dim oFormulario As Object

'Variables para acceso a los controles y para la puntuación del ítem

Dim Botones (3) As Object

Dim RespuestaAlumno As Integer

' ----  ACCESOS  --------------------------------------------------------

oHojaActiva = ThisComponent.getCurrentController.getActiveSheet()

oPaginaDibujo = oHojaActiva.getDrawPage()

oFormularios = oPaginaDibujo.getForms()

oFormulario = oFormularios.getByName("frmItemEleccion")

'ÍTEM 1. Acceso al control (botón de opción) Correcto

Botones(0) = oFormulario.getByName("btn1")

If Botones(0).State() Then

RespuestaAlumno = 1

Else

RespuestaAlumno = 0

End If

'  --- INFORME -----------------------------------------------------------------------

MsgBox "Puntuación del alumno en el primer ítem: " & RespuestaAlumno

End Sub

 

Dado que el proceso de acceso a los objetos (hoja activa, capa de dibujo, colección de formularios, formulario activo y botones de opción) ya ha sido explicado en [esta entrada] y queda claramente representado en la parte inicial del script y que la fase informe la resumimos mediante un MsgBox, me centraré en explicar el acceso a la respuesta correcta y la puntuación del ítem. Esta parte del código se inicia con el comentario 'ÍTEM 1. Acceso al control (botón de opción) Correcto y finaliza con la instrucción previa al comentario '  --- INFORME -------------.

Haciendo uso de la matriz Botones (3) y la variable RespuestaAlumno previamente declaradas, nos basta con acceder al primero de los botones (btn1) que asignamos al primero de los componentes de la matriz destinada a ese fin (Botones(0)) mediante la instrucción ya conocida (Botones(0) = oFormulario.getByName("btn1")).

En un segundo momento, analizamos el estado (activado/no activado) de dicho botón (Botones(0).State()), condicionando la puntuación del ítem (que asignamos a la variable RespuestaAlumno) a que dicho objeto esté activado (If Botones(0).State() Then -> RespuestaAlumno = 1) o no lo esté (Else -> RespuestaAlumno = 0)

Ni que decir tiene que, conocidas las opciones correctas, lo que podemos hacer para puntuar el resto de los ítem de la prueba es generalizar el procedimiento que acabo de explicar, con lo que ya disponemos de una forma simple de trabajar con cuestionarios basados en ítem de varias opciones, aunque no estaría de más realizar algunas mejoras; las más sencillas: sustituir la variable de asignación de puntuación por una matriz para ahorrarnos la creación de varias variables y crear un procedimiento más funcional para recoger y archivar los resultados (4). Aunque caben mejoras sin salirse de la simplicidad del procedimiento, con ellas no nos alejamos mucho de la formulación más básica del procedimiento, así que no las voy a plantear aquí y las dejo a tu mano. 

Adelanto, eso sí, que existen otras formulaciones más potentes, pero también de mayor complejidad, que nos interesa conocer; pero quedarán para la siguiente entrada; así en ésta nos podemos centrar en comprender el procedimiento explicado, en mejorarlo (5) y en aplicarlo en la práctica.

Documento. En el IDE de [ItemOpcion2a.ods] puedes ver el script comentado en esta entrada. Para mayor comodidad se activa desde el botón de comando CORREGIR, pero te recomiendo que analices y trates de mejorar el código del script al que está asociado.

NOTAS

(1) Un ejemplo es la prueba Estructuras gramaticales de PROLEC, en la que se presenta una imagen y el alumno debe seleccionar una de las cuatro frases que supuestamente están representadas en ese dibujo. Curiosamente, y sin una explicación específica del motivo, en PROLEC-R fue sustituida esta presentación por su contraria: una frase (input) y cuatro dibujos, debiendo el alumno seleccionar cual de ellos representa correctamente el significado de la frase. Sería interesante estudiar las diferencias entre los resultados de ambos tipos de presentación, estudiando los propios baremos de este subtest en ambos modos de presentación del ítem. Aunque es relativamente frecuente que las opciones gráficas sustituyan a las escritas (por ejemplo, en test de comprensión oral, lectora, de conocimiento léxico o de estructuras gramaticales), en test específicos de comprensión lectora, como queda dicho, el ítem que se expone en esta entrada es de uso muy frecuente en pruebas de comprensión lectora.

(2) Ambas cuestiones son importantes para que la prueba funcione y sea analizada de forma conveniente. Por ejemplo, gracias a  la forma en que nombramos los botones podremos después trabajar adecuadamente mediante script, pero necesitamos que respondan como opción-ítem, por lo que es necesario que cada conjunto quede adscrito a un grupo. La alternativa es dar el mismo nombre a los botones-opciones del ítem, pero esto nos crea problemas para el posterior análisis de las respuestas.

(3) En cierto modo, pero no en sentido estricto, este modo simplificado de análisis acerca este tipo de ítem al de V/F, ya que las respuesta final se define únicamente en estas dos posibilidades.

(4) Cierto que nos faltaría desarrollar un procedimiento más funcional para registrar y almacenar los resultados. Un ejemplo podría ser el que empleamos en los ítem de opción V/F ([Ver en el documento adjunto a esta entrada]). En el documento que anexo a la actual puedes encontrar un desarrollo simple y acumulativo del procedimiento que explica en el texto.

(5) Ya dije que esas posibles mejoras corren de tu cuenta, aunque te recomiendo que lo hagas; así desarrollarás tu lógica de programación y aplicarás aprendizajes anteriores. Una de esas propuestas de mejora podría ser crear funciones o subrutinas que reduzcan la repetición de instrucciones en el script principal. Otra la creación de ese procedimiento de almacenamiento de los datos resultantes de la aplicación de la prueba, incluyendo el cálculo de la puntuación total.