sábado, 31 de agosto de 2024

Evaluación. Ítem

Ítem de opción (a) V/F

Aunque los ítem de opción sean considerados unos de los ítem típicos de las pruebas de evaluación, lo cierto es que estos ítem, en su formulación textual son menos frecuente en los test de lo que pudiera parecer. Sí se empelan frecuentemente en la evaluación de la comprensión lectora y en cuestionarios de valoración actitudinal, pero no es frecuente en otro tipo de pruebas (1)


Como acabo de decir en los test de evaluación de la comprensión lectora (2) es frecuente emplear ítem de opción en diferentes configuraciones: 
  • De V/F y similares.
  • De opción correcta + distractores.
  • O de varias opciones correctas + distractores

También se usan en cuestionarios de evaluación de actitudes, preferencias o grado de satisfacción, en las que la opción seleccionada no implica acierto/error, pero sí puede implicar una valoración de tipo ordinal (3). En este caso, a nivel psicométrico (y sociométrico) estamos hablando de las ya citadas escalas Likert.  

Todos estas opciones de ítem pueden ser informatizados mediante diferentes objetos-control (de formulario o de cuadro de diálogo) que permiten implementar las opciones de respuesta. 

Dado que como objeto-control ya han sido tratados en otras entradas, me limitaré ahora a ejemplificar su uso como ítem de evaluación (4), atendiendo a cómo se implementan en la prueba, cómo se recoge la respuesta y cómo se trata ésta.

Desde esta perspectiva nos centraremos en si el ítem se valora en términos V/F (con independencia de las opciones de respuesta, sólo una es V) o si caben varias respuestas V (con independencia de que todas reciban la misma puntuación o no).

Cuando sólo una respuesta es V (y el resto F), cabe emplear al menos dos controles, el Botón de opción y el Cuadro de lista,  pero la que funcionalmente resulta más apropiada es el control [botón de opción]. Por el contrario, cuando necesitamos seleccionar varias opciones (5) lo es el control [casilla de verificación] (6). 

En esta entrada me voy a limitar a explicar cómo formular el ítem V/F más sencillo, esto es: aquel en el que sólo hay dos opciones de respuesta: V vs. F (y sus diferentes formulaciones). Veremos un ejemplo en el que suponemos una prueba o un ejercicio de comprensión lectora en en que, tras la lectura del texto, se plantean al alumno un conjunto de ítem que piden elegir entre V o F en respuesta a afirmaciones basadas en el contenido textual. Normalmente estos ítem van precedidos de una explicación que concreta la instrucción.

Después de leer (el texto) di si son verdaderas o falsas las frases siguientes:

  • Juan es hermano de Rosario - (Verdadero - Falso)
  • Juan tiene 8 años -  (Verdadero - Falso)
  • ...

Para abordar la informatización de actividades de este tipo (formen parte de ejercicios de aprendizaje o de pruebas de evaluación) es especialmente apropiado el uso del control Botón de opción, del cual ya sabemos unas cuantas cosas como control de formulario o de cuadro de diálogo. Entre lo sabido está el modo de implementar estos controles en (por ejemplo) un formulario creado sobre un documento Calc, pero no estará de más refrescar nuestros conocimientos.

La implementación del objeto botón de opción, como ya sabemos, se realiza en la capa de dibujo (o capa gráfica) del documento, que es en la que se posicionan los formularios y sus controles. Este proceso, que es en realidad complejo, no es perceptible en la fase de implementación que realizamos normalmente de forma manual, ya que se ejecuta de forma automática en función de la jerarquía de clases y objetos que deriva de la lógica de la programación orientada a objetos (POO) (7) en que se basa LibreOffice, por lo que, insisto, en esta fase del proceso nos limitaremos a "dibujar" los controles que deseemos, que serán dos por ítem: uno para la opción V y otro para la opción F.

Repitiendo el procedimiento tantas veces como ítem V/F tenga la prueba, crearemos el cuestionario, finalizando con ello la primera fase del proceso (8):


Cabe decir que la configuración de los botones para que funciones A (V) como alternativa de B (F) requiere que se cumplan determinadas condiciones (nota 8): o bien se les da el mismo nombre a ambos botones sin definir grupo, o bien se les da diferente nombre y se les asigna al mismo grupo; en ambos casos, si se establece celda de destino de la respuesta, cada botón debe tener asignada una celda diferentes (9).

