P12 evaluar

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

Proceso 1.2 Evaluar 

Como siempre, hablar de uno, dos, tres o los niveles de descripción que se quiera, es más un ejercicio de diseño desde lo general hasta lo particular. No hay un método estándar, depende de cada uno el cómo afronte este proceso de modelado.

Nivel L1 descriptivo

El proceso comprende desde la programación de actividades a principio de curso hasta la cumplimentación de actas al finalizar aquél. Sin entrar en detalle, podemos decir que el proceso completo es una secuencia como la que se muestra a continuación.

Sin embargo esta es una visión muy simplista de todo el proceso. Pruebas habrá varias, lo mismo que evaluaciones, una por prueba, con su correspondiente plazo de reclamaciones, etc.

La figura P12A2 está más cerca de la realidad. Es lógico realizar una programación previa de las pruebas a realizar, un calendario de pruebas de evaluación, sin más detalle que el tipo de prueba, su temporalización, si es por grupos o no, y el instrumento de evaluación o categoría en la que se incluirán.

Pero no hay una secuencia lineal hasta la cumplimentación de las actas de la asignatura, cada prueba ha de prepararse, realizarse, calificarse y, si las hubiere, resolver las reclamaciones. Es un bucle de tipo multiinstancia secuencial ya que sabemos  —por la tarea anterior— cuántas van a ser las pruebas y cuándo van realizarse. 

Podría argumentarse que este diseño no permite el solapamiento en el tiempo de dos pruebas —un control y una entrega de prácticas, por ejemplo— ya que la instanciación en secuencia hace que una prueba no esté disponible hasta que no finaliza la anterior. No vamos a entrar en ese detalle y suponemos que sí, que finaliza completamente una prueba y entonces puede comenzar la siguiente.

Aún así, nos faltan muchos detalles de la lógica de negocio que desarrollamos en un siguiente nivel.

Nivel L2 operacional

Pretendemos aquí incorporar, si no toda, la mayoría de la lógica de negocio del proceso.

En la figura P12B anterior utilizamos eventos de enlace ("aL01" y "aL02") para poder mostrar todo el proceso.

Como planteábamos antes, la fase de preparación de pruebas consiste en definir, temporalizar y asignar pesos. Este subproceso necesita algo más de desarrollo. Pero antes hay una tarea para establecer las categorías de las pruebas y, después, una validación por parte de todos los profesores de la asignatura. Eso se hace mediante una votación en una tarea de instancia múltiple en paralelo. Se le ha añadido una restricción de tiempo, de forma que un profesor que se retrase demasiado simplemente no vota. Esto asegura que el proceso continúe en un tiempo razonable. La votación necesita un recuento, y de conseguirse un consenso o mayoría el proceso avanzará; de ser negativo el resultado, volveremos al subproceso de preparación del calendario.

Hay un problema en este modelado y es la posibilidad de caer en un bucle infinito, que los profesores nunca se pongan de acuerdo. Es evidente que sería una situación extremadamente rara, casi imposible en la vida real, pero deberíamos darle alguna solución y preverla. 

La parte de evaluación de cada prueba se deja en forma de una llamada a actividad de instancia múltiple en secuencia. Se desarrollará más tarde.

La cumplimentaciónd de actas, si bien parece tener muchas tareas, es un proceso simple en cuanto a su secuencia. Se han incluido tareas manuales para ayudar en la comprensión del proceso. Por ejemplo, "revisar notas" es una tarea en la que se suman las calificaciones obtenidas por cada estudiante y se comprueba que cumple los requisitos del aprobado. Desde el punto de vista del sistema, esta tarea no tiene relevancia, es algo que se hará en papel, en hoja de cálculo o mirando los resultados en una plataforma específica. 

Sí debemos establecer un plazo para reclamaciones y publicar un anuncio de que las notas están disponibles para su consulta. Esta última tarea es de servicio, llamaremos a un servicio externo —un servicio web, una aplicación web, etc.— para que se publique ese anuncio. Esto es más un deseo que una realidad en el momento presente. Estamos suponiendo que nuestro sistema BPM es capaz de conectarse a, digamos, UACloud e insertar automáticamente un anuncio. Lo cierto es que ahora mismo se trataría igualmente de una tarea manual, ajena al sistema BPM: seríamos nosotros los que accederíamos a UACloud y publicaríamos el anuncio.

