Usos. Documentos prescriptivos

Campos de selección

Último campo que vamos a tratar en esta serie de entradas. Es un tipo de campo que normalmente se resuelve como campo simple, solicitando la entrada de datos al usuario, pero que presenta como peculiaridad que en ciertas circunstancias disponemos de información previa que podemos tener recogida como listado o base de datos. Es el caso de los listados de alumnos con sus datos básicos, por ejemplo: NIE, nombre, apellidos y fecha de nacimiento (1).

Tanto en el informe como en el dictamen nos encontramos con campos aparentemente sencillos e inevitablemente considerados de entrada directa y simple de datos. Un ejemplo (aunque no el único) es el que representa esta imagen: Dictamen de escolarización, datos personales del alumno (2)

En este caso, y a modo de ejemplo, me limitaré a los campos de esta tabla del dictamen de la que he eliminado el campo Edad ya tratado en la [entrada anterior]. Se trata de los campos NIE, Nombre y apellidos del alumno y Fecha de nacimiento y voy a presuponer que ya disponemos de información sobre esos datos puesto que contamos con una sencilla base de datos creada en Calc (3).

Como en el resto de los campos, al tratarse de un documento prescriptivo (dictamen) crearemos previamente los marcadores necesarios (3 marcadores) que usaremos en el procedimiento de escritura del documento que, en esta ocasión, resolveremos mediante bucle que llama a una función específica de posicionamiento (o escritura)

For i = 0 To 2:

sVar = mDatos(i)

Posicionamiento(sVar,"mcd",i)

Next

... habiendo asociado los contenidos (los datos a incluir en los campos del documento) a una matriz de datos (mDatos()) (4) la cual cumplimentaremos mediante la asociación de sus componentes a funciones...

mDatos(0) = NIE(CodAl)

... aunque por seguridad demos opción a modificar o corregir los datos que esa función devuelve en función del dato que le pasamos como parámetro (NIE(CodAl))

mDatos(0) = InputBox("NIE:","ALUMNADO", mDatos(0))

En este planteamiento, en el script principal es fundamental el papel que juega el procedimiento de obtención de la variable parámetro que se incluye en la llamada a las funciones (que veremos después). En esta ocasión he utilizado un método simple basado en InputBox():

CodAl = InputBox("Introduce el código de identificación del alumno: " & Chr(13) &_

"1. Roberto Marcial Pérez" & Chr(13) &_

"2. María Martínez Sanz" & Chr(13) &_

"3. Adela Decastro Morán" & Chr(13) &_

"4. Antonio Heernández Jiménez" & Chr(13) &_

"5. Matias Luján López" & Chr(13) &_

"6. Amalia Desantos Melquiades" & Chr(13), "ALUMNADO","1-2-3-4-5-6")

Este código nos permite asignar a la variable-parámetro CodAl el valor de posición que ocupan los datos de cada alumno en cada una de las matrices que se explicitan en las funciones de las cuales CodAl es parámetro, previa corrección de su valor (CodAl = CodAl-1) para asegurar la coincidencia (5).

Queda ahora analizar el funcionamiento de las funciones que devuelven esos datos (6) y como todas ellas (NIE(), Nombres(), Apellidos() y FechaNacimiento()) son iguales en su funcionamiento, me limitaré a explicar una de ellas como ejemplo.

La función NIE() se define con un parámetro (ID As Integer) y de tipo String (esto es: devuelve un dato texto) (7).

Dentro de la función se declara una matriz (Dim mNIE(5) As String), una variable (Dim AlNIE As String) y una variable contador (Dim i As Integer). A la primera se le asignan los datos de los NIE conocidos (v.g. mNIE(0) = "123456") y la variable nos sirve para hacer más claro el procedimiento de selección y la devolución de valor pertinente asignándola el valor correspondiente de la matriz anterior (AlNIE = mNIE(i)) y, posteriormente, asignando su contenido a la función (NIE = AlNIE).

Resulta clave comprender el procedimiento que permite ejecutar la búsqueda e identificación del valor de interés que se resuelve mediante este código. Muestro y explico:

For i = LBound(mNIE()) To UBound(mNIE()):

mNIE(i)

If i = Id Then

AlNIE = mNIE(i)

End If

Next