El proceso que sigue se basa en OOo Basic y supone desarrollar las dos fases que siguen a la primera: el acceso a las respuestas y su análisis. Aquí el análisis se limitará a puntuar los ítem, pero en un docap real habría que analizar esas puntuaciones en los términos que se ajuste a los objetivos de la intervención.

Primeramente mostraré un código no depurado por permitir una mejor compresión del procedimiento. Este código se puede descargar como archivo txt desde [este enlace] y lo iré comentando en lo que sigue de la entrada.

En un segundo momento mejoraremos el código inicial de forma que resulte más funcional y menos extenso. Pero no adelantemos acontecimientos. Ahora toca explicar la primera versión.
  
Como dije antes, la siguiente fase del proceso consiste en acceder al contenido de los controles, lo cual realizaremos mediante código OOo Basic (10). Para ello deberemos acceder sucesivamente al documento y a la hoja activa,  a la capa de dibujo, a la colección de formularios y al formulario al que pertenecen los controles; todo ello, como ya sabemos, requiere la previa declaración de variables de objeto a las que asignar los objetos indicados:

'ACCESO AL FORMULARIO

Dim oHojaActiva As Object
Dim oPaginaDibujo As Object
Dim oFormularios As Object
Dim oFormulario As Object

'Acceso a la hoja activa
oHojaActiva = ThisComponent.getCurrentController.getActiveSheet()

'Acceso a la página de dibujo en la que se encuentran los formularios
oPaginaDibujo = oHojaActiva.getDrawPage()

'Acceso a todos los formularios de la hoja de cálculo
oFormularios = oPaginaDibujo.getForms()

'Acceso al formulario por el nombre
oFormulario = oFormularios.getByName("frm2")

El segundo paso de esta fase es acceder al objeto botón (BotonesOpcion(0) =oFormulario.getByName("btn1a")) y a su contenido, lo cual se concreta como acceso a su estado (activado vs. desactivado) (BotonesOpcion(0).State()). Puedes observar que hemos asignado el objeto botón a un elemento de una matriz previamente declarada (Dim BotonesOpcion (7) As Object) (11).

Este acceso al estado del control se realiza mediante un condicional que permite asignar un valora a los elementos de la matriz en la que recogemos realmente los resultados (Dim RespuestasAlumno (3) As Integer). Los que se asignan son simplemente la traducción del boolean que resulta de la activación del control del formulario, de uno u otro elemento del par de controles, tal y como los establecimos en el formulario que se mostró en la imagen anterior. Veamos un ejemplo del análisis del funcionamiento del botón V del primer par (12):

If BotonesOpcion(0).State() Then
	RespuestasAlumno (0) = 1
End If
 
A partir de este momento iniciamos la tercera fase que afrontaremos medida un procedimiento de comparación de las respuestas contenidas en la matriz RespuestasAlumno() con las correctas, las cuales están recogidas en la matriz RespuestaCorrecta() y cuyo contenido he establecido mediante la función Array() (RespuestaCorrecta() = Array(1,0,0,1)). Esta comparación la realizamos mediante una doble estructura ciclo-condicional:

For i = 0 To UBound(RespuestasAlumno ())
If RespuestasAlumno (i) = RespuestaCorrecta (i) Then
	Puntuacion (i) = 1
Else
 	Puntuacion (i) = 0
End If

Next
  • El condicional permite comparar el contenido de las dos matrices: la que contiene las respuestas del alumno con las respuestas correctas (RespuestasAlumno (i) = RespuestaCorrecta (i)). En función de esta comparación se establece el valor de la puntuación en la matriz Puntuacion ().
  • El ciclo nos permite recorrer los cuatro elementos de las matrices antes indicadas para repetir la comparación que realizamos mediante el condicional.
Lo que resta del desarrollo de esta tercera fase (escritura de los resultados contenidos en la matriz Puntuacion () en determinas celdas, a modo de informe) carece de relevancia para lo tratado en esta entrada, y es conocido por haber sido tratado en otras entradas, por lo que ahora no me detendré en explicarlo.

explicaré, aunque brevemente, el segundo (conjunto de) script, que puedes encontrar en el IDE del documento que enlazo más abajo.

  • Se trata de un código más estructurado en el que se diferencia el script principal (ItemVF2) de los componentes secundarios, en los que se diferencian una función (Respuestas()) y dos subrutinas (PasarPtos() y BorrarRespuestas())
  • La función Respuestas() permite simplificar significativamente el código del script principal, ya que asume el desarrollo de la segunda fase de forma mucho más eficiente que mediante la repetición de las instrucciones de acceso a los controles y a su estado.