Hemos añadido un subproceso de evento no interruptor para las reclamaciones, con su lógica encapsulada en un subproceso todavía por detallar. La idea es que en cualquier momento del proceso nos pueden enviar una reclamación de cualquier tipo, se supone que relacionada con la evaluación. Lo importante de este objeto es que mientras se resuelve la reclamación —una revisión y modificación de notas en alguna prueba, por ejemplo—, por lo medios que sea, el proceso de evaluación no se interrumpe.

Para completar la cumplimentación de las actas de la asignatura y finalizar el proceso, hemos añadido una tarea simple de confirmación de que todo ha terminado, porque la firma de actas vuelve a ser una tarea manual y el sistema no la va controlar. Vuelve a ser una acción sobre otro sistema, o incluso en papel, que no tiene efectos sobre nuestro proceso mecanizado. Pero en vez de dejar al proceso simplemente terminar tras el fin del plazo de incidencias, tenemos que interactuar con el sistema para confirmar que hemos firmado actas —sea cierto o no—.

Nivel L3 técnico (pendiente de actualización)

En este punto deberíamos dar absolutamente todos los detalles sobre el proceso para implementarlo definitivamente. Aquí vamos a desarrollar los subprocesos y, más importante todavía, tomar decisiones sobre qué partes del proceso general convertir en procesos independientes con menor alcance, más pequeños. La idea es obtener un conjunto de procesos, sincronizados o no, disponibles para su ejecución cuando se requiera. Por ejemplo, podemos separar la preparación de las pruebas del resto de tareas, pudiendo acceder cuando queramos y modificando el calendario establecido en un primer momento.

Hemos tomado la decisión de separar el proceso único original en los siguientes procesos independientes —entiéndase "independiente" como fuera de una secuencia establecida, podría haber algún tipo de sincronización entre los procesos—.

• Programar pruebas

• Preparar prueba

• Evaluar prueba

• Atender a reclamaciones

• Cumplimentar actas

P121 programar actividades

P122 preparar actividad

P123 evaluar actividad

En primer lugar hay que aclarar que este proceso, en realidad, se realiza enteramente en Moodle, es decir, en una plataforma externa y completamente independiente del sistema BPM. No obstante, lo hemos modelado como si estuviera integrado en el sistema BPMS.

Cuando una actividad programada en Moodle llega a su día y hora de apertura, los alumnos tienen un plazo para entregar su trabajo, bien por subida de archivos, bien por respuesta directa en Moodle. Se puede dar el caso de que el profesor revise el trabajo durante ese plazo y el estudiante lo modifique y lo vuelva a entregar. Finalizado el plazo establecido, Moodle cierra la actividad y el profesor califica todas las entregas. Evidentemente, el estudiante puede entregar o no durante el periodo programado.

En la figura P123a se muestra el diagrama diseñado para este proceso. En primer lugar, el proceso padre supone una tarea de apertura del plazo de entrega y otra de cierre, para finalizar con la calificación. Esta última tarea se ha modelado como de instancia múltiple secuencial, pretendiendo reflejar que son varios los trabajos a calificar y no solo uno.

Entre apertura y cierre de plazo se situa la entrega de trabajos, una por cada estudiante. Es decir, para cada actividad tendremos múltiples entregas, tantas como estudiantes haya. Esto se ha modelado como una llamada a actividad de instancia múltiple en paralelo. Es la forma de reflejar que cada estudiante —o grupo de estudiantes— tendrá una entrega pendiente de su trabajo, que atenderá cuando lo considere conveniente.

El subproceso "entregar actividad" (fig. P123b), a su vez, en un subproceso en bucle, SUBIR RESPUESTA, en el que el estudiante o grupo puede realizar varias subidas de respuesta a la actividad —la "entrega" de la actividad— según va recibiendo retroalimentación por parte del profesor. Este subproceso se interrumpe cuando termina el plazo de entrega establecido para la actividad a evaluar.