• Un bucle For recorre la matriz de datos NIE asociando su índice con el valor de la variable contador i.
• Se condiciona (If) la asociación del contenido del NIE que se desea localizar al cumplimiento de la condición  i = Id, siendo id (como sabemos) el parámetro que traslada a la función el valor seleccionado por el usuario en el script principal.
• En el momento en que la condición i = Id -> True, entonces se realiza la asociación del valor de la matriz a la variable (AlNIE) que devuelve el resultado de la función.

Finalizo esta entrada [aportando un documento] que contiene el código explicado en ella (8) con el mismo objetivo de otras veces: facilitar su comprensión y las propuestas de mejora que se quieran aportar. Me planteo, no obstante, retomar este procedimiento ya que es mejorable desde dos punto de vista: el uso de las matrices y el acceso a la base de datos que contiene la información que aquí manejo mediante las funciones y las matrices que contienen.

NOTAS

(1) Podemos ampliar este listado de campos mucho más, incluyendo datos familiares y escolares. Sería de desear que se trabajar más con bases de datos (con independencia del soporte), tanto para registro como para consulta, pero no suele ser lo habitual en el ámbito de los SEO. Por desgracia y sin una razón clara, a parte del poco conocimiento de estas herramientas, es una práctica poco frecuente.

(2) Del mismo tipo son los datos familiares del dictamen y del informe. Tanto unos (los personales del alumno) como otros (los familiares) pueden ser conocidos a priori, como resultado del análisis del expediente del alumno o de la información aportada por otros servicios (en caso de nuevas escolarizaciones). Sería deseable que así fuera, como también que el SEO tuviera actualizadas sus bases de datos sobre esta información y sobre otras, pero...

(3) De no contar con estos datos ya elaborados, deberíamos aplicar a estos campos el procedimiento básico de solicitud de información al usuario del docap mediante InputBox(). Incluso en caso de nuevas escolarizaciones (EI 3 años) es posible contar con esta información en formato tabla Excel. De ella podemos partir para construir la base de datos que necesitamos. Existen, como sabemos, diferentes modo de acceder y utilizar estos datos. En esta entrada trataremos la forma más simple que se puede concretar en forma similar a como propusimos en [esta entrada]. Este será nuestro punto de partida.

(4) En el caso de nombre y apellidos he optado por emplear, como paso previo, dos variables (AlNombre y AlApellidos) para mejor manejo de los datos al estar estos diferenciados en la base de datos de origen, posteriormente se asignan mediante concatenación al elemento de la matriz (mDatos(1) = AlNombre & " " & AlApellidos)

(5) Recuerda que las matrices se inician con el elemento 0, no con el elemento 1. 

(6) Además contamos con una subrutina (Posicionamiento()) cuyo cometido es facilitar la escritura de los datos en la posición de los marcadores. No la explico ya que el funcionamiento de este código ha sido explicado en entradas anteriores, aunque integrado dentro del script principal. debido a ello, la única novedad es que aquí se emplea como subrutina y que cuenta con tres parámetros: dos para identificar el marcador y uno para recibir el dato o contenido a escribir (Posicionamiento (sDatos As String,MrN As String, i As Integer))  

(7) Dado que el NIE es en realidad un código de identificación, no es necesario considerarlo un valor numérico.

(8) Si en todos los casos este paso es conveniente, en este lo es especialmente. Aunque el documento cuenta con un comando que facilita el uso del script, el mero uso de código no es el objetivo, por lo que insisto en la necesidad de acceder al IDE y conocer el código de primera mano.

Documentos. Documentos prescriptivos.

Evaluación psicopedagógica. Docap múltiple.

Voy a explicar en esta entrada el funcionamiento del docap múltiple que combina varios servicios y permite la elaboración conjunta del dictamen, el informe y la acreditación.

Realmente es algo muy simple, por lo que no espero que puedas tener mayor dificultad, de todas formas me ha parecido necesario por seguir el modelo de trabajo aplicado con anterioridad y facilitar la compresión del paso de un docap complejo a uno complejo y múltiple. 

Este recurso permiten además una ganancia en tiempos de trabajo según explico [en esta entrada]. Espero que esto te anime a utilizar estas herramientas ya que las ventajas son evidentes.

Documentos:

• Fuente de datos
• Gestor
• Documentos-modelo: Informe, Dictamen, Acreditación.

