P11 impartir docencia

Para el proceso 1.1 "Impartir docencia" se propusieron los siguientes subprocesos que pasamos a detallar.

Proceso P111 Programar Sesiones

Nivel L1 descriptivo

En un principio, debemos dar una idea general de qué se pretende con este proceso. Debe tener suficiente detalle, pero ser lo suficientemente simple para el lector no tenga problemas en entenderlo. 

En este proceso definimos los contenidos que queremos desarrollar durante el curso y los acomodamos en cada sesión, de forma que obtenemos un programa o calendario de actividades y recursos. En nuestro caso, una sesión de teoría y otra de prácticas cada semana durante el periodo lectivo del semestre, 15 semanas por lo general.

Nótese que no hemos entrado al detalle de cómo se hace esto, son tareas muy generales con mucho trabajo manual que, finalmente, se traducirán en una introducción de datos en forma de calendario de sesiones, con el formato que sea, tampoco entramos en ello.

Nivel L2 operacional

En este nivel ya necesitamos un conocimiento profundo de BPMN. Las fichas de proceso nos ayudarán en el proceso de modelado, estableciendo claramente desde el principio, sin menoscabo de que puedan ser modificadas posteriormente, los límites y objetivos de cada uno.

En este caso se trata de un proceso sencillo en su secuenciación —que no en sus actividades—. Todas las tareas necesitan intervención humana.

Entiéndase que aún se trata de una descripción poco detallada. Por ejemplo, la tarea "definir contenidos" necesita matizaciones: 

• Los contenidos han de ajustarse a lo establecido en la guía docente de la asignatura.

• El calendario docente marca la cantidad de sesiones disponibles, y pueden ser distintas para teoría y práctica.

• Se puede partir de una definición previa o comenzar una completamente nueva.

• El formato y el tipo de archivo de la lista de contenidos debería establecerse por el tipo de restricciones que pueda generar.

Otro tanto podría decirse de "distribuir contenidos", e incluso de validar distribución en tanto en cuanto que no está claro en qué orden se van a realizar las actividades —excepto "validar distribución", que siempre será el último paso— ni cuántas veces. Es lógico pensar que los contenidos pueden estar predefinidos de otros cursos o que mientras se distribuyen se piense en añadir contenidos nuevos. 

En definitiva, sin diferenciarse mucho de la mostrada en la Figura P11B, una descripción más realista —aunque más difícil de entender por el profano en BPMN— es la siguiente:

Los subprocesos ad-hoc —etiquetados con el símbolo ~ (virgulilla, ALT-126)— permiten representar un conjunto de tareas que no tienen un orden claro y que se pueden ejecutar varias veces. No todos los gestores BPM lo pueden manejar y hay que prever cómo lo harán y si se ajusta a nuestras necesidades.

En definitiva, este proceso solo marca ciertos hitos relevantes, la mayor parte del trabajo se hace fuera de un software BPMS. Pero no pretendemos más en este caso.

Proceso P112 Preparar ejercicios

Este es un proceso relativamente difícil de modelar dado que se basa en valoraciones sobre el conjunto de ejercicios de cada sesión. Cada sesión y cada ejercicio de la sesión deben revisarse, pudiendo llegar a la conclusión de que necesitan modificaciones o incluso ejercicios nuevos. El último estado puede ser dejar la sesión pendiente para una nueva revisión posterior.

Nivel L1 descriptivo

En la figura P112a estamos describiendo de forma somera el proceso de proponer ejercicios para las sesiones. Más o menos, el lector puede intuir el flujo de trabajo general y resulta hasta coherente: revisar los ejercicios de los que se dispone, proponer nuevos y asignarlos al calendario de sesiones. Sin embargo, ¿cómo se hace esto en detalle?

En realidad, tendremos n sesiones, y pasaremos por todas y cada una de forma secuencial revisando ejercicios, proponiendo nuevos si hiciera falta y, finalmente, eligiendo aquellos que se mantienen o no en dicha sesión. Siendo más fieles al modelado que se pretende realizar, la figura P112b es más coherente. No obstante, también puede ser más difícil de entender para un lector no experto. En todo caso, una u otra opción de representación han de valorarse en función de ese potencial lector.

Nivel L2 operacional

En este nivel de descripción añadimos toda la lógica de negocio posible, desde la categorización del tipo de tarea hasta excepciones, subprocesos, etc. En el caso de los subprocesos, los modelamos colapsados para seguir ofreciendo una relativa simplicidad en el diagrama que facilite su comprensión. Aquí hemos hecho una excepción, ya comentada, con el subproceso "verificar ejercicios de la sesión", ya que prácticamente es el único objeto del proceso.