Function Respuestas (Form As String,Formulario As Object, Formularios As Object) As Object

Dim i As Integer
Dim BotonesOpcion (7) As Object
Dim Respuesta (3) As Integer

Formulario = Formularios.getByName(Form)

For i = 1 To 8
BotonesOpcion(i-1) = Formulario.getByName("btn" & i)
Next

For i = 0 To 3
If BotonesOpcion(i*2).State() Then
Respuesta (i) = 1
Else
Respuesta (i) = 0
End If
Next

Respuestas = Respuesta()

End Function
  • Las subrutinas PasarPtos() y BorrarRespuestas() asumen del desarrollo de los pasos finales de la tercera fase: la escritura del "informe" en la hoja y el borrado de los datos para eliminar la selección de los botones. 
Dado que no es esta la única forma en que se presentan los ítem de opción, en entradas sucesivas estudiaremos otras formulaciones, las cuales ya han sido enunciadas al inicio de esta entrada. La es la primera de esta serie. 

Documento. En el documento Calc [ItemEleccion.ods] puedes ver en funcionamiento el manejo de los controles botón de elección (13). 

NOTAS

(1) En realidad está más representado en ellas de lo que suponen estas afirmaciones, pero lo están en su versión gráfica, en la que el alumno debe seleccionar como respuesta una imagen entre varias. Por ello lo anterior es válido en lo que se refiere a la formulación textual. Como la formulación basada en gráficos fue tratada en [esta entrada], nos entraremos en esta entrada (y en las que la continúen) en las que llamo de formulación textual por ser el ítem expresado mediante alguan froma de expresión escrita.
(2) En [este enlace] se analiza un buen número de pruebas actuales de comprensión lectora. No todas emplean el ítem de opción múltiple, pero sí es el modelo de ítem usado en ellas con más frecuencia. Sirvan como ejemplos los siguientes test: [EDICOLE], [TECOLEIN] y [ECOMPLEC]
(3) En este caso, tanto a nivel psicométrico como sociométrico, estamos hablando de [escalas Likert].
(4) De hecho estos objetos están ampliamente representados entre las opciones disponibles en un formulario o en un cuadro de diálogo como tendremos ocasión de ver en esta entrada. También los hemos analizado de forma individualizada como elementos de las interfaces gráficas. Al respecto puedes consultar [esta página del blog].
(5) Y no sólo una entre varias, como en el caso anterior.
(6) En ambos casos estamos hablando de las opciones de control ideales, pero no las únicas. De hecho podemos articular un sistema de controles combinados que respondan a diferentes necesidades, incluyendo el uso de controles de comando (botones de comando, si se prefiere). En esta entrada abordaré primero el uso de los controles básicos (botones de opción y casilla de verificación) y después expondré algún procedimiento basado en la combinación de controles.
(7) Como ya sabes, si empleamos un Cuadro de diálogo deberemos trabajar desde el IDE del documento, cuestión esta que nos remite a entradas anteriores (ver nota 6), pero aquí me limitaré al uso de este control como parte de un formulario por ser el servicio y soporte más usado para informatizar las pruebas. Por lo que respecta a la implementación de cualquier control de formulario realizada de forma manual (que es lo más frecuente), ésta genera automáticamente acceso a la capa gráfica y crea también automáticamente un objeto formulario, por lo que ambos procesos pasan desapercibidos hasta que tenemos que acceder al control desde el código: en este momento se evidencia la jerarquía de clase y objetos que implica el trabajo con los controles de formulario.
(8) En realidad hay un par de cuestiones que conviene tratar, aunque hayan sido explicadas en entradas anteriores. Se trata del modo en que se implementa el control Botón de opción y cómo se configura. Respecto a la primera cuestión, en caso de que este control no esté visible en la barra Controles de formulario puedes implementar inicialmente un control Casilla y después cambiarlo a Botón de opción desde el menú emergente que se activa con clic derecho sobre el control, opción Reemplazar por. Respecto a la configuración del control, para un mejor tratamiento del objeto mediante código OOo Basic, te sugiero que des nombres secuenciales (btn1, btn2... btnZ), lo que te facilitará posteriormente automatizar el acceso a estos objetos, también te aconsejo que crees los grupos pertinentes (en este caso, cuatro) asociando a cada grupo el par de botones que corresponden con el ítem; de este modo se garantiza su adecuado funcionamiento opcional (si uno se activa, se desactiva su contrario). Finalmente, aunque no es necesario en sentido estricto, te aconsejo que asocies cada botón con una celda (y des al texto que resulta color blanco para que no sea visible); procediendo por parejas (V -> M1 vs F -> N1) después te será más fácil crear código para borrar el contenido de esas celdas y los botones sin seleccionar. Sobre estas cuestiones volveré en el texto de la entrada.
(9) No es necesario asignar el resultado a una celda, pero ayuda a gestionar el borrado o desactivación del botón (ver final de la nota 8).
(10) Podríamos desarrollar los procesos que siguen sin trabajar con OOo Basic, pero el uso de código mejora significativamente el rendimiento del docap, además de ser el objetivo de esta entrada.
(11) Además de esta matriz declaramos otras tres para el posterior manejo de los datos, como podremos ver en el texto de la entrada (Dim RespuestasAlumno (3) As Integer, RespuestaCorrecta (3) As Integer, Puntuacion (3) As Integer)
(12) En esta versión del script se repite el proceso descrito tantas veces como botones de opción hemos implementado en el formulario de la prueba; de ahí la extensión que ocupa este segmento del código.
(13) Al igual que en la primera versión del código, tampoco ahora nos interesa detenernos en  la explicación de estas subrutinas, por resulta ya conocidas al lector. En todo caso, en el IDE del documento puedes acceder a ese código para analizarlo en detalle.