Recuerda que tienes que descargar todos estos documentos y que tienes que reproducir la estructura de la unidad D (sin olvidar las carpetas) para que todo funcione correctamente.

Documentos. Informe.

Informe 2023 - 2. Docap.

La segunda fase de este proyecto contiene el docap InfoNE y la actualización de la fuente de datos. 

Este docap es la versión Informe de lo que anteriormente fue Acreditación, aunque con dos limitaciones: 

• Únicamente la parte que denomino "carátula", esto es, las tablas con las que se inicia el modelo de informe.
• Y sólo las que son relevantes en un informe de nuevas escolarizaciones. El resto serán desarrolladas como docap en otro momento, pero no son necesarias ahora y, por lo tanto, siguiendo el principio de actuación expresado al inicio de este proyecto, lo que se puede resolver de forma sencilla no tiene por qué ser complicado innecesariamente.

Aplicando este principio de simplicidad, existe sobrados motivos para que el Informe de nuevas escolarizaciones sea un documento específico, eliminando elementos no son pertinentes, que pueden dar lugar a confusión y que complican el trabajo con el documento.

En los enlaces que siguen dejo acceso al conjunto de documentos que conforman este docap. También a mi propuesta de Informe específico para Nuevas Escolarizaciones.

Documentos

• Fuente de datos actualizada (Base). Funciona conjuntamente con el Gestor
• Gestor del Docap Informe (Calc). Funciona con fuente de datos y con InfoNE
• Documento InfoNE (versión general) (Writer). Funciona con el Gestor.

Documentos. Informe.

Informe 2023 - 1. Carátula.

Como primer paso de este proyecto, desarrollaré un docap para cumplimentar el documento Informe Psicopedagógico (2023), específicamente de la carátula.

Soy consciente que este docap deja sin resolver lo fundamental de la elaboración del informe psicopedagógico, pero mi objetivo actual es aplicar la estrategia de automatización de la cumplimentación de los datos presentados en formato tabla, así que la limitación del objetivo está justificada. En documentos tan complejos como es el informe psicopedagógico es necesario ir por partes.

También está justificado no abordar ahora las implicaciones del análisis iniciado en la [entrada anterior], siendo, eso sí, necesario analizar las implicaciones que conlleva plantear este nuevo docap teniendo en cuenta las diferencias entre el documento Acreditación y el documento Informe, por un lado, y la delimitación del informe como Informe de nueva escolarización por otro.

De  momento, por eso de que también en esto hay que ir por partes, en esta entrada me limito a desarrollar y aportar el documento-base del informe, adaptado al proceso de nuevas escolarizaciones. Lo puedes descargar desde el enlace que sigue.

Documento-base [Informe psicopedagógico Nueva escolarización] (Contiene marcadores)

Documentos. Acreditación.

Acreditación -8. Docap complejo (d2)

En esta entrada explico la segunda fase de la creación del documento Acreditación. Es en ella en la que, precisamente, se genera dicho documento.

No parecen necesarias más explicaciones que dadas en el entrada anterior, ya que ésta viene condicionada por razones de duración de la exposición. 

Sí quisiera insistir en que trabajar con  marcadores nos permite prescindir del control de la ubicación inicial del cursor y de sus desplazamientos a lo largo del script, algo que era crítico en el modelo macro basado en el posicionamiento mediante tablas y celdas.

Otra cuestión de interés es mantener dos objetos abiertos (Hoja del cálculo y Documento de texto), trabajando desde una (la que contiene el script) en la otra (la que recibe el resultado de la acción del script).

Una vez finalizada esta primera fase del proyecto, interesa plantear cuáles podrían ser los desarrollo subsiguientes, cuestiones éstas que podrían necesitar más tiempo del que parece conveniente dedicar en estos momento.

Documentos:

• Fuente de datos (Base)
• Gestor (calc)
• Documento (Writer)

Documentos. Acreditación

Acreditación -7. Docap complejo (d1)

Iniciando con lo prometido nos adentraremos ahora en el análisis del conjunto de script  que conforman esta docap.

Podemos ver en la imagen que sigue los tres módulos que componen la biblioteca Standard y los script individuales que contienen. 

