II JORNADAS DE INNOVACIÓN DOCENTE, TECNOLOGÍAS DE LA INFORMACIÓN Y DE LA COMUNICACIÓN E INVESTIGACIÓN EDUCATIVA EN LA UNIVERSIDAD DE ZARAGOZA 2008 FEDAI: Formación de Equipos para el Desarrollo de Aplicaciones Informáticas Una experiencia de aprendizaje basado en proyectos José Antonio Baldovín Oliver Profesor Asociado/ Facultad de Ciencias José Carlos Ciria Cosculluela Profesor Contratado Doctor/ Facultad de Ciencias Ángel de Miguel Artal Profesor Ayudante/ Facultad de Ciencias Eladio Domínguez Murillo Catedrático de Universidad/ Facultad de Ciencias Ángel Francés Román Profesor Titular de Universidad/ Facultad de Ciencias Jorge Lloret Gazo Profesor Titular de Universidad/ Facultad de Ciencias Áurea Rodríguez Villanueva Profesora Ayudante/ Escuela Universitaria de Estudios Empresariales Beatriz Pérez Valle Profesora Ayudante/ Escuela Universitaria de Estudios Sociales Mª Antonia Zapata Abad Profesor Titular de Universidad/ Facultad de Ciencias Síntesis: El proyecto tiene como objetivo básico la formación de estudiantes para el desarrollo de aplicaciones informáticas mediante el trabajo en equipos. La aplicación debe resolver un problema real, de interés práctico para el grupo de profesores participantes en el proyecto. Dicho problema se propone a principio del curso académico. A lo largo del curso se crean una base de datos y se desarrolla una aplicación que permita la introducción, modificación y consulta de los datos almacenados. Se pretende hacer énfasis en el desarrollo de las competencias: o capacidad de comunicación oral y por escrito. o manejo de distintos paradigmas de programación: adquisición de pautas para decidir cuál es el más adecuado para una situación dada. o adquisición de una metodología para el desarrollo de aplicaciones que garantice la fiabilidad, eficiencia y buen estilo de programación. Palabras clave Aprendizaje Basado en Proyectos, Práctica Profesional 1
1. INTENCIONES DE LA PROPUESTA Como parte del sistema educativo, tenemos la responsabilidad de estar atentos a las necesidades de formación de nuestros estudiantes y a lo que de ellos se espera al salir de la Universidad. En el reciente proceso de adaptación de la Universidad al marco europeo se hace énfasis en esta idea. Baste citar el Real Decreto 1393/2007, de 29 de octubre, por el que se establece la ordenación de las enseñanzas universitarias oficiales, que en su artículo 9 afirma: "1. Las enseñanzas de Grado tienen como finalidad la obtención por parte del estudiante de una formación general, en una o varias disciplinas, orientada a la preparación para el ejercicio de actividades de carácter profesional." Es fundamental la retroalimentación que proporcionan las opiniones de los licenciados, así como de las empresas, administraciones y grupos en que se integran. Una opinión generalizada respecto de los estudios de Matemáticas es que existe un déficit en cuanto a conocimientos de Informática [1][2]. Esos estudios son, precisamente, los más valorados por quienes trabajan en la empresa y por la empresa misma (que los considera muy relevantes, por ejemplo, en el proceso de selección de personal). Por otro lado, hay toda una serie de competencias cuya relevancia en la vida profesional está unánimemente aceptada, y que no se adquieren durante la carrera. Dichas competencias son instrumentales (toma de decisiones, capacidad de comunicación), personales (integración efectiva en un equipo), sistémicas (iniciativa, motivación por la calidad), profesionales (aplicación de los conocimientos a la práctica)... Competencias que marcan el salto entre un estudiante y un profesional (de la empresa, la investigación o la docencia). Es deseable acortar este salto para facilitar la empleabilidad de los estudiantes [3]. Una posible estrategia para ello es incorporar la práctica profesional al currículo universitario [4]. Ésta es la intención primordial de nuestra propuesta: proporcionar a los estudiantes un entorno en que puedan desarrollar actividades propias de la profesión de informático. El Área de Ciencia de la Computación es responsable de la enseñanza de Informática en la Licenciatura de Matemáticas. Uno de nuestros retos es dar consistencia al bloque de asignaturas de Informática de la carrera armonizando su desarrollo. Debe haber entre ellas un hilo conductor en contenidos, planteamientos y metodología docente. Somos investigadores en Computación, y a lo largo de los años el grupo ha acumulado experiencia en el desarrollo de proyectos para administraciones públicas y empresas. Desde ambas perspectivas (teórica y profesional) somos conscientes del gran desafío planteado en el mundo de los Sistemas de Información: la falta de tecnologías y métodos definitivos que garanticen la fiabilidad del software. El desarrollo de un sistema de información es costoso, lento para las exigencias de la empresa e inseguro. Diversas fuentes estiman en más de 300.000 millones de dólares anuales las pérdidas anuales a consecuencia de proyectos abandonados, reescritura de código para corregir errores una vez entregada la aplicación, pérdidas de información por fallos del sistema... [5]. Queremos transmitir a los estudiantes nuestra percepción de las grandes 2
dificultades que plantea el desarrollo de un sistema, y la necesidad de establecer y seguir una metodología fiable de trabajo. 2. OBJETIVOS Queremos que el estudiante: o o se familiarice con una metodología de buenas prácticas admitidas y seguidas en la comunidad de software para el desarrollo de aplicaciones, y con tecnologías de bases de datos y programación en la WEB. adquiera destreza en el uso de distintos paradigmas de programación. En las distintas asignaturas de Informática se presentan varios paradigmas: estructurada (Informática I, troncal 1º de carrera), orientada a objetos (Informática II, optativa de primer y segundo ciclo), declarativa (Modelos Matemáticos de Bases de Datos, optativa de segundo ciclo). El desarrollo de una aplicación informática hace que el estudiante utilice distintos paradigmas en un mismo proyecto (usa SQL para realizar consultas, un lenguaje procedural como PL/SQL para implementar reglas de negocio, Java para crear la aplicación). De este modo, aprende a adecuar la estrategia de trabajo a cada contexto. o aprenda a someter su trabajo a un control de calidad, referido a garantizar la consistencia de los datos almacenados, la usabilidad de la aplicación y la ergonomía en el diseño de la interfaz. o desarrolle competencias personales (razonamiento crítico, trabajo en equipo) y sistémicas (motivación por la calidad, creatividad e iniciativa). El planteamiento del proyecto, desarrollado transversalmente a lo largo de varias asignaturas, hace que el estudiante tome conciencia de la necesidad de comunicarse eficazmente por escrito (los equipos que implementan las reglas de negocio o que construyen la aplicación que accede a la base de datos necesitan una buena documentación para entender sobre qué están trabajando) y oralmente (con el profesor, o al plantear los problemas en clases de asesoría.). 3. VIABILIDAD DEL PROYECTO: LA EXPERIENCIA DEL 'MÁSTER EN BASES DE DATOS E INTERNET' El mejor argumento a favor de la viabilidad de nuestro proyecto es que en el pasado hemos desarrollado iniciativas parecidas. En cursos anteriores, en las asignaturas de 'Bases de Datos II' y 'Desarrollo en Gestores de Bases de Datos' (diplomatura de Estadística) y en 'Modelos Matemáticos en Bases de Datos' (licenciatura de Matemáticas) se proponía a los estudiantes una evaluación continua. Era posible superar la asignatura realizando tres pruebas a lo largo del cuatrimestre y desarrollando por equipos un proyecto: en 'Bases de Datos II', el diseño 3
de una base de datos; en 'Desarrollo en Gestores de Bases de Datos', una aplicación cliente-servidor sobre una base de datos ya construida. La experiencia fue bastante satisfactoria pero se quedaba corta: los proyectos sólo cubrían parcialmente el conjunto de fases del ciclo de vida de una aplicación, y se trataba de proyectos de planteamiento académico. Donde realmente hemos implementado la filosofía de la práctica profesional es en el 'Máster en Bases de Datos e Internet' [6]-[8]. En él se simula una empresa en formación: los participantes dedican aproximadamente la mitad de su tiempo a realizar distintos cursos de 20-30 horas, al final de cada uno de los cuales debe superar una prueba. Además, desde el principio se agrupan en equipos de trabajo, a cada uno de los cuales se le encomienda un proyecto real. Estos proyectos surgen de acuerdos con empresas y administraciones públicas [9]. La novedad de nuestra propuesta radica en aplicar a unos estudios reglados (la licenciatura en Matemáticas) toda la experiencia acumulada en el desarrollo de proyectos reales llevado a cabo en el seno del Máster. La propuesta se plantea con vocación de sostenibilidad. No es un punto de inicio, sino la continuación de un proceso de búsqueda de nuevas prácticas docentes que empezó hace cuatro años (con la primera edición del Máster) y aspiramos a continuar en el tiempo. 4. PLANIFICACIÓN: CRONOLOGÍA A los estudiantes de las asignaturas indicadas se les ofrece a principio de cuatrimestre, de modo voluntario, la posibilidad de acogerse a un régimen de evaluación continua. Para ello deberán realizar dos pruebas periódicas a lo largo del curso y realizar un proyecto en equipo. Quienes elijan la opción tradicional (el examen de la convocatoria oficial) tienen opción a realizar las mencionadas pruebas con objeto de regular su ritmo de estudio y autoevaluarse. Un equipo acepta el encargo de realizar un proyecto en el momento en que entrega el documento de objetivos, alcance y planificación. Este documento se considera un contrato por el que el equipo se compromete a entregar en los plazos acordados documentación correspondiente a las distintas fases del ciclo de vida de la aplicación, y a completar la aplicación. Consideramos importante que el equipo se responsabilice a marcarse un ritmo de trabajo y asuma el compromiso de cumplirlo. En caso de incumplimiento de plazos se analiza conjuntamente la causa. Los proyectos se realizarán a lo largo del curso académico. La cronología estimada para el desarrollo de los proyectos es: Primer cuatrimestre: diseño y creación de una base de datos en ORACLE. o mediados de octubre: entrega del documento de 'Objetivos, alcance y planificación' o mediados de noviembre: entrega del documento definitivo de 'Análisis' 4
o principio de diciembre: entrega del esquema conceptual de la base de datos. o finales de diciembre: entrega del esquema lógico de la base de datos. o mediados de enero: entrega del código SQL para la creación de la base de datos. Segundo cuatrimestre: o finales de febrero: entrega del documento de 'Objetivos, alcance y planificación' o implementación de reglas de negocio en el servidor o mediados de marzo: entrega del documento de 'Análisis' o finales de marzo: entrega del código en PL/SQL o desarrollo de una aplicación en JAVA para acceder a la base de datos. o mediados de abril: entrega del documento de 'Análisis' o mediados de mayo: entrega de prototipo de interfaz. o finales de junio: entrega de la aplicación. Como en toda planificación, las fechas indicadas son meramente orientativas. Con cada equipo se acordarán fechas estimadas de entrega, que serán reflejadas en el documento de planificación. 5. DESARROLLO DE LA EXPERIENCIA. COMPETENCIAS MÁS RELEVANTES 5.a Comunicación oral y escrita Una competencia fundamental que queremos desarrollar en nuestra asignatura es la capacidad para comunicarse eficazmente de modo oral y escrito, competencia recogida en nuestra guía docente para la asignatura Métodos Matemáticos en Ingeniería del Software. La asignatura se presta especialmente a ello, ya que los estudiantes deben comunicarse con un "cliente" que les expone un problema (rol desempeñado por el profesor), transmitir a los demás equipos las líneas principales de su trabajo (especialmente aquellos puntos de conexión entre módulos desarrollados por distintos equipos) y a documentar correctamente el propio trabajo. En los proyectos desarrollados a lo largo del curso 2006-07 la documentación pasó un doble filtro: la revisión por parte del profesor y la lectura por parte de compañeros de distintos equipos. Ambos filtros supusieron la depuración de los distintos documentos a través de sucesivas versiones. Asimismo, cada uno de los equipos impartió un seminario relativo a su parte del proyecto. Nuestro propósito para el presente curso es formalizar y dar más rigor a estas iniciativas: 5
Cada equipo deberá evaluar la documentación generada por al menos otro. Dicha evaluación incluirá valoraciones cuantitativa (de 0 a 5) y cualitativa. También se formularán preguntas al equipo evaluador para determinar si la información ha sido transmitida eficazmente. De este modo reproducimos el sistema de evaluación por pares, utilizado tanto en el ámbito académico como en el empresarial. Un valor añadido de este método es que, a través de la evaluación del trabajo ajeno, uno aprende a "verse desde fuera" y a valorar objetivamente su propio trabajo. También perfeccionaremos el modo en que se desarrollan los seminarios: los integrantes del grupo exponen su proyecto durante 30-40 minutos. A continuación hay un turno de preguntas, tras el cual se pide a los demás estudiantes que en 5-10 minutos rellenen un formulario rápido indicando: o Cuál ha sido, en su opinión, el objetivo de la charla o Un resumen de la charla o Puntos destacados o Valoración de la exposición. A los integrantes del grupo se les pide igualmente que se autoevalúen: qué valoración global hacen de su presentación y qué es lo que menos les ha gustado. El objetivo de la sesión es doble: por un lado, cada grupo informa al resto de sus avances. Por otro, se evalúa el modo en que nos expresamos en público. Insistimos en la necesidad de recalcar cuál es el objetivo principal de la charla (la idea que todo el mundo tiene que tener clara al salir), de articular la presentación de modo que sea fácil seguir el hilo argumental, de evitar vicios de principiantes (como obsesionarse con los detalles técnicos de la charla). 5.b Un proyecto multitecnológico: aplicación de la ingeniería del software Al plantear el proyecto en clase surgió un debate sobre la herramienta a utilizar. La propuesta inicial fue hacer uso del entorno de desarrollo integrado JDeveloper, de ORACLE, que permite desarrollar aplicaciones en Java. Se había redactado un manual de uso de la herramienta para poner a disposición de los estudiantes. Un grupo reducido de estudiantes objetó que, al no haber cursado la asignatura de Informática II, no tenía conocimientos de Java, y se sentían desbordados. Otro grupo, minoritario, mostró su malestar por tener que utilizar JDeveloper en vez de una herramienta de software libre, como NetBeans. Resumimos brevemente los argumentos del profesor, y los acuerdos alcanzados. JDeveloper puede descargarse y utilizarse libremente para el desarrollo de aplicaciones. Se puede completar la funcionalidad de la herramienta incorporando a los programas desarrollados en ella librerías programadas en Java con cualquier entorno de desarrollo. No obstante, no cumple todos los requisitos del software libre: su código no es abierto, con lo que no puede ser estudiado, adaptado ni modificado para redistribuirlo. 6
La herramienta (JDeveloper) se eligió por su sencillez de uso. Genera automáticamente los componentes de la capa de negocios a partir de las tablas de la base de datos, liberando al programador de la tarea de escribir código para gestionar las transacciones. Por otro lado, favorece un estilo de desarrollo planificado y estructurado, al marcar claramente las distintas capas de la aplicación. La respuesta a las inquietudes planteadas fue flexibilizar las condiciones del proyecto para permitir el uso de distintas tecnologías. Se recalcó el paralelismo entre la situación vivida y la que experimentan las empresas a consecuencia del vertiginoso desarrollo tecnológico. A los equipos sin recursos (ni conocimientos de Java ni disponibilidad de tiempo para aprender) se les ofreció la posibilidad de utilizar Developer. Developer es una herramienta de ORACLE para cuya programación se requiere PL/SQL, lenguaje explicado en la primera mitad de cuatrimestre, y por tanto conocido por todos los estudiantes. El Servidor de Aplicaciones de ORACLE permite distribuir a través de la WEB los formularios e informes generados con Developer: el usuario accede a ellos a través de su navegador WEB, al que basta incorporar un plugin. A los equipos sin conocimientos de Java pero con disponibilidad de aprender se les entregó un manual de aprendizaje y se habilitaron sesiones de tutoría. Se dio a los equipos libertad a la hora de elegir herramienta. Se podía utilizar NetBeans, advirtiendo que, a falta de manual, el soporte por parte del profesor en el uso de la herramienta se restringiría a la ayuda a la resolución de problemas concretos de uso. Estas circunstancias enriquecieron notablemente el curso. Entre otras razones, permitieron hacer énfasis en dos de los objetivos planteados: adquirir destreza en el uso de distintos paradigmas de programación (declarativo procedural con PL/SQL, orientado a objetos con Java) y familiarizarse con la metodología seguida en el desarrollo de aplicaciones. En particular, los estudiantes vivieron la necesidad de planificar adecuadamente las fases del ciclo de vida de una aplicación: distinguir entre el proceso de entender el problema (análisis); proponer una solución general, independiente de ninguna herramienta específica, haciendo abstracción de las peculiaridades tecnológicas de las distintas herramientas (diseño); implementar la solución utilizando una herramienta determinada. Esto es esencial en ingeniería del software, pero muchos estudiantes no son conscientes de su relevancia. Muchos consideran que el diseño es una pérdida de tiempo, y hay quien lo percibe como un castigo (la obligación de aprender "un nuevo lenguaje de programación: el pseudocódigo", como definió un estudiante). Pues bien, las soluciones propuestas para cada módulo del proyecto debían ser comprendidas por todos los estudiantes, independientemente de en qué tecnología fueran "expertos". Surgió de modo natural el uso de diagramas de actividad UML para la fase de diseño. En la posterior exposición de cómo cada grupo había implementado la solución se puso de relieve que paradigmas distintos abordan un mismo problema con distintas mentalidades, y proporcionan soluciones distintas. 7
Para el próximo curso planteamos escribir una guía práctica de ingeniería del software: un cuaderno de bitácora de la construcción de la aplicación, en que se distingan claramente las fases y se indique el modo de implementar las soluciones utilizando herramientas distintas. 5.c Control de horas A todos los estudiantes se les pide que, cada vez que trabajan en el proyecto, rellenen una hoja de trabajo. En ella se especifican la persona o personas participantes en la sesión de trabajo, la fecha, la duración de la sesión y un breve resumen de la misma. Esta práctica es útil tanto para profesores como para estudiantes. Al profesor le ayuda a medir la complejidad de los proyectos de cara a futuros cursos: el trabajo en un proyecto no debe ir en detrimento de la dedicación al resto de asignaturas. Al estudiante le permite autoevaluar su capacidad y le será de ayuda al planificar su trabajo. 5.d Evaluación En el presente curso queremos afinar el método de evaluación del trabajo en proyectos, incorporando nuevos criterios. Los estudiantes que se acojan a la modalidad de evaluación continua deberán superar dos pruebas a lo largo del cuatrimestre, cada una de las cuales tendrá un peso del 30% respecto del total de la asignatura, siendo obligatorio alcanzar el 5 en cada una. La nota del proyecto tendrá un peso del 40% respecto del total de la asignatura. Se evaluará: o El correcto funcionamiento del módulo (2 puntos). o La calidad de la documentación (1 punto). o La calidad del trabajo en equipo (1 punto): se tendrán en cuenta la claridad y eficiencia en los seminarios, la exigibilidad individual (cada miembro del equipo debe demostrar en las entrevistas con el profesor que domina no sólo la parte del trabajo que le ha sido asignada, sino también la parte de sus compañeros) y la reflexión sobre el trabajo realizado (la autocrítica en la entrevista final: qué consideras que has aprendido del trabajo en equipo, qué errores habéis detectado en vuestro modo de trabajar...) 8
Referencias bibliográficas y citas 1. Agencia Nacional de Evaluación de la Calidad y Acreditación, Título de Grado en Matemáticas, marzo 2004. http://www.aneca.es/modal_eval/docs/conver_matematicas.pdf 2. Agencia Nacional de Evaluación de la Calidad y Acreditación, Encuesta de Inserción Laboral, marzo 2004. http://www.aneca.es/docs_trabajo/doc_trabajo.html 3. Esta idea es recurrente en los textos relacionados con la convergencia de Bolonia. Ver, por ejemplo, http://www.crue.org/mensajeconvesp.htm 4. ACM/IEEE CS Joint Task Force, Computing Curricula 2001, Final Report, December 2001, http://www.acm.org/sigcse/cc2001/15-12-2001.html 5. Gartner Group ( http://www.theinternetfoundation.org/y2k/presentation/tsld004.htm ) Standish Group, "The Chaos Report" ( http://www.standishgroup.com/sample_research/chaos_1994_1.php) 6. Professional Learning Systems, E.Domínguez et al., IADAT Journal of Advanced Technology on Education 1 (2004) 55-57 http://www.unizar.es/ccia/iadat.pdf 7. Professional Practice: An Experience in the Education Field, E.Domínguez et al., presentado en el congreso Internacional Conference on Education IADAT e-2004 (IADAT2004 Conference Proceedings Book págs 91-95) 8. Universidad y Empresa: Una Experiencia de Convergencia en el Contexto de un Máster, E.Domínguez et al., presentado en el Congreso Internacional de Docencia Universitaria e Innovación 2006 (CIDUI06) http://www.unizar.es/ccia/cidui06.pdf 9. Ver 'Nuestros Servicios/Casos de Éxito' en http://www.masterbdi.es Puede encontrarse información más detallada de algunos casos de éxito en las direcciones: o Proyecto INAGUA: http://noema2bis.unizar.es/masterbdi/articulospublicados/artinagua5.jpg o Proyecto CIMAS: http://noema2bis.unizar.es/masterbdi/articulospublicados/cimasbenasque.jpg 9