miércoles, 21 de agosto de 2024

Evaluación. Ítem.

Ítem gráfico (b). Mapa interactivo.

Este tipo de ítem, basado en el uso de imágenes como [el anterior] está mucho menos representado en las pruebas de evaluación que aquel, aunque podemos considerarlo apropiado para el tratamiento de todas aquellas actividades que se basen en la localización de elementos en un "mapa" o gráfico complejo en el que se representan diferentes elementos.


La prueba CONCEBAS (Conceptos básicos) puede considerarse apropiada para aplicar este método de informatización del ítem, pero donde más aplicaciones puede tener es en la elaboración de materiales para la intervención: enseñanza y evaluación de vocabulario (en español o en lengua extranjera), identificación de elementos individuales en imágenes complejas, posicionamiento de elementos en un mapa geográfico...

Las bases técnicas de la elaboración de este tipo de ítem están expuestas [en esta entrada] en su parte final. Partiendo de lo visto en ella voy a aplicarlo a crear un ítem que puede servir para la evaluación o para la intervención; en realidad se trata de un ejercicio de vocabulario de la anatomía de la cara, basada en una lámina de Esther Moret García publicada en es.liveworksheets.com, sobre la cual se han construido otras aplicaciones, como el vocabulario de las partes de la cara en inglés.


En
 este caso trabajaremos la identificación del vocablo enunciado por el adulto sobre la imagen. Para ello sobrepondré una imagen transparente, asociando a ella la valoración (A-E /1-0) en función del acierto o fallo.

Como ya vimos [al tratar este procedimiento], el mayor trabajo está en organizar el material y dar el tratamiento adecuado a la imagen principal y a las imágenes que sirven de comando (1); los script y subrutinas no se diferencian del código creado para el trabajo con otros ítem basados en imágenes o gráficos, como podemos ver a continuación (2).

Script

Sub Boca

    Dim sOpcion As String

    sOpcion = "A"
    Resultado (sOpcion)

End Sub

Subrutina

Sub Resultado (Opcion As String)

Dim oHoja As Object, oCelda As Object

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

oCelda = oHoja.getCellRangeByName( "B5")

oCelda.setString(Opcion)

oCelda = oHoja.getCellRangeByName( "C5")

If Opcion = "A" Then

oCelda.setValue(1)

Else

oCelda.setValue(0)

End If

End Sub

Documento. En [este documento] se desarrolla la propuesta que explico en la entrada.

NOTAS

(1) Eliminar la línea del contorno de la figura, dar el color a estas imágenes auxiliares que más se adecue a la principal, dar el grado de transparencia que cumpla el objetivo esperado... 
(2) Otra cuestión es el tratamiento del conjunto de ítem de la prueba o del ejercicio, pero en este caso nos limitaremos al tratamiento del ítem individual, por lo que los script creados son suficientes. LO que sí he añadido a la subrutina es la puntuación del ítem (sobre la celda C5), no sólo al registro de la respuesta. Con ello carece de sentido crear una función Calc que cumpla ese cometido.

martes, 20 de agosto de 2024

