Inserción profesional con productos reales

1.- Justificación

La finalidad de la FP consiste, obviamente, en posibilitar la inserción profesional del alumnado. Sin embargo, concentrados en proporcionarles los conocimientos técnicos que cada alumno/a debe acumular durante su paso por los ciclos formativos, con frecuencia los docentes olvidamos un poco que las posibilidades de ser contratados e, incluso, el éxito profesional a largo plazo, depende en gran medida de otros factores, que, aunque están ligados a los conocimientos técnicos, entroncan mas directamente con la adquisición de ciertas capacidades, tanto individuales o de relación con el entorno laboral. En particular, resultan muy valorados aspectos como la iniciativa personal, la autonomía en la resolución de situaciones o la capacidad de integrar el trabajo propio dentro de un marco mas amplio. No queda duda de que, en el mundo empresarial, los trabajadores/as que han desarrollado este tipo de actitudes pueden conseguir una productividad mas alta que redunda en mayor facilidad para encontrar/mantener un puesto de trabajo o, incluso, para impulsar una empresa propia. Sin embargo, los métodos de trabajo en el aula que habitualmente solemos aplicar en FP pecan de un déficit en la adquisición de ese tipo de actitudes, quizás derivado del mecanismo de transmisión de conocimientos unidireccional que tradicionalmente utilizamos y que, por su propia mecánica, puede tender a implantar en el alumnado costumbres como resolver preguntando antes de buscar sus propias soluciones o confiar en lo que se les cuenta sin cuestionarse su idoneidad o las posibles repercusiones. Está bastante difundida la opinión de que para resolver esta carencia está la fase de prácticas en empresas (FCT), pero, aunque la inmersión en un contexto laboral real sea una excelente forma de adquirir esos hábitos, seguramente nuestro alumnado agradecerá que, previamente, se les hayan proporcionado las bases para ello. Desde luego, estas bases parten de ser conscientes de las carencias y de haber tenido, al menos, la oportunidad de resolverlas en un ambiente controlado como es el aula.

El método de trabajo por proyectos, ampliamente conocido, permite crear en el aula una simulación bastante similar a las de los casos reales, siempre y cuando se establezcan unas condiciones adecuadas. Estas deben incluir, para ser convincentes, un componente de presión intelectual controlado que motive al alumnado a sentirse “como en una empresa”, lo que se puede tratar de lograr utilizando varios factores:

a)La seguridad de que los resultados que obtengan son productos reales, es decir, que lo que entreguen puede ponerse en uso real al terminar su desarrollo. Esta condición es fundamental, por su impacto intelectual, pero puede implicar el que el proyecto, en si, abandone, en parte, un hilo de desarrollo convencional (planteamiento-diseño-realización-evaluación) en favor de un enfoque mas realista, donde puede ocurrir que partes del diseño vengan predeterminadas o que la evaluación tenga que adaptarse en función de dificultades, e incluso, imprevistos, que aparezcan, como en cualquier proyecto real en la fase de realización.

b)La importancia que se otorgue a la evaluación de sus resultados, es decir que tengan “la sensación de estar jugándose algo importante”. A este efecto, la forma en que se evalúa es crítica y tiene que ser percibida por el alumnado como un mecanismo objetivo y justo, ya desde antes de empezar el desarrollo del proyecto, siendo, además, una guia fundamental en el desarrollo del mismo.

c)El dominio del entorno operativo del proyecto en su fase de explotación, es decir, que conozcan con detalle las condiciones reales en que se podrían usar los productos que desarrollen dentro del proyecto. Esta condición les permite comprender mejor las condiciones reales en que se espera que operen sus productos finales y, por tanto, la importancia que los errores cometidos tienen en la evaluación.

2.- Marco de aplicación: contexto del Modulo Formativo E.4.G.

El módulo de Desarrollo de Aplicaciones en Entornos de 4ª Generación con Herramientas Case (Ciclo Formativo de grado superior Desarrollo de Aplicaciones Informáticas, familia profesional de Informática, abreviado E4G), pretende que el alumno, además de aprender programación avanzada en varios lenguajes y entornos, como puedan ser servidores SQL, entornos como Oracle Developer o plataformas LAMP (Linux+Apache+Mysql+PHP), desarrolle un importante grado de autonomía a la hora de resolver los problemas que se le plantean. Esta actitud incluye pautas de trabajo extraídas del contexto laboral actual, entre las que se encuentran la búsqueda, selección y aprovechamiento de documentación a través de Internet o la capacidad de adaptación de soluciones ya desarrolladas por terceros (reutilización de código, trabajo en equipo), trabajando siempre en un marco de referencia ampliado (aplicaciones realizadas por múltiples programadores) y realista (requerimientos de diseño reales).

