Dictamen 2024. Una propuesta de automatización.
Comenté en [esta entrada] el documento-modelo de informe de la Consejería de Educación asturiana de 2024 y [en esta otra] hice algunas propuestas (1) para su adaptación y uso por parte de los SEO. Además en [Usos] he estado desarrollando la explicación de diferentes estrategias para complementar los datos solicitados en las tablas tanto del informe como del dictamen (2), pero aun no he expuesto una propuesta de docap para automatizar la cumplimentación del modelo de dictamen, así que ahora toca.
Creo haber comentado ya algunas de las novedades del presente documento, que son menos que las que presenta el modelo de informe, aunque algunas hay y no necesariamente favorables para los SEO, pero en general se trata de un documento conservador, que se mantiene en la misma línea que los que le han precedido y que, al igual que aquellos, carece de herramientas para facilitar el trabajo de los SEO.
Mi idea es presentar aquí un docap que facilite el trabajo con el documento, empleando diferentes procedimientos de automatización de su cumplimentación. El resultado queda disponible como enlace al final de esta entrada.
El dictamen de escolarización es, en lo formal, es un formulario basado en tablas, claramente diseñado para ser cumplimentado desde el procesador de texto. dado que es un documento de uso obligado, no da lugar a propuestas de mejora, así que poco hay que decir al respecto, salvo constatar las múltiples posibilidades que presenta en lo que a mejoras se refiere. Y estoy pensando únicamente en las de carácter formal y de uso del documento. Del resto (el contenido y la carga conceptual que conlleva) mejor me mantengo en silencio, por lo que me centraré en explicar el funcionamiento del docap.
El enfoque que desarrollo en este docap es diferente a propuestas anteriores sobre otros modelos documentales similares (ver [aquí] una propuesta anterior), y puede que incluso menos ambiciosa, ya que aquella era una propuesta que implicaba el uso de un docap complejo, que involucraba y relacionaba varios documentos, y esta se limita a un docap simple, basado en un único documento (Writer). No obstante lo que aquí presento supone una mejora significativa en lo que al desarrollo del código se refiere, por lo que no creo que se trate de una simplificación de procedimientos que redunde negativamente en la funcionalidad de uso, más bien al contrario.
Este modelo de docap no permite unificar el proceso de creación de los diferentes documento prescriptivos (como sí sucede en el docap que se cita antes), pero gana en simplicidad de uso y supone una mejora importante del código.
Empezando por la forma de uso, es suficiente con hacer clic en el botón de comando (Crear DE) para que automáticamente se desarrolle la secuencia de pasos que se definen en el código, obteniéndose al final y como resultado, el documento cumplimentado y listo para ser archivado para su posterior manejo según las prescripciones de la Consejería, incluyendo su conversión el formato pdf (proceso que hay que realizar "manualmente" usando las funcionalidades de Writer). Lo que toca hacer al OE responsable de su elaboración es ir introduciendo los datos que se le solicitan mediante funciones InputBox() y MsgBox() (3)
No se contempla cumplimentar el anexo 1 ya que que su elaboración compete al ER (4) y no al EOE del sector, por lo que, en la práctica, dicho anexo es tratado como un documento independiente del dictamen, aunque se incluya en él.
Se centra en el proceso de Nuevas Escolarizaciones (5), por lo que determinados campos son obviados, ya que no corresponden precisamente por su especificidad o cuyo contenido está ya predefinido por este mismo proceso. La consecuencia es que el contenido de determinados campos se asigna directamente en el script o no se tiene en cuenta.
Como cabe esperar, por motivos de confidencialidad, cuando en el código se incluyen datos personales (alumnado, familias, OE), éstos son inventados.
Comento a continuación la estructura de script del docap y su funcionamiento básico.
Consta de 15 script que se distribuyen en 3 módulos:
- Principal, que contiene el script principal (Carátula)
- Auxiliares, que contiene las subrutinas y funciones que permiten el desarrollo de los procedimientos requeridos por el script principal
- Matrices, que contiene las funciones que permiten la elección de los contenidos de los campos de selección (6)
El funcionamiento interno del algoritmo se basa en la llamada a las subrutinas y funciones desde el script principal, facilitando así el funcionamiento modular del conjunto. En la base de este funcionamiento está el principio de linealidad o sucesión, de modo que el proceso se va desarrollando según el desarrollo del propio documento, tal y como éste se visualiza.
El uso de una matriz general de asignación de contenido (mDatos ()) permite la cumplimentación de los campos mediante un bucle (For) que, a su vez llama a la subrutina de escritura (Posicionamiento). Estos campos se identifican en el documento mediante marcadores, por lo que script y documento quedan relacionados mediante esos marcadores que han sido ubicados en el documento previamente (7)
Posicionamiento(sVar,"d",i)
La correspondencia de los numerales de los marcadores y de la matriz facilitan la correspondencia entre ambos y la variable contador (i), garantizando la correcta ubicación del contenido de la matriz en las posiciones que indican los marcadores.
Mediante [este enlace] puedes acceder al docap. Se debe descargar, guardar donde se desee y abrir con LO-Writer activando macros.
Como es habitual, antes manipular el documento y sus script se recomienda crear una copia del documento que sirva de copia de seguridad. Así se evita que cualquier alteración del original obligue a realizar una nueva descarga. Es preferible que esa copia de seguridad se haga en formato plantilla y que se trabaje abriendo el documento en esta versión.
NOTAS
(1) En realidad se trata de una serie de tres entradas que se complementan. Aquí la [segunda] y la [tercera]. (3) Me he ahorrado conscientemente (también de las consecuencias negativas de esta decisión) el trabajo de implementar recursos de interface más "vistosos", ya que se trata de una propuesta pensada para que sea accesible a un orientador interesado en ajustarla a sus propias necesidades. Carece de ambición comercial y no hace concesiones a este enfoque, así que se sacrifica lo "vistoso" (incluso lo amigable) a lo funcional, también en términos de acceso al código y a su posible modificación por el usuario.
(4) Equipo Regional para la Atención del Alumnado con NEAE. Consejería de Educación del Principado de Asturias.
(5) Proceso cuyo responsable por norma es el equipo de sector y en el que colabora, si así se considera, el ER. El objetivo de este proceso y a la vez programa (para estos SEO) es facilitar la escolarización de los niños y niñas con NEAE (fundamentalmente NEE) en 1º de E. Infantil para el curso siguiente, atendiendo a sus necesidades educativas. La resolución del mismo corresponde a una Comisión de Escolarización.
(6) Puedes encontrar la explicación de su estructura y funcionamiento en esta entrada ([campos de selección]) (7) Previo a la creación del código se estudia el documento y se determinan las posiciones (campos) que es necesario identificar. Sobre esta base se crea una tabla de tres columnas en las que se enumeran y relacionas los marcadores, los elementos de la matriz (mDatos()) y el contenido. Posteriormente se ubican los marcadores en las posiciones correspondientes, los cuales se enumerar de forma sucesiva mediante un código alfanumérico simple (vg. d0,d1,d2...). Esto permite la posterior correspondencia entre marcadores y elementos de la matriz, de modo sea posible realizar la automatización de la escritura mediante un bucle For, tal y como se explica en el texto.