La ficha de los procesos nos sirve como ejercicio de planificación de las tareas a modelar. A la hora de diseña el modelo, y dependiendo del estilo de cada uno, estas fichas son una forma de pensar en qué necesitamos, cuándo y cómo antes de ponernos a "dibujar". Te aconsejamos realizar este ejercicio incluso antes del primer diagrama.

Partimos del supuesto de que las sesiones ya están definidas y, posiblemente, con ejercicios ya confeccionados de cursos anteriores. Se trata de revisar esos ejercicios, modificarlos si hace falta o redactar nuevos ejercicios.

El proceso sigue siendo PREPARAR EJERCICIOS. Lo que hemos hecho es expandir el subproceso "verificar ejercicios de sesión", ofreciendo más información sobre lo que realmente se hace en el proceso. 

En cada ejecución del subproceso VERIFICAR EJERCICIOS DE SESIÓN —en cada instanciación del subproceso— se parte de un identificador de sesión concreto, se va a revisar una sesión en particular. El proceso padre, PREPARAR EJERCICIOS, establece la lista de sesiones a revisar; en realidad, recupera la lista de sesiones desde un almacén de datos por definir y, al llamar al proceso hijo, ya está indicando cuántas veces y con qué sesión se creará una nueva instancia. 

Para cada sesión, se ejecutará el flujo propuesto en la expansión del subproceso. REVISAR EJERCICIOS PROPUESTOS es otro subproceso de instancia múltiple secuencial, pero en este caso para los ejercicios ya incluidos en la sesión. Una vez que se han revisado todos los ejercicios de la sesión, se valora el conjunto completo de ejercicios —se examina en conjunto— y se decide si se necesitan ejercicios nuevos. De ser esta la decisión, se llamará a PROPONER EJERCICIO NUEVO —nuevamente como subproceso colapsado— tantas veces como sea necesario (actividad en bucle). Téngase en cuenta que, de alguna manera, el subproceso debe prever una condición de finalización del bucle, posiblemente un simple botón de "he terminado ya de poner ejercicios". El siguiente paso es REASIGNAR EJERCICIOS, planteado como un marcaje de los ejercicios que serán asignados definitivamente a la sesión, eligiendo unos y descartando otros. Si al reasignar los ejercicios hemos quedado satisfechos, el sistema (tarea de script) marca la sesión como verificada. En caso contrario, la sesión permanece pendiente de revisión para otra ejecución del proceso más adelante.

Nivel L3 técnico

Esta división en niveles es orientativa, cada diseñador puede tener su forma de hacer las cosas. Según [JF14], referencia que hemos usado para esta clasificación, el nivel técnico es el directamente implementable en un BPMS. Dicho de otra forma, la guía para el técnico que ha de poner en marcha el proceso. Se trata de un especialista que necesita todos los detalles bien definidos, desde almacenes de datos, pasando por descripciones exhaustivas de los flujos de trabajo y coordinación entre procesos, hasta el aspecto de las interfaces.

Sin llegar a tanto, nuestro tercer nivel de descripción expande todos los subprocesos hasta ahora colapsados, introduce situaciones de excepción —qué pasa si...— y artefactos representando documentos o almacenes de datos. En este sentido, la figura P112c muestra esos detalles.

Puesto que el diagrama es muy parecido al anterior (figura P112c) nos vamos a centrar en describir los subprocesos expandidos.

El subproceso REVISAR EJERCICIOS PROPUESTOS parte de un identificador de sesión. Tiene una primera tarea de tipo ad-hoc, lo que significa que las actividades que incluye se pueden realizar o no, sin orden establecido y cuantas veces se quiera. Estas tareas son "adaptar el enunciado" y "mejorar la solución". Una vez se ha terminado esta tarea ad-hoc se valida el ejercicio, con el resultado de ser aceptado o rechazado. En todo caso, el ejercicio queda almacenado en el sistema, sea cual sea la etiqueta que le hayamos puesto, y puede recuperarse posteriormente. Las tareas de mantenimiento de este "banco de ejercicios" se suponen implementadas.

El subproceso PROPONER EJERCICIO NUEVO —instanciado una cantidad indefinida de veces— sirve para crear un ejercicio. Consiste en redactar un enunciado, proponer una solución y asignarlo a la sesión que se está revisando. El bucle termina cuando el usuario decide no continuar añadiendo ejercicios.