El aprendizaje de las pautas de trabajo que se pretende imbuir en el alumno/a se desarrolla durante todo el curso. Se parte de un inicio de tipo clásico (contenidos impartidos de forma tradicional, ejemplos, ejercicios para el alumnado, examen de evaluación), que entronca con los métodos que se suelen utilizar en primer curso, dura el primer tercio del curso, para pasar, en el segundo tercio del curso, a introducirle progresivamente en la necesidad el fomento de la iniciativa y el autoaprendizaje. En ese segundo tramo del desarrollo del módulo, se realiza una primera tanda de proyectos que suponen el contacto inicial del alumnado con este método de trabajo, por lo que los requerimientos deben adaptarse para evitar un impacto demasiado fuerte. En el tramo final del curso, los elementos técnicos se imparten ya de una manera ciertamente similar a la que el alumnado podrá esperar de la fase de FCT que seguirá al final de curso, en el sentido de que se les proporcionan, no ya bloques completos de contenidos, sino simplemente series de diferencias de conceptos a partir lo que se asume que saben o indicaciones para localizar información en Internet. Esta fase incluye el proyecto de final de curso, que ocupa el último 25% del tiempo y donde se integran las enseñanzas técnicas impartidas en el módulo mas contenidos que el alumno/a debe aprender por propia iniciativa (con la mínima orientación por parte del profesor). El mecanismo de trabajo desarrollado para la realización y evaluación de estos proyectos de final de curso es el que se va presentar en detalle.

3.- Aplicación del método de proyectos

Los proyectos de final de curso del módulo E4G suponen la aplicación de todos puntos que se describían en la justificación de este artículo, aplicado a un caso real. Dicho caso real se referirá al desarrollo de software para gestionar la intranet del IES Galileo. Dado que el alumnado ya ha utilizado sistemáticamente la intranet durante todo el ciclo, especialmente en el propio módulo E4G, resulta sencillo que comprendan con profundidad el contexto operativo (1200 usuarios, mas de 600 asignaturas-grupo, etc) y las condiciones de uso real (mentalidad de usuarios de profesores/as y alumnado, etc), lo que les pone rápidamente en situación (punto 1a de la justificación). Por otro lado, el hecho de descubrir que parte del software que gestiona la intranet del centro ha sido desarrollado como proyectos de fin de curso de compañeros/as suyos en cursos precedentes, supone un estimulo considerable a la hora de que asuman que el producto final de su trabajo va a estar en uso real, con las repercusiones que esto conlleva, tal como se describía en el punto 1c de la justificación. Por último, es preciso, según se exponía en el punto 1b de la justificación, conseguir un mecanismo de evaluación objetivo que sirva de guía y aporte la ”dosis de presión” necesaria, especialmente si se tiene en cuenta que la nota del proyecto supone una parte fundamental (30%) de la nota global del módulo E4G.

Incidiendo ya en el contenido de los proyectos, es importante remarcar que el desarrollo de software para la gestión de la intranet del centro(dentro del proyecto ILEX que se aplica, junto con otros centros, en el IES Galileo) supone un nuevo marco de trabajo para el alumnado, por cuanto se enfrentan a una situación completamente real que choca frontalmente con los hábitos que conocen hasta ese momento. Sirvan de ejemplo estos datos:

Cualquier programa incluido en la gestión de la intranet puede tener de miles de lineas de código, mientras que están acostumbrados a trabajar con programas que apenas sobrepasan el centenar.

Su trabajo consistirá, en gran medida, en modificar programas hechos por terceros con los que no tienen ninguna forma de contactar, que trabajan en otros idiomas (francés e inglés) y con metodologías de programación diferentes (e, incluso, sin metodología alguna, o sea autenticas chapuzas, pero de tamaño real).

Los mecanismos de interacción con los usuarios finales (pantallas de presentación de datos, etc), responden muy mal a muchos de los mecanismos de programación que mas habitualmente utilizan, debido a múltiples razones (retardos, longitud de las pantallas, etc).

Consecuencias inmediatas son, por ejemplo, la multiplicación del factor tiempo necesario para realizar cualquier trabajo – tal como ocurre en la realidad -, la apertura de un amplio abanico de repercusiones para cualquier operación de realicen o la obligación de ajustarse a un marco de referencia que puede tener puntos cuya justificación no es comprensible a veces, pero no es cuestionable. A todo ello se suma el hecho insoslayable de que la fecha de entrega no es prorrogable (por ser precisamente el final de curso). La vida misma, en suma.

Por otro lado, la ayuda del profesor se limita a resolver solo aquellas cuestiones que, decididamente, no pueden resolver por si mismos (por ejemplo, por tiempo). En general, la ayuda del profesor se reduce a tres aspectos clave: aclarar los requerimientos que se les hace, “refrescar” los conocimientos técnicos procedentes de otros módulos que pudieran necesitar (Sistemas Operativos, etc) e indicar fuentes de información en Internet. Cualquier otro problema tiene que ser capaces de resolverlo por si mismos en el tiempo de que disponen.

4.- Evaluación del método de proyectos