Evaluación. Ítem.

Ítem gráfico (a). Elección de imagen.

Desde el punto de vista de la informatización de las pruebas de evaluación, este ítem presenta características que exigen una explicación, ya que supone diferencias importantes respecto a los anteriores al introducir gráficos (imágenes) como parte del input con implicaciones en la forma de respuesta del alumnado.


Este tipo de ítem son muy frecuentes en las pruebas de evaluación; algunos ejemplos
  • EDAF, prueba de discriminación auditiva de palabras
  • RFI
  • CEG
  • Peabody
  • ...
... así como  en muchos subtest de baterías como el subtest de comprensión de oraciones del test PROLEC(R) y diversos subtest de pruebas de evaluación cognitiva, como las distintas versiones del WISC, los subtest no verbales del RIAS y un largo etcétera. 

Por ello, esta modalidad de ítem resulta de gran interés para el desarrollo de recursos de evaluación.

En estos ítem, el input puede combinar elementos verbales y/o textuales, pero lo importante es la presencia de gráficos (imágenes), ya que estas tienen una función secundaria en las hojas de cálculo (servicio que usamos como soporte), pero adquieren una función central en nuestros docap.

A parte de la explicación y la posible ejemplificación, la formulación más frecuente del ítem es la siguiente: el examinador expresa el input verbal y (en su caso) señala o toca cada una de las imágenes (1).

En cuanto a la respuesta (output) se espera que el alumno seleccione la imagen correcta, bien señalándola, bien tocándola directamente (2). En este sentido, este ítem es similar a los de opción binaria o múltiple, aunque este modelo de ítem presenta también características propias que requieren un tratamiento específico.

Si llevamos este modelo de respuesta a planteamientos de programación, podremos convertir el tacto en medio de automatización de la respuesta. Y esto constituirá el núcleo de la informatización del ítem.

Dado que empleamos gráficos, lo primero que tenemos que aprender es a incluir imágenes en una hoja de cálculo, lo que no presenta grandes dificultades, ya que Calc cuenta con diferentes opciones:
  • Menú Insertar | Imagen (3)
  • Menú Insertar | Forma
  • O usando el objeto Botón de comando de Formulario -> Propiedades -> Imagen (4)
Las dos primeras opciones requieren un tratamiento específico posterior que puede desarrollarse de diferentes formas, como tendremos ocasión de ver más adelante en esta entrada. El uso de imágenes en los botones de comando resuelve directamente parte de ese tratamiento, ya que conserva las cualidades del botón de comando, principalmente su necesaria conexión con un script. Dada su simplicidad y el conocimiento que ya tenemos del uso de los botones de comando, empezaremos por esta opción.

Para ejemplificar los distintos procedimientos (incluido el uso de comandos), desarrollaré una propuesta simple [en este documento]. En ella se presentan cuatro imágenes (formas geométricas, para simplificar el ejemplo), una de las cuales deberá ser seleccionada en función de la demanda verbal (input) relativa a su forma y color (5), por ejemplo: 
  • Instrucción: "Selecciona la forma que te digo a continuación. Para ello haz clic en (la forma/en el botoncito naranja situado debajo de la forma."
  • Input: "Cuadrado rojo"
En la hoja UsoCmd ejemplifico esta opción. Este procedimiento se basa en imágenes incrustadas en los botones de comando tal y como se explica en [esta entrada]. Después deberemos crear un script por cada botón, resolviendo la ejecución de la acción (la grabación de la opción seleccionada) mediante una subrutina (6).