La forma de avisar al profesor de que tiene entregas ya subidas al sistema y de que puede revisarlas si quiere es mediante sincronización por mensajes entre procesos. SUBIR RESPUESTA envía un mensaje a REVISAR ENTREGA que permite al profesor revisar la entrega y, a su vez, avisar al estudiante de tiene comentarios de retroalimentación. En ese momento se reanuda SUBIR RESPUESTA que se había parado esperando dicho mensaje de respuesta, y el estudiante puede proceder a modificar su respuesta y subirla al sistema de nuevo.

Aunque puede parecer complejo, lo hacemos así para evitar patrones de retroceso desde una actividad o compuerta a actividades anteriores, un bucle tradicional en algoritmia, por poner un ejemplo.

Fijémonos en que el proceso completo se detiene al finalizar plazo de entrega, es decir cuando se activa el temporizador interruptor adjunto a SUBIR RESPUESTA, no hay otra forma de terminar el proceso. Como el subproceso está planteado como un bucle infinito, la conexión directa entre SUBIR RESPUESTA y el evento final "entrega finalizada" se mantiene por coherencia sintáctica pero nunca se recorrerá.

Debemos comentar que el concepto de "bucle infinito" no es totalmente adecuado para una implementación en BPMN, normalmente es recomendable establecer una cantidad máxima de iteraciones, pero esta puede ser lo suficientemente grande para que parezca "infinita".

En la figura P123c, mostramos el detalle de la última llamada a actividad: RECLAMAR. Se establece que el estudiante puede reclamar hasta 2 veces la nota publicada por el profesor. Nuevamente lo representamos mediante un subproceso expandido con bucle, REVISAR NOTA, solo que en este momento establecemos 2 iteraciones como máximo.

Dentro de ese subproceso, el estudiante revisa su calificación junto con los comentarios de corrección y puede o aceptar la nota, o reclamar su revisión. Si acepta la nota, se lanza el evento de escalado (conforme con calificación) que, a su vez, inicia el subproceso de evento CIERRE POR CONFORMIDAD. Este subproceso es interruptor, y tiene dos objetivos: evitar nuevas iteraciones de REVISAR NOTA, y finalizar el proceso RECLAMAR.

Sea la primera o la segunda vez que el estudiante revisa su nota, si no está conforme, el profesor debe responder al activarse la llamada a actividad VALORAR RECLAMACIÓN. Esta tiene modelada una interrupción por temporizador de 48 horas, es decir, desde el momento en que se inicia la reclamación, el profesor dispone de ese tiempo para responder. De no hacerlo, el proceso termina con una señal de escalado que afectará al proceso padre, a RECLAMAR. Lo hará activando el subproceso de evento interruptor asociado a esa señal de escalamiento (silencio administrativo).

Por otro lado, el proceso de reclamación también terminará si se agota el plazo de reclamaciones. Esto se consigue con el otro evento de inicio del subproceso de evento CIERRE POR CONFORMIDAD. Este doble inicio funciona de tal manera que el que primero que se active pondrá en marcha el subproceso, y terminará el proceso RECLAMAR esté este en el punto de ejecución que esté.

P124 definir grupos de alumnos

Aunque en principio pueda pensarse que este es un proceso sencillo, se han de tener en cuenta varios aspectos que dificultan el modelado.

El proceso se ha expandido mediante un subproceso para poder reflejar el plazo que se establecerá para la asignación de roles dentro del grupo una vez constituido, lo que se comentará más adelante. 

En cuanto al proceso principal, es necesaria una preparación previa a partir de los datos de matriculación para establecer el tamaño de los grupos y crear las etiquetas que los denominen. Esas etiquetas, y el número de miembros, se utilizan en Moodle para parametrizar una actividad denominada "apuntarse a grupo". El estudiante, una vez la actividad esté activa, debe identificarse en la plataforma y elegir el grupo al que quiere pertenecer. Normalmente lo hará habiendo establecido previamente quiénes formarán el grupo; no es habitual que se incorpore a un grupo cualquiera sin más. A continuación se producirá la asignación de roles —"líder" al menos— por votación en el grupo. Finalmente, el profesorado confirmará, verificará que toda la información es correcta y se dará por finalizado el proceso.