El mecanismo de evaluación de los proyectos trata de lograr un sistema lo mas objetivo e imparcial posible, además de cumplir una serie de objetivos paralelamente a la mera calificación. En esa linea, la forma de calificar los proyectos intenta servir de guía para el propio desarrollo, de ayuda para que comprendan la diferencia entre lo importante y lo superfluo en el desarrollo de aplicaciones informáticas y, especialmente, pretende facilitar la autoevaluación y, con ella, ayudar a desarrollar la iniciativa y la autonomía en la resolución de problemas. Para ello, obviamente, el alumno/a tiene que conocer con precisión el mecanismo de evaluación antes de empezar a desarrollar sus proyectos, tanto la mecánica global como la aplicación concreta a su caso.

Básicamente, para cada proyecto se establecen una serie de criterios de evaluación “atómicos”, en el sentido de que no se podrían descomponer en otros mas pequeños sin que perdieran el sentido de entidad completa. Estos criterios atómicos se agrupan en orden de importancia, por niveles: una serie de ellos conllevan el aprobado, otra serie de ellos el bien, otra el notable y otra el sobresaliente. Cada criterio atómico puede estar B (Bien, sin errores funcionales), R (Regular, sin errores funcionales pero con, como máximo, un error de cualquier otro tipo) o M (Mal, con uno o varios errores funcionales o con mas de un error de otro tipo). Se entiende como error funcional el que altera el funcionamiento de forma que entrega resultados invalidos. Cada nivel supone que todos los criterios estén conseguidos con B o, como mucho, hay un criterio con R. Si existen dos criterios con R o uno con M, el nivel no es sobrepasado por el alumno/a. Los criterios que pertenezcan a niveles superiores al nivel que no se ha sobrepasado no se tienen en cuenta para la nota del proyecto. Todo esto supone, traducido a palabras pobres, que:

Para aprobar tienen que tener correctos los criterios de mínimos, admitiéndose un solo error no grave.

Para aspirar a tener una nota cualquiera, supongamos un notable, es preciso tener B (o con un solo R, error no grave) en todos los criterios previos a los que corresponden al notable (calificaciones suficiente y bien). Sin embargo, una vez que todos ellos están superados, para obtener el notable el propio alumno/a puede decidir, dentro de un margen, como lo logrará, seleccionando los elementos a realizar de entre los que necesite para superar los criterios de evaluación correspondientes al notable.

Por otro lado, en cuanto a la forma de elegir los criterios, hay algunos detalles importantes:

Es importante el que no existan proyectos iguales, por lo que los criterios, en su mayoría difieren de proyecto a proyecto (salvo los comunes y los idénticos, tal como se explica a continuación). Esto requiere un considerable esfuerzo de planificación por parte del profesorado, ya que conseguir que la dificultad sea similar puede llegar a ser complejo. Dado que también pueden surgir imprevistos, es frecuente negociar algún criterio con algún proyecto durante el desarrollo del mismo.

Existen algunos criterios idénticos a todos los alumnos/as, que suponen el mismo trabajo y que hay que realizar en todos los proyectos. Por ejemplo, el denominado “Bitacora continua en foros”, que representa la obligación de ir dejando constancia de la evolución día a día del desarrollo del proyecto utilizando una herramienta electrónica (foro).

Existen criterios comunes (pero no idénticos) a todos los proyectos, que suponen la realización de un trabajo similar, con diferente contenido pero igual técnica, para asegurar que que todos/as adquieren determinados conocimientos técnicos a partir de cierto nivel. Por ejemplo, el denominado “Listado PDF de etiquetas”, aparece en todos los proyectos (cambiando el contenido del listado, unos listan etiquetas de correo y otros otro tipo de datos, pero la técnica PDF es la misma).

Existen criterios “desincentivadores” que, por su ubicación en un segmento de notas, orientan el trabajo del alumnado en otra dirección. Un ejemplo podría ser la “Estética integrada” , que aparece dentro del último segmento, como forma de fomentar que no se pierda tiempo en adornos si no se ha garantizado la funcionalidad.

Para terminar, reincidir en que el alumnado tiene que disponer de la plantilla de evaluación con todos los criterios antes de empezar el desarrollo del proyecto, ya que esto le permite planificar su esfuerzo en función del resultado que pretender obtener. En cuanto a la corrección de los proyectos, es muy conveniente hacerlo con el propio/a autor/a delante, para que vea por si mismo la causa de que algún criterio pudiera estar evaluado con R o M. Incluso así, es fundamental rellenar las OBSERVACIONES de los criterios evaluados con R o M, para poder justificar la nota global en cualquier momento. En grupos grandes, esto puede dificultar la entrega de los proyectos, ya que la corrección,realizada con el alumno/a delante, puede llevar una considerable cantidad de tiempo. En cualquier caso, ya se corrija con el alumno/a delante o no, es fundamental entregarle una copia del formulario una vez rellenado.

El ejemplo que se presenta en el archivo adjunto, es copia del formato real de evaluación, salvo que este no presenta más que una columna de notas, mientras que la copia que se incluye a continuación incluye 3 casos distintos a la vez. Estos casos presentan peculiaridades que resaltan las características del método usado para evaluación.