Insistimos en que todo se inicia en PREPARAR EJERCICIOS que establece qué sesión se está revisando en cada momento. Ese identificador le sirve a todos los subprocesos para recuperar los ejercicios ya propuestos o para asignar nuevos enunciados y soluciones a la sesión.

Se han añadido algunos artefactos para recalcar que la programación de sesiones y el banco de ejercicios tienen sus almacenes de datos propios con los que interactúa el proceso.

Este proceso en su conjunto es una muestra de decisiones de modelado que tienen su alternativa: estamos estableciendo el procedimiento de preparación de ejercicios para las sesiones de una forma concreta, pero podría haberse llegado a otra solución, otra secuencia de acciones y decisiones. El uso de este proceso determinará si debe mejorarse de alguna forma.

El uso de subprocesos embebidos (subprocess) o llamadas a actividad (call activity) reduce la complejidad del modelo, encapsulando conjuntos de tareas que de otro modo aparecerían todas juntas en un único pool. También, como en este caso, facilitan ciertos tipos de tareas especiales como los bucles o las de instancia múltiple. Las llamadas a actividad se diferencian de los subprocesos en que la línea del borde es más gruesa. Los subprocesos, ya se vean colapsados o expandidos, solo existen dentro de su proceso padre, mientras que las llamadas a actividad son procesos independientes que pueden ser invocados desde otros procesos o ejecutados directamente, naturalmente proporcionándole todos los datos que necesita para ejecutarse. Un buen sitio para comprender la diferencia entre unos y otros es la documentación de Camunda.

Aprovechamos aquí para introducir otro tipo de eventos intermedios (figura P112e), los de enlace. Son meramente estéticos, enlazan partes de un diagrama grande que no cabe en una única hoja o, como en este caso, para acomodarlo en un formato vertical. Es una presentación alternativa que puede gustar más o menos, o ser más o menos necesaria, queda a decisión del maquetador de la documentación.

Proceso P113 Impartir clase

Nivel L1 descriptivo

Al definir las sesiones y sus ejercicios hemos establecido qué contenidos han de desarrollarse en ellas. En este momento vamos a diseñar la clase presencial, estableciendo la forma de exponer esos contenidos y ajustando su temporalización. Al finalizar la clase, anotaremos el resultado y las incidencias observadas durante el desarrollo de la clase; pueden ser cosas como "esta parte no ha dado tiempo", "ejercicio demasiado complicado", etc.

Nivel L2 operacional

En este caso hemos modelado que el sistema inicie automáticamente este proceso cada lunes del periodo de clases. La idea es que examine la tabla de sesiones y para cuándo están programadas, con el resultado de establecer la siguiente clase a impartir con una cierta antelación. Es una especie de aviso automático de que tenemos una clase que preparar y dar. Con este dato, el proceso continua con sus tareas previstas. Esa es la función de la tarea de script "recuperar sesión", consultar la base de datos y devolver la siguiente clase a impartir dentro de, digamos, dos semanas. Es una tarea automática realizada por el gestor BPM y necesita que se configure ese tiempo.

Algunas de ellas son meramente descriptivas de lo que ocurre en la realidad. "Documentar la clase", "desarrollar exposiciones" y "dar la clase" se modelan como tareas manuales, sin interacción con el sistema, no requieren ninguna entrada de datos ni van a generar dato alguno. Son tareas que el profesor realizará al margen del gestor. "Documentar la clase" es una actividad que hace el profesor pero que a nuestro proceso no le supone ninguna acción o dato a registrar. En el nivel técnico sí tendremos que decidir qué hacemos con esta tarea, posiblemente se convierta en un formulario con una entrada que indique que la hemos finalizado. Podría servir como un dato temporal, por ejemplo, que nos permita analizar posteriormente cuánto tardamos en esa tarea. Por otro lado, si no nos interesa ese dato, en el nivel técnico podemos optar por eliminar directamente la tarea, ya que no afecta al desempeño del proceso, como hemos hecho en la figura P113c.

Sí requieren interacción con el sistema en "establecer secuencia de actividades", "establecer tiempos" y en los registros finales. Queremos guardar esos datos en la base de datos esos datos.

Finalmente, para el registro de cumplimiento y de incidencias hemos usado una compuerta paralela. Son dos tareas que han de realizarse rellenando el formulario correspondiente. Hay que entender que, cuando estén disponibles, el usuario verá que tienen dos tareas pendientes que "tomar" y ejecutar. Ya será decisión suya cuál hace primero, o podría darse el caso de dos usuarios diferentes que las ejecuten realmente en paralelo. En todo caso, ambas tareas han de terminarse para que el proceso pueda acabar.