El subproceso "asignar roles", además de la votación ya comentada, prevé una penalización en puntos a los miembros del grupo que no comunique sus roles al profesorado en tiempo. Además, esto conllevará la designación de cualquier miembro como líder, a discreción del profesorado.

En la figura P124 se describe cómo será el flujo de trabajo de este proceso. En el proceso "definir grupos" cabe destacar la tarea "programar inscripción" que se ha categorizado como manual ya que se realiza en una plataforma externa —Moodle— sin comunicación ninguna con un posible gestor BPM.

Más explicación requiere la tarea "asignar roles", en el mismo proceso "definir grupos", que es un subproceso colapsado y de instancia múltiple. Que sea un subproceso quiere decir que se trata de una tarea compleja que se ha elegido modelar aparte; y de instancia múltiple porque se iniciará una instancia por cada grupo. Dicho de otra manera, el proceso lo inicia y lo desarrolla una persona —un profesor— pero llega un momento en que lanza una tarea a cada grupo para que elija y asigne sus roles de grupo. Cuando todos ellos terminen, el profesor continuará con el proceso inicial. 

El subproceso "asignar roles", en la figura P124B, representa el conjunto de tareas que debe realizar cada grupo con ese fin. En este caso, se utiliza un subproceso expandido "votar roles" con la intención de incorporar un evento adjunto de interrupción, "plazo finalizado". Explicado en palabras sencillas, el grupo tiene que "votar", "elegir líder", "elegir organización interna" y "comunicar resultados" dentro de plazo. Si lo hacen antes de que expire, el subproceso termina normalmente y cederá el control al proceso "padre", "definir grupos". Si tardan demasiado, el proceso "votar" se interrumpe —haya llegado al punto que haya llegado— y se ejecutan "penalizar miembro grupo" y "forzar roles".

"Votar", como tarea, es una actividad de instancia múltiple en paralelo puesto que todos los miembros del grupo deben hacerlo. Es en paralelo porque todos pueden votar al mismo tiempo. Sin embargo el resto de tareas las completará el estudiante que haya iniciado el subproceso. En realidad, no se ha establecido quién lo va a hacer, se supone que el grupo lo decidirá antes o después de activarse.

"Comunicar resultados" se ha caracterizado como tarea manual porque se hace mediante un correo electrónico enviado al margen del gestor BPM.

Igualmente, "penalizar miembro grupo", es una tarea manual porque se realiza en Moodle. Y, además, es de instancia múltiple secuencial, esto es, la tarea la realiza el profesor que debe ir uno a uno estableciendo dicha penalización a todos los miembros del grupo. 

"Forzar roles" también es una tarea manual porque no implica interacción con el sistema BPM.

Por último, hemos modelado "inscripción en grupo" (figura P124C) como proceso independiente, sin otro motivo que el que dicha tarea se realiza en Moodle y está totalmente controlada por la plataforma. Podríamos eliminarlo y que formara parte de la tarea manual "programar inscripción" que se ha descrito anteriormente.

Tan solo queríamos reflejar que, primero, el proceso se instancia por cada estudiante que accede a la activdidad de Moodle, y cuando este abre la actividad. Si el estudiante se inscribe normalmente, el proceso termina satisfactoriamente, y Moodle tendrá registrada su inscripción. Si se termina el plazo, la tarea "inscribirse" se interrumpe, y el flujo de proceso simplemente termina con un estado de error, "estudiante sin grupo", y no se detallan más acciones a partir de este estado.

Es importante recalcar que esto no refleja del todo la realidad. Según la figura P124C alguien podría iniciar la tarea "inscribirse" —técnicamente, "tomar" la tarea, reconocer en el sistema que tiene una tarea pendiente— y no hacer nada hasta que se acaba el plazo. La realidad en Moodle es que la tarea se hace disponible para todos y, simplemente, el estudiante la ejecuta o no; en el segundo caso, simplemente Moodle lo tendría en la lista de estudiantes matriculados pero sin pertenencia a ningún grupo.

P125 cumplimentar actas