• Tenemos, en primer lugar, un módulo con script auxiliares cuyas funciones indican sus propios nombres. Dado que no se trata de script centrales del docap actual, no nos detendremos a explicar su funcionamiento.
• El módulo CapturaDatos reúne los script cuyo cometido es recopilar la información que aporta el usuario o usuaria (fase input)
• Y el módulo CreaDocum contiene el script que se ocupa de trasladar los datos anteriores al documento Writer que nos sirve de base para crear la acreditación.  
  
  

Además del módulo auxiliar, esta estructura revela la existencia de un proceso dividido en dos partes: el acceso a los datos y su ubicación controlada en celdas del soporte Calc y la captura del contenido de las celdas y su traslado al documento Writer.

En esta entrada nos centraremos en los script que forman parte del módulo CapturaDatos: DadosDocum y DatosAlumn; esto es, en la captura de datos del usuario 

Documentos:

• Fuente de datos (Base)
• Gestor (calc)
• Documento (Writer)

Documentos. Acreditación.

Acreditación -6. Docap complejo (c)

Como paso previo para explicar el código del docap que constituye mi tercera propuesta de automatización del documento Acreditación, voy a dedicar esta entrada a explicar la estructura de elementos que componen la hoja de cálculo.

Calc es el servicio principal en este conjunto interrelacionado de servicios, y lo es por ser quien lleva la carga de gestionar el conjunto de los procesos que se desarrollan en este docap. La posición central que ocupa en la imagen siguiente reflejar esa centralidad funcional, del mismo modo que las flechas representan los flujos de interacciones que tienen lugar en el docap: Calc mantiene con Base (BD) una relación bidireccional tal y como expliqué en la [entrada anterior], y unidireccional con Writer.

Documentos:

• Fuente de datos (Base)
• Gestor (calc)
• Documento (Writer)

Documentos. Acreditación.

Acreditación -5. Docap complejo (b)

Respecto a esta tercera opción, ya conocemos por la [entrada anterior] su forma básica de funcionamiento y cómo está diseñado el documento Acreditación. Ahora analizaremos el papel de la fuente de datos (BD) y cómo se relaciona con el archivo Calc.

Nuestra base de datos (AlumnNE) es la misma que utilizamos en la segunda opción (basada en Combinar correspondencia) y tiene exactamente las mismas características y la misma estructura y contiene los mismos datos; pero ahora es posible lo que en aquella ocasión no llegaba a ser recomendable: mantener una relación bidireccional con el elemento con el que está relacionada (ahora la hoja de cálculo).

Dedicaremos esta entrada a explicar esta relación que, como podrás comprobar, es de carácter bidireccional, mientras que la que se establece entre el hoja Calc y el documento Writer es unidireccional. Esa bidireccionalidad es consecuencia de que la relación se establece mediante formulario vinculado a la BD y no mediante Combinar correspondencia, que era como se establecía en el modelo B. 

Ahora, al utilizar una hoja de cálculo como servicio que intermedia entre la fuente de datos y destinatario final (el documento Writer), podemos aprovechar plenamente lo que implica esa bidireccionalidad sin comprometer las funcionalidades básicas del documento Acreditación.

Aun no hemos abordado el análisis de la hoja de cálculo, que estamos usando como sistema de gestión del docap, por lo que en el vídeo anterior no hemos atendido a nada que no sea la vinculación del formulario (de uno de los formularios) de nuestra hoja de cálculo con la BD. 

Al análisis al que me refiero el párrafo anterior dedicaré la próxima entrada.

Documentos. Acreditación.

Acreditación -4. Docap complejo (a)

No se puede decir que lo que presento como tercer procedimiento de automatización de Acreditación suponga un cambio radical respecto a los dos anteriores, no al menos en la lógica de programación subyacente, pero es cierto que transformar la idea en una realidad funcional sí que ha supuesto introducir cambios significativos respecto al diseño de las dos propuestas anteriores.

Para empezar la única novedad en términos de lógica de programación respecto a la segunda de las dos propuestas anteriores es introducir una hoja de cálculo entre la fuente de datos (BD) y el documento final (Acreditación). 

Partiendo de la facilidad con la que podemos conectar un formulario (y sus campos) con una fuente de datos, la idea de introducir una hoja de cálculo como elemento intermedio de conexión (entre la fuente de datos y el documento) es aprovechar la versatilidad de Calc para trabajar con formularios, facilitando la conexión entre los controles de formulario y las celdas, así como la relativa sencillez con la que admite la creación de script de acceso a las celdas.