En las hojas UsoImg1 y UsoImg2 se ejemplifican dos modos de resolver la interacción del alumno con la prueba cuando se emplean formas. En UsoImg1 recurro a un procedimiento similar al usado en UsoCmd, sólo que los botones de comando son, en este caso, el recurso para facilitar la interacción, siendo las imágenes meros elementos de input. Por el contrario, en UsoImg2, cada una de las formas es a la vez estímulo y medio para la acción del sujeto (output). Para ello se asignan script a las imágenes, tal y como se describe en [esta entrada(7). En ambos casos se reproduce el mismo procedimiento que ya se describió para UsoCmd, incluyendo lo indicado en nota 6.

Por simplificar la explicación y el ejemplo, me he limitado a crear cuatro script para asociar a cada uno de los comandos (UsoCmd y UsoImg1) o figuras (UsoImg2), de modo que en las tres opciones sus elementos funcionan con los mismos script. También la subrutina es compartida (8)

Ejemplo de script (corresponde al elemento Cuadrado rojo)

Sub FormaCdR
Dim sOpcion As String

sOpcion = "A"
Resultado (sOpcion)
End Sub

Subrutina

Sub Resultado (Opcion As String)

Dim oHoja As Object, oCelda As Object

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

oCelda = oHoja.getCellRangeByName( "B5")

oCelda.setString(Opcion)

End Sub 

El script (todos ellos, en realidad) contiene una variable String (sOpcion) a la que se le asigna un valor alfanumérico (sOpcion = "A") y que se pasa por referencia a la subrutina (Resultado (sOpcion)).

Esta  cuenta con un parámetro (Resultado (Opcion As String)) que permite dotar de contenido a la instrucción de asignación (grabación de dato en la celda) (oCelda.setString(Opcion)). Previamente hemos accedido a la hoja Resultados y a la celda (B5 en esta caso) mediante instrucciones ya conocidas de asignación de objetos a variables de objeto (Dim oHoja As Object, oCelda As Object) para hoja (oHoja = ThisComponent.getSheets().getByName("Resultados")) y para celda (oCelda = oHoja.getCellRangeByName( "B5")) (9)

Documento

En [este documento] encontrarás las propuestas de formulación del ítem explicadas en la entrada. Como siempre, en su IDE puedes acceder al código que he aplicado.

NOTAS

(1) Por ejemplo en el test de discriminación auditiva de palabras del test EDAF. Ese tacto no es necesario en otros test, ya que el input (verbal) es único y se trata de que el alumno identifique (y señale, output) la imagen. Este es el caso, por ejemplo, del test Peabody. En otros ni siguiera es necesario ese input verbal, que se presenta por escrito, correspondiendo al alumno la lectura del texto.
(2) En otros casos, por ejemplo en el RFI, se espera que el alumno nombre la imagen. Se trata de en caso especial en el que la imagen es fundamental en cuanto al objetivo de la evaluación, pero carece de importancia en términos de programación, al margen de su implementación como input. 
(3) Con esto resolvemos el input de pruebas como el RFI, ya que en ellas las imágenes deben ser nombradas, no seleccionadas de alguna forma. La opción Forma como alternativa a Imagen no es relevante, simplemente nos facilita la creación de formas (fundamentalmente geométricas) y su uso en el docap, evitándonos la necesidad de buscar y/o crear ese tipo de imágenes en fuentes ajenas al servicio Calc.
(4) En este caso resolvemos directamente el procedimiento que se explica posteriormente en el texto de la entrada.
(5) Podemos entender que este ítem forma parte de una prueba que evalúa la comprensión de conceptos básicos combinados forma-color de cuatro formas geométricas básicas.
(6) Esta fase del procedimiento no se diferencia de la ya explicada en [entradas anteriores]
(7) Si en vez de formas empleamos imágenes, el procedimiento de asignación del script a la imagen es ligeramente diferente al que se sigue para la asignación del script a la forma. Esto quedó explicado en [esta entrada]. El resto del procedimiento es igual para ambos tipos de contenidos.
(8) Por las mismas razones de simplificación resuelvo la identificación de alumno mediante un "cuestionario" basado directamente en celdas (Hoja Datos, que está protegida, menos las celdas donde se deben introducir los datos) y la asociación de estas celdas con las correspondiente de la hoja Resultados.
(9) También por las razones que para 7 y 8 y por ejemplificar las posibilidades que ofrece la combinación de script OOo Basic con funciones Calc, la puntuación del ítem corre a cargo de una función Calc incluida en la celda B6 (=SI(B5="A";1;0)). Otra opción habría sido incluir la puntuación del ítem dentro de la subrutina, repitiendo la asignación de celda a la oCelda (en ese caso para B6), empleando un condicional asociado a la valoración del parámetro Opcion (If Opcion = "A" Then... Else... End If). En este caso, la instrucción de asignación subsiguiente debería ser oCelda.setValue().





martes, 13 de agosto de 2024

Procedimientos. Datos.

Calc. Funciones de fecha y hora.

Dentro de las funciones propias de Calc, las de fecha y hora tienen un interés especial para el trabajo del OE, ya que permiten registrar datos temporales y realizar cálculos en ellos, siendo éstos fundamentales para el registro de las actuaciones y para el trabajo en los procesos de evaluación.


Empezaremos por la función AHORA() que tomaremos como referencia para otras funciones. AHORA() devuelve la fecha y la hora actual del sistema expresada según el idioma de configuración del programa. En mi caso, los valores devueltos se expresan como dd/mm/aaaa hh:mm. Una característica de esta función es que el resultado que devuelve se actualiza automáticamente en el momento en que se emplea.

Sobre esta función o directamente sobre un valor que expresa la fecha o la hora es posible aplicar funciones que calculan cada uno de sus componentes: AÑO(), MES(), DIA(), HORA(), MINUTO() y SEGUNDO() (1).

Todas estas funciones Calc tiene su equivalente en funciones OOo Basic, siendo la única diferencia el que se expresan en inglés, así AHORA() se expresa en OOo Basic como Now(). El resto de las funciones de fecha y hora también pueden toma como valor de referencia la función Now: Second(Now) (2). Estas son las equivalencias entre las funciones Calc y las funciones integradas (Built-In) en OOo Basic (3):
  • AHORA() - Now()
  • AÑO() - Year()
  • MES() - Month()
  • DIA() - Day()
  • HORA()Hour()
  • MINUTO() - Minute()
  • SEGUNDO() - Second()

NOTAS

(1) En el caso de aplicar cualquiera de estas funciones sobre AHORA(), la expresión será (por ejemplo) como sigue: MES(AHORA()). Aunque AHORA() no contemple necesariamente a la expresión del valor de los segundos (depende de cómo se haya configurado la expresión del valor), éste está presente implícitamente, por lo es posible conocer este valor mediante la función SEGUNDO().
(2) AHORA() - Now() es una función sin argumentos, por lo que se puede expresar con o sin paréntesis (AHORA() = AHORA).
(3) Como se puede ver, se trata de una mera traducción de términos. Las funciones Calc se expresan en español por ser éste (en mi caso) el idioma elegido en la instalación de LibreOffice. Sobre las funciones Built-In OOo Basic puedes ver [esta entrada] y las que siguen en la sección Funciones.

jueves, 8 de agosto de 2024

Evaluación. Estategias.

Análisis de una práctica

Me voy a referir (y a limitar) en esta entrada a mi propia práctica profesional en cuanto a creador y usuario de soportes de evaluación basados en medios informáticos. Digo también limitar porque lo que aquí se expone no pretende tener carácter de modelo ni mucho menos ser representativo de la práctica común de los OE.


Como análisis lo que contiene está entrada está basado en el contenido de la documentación elaborada a lo largo de mi intervención, aunque limitada a los últimos años. No ofreceré más que el resultado del análisis de esos datos, no los datos en si mismos, ya que carecen de valor y aportarlos podría dar a entender un rigor del que necesariamente carece este análisis (por lo limitado que es).

Como reflexión, pretendo mostrar las líneas de trabajo y cómo se fueron concretando, sus fortalezas y debilidades. Todo ello con la pretensión de servir de base para lo que en este blog se desarrolla y pretende aportar como recurso para la práctica profesional.

Debo decir, en primer lugar que los datos recogidos de las fuentes (1) confirman la persistencia del interés por informatizar el proceso de evaluación (y más concretamente de los recursos o instrumentos), más allá de lo que podemos denominar como digitalización, entendiendo por tal la mera réplica del recurso en formato digital. Esta forma limitada de informatización se manifiesta en concreto como archivo de documentos en soporte pdf y/o doc (procesador de texto) y su peso en la documentación consultada es escaso y limitado a ciertas pruebas. 

Escaso numéricamente, ya que no resulta funcional crear soportes que ya están disponibles como materiales originales (2) y limitado a ciertas pruebas por ser éstas recursos que o bien no se comercializan o están disponibles libres de restricciones (3).

Dos son las formas en que se ha concretado mayoritariamente el esfuerzo de informatización o semiautomatización de los recursos: como bases de datos y/o como hojas de cálculo (4), predominando numéricamente las hojas de cálculo, aunque la mayor complejidad se produce en los materiales basados en base de datos.

Estas bases de datos se desarrollan mediante la lógica propia de las mismas (tablas interrelacionadas) complementadas con un lenguaje de macros propio del producto (FileMaker), consiguiéndose buenas prestaciones en el soporte resultante; además, el propio servicio de base de datos facilita el almacenamiento de los resultados. No obstante esta solución presenta dificultades y condicionantes que hace que sea poco viable como medio para generalizar la informatización de las pruebas (5), sobre todo si contamos con recursos gratuitos y mucho más sencillo de usar.

De hecho las bases de datos resultan ser el servicio ofimático de mayor complejidad y menor uso entre los profesionales de los SEO, mientras que las hojas de cálculo, aun con no tener un uso generalizado, son más conocidas y, sobre todo, mucho más sencillas de utilizar. 

A la mayor familiaridad de los profesionales de los SEO con las hojas de cálculo respecto a la que tienen con las bases de datos se suma que el servicio (Excel) forma parte del paquete ofimático que provee la Administración, con lo que no tiene coste real para el SEO y además tienen una serie de ventajas reseñables:
  • Presentan las capacidades básicas de una base de datos sencilla en lo relativo al almacenamiento de los resultados.
  • Permiten crear interfaces sencillas sin mucho coste en tiempo de trabajo.
  • E incorporan funciones que cubren en gran parte las necesidades derivadas del análisis de los datos.
Creo que es la suma de todo esto lo que explica el relativamente frecuente empleo del soporte Hoja de cálculo como servicio para crear soportes de evaluación, incluyendo el desarrollo de diferentes versiones del mismo (6). De hecho estos documentos se encuentran con cierta frecuencia en mis "expedientes" y en mi colección de recursos de intervención, pero no observo en ellos constatación de haber sabido dar el paso adelante que implica la creación sistemática de macros y mucho menos de script basados en VBA (7). Aunque algunos ejemplos hay de ello, lo cierto es que mi esfuerzo se centró en el aprovechamiento de las funciones de Excel, alcanzando en algunos soportes un nivel interesante de complejidad, en línea con lo que he presentado en este blog como [modelo básico de docap de evaluación]

Sinceramente creo que en esto mi descubrimiento tardío de LibreOffice tiene gran parte de culpa, pero hay otra realidad no menos evidente: trabajar con un lenguaje de macros no deja de ser trabajar con un lenguaje de programación, lo que requiere un esfuerzo por aprender a programar. Los imperativos del trabajo diario no dejan demasiado tiempo para estas excursiones.

La suite LibreOffice (8) enfoca el tema de las macros de una forma mucho más accesible que MSO y al ser un recurso de código abierto, accesible y gratuito, cuenta con un importante colectivo de colaboradores que ofrecen recursos de formación en español y mucho más accesibles que la documentación técnica, resultando así verdaderos puentes de accesibilidad hacia funcionalidades que difícilmente se pueden "descubrir" por el mero "sumergirse" en la herramienta.

En gran parte, este blog es un resultado práctico de lo que acabo de decir. Y su publicación un intento de colaborar con la ampliación de este empeño, cercano eso sí a las necesidades de un colectivo profesional específico: el de los SEO.

NOTAS

(1) Esto es, la documentación recopilada o, si se prefiere, el contenido de lo que podríamos llamar de forma un tanto altisonante "expedientes SEO".
(2) Que son, además, de uso obligado en función de las recomendaciones y provisiones de materiales de las editoriales que comercializan las pruebas. Lógicamente, al ser estos materiales documentos analógicos (papel) no quedan recogidos en "expedientes" digitales y a nivel práctico no resulta necesario escanearlos. Por motivos obvios no dispongo de los "expedientes físicos" y aunque su análisis resultaría de gran interés para los objetivos de este análisis, esas fuentes documentales no está actualmente a mi alcance.
(3) Las pruebas de Canals o el test de Weepman entrarían dentro del primer grupo; las pruebas de protocolos de evaluación como el de Canarias o el de la Junta de Andalucía pueden considerarse dentro del segundo. Hablaremos de ellas en otras entradas de este blog.
(4) Las basadas en base de datos lo son en formato FileMaker y las basadas en hojas de cálculo lo son en formato Excel. Muchos de estos soportes son en realidad versiones diferentes del mismo proyecto o proyectos diferentes sobre el mismo recurso de evaluación. Comparten todas ellas ser complementarias de los procedimientos estandarizados de evaluación establecidos en los materiales originales de dichas pruebas.
(5) Precio, complejidad de la creación de soportes y limitaciones del lenguaje de macros.
(6) Lo que evidencia interés por mejorar el recurso, un proyecto que se mantiene en el tiempo, aunque con frecuencia no lo suficiente.
(7) Visual Basic for Aplications (VBA) es el lenguaje de macros de MSO. A las dificultades que conlleva dar este paso añade MSO no pocas reticencias y limitaciones, lo que dificulta seriamente al usuario medio acercarse a este nivel de competencia ofimática.
(8) Heredera también en esto de OpenOffice.