No obstante, este planteamiento conlleva alguna que otra "complicación" respecto a los modelos precedentes: necesitamos desarrollar mucho más código sobre la hoja de cálculo y sobre el documento Acreditación. Pero también aparecen posibilidades que hasta ahora se han mantenido ocultas: usar referencias y accesos a los marcadores de texto como modo de facilitar la ubicación de los datos en el documento nos evita trabajar con tablas así como las complicaciones de los desplazamientos por las mismas.

Y no es ésta la única ventaja, aunque sí la única de la que me aprovecho en este momento. Para desarrollos posteriores queda el trabajo unificado sobre los otros dos documentos (DE e Informe) y lo que esto supone en el desarrollo de un procedimiento de trabajo que integre los tres en un único proceso de automatización, con el ahorro de tiempo que esto puede suponer...

Aunque suponga empezar la casa por el tejado me centraré en esta entrada en el cambio que para la formulación de Acreditación supone el uso de los marcadores de texto, como trabajar con ellos y cómo acceder a sus posiciones desde OOo Basic.

En el vídeo que sigue voy a explicar cómo afecta el uso de marcadores al diseño del documento Acreditación, que hace innecesarias muchas de las precauciones que debíamos adoptar en las dos propuestas anteriores: una tabla única, por ejemplo. No obstante, también  tiene sus limitaciones y bueno es conocerlas.

Documentos. Acreditación.

Acreditación. Modelo B. Combinar correspondencia.

Disponemos de otras opciones, además de Crear macros para automatizar la el documento Acreditación, por ejemplo establecer una vinculación a fuentes de datos y, a partir de ella, utilizar la función Combinar correspondencia.

En esta ocasión vamos a desarrollar dos formulaciones del mismo principio (vinculación a fuente de datos), partiendo de una tabla de una base de datos (en anteriores ocasiones hemos trabajado con hojas de cálculo como fuentes de datos) que combinaremos con un documento Writer, el que contiene el documento Acreditación. 

Ahora las entradas de Acreditación son tratadas como campos que se vinculan directamente o por medio de un formulario, con los campos de la fuente de datos (BD). 

Para ello necesitamos crear una base de datos y utilizar al menos dos de sus componentes: una tabla y un formulario. También necesitamos registrarla para que quede disponible como fuente de datos. Para todo ello es necesario contar con una serie de conocimientos previos que no son objeto de esta entrada, pero que sí parece conveniente que estén accesibles, por lo que te dejo los enlaces que siguen.

• Libre Office - Data. Manual básico.
• Libre Office - Data. Manual avanzado.
• Libre Office - Data. Vincular bases de datos.
• Combinar correspondencia con Libre Office

La primera opción se basa en Combinar correspondencia, funcionalidad ya utilizada en este blog, aunque con otros fines. Aunque podríamos haber utilizado este mismo procedimiento, en realidad sólo encaja con los contenidos de la tabla 1 (Datos personales...), la cual ha servido de base para crear la tabla Alumnado de la BD. El resto del documento queda para ser cumplimentado mediante el procesador de textos, aunque caben otras opciones.

La segunda forma se basa en la vinculación entre la base de datos (y su tabla Alumnado) y los controles de un formulario que utilizamos también para cumplimentar la tabla 1 de Acreditación. La diferencia es que también empleamos controles de formulario para facilitar la entrada de datos de otros "campos", aunque no vinculados a la tabla Alumnado. Aunque esta fórmula parece un avance sobre Combinar correspondencia, presenta algunas limitaciones que no la hacen especialmente recomendable.

Para finalizar, y a modo de síntesis he desarrollado una tercera opción que se basa en las dos anteriores: mantengo Combinar correspondencia para cubrir la tabla 1, pero también uso controles de formulario para cumplimentar otros campos (no vinculados a la BD), e incluso propongo el uso directo del procesador de textos como herramienta para cubrir determinados campos. El resultado es una solución satisfactoriamente funcional, conseguida sin hacer uso de OOo Basic o de Grabar macro, lo que puede ser un aliciente para quienes no estén interesado en adentrarse en el mundo de la programación.

Documentos:

• Base de datos
• Modelo A (Combinar correspondencia)
• Modelo B (Formulario vinculado a BD)
• Modelo C (Combinar correspondencia + Controles de formulario)

NOTA Una mala noticia: no está garantizado el correcto funcionamiento de los vínculos de la BD a los campos utilizados en A ni a los controles de B, dado que la BD no forma parte de las bases de datos vinculadas en tu sistema. Deberás vincular esta base de datos y restablecer las conexiones en los documentos modelos.

 

Documentos. Acreditación.

Acreditación - 2. Docap basado en macros (b)

Una que hemos [creado la macro] necesitamos adaptarla para que nos permita introducir los datos necesarios, dotando al docap de capacidad interactiva. Para ello deberemos modificar el código generado desde Grabar macro.

El trabajo que toca ahora tiene tres objetivos:

• Eliminar el código "basura" para mejorar el rendimiento de la macro.
• Estructurar el contenido de la macro para facilitar su comprensión.
• Generar procedimientos específicos de entrada de datos para dotarle de interactividad.
• 
  
  

Las dos primeras partes, aunque necesarias, carecen de interés para lo que ahora nos importa, por lo que las trataré someramente en el vídeo que acompaña a esta entrada, pero la tercera hace necesario que nos detengamos en ella, por lo que bien se merece una explicación que puedes ver en [el vídeo que acompaña esta entrada]

Documentos. Acreditación.

Acreditación -1. Docap basado en macro (a)

No puedo asegurar que esta sea la primera alternativa disponible, pero grabar una macro está dentro de las opciones que ya hemos trabajado en este blog como posible forma de automatizar procesos y constituye una evolución lógica de la propuesta de crear un documento-modelo personalizado, puesto que se basa en el mismo principio y supone aplicar una funcionalidad disponible dentro del servicio Writer.

Bueno, lo anterior no es del todo cierto: hacer una macro con Grabar macro no resuelve el problema, pero sí supone un paso en la buena senda... en una de las posibles sendas...

Además, antes de crear la macro es necesario realizar algunas modificaciones al documento original por eso de lo dicho en el [vídeo que acompaña a la entrada]. Es conveniente que el documento cuente con una única tabla para simplificar los desplazamientos... también eliminar los vestigios del uso manual del mismo.

.

Opinión. Documentos de evaluación.

Documentos para la valuación psicopedagógica - 2.

Tomando como referencia los [tres soportes que he creado] y usándolos  como modo de plantilla, te propongo realizar un sencillo experimento que te resultará fácil reproducir si lo deseas: cumplimentarlos una serie de veces hasta obtener tiempos de ejecución estables. Yo he necesitado cinco repeticiones para Acreditación y Dictamen y dos para el Informe.

Aunque no pretendo que sirvan como padrón, sí utilizo los resultados que he obtenido como referencia para mi argumentación: en condiciones ideales (suponiendo acceso inmediato y completo a los datos) y  utilizando resultados "optimistas", los tiempos aproximados de ejecución para cada documento son los siguientes

• Informe de evaluación (carátula y similares): 3':30"
• Dictamen de escolarización: 5':40"
• Acreditación: 2':15"

Si situamos este proceso en el marco del Programa Nuevas escolarizaciones y suponemos una carga de trabajo de 10 "casos" por OE, el coste de tiempo por profesional será de 1h:54':10" y para el conjunto del SEO (90 "casos" completos) de 17h:7':30". 

Cierto es que ambas referencias sobredimensionan el coste en tiempos, ya que no todos los procesos implican DE, pero permiten apreciar la carga de trabajo que conlleva utilizar los documentos de la Consejería como documentos-modelo. Estos resultados son motivo más que sobrado para que interese analizar posibles modos de reducir el tiempo de trabajo, empezando por la forma en que están construidos los documentos y siguiendo por las posibilidades de implementar alternativas de automatización.

Esto es lo que llevo proponiendo desde este blog y creo haber demostrado, antes y ahora: que ambos enfoques permiten un ahorro significativo de tiempo, ya que he comprobado personalmente que la simple estrategia de crear un modelo personalizado de plantilla del documento Acreditación, consistente en cumplimentar aquellos campos no susceptibles a ser modificados en determinadas condiciones, y utilizado este documento como plantilla en sustitución del documento de la Consejería, permite un ahorro de tiempo por documento ligeramente inferior a un minuto: se pasaría de 2':15" por Acreditación a 1':20". 

Para facilitar una mejor comprensión de lo que planteo, en el vídeo que sigue analizo el documento Acreditación, identificando los factores que influyen en el tiempo necesario para cumplimentarlo.

Respecto a las propuestas de automatización, me propongo aplicarlas inicialmente también sobre el documento Acreditación, basándolas en la suite Libre Office, servicio Writer. 

Realizaré un recorrido por las distintas opciones disponibles, lo que conllevará la publicación de sucesivas entradas, concluyendo el proceso con el abordaje conjunto de los tres documentos (Informe, DE y Acreditación) como estrategia para maximizar la reducción de costes de ejecución.

Cada alternativa presenta ventajas, pero también limitaciones e inconveniente, por lo que es decisión de cada cual elegir el modo de trabajo que mejor se ajuste a sus conocimientos, intereses y/o preferencias.

Opinión. Documentos de evaluación.

Documentos para la evaluación psicopedagógica -1.

La evaluación psicopedagógica es una de las tarea más complejas que debe realizar un SEO y para los EOE es la que mayor carga de trabajo conlleva. A ello contribuye en gran medida el Programa de Nuevas Escolarizaciones. Por diferentes motivos, la Administración educativa provee de documentos para el desarrollo del proceso.

Esta práctica cubre un triple objetivo:

• Garantizar que el proceso se desarrolla formalmente conforme a norma.
• Dar uniformidad procedimental al proceso
• Y facilitar modelos de referencia a los SEO.

También se pueden identificar aspectos negativos:

• Representan una interpretación concreta de la norma; en la práctica la se identifica como "correcta".
• Convierte al/ a la OE en técnico, limitando su autonomía profesional.
• Los documentos generan una carga de trabajo burocrático no  siempre optimizado.

En estas entradas me voy a detener en lo que implican los puntos terceros de ambas listas, en coherencia con el objetivo de este blog. Su abordaje está sobradamente justificado  en función de la optimización del trabajo de los SEO, algo que entiendo no genera mayor controversia.

La Consejería de Educación del Principado de Asturias proporciona tres modelos documentales: Informe psicopedagógico, Dictamen de escolarización y Acreditación, los cuales están disponibles desde la Intranet de la Consejería. Paso a presentarlos brevemente.

En entradas posteriores me detendré, en primer lugar en el documento Acreditación. En la que sigue a la actual explico los motivos de esta elección.

Documentos. Planificación.

Programa de trabajo y memoria - 3

Una vez atendida la cuestión del seguimiento de las intervenciones del EOE en el centro, otro recurso que puede ayudar en la intervención del SEO (en este caso identificado como UO) es el registro sistemático de sus reuniones de coordinación (R.UO) mediante el seguimiento y análisis de sus actas.

Frecuencia y calendario

Hablar de la organización de la UO es hablar de sus reuniones y del contenido de las mismas, su planificación en el tiempo (calendario), que está determinada por la frecuencia con que nos planteemos celebrar dichas R.UO.

La normativa impone un mínimo de una reunión mensual, pero se puede optar por mantener reuniones quincenal o semanalmente. En mi opinión, esta cuestión (la de la frecuencia) debe afrontarse desde la perspectiva de los objetivos que se plantee la UO para el curso y de sus necesidades de funcionamiento.

Y esta sería la cuestión a plantear, tanto en el propio programa de trabajo (el de la UO, no el del EOE) y analizar en la Memoria (en la de la UO, no necesariamente en el del EOE). Esta distinción entre UO y EOE es importante, ya que no es lo mismo el plan de trabajo del EOE en el centro (y su memoria) que el plan de trabajo de la UO (y la suya). 

Considero conveniente para el EOE plantearse las implicaciones de esta diferenciación.

Plan de trabajo y Memoria de la UO

Volviendo a la UO y a la temporalización de las R.UO, en mi opinión, también aquí menos es más si es suficiente. Dicho de otro modo: la frecuencia de las reuniones debería ajustarse a las necesidades y éstas no son las mismas a lo largo del curso, por lo que tampoco se puede establecer una calendario uniforme, aunque sí una previsión que se ajuste a esa variabilidad y a la carga de trabajo que se prevé en los diferentes periodos del curso.

Por eso lo que propongo como herramienta es un recurso que, partiendo de un modelo-base de curso en cuanto a día de la semana, se ajuste en un segundo momento a las circunstancias de los diferentes periodos y a la elección de temporalización.

Tanto el seguimiento como el análisis final (para la Memoria de la UO), podría basarse en criterios como los siguientes:

• Ajuste entre planificación y ejecución.
• Ajuste entre la previsión de orden del día y tratamiento de los temas.
• Grado de cumplimiento de las funciones de la UO
• Atención efectiva a las prioridades establecidas en la planificación
• Grado de consecución de los objetivos planteados en esa priorización.

Esto conlleva (y obliga a) plantear un orden del día basado en criterios de relevancia y ajuste a la planificación inicial, lo que no impide atender lo urgente e inmediato, a la vez que evita que lo urgente relegue a lo importante.

Para ello me parece conveniente disponer de un recurso de planificación y seguimiento de las R.UO. El que propongo está elaborado sobre un libro LO-Calc y combina en su funcionamiento script OOo Basic, funciones propias de Calc y trabajo manual que se espera realice el usuario o usuaria, preferentemente el coordinador o la coordinadora dela UO.

En cuanto al código OOo Basic, supone una mejora respecto al calendario de planificación de asistencia que desarrollé en la entrada anterior. Si alguien se anima a modificar aquel implementando el código del actual (con los cambios que requiere este proceso), me encantaría conocer el resultado de este trabajo que, además, se podría compartir desde este blog.

Este soporte debe ser mejorado, pero como punto de partida puede ser suficiente. La mejora queda pendiente a tus peticiones y sugerencias.

Acta R.UO

En lo que al acta se refiere, me limitaré a desarrollar un documento-modelo de acta que resulte sencillo de cumplimentar, a sabiendas que lo verdaderamente importante, desde la perspectiva planteada en el apartado anterior, no es tanto este soporte como la planificación que conlleva en función de la organización de las R.UO y de su planificación de objetivos.

Ahora bien, esa es una responsabilidad que compete al coordinador o coordinadora; la mía (la que yo asumo) es facilitar su trabajo en la medida en que esto es posible.

Y ahora toca facilitar la elaboración de las actas de la R.UO, tarea ésta que si bien no es especialmente compleja, sí supone una carga de trabajo añadida que se puede aligerar, en cierta medida, claro.

En este caso elijo como soporte un documento LO-Writer que se cumplimenta en parte de modo interactivo, dejando para la escritura manual lo fundamental: el desarrollo de la sesión y los acuerdos alcanzados, ya que en ambos no parece conveniente automatizar el proceso.

Lo primero es seleccionar un modelo sencillo y el que propongo me parece que lo es.

Este modelo es similar al que yo utilicé en su momento, aunque éste me parece más ajustado que el mío a las formas de trabajo de las UO.

Le faltan algunos datos que considero de interés recoger para facilitar el posterior análisis de resultados. También le falta la sección de firmas, pero eso es debido a que se trata de una captura parcial de pantalla.

Sobre esta base voy a construir un docap basado en InputBox() y MsgBox como recursos de interface, introduciendo en el código directamente unos supuestos datos de identificación y los que considero necesarios para la elaboración del orden del día.

Este docap tiene dos botones para activar los dos script principales, pero estos botones no se imprimen ni aparecen en el documento .pdf que puedes crear a partir de él.

Lo que sí necesitarás es modificar los datos que le dan contenido, pero el nivel de conocimiento que en estos momentos se le supone a quien sigue este blog, permiten hacerlo sin grandes dificultades.

Además, en las páginas (que no en las entradas) que sirven de índice a este blog y más específicamente la página Código, puedes encontrar información de ayuda. En breve iré introduciendo en ella información necesaria para facilitar la comprensión de este docap.

Aún así es necesario acceder al código del documento desde el IDE para realizar las modificaciones necesarias. Te dejo el código de los dos script fundamentales en un documento .txt para que te resulte más sencillo echarles un vistazo. En él podrás localizar los elementos que resulta necesario modificar.

Si estás interesado en hacer estas modificaciones y necesita una ayudita, no tiene más que pedirlo.

Documentos

• Calendario R.UO.
• Modelo de Acta de la R.UO. Código OOo Basic.