2 0 1 5jenui2015.uols.org/app/assets/files/JENUI2015_Actas_Simposio... · 2 0 1 5 Actas del...

2 0 1 5Actas del simposio-taller sobre estrategias y

herramientas para el aprendizaje y la evaluación

Andorra La Vella, 7 de julio de 2015

Organizadas por:

Universitat Oberta La Salle Asociación de Enseñantes Universitarios de la Informática

Responsables Académicos:José Manuel BadíaDavid López

EditoresXavier CanaletaAugust ClimentLluís Vicent

2 0 1 5

XXI Jornadas sobre la Enseñanza Universitaria de la Informática

Andorra La Vella7 de Julio

Organizan

Colaboran

Patrocinadores

Patrocinadores

Actas del simposio-taller sobre estrategias y herramientas para el aprendizaje

y la evaluaciónISBN: 978-99920-70-09-3

DL: AND.91-2015

José Manuel Badía, David López (Responsables Académicos)Xavier Canaleta, August Climent, Lluis Vicent (Editores)

I

Comités

Responsables académicos

José Manuel Badía, Universitat Jaume I de Castelló

David López, Universitat Politècnica de Catalunya

Comité directivo

El comité directivo de las «XXI Jornadas sobre la Enseñanza Universitaria de la Informática» está

formado por:

María Asunción Castaño Álvarez, Universitat Jaume I de Castelló. Presidenta

Marta E. Barria Martínez, Universidad de Valparaíso. Chile

Patricia Miriam Borensztejn, Universidad de Buenos Aires. Argentina

Agustín Cernuda del Río, Universidad de Oviedo

César Collazos, Universidad del Cauca. Colombia

Martha Dunia, Ciudad Universitaria José Antonio Echeverría. Cuba

Juan José Escribano Otero, Universidad Europea de Madrid

Marcela Genero Bocco, Universidad de Castilla-La Mancha

John Paul Hempel Lima, Universidade de São Paulo (USP). Brasil

Inés Jacob Taquet, Universidad de Deusto

David López, Universitat Politècnica de Catalunya

Eva Millán, Universidad de Málaga

Joe Miró Julià, Universitat de les Illes Balears

Fermín Sánchez Carracedo, Universitat Politècnica de Catalunya

Martin Solari, Universidad ORT. Uruguay

Edmundo Tovar, representante del Capítulo español de la Sociedad de educación de IEEE

Comité organizador

El comité organizador de las «XXI Jornadas sobre la Enseñanza Universitaria de la Informática» está

formado por:

Xavier Canaleta, Universitat Oberta La Salle (Presidente)

Lluís Vicent, Universitat Oberta La Salle. (Coordinador)

August Climent, Universitat Oberta La Salle. (Coordinador)

Marina Abián, Universitat Oberta La Salle

David Fonseca, Universitat Oberta La Salle

Francesc Xavier Francesch, Universitat Oberta La Salle

Javier Higueras, Universitat Oberta La Salle

José Antonio Montero, Universitat Oberta La Salle

Joan Navarro, Universitat Oberta La Salle

Miquel Ribó, Universitat Oberta La Salle

Laia Sánchez, Universitat Oberta La Salle

Marc Segarra, Universitat Oberta La Salle

Sofía Sevillano, Universitat Ramon Llull

Xavi Solé, Universitat Oberta La Salle

David Vernet, Universitat Oberta La Salle

II

Presentación El simposio-taller previo a las JENUI, en su formato actual de presentacion de trabajos y discusion, nacio

en 2011 con las JENUI de Sevilla. El objetivo de esta actividad, como el de las Jornadas en las que se

engloba, es favorecer el contacto e intercambio de experiencias docentes entre profesores universitarios

de Informatica. El taller ofrece un foro adicional al propio de las JENUI: un lugar donde presentar

trabajos en desarrollo o que por su naturaleza no encajan en JENUI, pero que resultan muy interesantes

para discutir con los colegas, recibiendo realimentacion, ideas y animos (que a veces hacen falta en este

entorno en el que nos movemos, especialmente en los tiempos que corren). Las ponencias presentadas serviran como base para una discusion entre los asistentes para el intercambio

de ideas y experiencias. A diferencia de un simposio tradicional, se prima la discusion y reflexion en

grupo sobre la presentacion de ponencias. El simposio-taller se realiza tradicionalmente la tarde anterior al inicio de las JENUI y, al igual que estas,

esta promovido por la Asociacion de Ensenantes Universitarios de Informatica (AENUI). La primera

edicion, celebrada conjuntamente con las JENUI 2011 de Sevilla conto con Joe Miro (Universitat de les

Illes Balears) y Juan Jose Escribano (Universidad Europea de Madrid) como responsables academicos,

presentandose 14 trabajos. La segunda edicion, celebrada en Ciudad Real en 2012 y con Joe Miro y David

Lopez (Universitat Politecnica de Catalunya) como responsables academicos, conto con 11 trabajos

presentados. La tercera edicion, celebrada en Castellon en 2013 y con Belen Vaquerizo (Universidad de

Burgos) y David Lopez como responsables academicos, conto tambien con 11 trabajos. La cuarta edicion

se celebró en Oviedo en 2014 con David López y José Manuel Badía (Universitat Jaume I de Castelló) y

contó con 8 trabajos presentados. Este ano, el taller se engloba en las JENUI que organiza La Salle Open University de Andorra. Tenemos

6 interesantes trabajos que van a servir como base para una fructífera discusión en la que todos podremos

aprender de nuestra experiencia y reflexion compartidas. Esperamos que los disfruteis.

José Manuel Badía y David López Responsables académicos

III

Índice

Comité del programa I

Presentación II

Simposio-taller sobre estrategias y herramientas para el aprendizaje y la evaluación 1

Análisis de los resultados de la implantación ABP en un Grado de Ingeniería Informática ................ 2

José Ángel Vadillo, Imanol Usandizaga, Alfredo Goñi y José Miguel Blanco

Diseño de una propuesta de proyecto transversal para la especialidad de Ingeniería del Software

del Grado en Ingeniería Informática .......................................................................................... 10

José Miguel Blanco, Alfredo Goñi, Jon Iturrioz, Imanol Usandizaga y José Ángel Vadillo

La enseñanza de la Ciberseguridad en el Grado en Ingeniería Informática ....................................... 18

José Ant. Gómez Hernández

Evaluación mediante encuestas de la importancia de disponer de un repositorio de código

individual, público y compartido para los estudiantes de Grado de Informática en la región de

las Islas Baleares ....................................................................................................................... 24

Carlos Guerrero Judit Jiménez Isaac Lera Antoni Jaume-i-Capó y Carlos Juiz

Cambio a metodología de clase inversa en una asignatura obligatoria .............................................. 32

Sílvia Terrasa Barrena y Gabriela Andreu García

Organizando la docencia y el aprendizaje con Symbaloo .................................................................. 38

Adelaida Delgado Domínguez

Simposio-taller sobre estrategias y

herramientas para el aprendizaje y la

evaluación

Actas del simposio-taller sobre estrategias y herramientas para el aprendizaje y la evaluación

Andorra La Vella, 7 de julio 2015 ISBN: 978-99920-70-09-3

1

Análisis de los resultados de la implantación ABP en un Grado de Ingeniería Informática

José Ángel Vadillo, Imanol Usandizaga, Alfredo Goñi y José Miguel Blanco Dpto. de Lenguajes y Sistemas Informáticos

Universidad del País Vasco / Euskal Herriko Unibertsitatea (UPV/EHU) Donostia-San Sebastián

(vadillo, imanol.usandizaga, alfredo, josemiguel.blanco)@ehu.es

Resumen Tras cuatro cursos académicos de implantación de metodologías activas en primer y segundo curso del Grado en Ingeniería Informática, hemos recogido la opinión tanto de los alumnos como de los profeso-res implicados en dicha implantación. En este artículo mostramos el plan de implantación que se ha seguido y el resultado del análisis realizado en base a las respuestas recibidas por los participantes. Podemos concluir que se aprecia un interés en continuar haciendo uso de metodologías activas en el tercer curso, concretamente en la especialidad de Ingeniería del Software, aunque también sería aplicable en las otras dos especialidades de la titulación, Ingeniería de Computadores y Computa-ción.

Abstract During the last four academic years, several sub-jects corresponding to the first and second year of the Degree in Computer Science have been taught by applying active methodologies according to a previously established implementation plan. Last year, we gathered information about this experience from the teachers and students involved in those subjects. In this article, we show the implementa-tion plan followed and the obtained results that reflect the opinion of students and teachers. By analyzing these results, we can conclude that active methodologies should also be applied in the sub-jects corresponding to the Software Engineering major, in the third year. However, this could be also true for the other majors: Computer Engineering and Computing.

Palabras clave Metodologías activas, ABP, Análisis de resultados.

1. Introducción Este trabajo se centra en presentar un análisis de

la opinión de los estudiantes y profesores/as respec-

to a la implantación ABP gradual en cuatro asigna-turas del Grado en Ingeniería del Software. El análisis incluye, por un lado, la reflexión del profe-sorado implicado en la docencia de asignaturas que usan ABP de primer y segundo curso durante varios años y, por otro, la síntesis de la opinión de dos promociones distintas de estudiantes. Por un lado 44 estudiantes de tercer curso que han vivido la implantación en sus dos primeros cursos y por otro estudiantes de segundo curso en este curso acadé-mico, que han respondido a las encuestas sobre valoración de la metodología ABP. Las lecciones aprendidas tras varios cursos de implantación del Grado y los resultados obtenidos en este estudio orientan las bases de propuestas futuras para conse-guir implantar estas metodologías en los cuatro cursos de la titulación, incluso considerando propo-ner un único proyecto que abarque a diferentes asignaturas [9]. Propuestas que deben ser sosteni-bles en el tiempo, y viables, considerando las múl-tiples restricciones que conlleva la organización docente en términos de calendario, horarios, coor-dinación y sistemas de evaluación.

2. Alcance del estudio Para centrar el objeto de este estudio mostramos

en el Cuadro 1 el plan de estudios del Grado en Ingeniería Informática de nuestro centro. En él se puede observar que hay dos cursos comunes: el primero y el segundo. Es en el tercero donde hay que elegir una especialidad entre tres, a saber: Ingeniería del Software, Ingeniería de Computado-res y Computación.

El cuarto curso está dedicado al estudio de asig-naturas optativas y al desarrollo del proyecto fin de grado. En cada curso se deben completar 60 crédi-tos, haciendo así entonces un total de 240 créditos.

Así mismo, el centro consideró conveniente para la formación del alumnado la aplicación de metodo-logías activas - en concreto la metodología ABP - y decidió que tanto en primero como en segundo curso se impartiera una asignatura por cuatrimestre utilizando esta metodología [6].



2

Cuadro 1: Estructura del Plan de Estudios

Todas las asignaturas escogidas han tenido que realizar un diseño de las mismas guiado y aprobado oficialmente por el Servicio de Asesoramiento Educativo (SAE) de la UPV/EHU mediante su programa de formación del profesorado en metodo-logías activas (ERAGIN). Las asignaturas en con-creto son las siguientes:

• Fundamentos de Tecnología de Computado-res (FTC). Asignatura del área de Arquitectura y Tecnología de Computadores (ATC) que es cursada aproximadamente por 80 estudiantes y que presenta un porcentaje de aprobados del 50%. Los grupos que realizan el proyecto ABP son de tres personas y se planifica un trabajo no presencial por alumno de entre 40 y 60 horas

• Estructura de Computadores (EC). Asigna-tura de ATC con un mismo número aproxima-do de alumnos e idéntico porcentaje de apro-bados que la anterior. El tamaño de los grupos ABP es variable entre 3 y 5 y el trabajo pre-sencial estimado entre 40 y 60 horas por estu-diante.

• Arquitectura de Computadores (AC). En es-ta asignatura no se aplica ABP en todos los grupos1, por tanto el número de alumnos es menor, aproximadamente 50. Los grupos prác-ticos son de 3 personas con un trabajo no pre-sencial por estudiante sobre 50 horas [1].

1 En segundo hay tres grupos separados por idioma: castellano, euskera e inglés.

• Ingeniería del Software (IS). Se aplica ABP en todos los grupos de segundo curso. Aproximadamente a 80 alumnos y con un 65% de aprobados. Los grupos son de 3 estudiantes salvo excepciones donde se intenta que sean de 4 y no de dos. El número de horas estimado de trabajo no presencial por persona es de 60 horas [5].

3. Plan de implantación Como se ha comentado anteriormente la Facultad

de Informática de San Sebastián (UPV/EHU), diseñó un plan de implantación consistente en aplicar ABP en una asignatura por semestre en los dos primeros cursos de la titulación.

En el curso 2010-11, se animó al profesorado a formarse en metodologías activas dentro del plan ERAGIN2 de la UPV/EHU. Este plan está orientado a realizar un diseño tutorizado de la asignatura aplicando ABP para implantarlo en el siguiente curso.

De esta manera en el curso 2011-12 se aplicó ABP en dos asignaturas de primer curso:

• Fundamentos de Tecnología de Computado-res (Primer Curso, Primer Cuatrimestre) y

• Estructura de Computadores (Primer Curso, Segundo Cuatrimestre).

2 Este plan de formación lleva vigente durante seis cursos, comenzando en el curso académico 2009-10



3

Durante este curso, diferentes profesores de asig-naturas de segundo curso entramos en el plan de formación ERAGIN para el diseño ABP de dos nuevas asignaturas.

En el curso 2012-13 se implantó ABP en dos asignaturas más en este caso de segundo curso:

• Arquitectura de Computadores (Segundo Cur-so, Primer Cuatrimestre).

• Ingeniería del Software (Segundo Curso, Se-gundo Cuatrimestre).

Durante los cursos, 2013-14 y 2014-15 (el actual) se ha dado continuidad a dicha implantación. La razón principal para esta continuidad es que pesa más la opinión favorable3 de los estudiantes que la carga extra de trabajo que supone tanto para los alumnos como para los profesores.

4. Resultados y análisis del estudio

Para realizar la valoración de la adecuación me-todológica en diferentes asignaturas del plan de estudios del Grado en Informática se han contrasta-do tres tipos diferentes de fuentes de datos:

• Encuesta realizada a una población de 44 estu-diantes de tercer curso. Estos estudiantes en su mayoría han cursado las cuatro asignaturas mencionadas en el capítulo anterior, en su mo-dalidad de ABP4. Esta encuesta ha sido dise-ñada y pasada por los autores de este artículo en asignaturas donde la mayoría de los asisten-tes están matriculados en la especialidad de Ingeniería del Software.

• Encuesta sobre ABP proporcionada por el Ser-vicio de Asesoramiento Educativo (SAE) de la UPV/EHU.

• Encuestas de satisfacción de los estudiantes sobre la docencia de sus profesores. Estas en-cuestas son de pase obligado dentro de la UPV/EHU. Por razones de confidencialidad sólo disponemos de los datos de una de las cuatro asignaturas implantadas: Ingeniería del Software de segundo curso.

4.1. Resultados de la encuesta a los alumnos de la especialidad de Ingeniería del Software

Estos alumnos cursaron las cuatro asignaturas ya citadas, en sus dos cursos anteriores, siguiendo la

3 Se realiza cada curso académico una encuesta sobre la adecuación de las metodologías activas a las asignaturas en las que se aplican. 4 En nuestro centro no es obligatorio cursar las asignaturas en evaluación continua. Los estudiante spueden elegir entre global y continua en cada una de las asignaturas que cursan.

metodología ABP. Cabe mencionar que, aunque es opcional el cursarlas de esta manera, puesto que siempre es posible que decidan ser evaluados mediante una prueba de conjunto final, la mayoría de ellos optan por la metodología ABP.

Además de la valoración de cada asignatura y

una valoración general se les hicieron preguntas sobre la implantación de la metodología en cada asignatura (alumnos por grupo, horas de dedica-ción, porcentaje de la nota obtenido de esta manera) con el objetivo de que sus respuestas nos ayudaran a hacernos una idea más exacta de cuál fue su experiencia con el uso de las metodologías ABP. Para valorar cada asignatura se les formuló la siguiente pregunta:

“Teniendo en cuenta en su conjunto, aprendi-

zaje, dedicación y calificación, valora entre 1 y 5 el uso de la metodología ABP en la asignatura --nombre de la asignatura --.”

Obteniendo los siguientes resultados medios:

ASIGNATURA MEDIA

Fundamentos de Tecnología de Computadores (FTC) 3,9

Estructura de Computadores (EC) 3,7

Arquitectura de Computadores (AC) 3,7

Ingeniería del Software (IS) 4,1

Cuadro 2: Valoración media ABP por asignatura

La distribución de las puntuaciones por asignatu-ras se puede apreciar en las siguientes figuras.

Figura 1: Valoración FTC



4

Figura 2: Valoración AC

Figura 3: Valoración EC

Figura 4: Valoración IS

Aunque los valores medios son similares, las dis-

tribuciones de sus valoraciones son bastante dife-rentes. Pero en todos los casos la suma de valora-ciones 4 y 5 es muy superior a la suma de valora-ciones 1 y 2.

Para poder valorar su satisfacción global, es de-

cir, fuera del contexto de una asignatura se les realizó la siguiente pregunta:

“Indica el grado de satisfacción general en el

uso de ABP en la docencia del Grado en Ingenie-ría Informática”

Como resultado se obtuvo un valor medio de

3,81 sobre 5. Valor algo superior que la media de los resultados de las cuatro asignaturas que es 3,77

pero que resulta bastante consecuente con los resultados obtenidos en cada una de las asignaturas. El detalle de las respuestas lo podemos ver en la siguiente figura:

Figura 5: Valoración global

Para valorar su predisposición a seguir cursando

asignaturas bajo la metodología ABP y contrastar los resultados de los gráficos anteriores se formuló la siguiente pregunta:

“Se está analizando la posibilidad de implan-

tar ABP en una o más asignaturas de la línea de Ingeniería del Software. Señala, de entre las siguientes afirmaciones, la que refleja tu opi-nión:

• Preferiría que no se utilizara esta metodolo-gía.

• Me gustaría que hubiera como máximo una asignatura por cuatrimestre.

• Me gustaría que hubiera como mínimo una por cuatrimestre.

• Cuantas más mejor.”

Obteniendo los siguientes resultados, por cada

una de las opciones posibles (cuadro 3): Preferiría que no se utilizara esta metodología 3 7%

Me gustaría que hubiera como máximo una asignatura por cuatrimestre

13 30%

Me gustaría que hubiera como mínimo una por cuatrimestre 19 42%

Cuantas más mejor 9 21%

Cuadro3: Resultados de opinión sobre futura im-plantación ABP

En este caso los resultados también son claros, la mayoría de los estudiantes desea que esta metodo-logía se implante en el curso tercero e incluso en más de una asignatura por cuatrimestre. En realidad



5

ya estamos trabajando en esta línea. En concreto, estamos diseñando una propuesta ABP que englobe a tres asignaturas de la especialidad en el primer cuatrimestre. Ya hemos realizado durante dos cursos experiencias piloto de carácter no obligato-rio. Sobre estas experiencias se va a presentar otro artículo en el taller de esta edición (JENUI’15)

4.2. Encuestas PBL del S.A.E.

Al final de cada curso se solicita a los alumnos rellenar una encuesta cuyo diseño se ha realizado por el S.A.E. de la UPV/EHU. En las siguientes figuras se muestran los resultados obtenidos en dos asignaturas de segundo curso: Ingeniería del Soft-ware y Arquitectura de Computadores [1], durante los tres últimos cursos lectivos: 2012-13, 2013-14 y 2014-15.

Las preguntas en las que se basan estos resulta-dos son:

• Esta metodología en comparación con un mo-delo más tradicional, te ha ayudado a aprender Menos/Igual/Más/Mucho Más. (Fig.8)

• ¿La orientación proporcionada por los profeso-res ha satisfecho tus necesidades? Mu-cho/Bastante/Suficiente/Poco (Fig.9)

• Valora globalmente el grado de satisfacción con este modelo de aprendizaje. Muy Satisfe-cho/Bastante Satisfecho/Poco/Nada(Fig.10)

• ¿Si pudieras, volverías a repetir la experiencia? Si/No (Fig.11)

Cabe destacar que en casi todos los cursos, en ambas asignaturas y para todas las preguntas, la suma de los porcentajes de respuestas con satisfac-ción alta o muy alta es superior al 50%, en algunos casos llegando a superar el 90%. Sólo hay una situación en Ingeniería del Software en el curso 2012-13 donde la orientación dada por los profeso-res se valoró como suficiente o escasa por un 66% de los estudiantes.

Si analizamos su valoración sobre el aprendizaje como media han respondido mucho más y más el 71% de los estudiantes.

Sobre su satisfacción general, el 85% de los es-tudiantes, como media, están muy satisfechos o bastante satisfechos.

Finalmente, el 83% repetiría la experiencia. Estos datos realmente animan a pensar que la implanta-ción ha sido muy bien aceptada y además sus resultados académicos como se presentó en JE-NUI’14 [5], han mejorado.

4.3. Encuestas de opinión de la UPV/EHU

Para tener una tercera dimensión en este estudio vamos a utilizar las encuestas institucionales de la UPV/EHU. Todos los cursos académicos se pasa

una encuesta por grupo y asignatura para conocer la opinión de los estudiantes sobre la docencia de sus profesores. Aparte de las preguntas más típicas de este tipo de encuestas (asiste regularmente a clase, es un buen profesor/a, etc., se pide que valoren el interés por la asignatura antes y después de haber sido cursada. Las figuras 6 y 7 muestran los valores obtenidos en estos últimos apartados durante los cursos 2012-13 y 2013-14 en la asignatura Ingenie-ría del Software.

3,7%7,4%

25,9%

51,9%

11,1%

0,0%

7,4%

14,8%

59,0%

18,8%

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

70,0%

Muy Bajo Bajo Medio Alto Muy Alto

Interés Inicial 2013

Interés final 2013

Fig. 6 Interés por la asignatura antes y después de cursarla en 2013

0,0%

11,0%

47,0%

32,0%

10,0%

0,0%

10,0%

16,0%

58,0%

16,0%

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

70,0%

Muy Bajo Bajo Medio Alto Muy Alto

Interés Inicial 2014

Interés final 2014

Fig. 7 Interés por la asignatura antes y después de cursarla en 2014

Lo más destacable es, que no sólo se mantiene el interés inicial, sino que se mejora en los valores altos (alto y muy alto). En el curso 2012-13 se pasó del 63% al 79%. Y en el curso siguiente del 42% al 74%.

Podemos interpretar como consecuencia de estos resultados que el contenido de la asignatura y sus actividades relacionadas, han servido como alicien-te y motivación de los estudiantes para mejorar su percepción sobre esta asignatura.

Los resultados de los tres tipos de indicadores,

con grupos de perfiles de estudiantes diferentes5 muestran resultados satisfactorios bastante similares en cuanto a porcentajes de valoraciones positivas.

5 Se han recogido opiniones de estudiantes de tres promociones diferentes.



6

11%

22%

39%

28%

4%

19%

52%

26%

0%7%

44%

48%

9%

15%

54%

15%

17%

27%

42%

14%

28%

11%

39%

22%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

IS2013 IS2014 IS 2015 AC2013 AC2014 AC2015

Mucho mas

Mas

Igual

Menos

Fig. 8 Valoración sobre el aprendizaje con ABP

25,6%

41,9%

27,9%

4,7%

11,5%

36,5%

42,3%

9,6%

3,7%

25,9%

40,7%

29,6%

4,3%

34,0%

32,0%

29,7%

7,0%

41,3%

34,5%

17,2%

16,0%

28,0%

28,0%

28,0%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

IS2013 IS2014 IS 2015 AC2013 AC2014 AC2015

Mucho

Bastante

Suficiente

Poco

Fig. 9 Valoración sobre orientación y asistencia de los docentes

0,0%11,0%

61,0%

27,0%

0,0%11,0%

67,0%

22,0%

0,0%7,4%

44,4%

48,2%

2,1%2,2%

72,3%

23,4%

3,4%

13,8%

68,9%

13,9%

6,0%

28,0%

55,0%

11,0%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

IS2013 IS2014 IS 2015 AC2013 AC2014 AC2015

Muy Sat.

Bastante

Poco Sat.

Nada Sat.

Fig. 10 Valoración Global ABP



7

84,0%

16,0%

81,0%

19,0%

92,6%

7,4%

96%

4%

78%

22%

73%

27%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

IS2013 IS2014 IS 2015 AC2013 AC2014 AC2015

NO

SI

Fig. 11 ¿Repetirías la experiencia?

5. Valoraciones generales Además de preguntas cuantitativas, se solicitó a

los estudiantes que valoraran a nivel cualitativo lo mejor y lo peor de sus experiencias con ABP. Res-pecto a la valoración de los profesores, durante este curso académico se organizaron unas jornadas en el centro para presentar y debatir precisamente la implantación ABP objeto de este artículo. De este debate salieron algunas conclusiones que resumi-remos también en este capítulo.

Aspectos valorados positivamente por los estudiantes

Lo que más positivamente valoraron fue:

• la posibilidad de realizar proyectos en equipo,

• la búsqueda autónoma de información,

• la presentación de los proyectos de forma pú-blica en el ámbito del grupo de clase.

• el hecho de que los proyectos se parecen más a proyectos reales en el ámbito laboral.

Aspectos valorados negativamente por los estudiantes

También comentaron aquellos aspectos que no les gustaron o no los encontraron necesarios. Con-cretamente las actividades tipo puzzle y tipo póster no les parecieron rentables en la relación tiempo dedicado / aprendizaje. Otros frentes abiertos fue-ron los relativos a la evaluación de grupo frente a la evaluación de cada estudiante. Algunos consideran que no se valora adecuadamente el esfuerzo perso-nal. Otros comentarios pero más minoritarios atacan a la propia filosofía ABP, autonomía en el aprendizaje en lugar de clases magistrales. Búsque-

da autónoma en lugar de listados de referencias bibliográficas, etc.

Aspectos valorados positivamente por los profesores

Hay un consenso a valorar positivamente el ABP en lo que respecta a las competencias transversales. En la mayoría de los casos los proyectos son docu-mentados, se desarrollan en equipos de tres o cuatro personas y además se deben presentar en el aula delante de sus compañeros y profesores. También es mayoritaria la opinión de que se afianzan mejor los conocimientos adquiridos, se reduce el absen-tismo y se mejoran los resultados académicos. En [5] se comenta con más detalle cómo en la asigna-tura de Ingeniería del Software ha disminuido la tasa de absentismo del 50 al 33%. Los resultados académicos han mejorado pero no sólo en sus calificaciones sino en la calidad de los proyectos desarrollados con respecto a cursos con metodolo-gías tradicionales basadas en clases magistrales y laboratorios.

Aspectos valorados negativamente por los profesores

Sin embargo también hay aspectos negativos o mejorables. Estas metodologías suponen una carga de trabajo bastante mayor para poder dar un feed-back a tiempo. La falta de este feed-back es motivo de fracaso en estas metodologías. Desde el punto de vista de coordinación horizontal de los cursos es necesario controlar que la dedicación a los proyec-tos no se solape con el trabajo no presencial de otras asignaturas del mismo curso y mismo cuatri-mestre. Esta es una de las principales razones por las que la implantación no pretende abarcar más que una asignatura por cuatrimestre y curso.



8

6. Conclusiones En este artículo se ha descrito el proceso de des-

pliegue de las metodologías activas, concretamente ABP, en el Grado en Ingeniería Informática que imparte la Facultad de Informática de la UPV/EHU. Además una vez consolidado dicho despliegue se han analizado las opiniones de los estudiantes mediante tres diferentes herramientas:

• Encuesta contestada por un grupo de estudian-tes de la especialidad de Ingeniería del Softwa-re de tercer curso. Estos estudiantes han vivido el proceso de despliegue.

• Encuesta sobre ABP del Servicio de Asesora-miento Educativo de la UPV/EHU. Contestada por tres promociones de alumnos.

• Encuesta de opinión institucional de la UPV/EHU.

Tras analizar los resultados obtenidos podemos extraer las siguientes conclusiones: 1) tanto los estudiantes como profesores valoran positivamente la implantación de metodologías activas; 2) los alumnos mayoritariamente están a favor de implan-tarlas en tercer curso y 3) los resultados académicos y por tanto la calidad de los entregables han mejo-rado considerablemente.

Esto ha supuesto un acicate para diseñar la im-plantación de un proyecto ABP de forma transversal en tres asignaturas de tercer curso que se imparten en el mismo cuatrimestre. El análisis de los pro-blemas y posibles soluciones se presenta en [9].

Referencias

[1] Olatz Arbelaitz, José I. Martín y Javier Muguerza: Analysis of Introducing Active Learning Methodologies in a Basic Computer Architecture Course.IEEE Transactions on Education. 01/2014; 58(2):1-1.

[2] Cristina Barrado, Raúl Cuadrado, Luis Del-gado, Fernando Mellibovsky, Enric Pastor,

Marc Pérez, Xavier Prats, Jose I. Rojas, Pa-blo Royo, Miguel Valero: Una experiencia de unificación de asignaturas para desplegar ABP (y las quejas que originó). En ReVisión, vol. 6, núm. 2, Septiembre de 2013.

[3] Blanco J.M., Usandizaga, I., Jaime,A.: Ges-tión de Proyectos en el Grado en Ingeniería Informática: del ABP a la espiral de proyec-tos. ReVisión, vol. 7, núm. 3, septiembre de 2014.

[4] María José García García, Juan José Escriba-no Otero y Ma Cruz Gaya López: Experiencia de aplicación de ABP al Grado de Ingeniería Informática. En Actas de las XX Jornadas de Enseñanza Universitaria de Informática, Je-nui 2014, pp. 125-132, Oviedo, julio de 2014.

[5] Goñi A., Ibáñez J., Iturrioz, J. y Vadillo J.A.: Aprendizaje Basado en Proyectos usando metodologías ágiles para una asignatura bási-ca de Ingeniería del Software. En Actas de las XX Jornadas de Enseñanza Universitaria de Informática, Jenui 2014, pp. 133 – 140, Oviedo, julio 2014.

[6] Montse Maritxalar y José Miguel Blanco: Proyecto Docente en la Facultad de Informá-tica de la Universidad del País Vasco. En Ac-tas de las Jornadas de Intercambio Docente, JIED-2013, pp. 27-34. Servicio Editorial de la UPV/EHU, 2013.

[7] Joe Miró Julià: De las creencias a los princi-pios: ejemplo de diseño de una asignatura. Revisión, vol. 6, núm. 2, septiembre de 2013.

[8] Miguel Valero-García: ABP (Piénsalo Bien antes de Liarte). ReVisión, vol. 5, núm. 2, Di-ciembre de 2012.

[9] José Miguel Blanco, Alfredo Goñi, Jon Itu-rrioz, Imanol Usandizaga, José Ángel Vadi-llo: Diseño de una propuesta de proyecto transversal para la especialidad de Ingeniería del Software del Grado en Ingeniería Infor-mática. En Actas de las XXI Jornadas de En-señanza Universitaria de Informática, Jenui 2015, Andorra la Vella, julio 2015.



9

Diseño de una propuesta de proyecto transversal para la especialidad de Ingeniería del Software del Grado en

Ingeniería Informática

José Miguel Blanco, Alfredo Goñi, Jon Iturrioz, Imanol Usandizaga, José Ángel Vadillo Dpto. de Lenguajes y Sistemas Informáticos

Universidad del País Vasco / Euskal Herriko Unibertsitatea (UPV/EHU) Donostia-San Sebastián

(josemiguel.blanco, alfredo, jon.iturrioz, imanol.usandizaga, vadillo)@ehu.es

Resumen El artículo presenta los resultados de la puesta en marcha de una experiencia piloto de realización de proyectos transversales enfocados a la aplicación integrada de los contenidos de las asignaturas de la especialidad Ingeniería del Software del Grado en Ingeniería Informática. El trabajo revisa las limita-ciones que condicionan el diseño, así como el análisis de los riesgos y las oportunidades. Se analiza la propuesta experimentada y los resultados obtenidos durante dos cursos, para acabar justifi-cando la continuidad y las líneas de mejora futuras.

Abstract In this paper we present the results of the imple-mentation of a pilot project whose goal was that students enrolled in several subjects belonging to the Software Engineering major of the Computer Science degree developed transversal projects. We revise the restrictions that have influenced the design as well as the risk analysis and opportunities of this experience. Moreover, we analyze the pro-posal and the results obtained during these two years and justify the continuation of this project and future lines to improve it.

Palabras clave Ingeniería del Software, metodologías activas, proyectos transversales.

1. Introducción El despliegue del proceso de implantación de la

nueva titulación de Grado en Ingeniería Informática en la UPV/EHU ha incluido, entre otras novedades, la aparición de las especialidades. Las especialida-des, relacionadas con agrupaciones modulares de, al menos, 48 créditos, dan continuidad a la formación básica y común de la ingeniería informática. Estas especialidades permiten al estudiante orientar su

formación hacia diferentes áreas de la informática, de forma que puede profundizar en una u otra, en función de sus intereses.

También ha sido muy común en las implantacio-nes de lo nuevos grados apostar por las metodologí-as activas, entre las que, en el caso de la ingeniería informática, han mantenido un protagonismo im-portante las aproximaciones basadas en proyectos (ABP). Se ha tratado de aumentar la capacidad de los estudiantes para resolver problemas complejos en contextos cambiantes, trabajando en equipo y aplicando conocimientos, técnicas y herramientas avanzadas [1,2,4,5,9,11].

Entre otras iniciativas [6], en la Facultad de In-formática de Donostia-San Sebastián (FISS), se ha querido probar la viabilidad de dar continuidad a la buena acogida que entre los estudiantes ha tenido, en particular en el ámbito de la enseñanza de la Ingeniería del Software, el aprendizaje basado en proyectos [1,3,5,10]. Para ello, de acuerdo con el centro, responsable de la coordinación del grado, se ha implantado de forma experimental durante los cursos 13-14 y 14-15 una propuesta de proyecto transversal en la especialidad de Ingeniería del Software. Este trabajo presenta los principios de diseño que han enmarcado el desarrollo de una experiencia que ha implicado a cuatro asignaturas de la especialidad de Ingeniería del Software, que se imparte en el tercer curso, en el Grado de Inge-niería Informática.

La reflexión recogida en este documento se inicia presentando el contexto académico de la experien-cia y se estructura en seis apartados más. Se co-mienza revisando las limitaciones que han sido consideradas, los riesgos y las oportunidades. Posteriormente se presenta la propuesta experimen-tada y cómo se ha implantado durante dos cursos. Por último, se discuten los resultados obtenidos, como paso previo a la presentación de las líneas de actuación futuras.



10

2. Contexto académico de la especialidad de Ingeniería del Software

En el Cuadro 1 se sintetiza el plan de estudios del Grado en Ingeniería Informática de la FISS. En él se puede observar que los dos primeros cursos están conformados por contenidos obligatorios y comu-nes para todos los estudiantes. Es en tercero donde deben elegir una especialidad entre tres posibilida-des, a saber: Ingeniería del Software, Ingeniería de Computadores o Computación. El cuarto curso está dedicado al estudio de asignaturas optativas, estan-cias en programas de intercambio, prácticas en empresa y al desarrollo del proyecto de fin de grado. En cada curso se deben completar 60 crédi-tos, hasta alcanzar un total de 240 créditos.

Cuadro 1: Estructura del Plan de Estudios

A continuación presentaremos las asignaturas de

la especialidad de Ingeniería del Software y nos centraremos1 en las que se imparten en el primer cuatrimestre. Esta especialidad comprende ocho asignaturas nucleares, divididas en dos cuatrimes-tres (ver cuadro 2). Para el conjunto del módulo están definidas2 unas competencias específicas a desarrollar, enunciadas de forma resumida, son:

(1) Solucionar problemas de integración entre estándares y tecnologías. (2) Identificar, evaluar y gestionar riesgos. (3) Identificar y analizar problemas y diseñar, desarrollar, implementar, verificar y documentar soluciones software. (4) Desarrollar, mantener y evaluar servicios y sistemas software. (5) Diseñar soluciones apropiadas en uno o más dominios de aplicación utilizando métodos de la

1 Nuestra propuesta relativa a proponer un proyecto transversal está pensada precisamente sobre las cuatro asignaturas de la especialidad que se imparten en ese primer cuatrimestre. 2 Resolución de 8 de junio de 2009, de la Secretaría General de Universidades por el que se establecen recomendaciones para la propuesta por las universidades de memorias de solicitud de títulos oficiales en los ámbitos de la Ingeniería Informática.

ingeniería del software que integren aspectos éti-cos, sociales, legales y económicos. (6) Valorar las necesidades del cliente y especifi-car los requisitos software para satisfacer estas necesidades

Si nos centramos en las asignaturas del primer cuatrimestre, objeto de nuestra posterior propuesta, éstas deben, explícitamente, contribuir al desarrollo de una parte del total de las competencias mencio-nadas, concretamente las competencias 1, 3, 4 y 6.

Como se puede apreciar en el Cuadro 2, en el primer cuatrimestre hay una asignatura, Ingeniería del Software II, que cubre aspectos relacionados con prácticamente todo el ciclo de vida de desarro-llo de software (diseño, implementación, pruebas de software y mantenimiento). En concreto. se profun-diza en el diseño, estudiando diferentes patrones (como el modelo-vista-controlador MVC) y en la implementación utilizando frameworks. Interac-ción Persona Computador se centra en la capa de presentación o vista. Sistemas Web trabaja tanto la lógica de negocio (aplicaciones de servidor) como las tecnologías web. Por último, Diseño de Bases de Datos desarrolla los aspectos de la capa de datos o modelo de datos. En cada una de ellas se piden a los estudiantes trabajos prácticos que tienen cierto grado de solapamiento con el resto de las asignatu-ras, normalmente con requisitos, dominios y tecno-logías diferentes. En todo caso, estos trabajos están orientados a la comprensión y profundización de los conceptos, técnicas y herramientas propias de cada asignatura.

Cuadro 2: Módulo de Ingeniería del Software

Parece claro, a priori, que las cuatro asignaturas

del primer cuatrimestre de la especialidad tienen la posibilidad de colaborar conjuntamente en el desa-rrollo de una aplicación web de una cierta dimen-sión, en que el problema a resolver sea el elemento tractor y los aspectos tratados en cada una de las asignaturas se conviertan en recursos al servicio de la resolución del reto-problema. Pero del dicho al hecho hay mucho trecho y hemos preferido pensar-lo bien [7,11] antes de liarnos… o liarla [2,8].

Como ya se ha mencionado anteriormente, la in-troducción coordinada y sistemática de las metodo-logías activas en el Grado en Ingeniería Informática de la FISS ha incluido diversas actividades de evaluación y anáĺisis [1,5,6,10]. De esas reflexiones se ha extraído que, con carácter mayoritario, tanto los estudiantes como los profesores valoran positi-



11

vamente la implantación de metodologías activas y, particularmente, el enfoque ABP. Además, en la asignatura Ingeniería del Software de segundo los resultados obtenidos son especialmente satisfacto-rios [5,10].

3. Limitaciones y riesgos en proyectos que implican a varias asignaturas

Cuando se trata de concebir una solución a un problema complejo como es el de coordinar una propuesta formativa que implica a varias asignatu-ras en un contexto organizativo donde la fragmen-tación y la modularidad (horarios, asignaciones docentes, calendarios, formas de evaluación) no va a cuestionarse, sino que debe ser aceptada como marco de trabajo, es necesario realizar y consensuar entre los implicados (dirección del centro, coordi-nación de la especialidad, profesores implicados en las asignaturas y representantes de estudiantes) un diagnóstico común que enmarque la propuesta a realizar [6,10]. Vamos a repasar algunas de las limitaciones consideradas, que han sido objeto de análisis y de reflexión. Las más importantes hacen referencia a cinco aspectos:

• La relación entre la matrícula de los estudian-tes y la propuesta.

• Carácter optativo u obligatorio e influencia en la calificación.

• Responsabilidad de la coordinación y respon-sabilidad en la calificación.

• Sostenibilidad y robustez frente a cambios de-rivados de la gestión de profesorado.

• Problemas asociados al calendario.

Relación entre la matrícula de los estudiantes y la propuesta. El primer aspecto a considerar es que, en las asignaturas de la especialidad de Ingeniería del Software se pueden matricular, tanto los estudiantes que la escogen como eje de su tercer curso y, en su momento, obtendrán la mención asociada a la especialidad, como aquellos otros que cursan algu-nas de las asignaturas (en un caso extremo, podrían ser todas) en cuarto curso como complemento a la especialidad (Computación o Ingeniería de Compu-tadores) que han elegido. Por tanto, tenemos estu-diantes que pueden no estar matriculados de todas las asignaturas, además del problema estructural de que no todos los estudiantes tienen por qué matricu-larse3 de todas las asignaturas de la especialidad en el mismo curso académico. Con esta limitación, consideramos inoportuno (además de inviable) obligar a todos los estudiantes a realizar proyectos que impliquen varias asignaturas (puesto que habría

3 Aún menos, aprobar.

que obligarles a matricularse en bloque en todas ellas en el mismo curso). Carácter optativo u obligatorio e influencia en la calificación. Aceptado que no es conveniente obligar a todos los estudiantes, la siguiente duda a despejar es si resultaría adecuado que el proyecto conjunto fuera un requerimiento para los que sí estaban matriculados en las asignaturas optativas implicadas. Inmediatamente se descartó esta posibi-lidad, para no generar un trato discriminatorio con los anteriores. De este acuerdo se derivó de forma directa la necesidad de concebir una forma de calificación que fuera compatible con el concepto de oportunidad y que no interfiriera negativamente en las calificaciones de los no implicados. Responsabilidad de la coordinación y responsabili-dad en la calificación. Desde que la idea empezó a ser considerada, resultó evidente la necesidad del rol de coordinador, no sólo durante el proceso de concepción, sino durante la implantación y desarro-llo de la propuesta. Esta función de coordinación tendría asociada la definición y mejora de la pro-puesta, acordada con los diferentes agentes, la difusión y la resolución de dudas ante los estudian-tes, la gestión de solicitudes y niveles de interlocu-ción y, por último, la coordinación de las activida-des asociadas a la evaluación. Evidentemente, este trabajo, sin reconocimiento explícito en la gestión académica, debía tener como base la propia volun-tad de coordinarse de los profesores implicados y una aceptación proactiva de la figura del coordina-dor. Tomando como referencia al coordinador, los profesores implicados negociarían, ajustarían y acordarían cómo influiría la calificación del proyec-to en cada una de las asignaturas. Sostenibilidad y robustez frente a cambios deriva-dos de la gestión de profesorado. Con las actuales condiciones en que se enmarca la gestión académi-ca es habitual que se produzcan cambios, tanto entre un curso y otro como, incluso, dentro del propio año académico. Una de las dificultades asociadas a la gestión de estos cambios suele con-sistir en mantener la consistencia en los procesos de evaluación. Mientras el número de profesores es reducido y el ámbito acotado a una asignatura, los problemas se suelen resolver con un impacto limi-tado. Sin embargo, una iniciativa como la estudiada tiene una debilidad, derivada de la interdependencia entre profesores de diversas asignaturas. Al haber llegado a la conclusión previa de que el proyecto sería voluntario para el estudiante y su calificación complementaria, existía la posibilidad de que, ante una situación sobrevenida o un cambio de orienta-ción debido al criterio de un profesor, una asignatu-



12

ra pudiera descolgarse del plan inicial. Por supues-to, convenientemente explicitado en el procedi-miento este extremo. Se limitaba así el riesgo de que un problema puntual en una asignatura arrastra-se al resto de las implicadas. Por otra parte, llevaba a plantear un proyecto modular en el que pudiesen estar implicadas distintas combinaciones de las asignaturas de la especialidad. Este enfoque, ade-más de permitir una mejor gestión de riesgos, tenía la virtualidad de permitir al estudiante optar por un subconjunto de asignaturas a la hora de enfocar su proyecto (bien por razones relacionadas con la calificación objetivo, bien por el propio interés que le suscitasen unas u otras asignaturas).

Problemas asociados al calendario. El calenda-rio lectivo enmarca cualquier iniciativa que vaya a implantarse. En nuestro caso (y es común en mu-chas universidades) existe una notable diferencia entre el primer y el segundo cuatrimestre, debido a la ubicación del periodo navideño. Así, en el primer cuatrimestre, existe un paréntesis importante entre el final de las actividades lectivas y el periodo dedicado específicamente a la evaluación en el mes de enero. Por el contrario, en el segundo cuatrimes-tre, ambas etapas se suceden sin solución de conti-nuidad. Por otro lado, los ritmos de inicio de las asignaturas del primer cuatrimestre (tras el periodo vacacional veraniego) y la distribución de festivos en el primer cuatrimestre, complican de forma evidente la concepción y desarrollo de proyectos que se inicien de forma temprana. En el caso que nos ocupa, se dan varias afortunadas circunstancias que van a ser claves en la definición de la propues-ta. La primera de ellas es que dos de las asignaturas de la especialidad de Ingeniería del Software del primer cuatrimestre, Diseño de Bases de Datos e Ingeniería del Software II, serían la referencia de partida en cualquier proyecto que abarcara a varias asignaturas; la segunda, que la forma de evaluación propuesta para todas las asignaturas implicadas, basada en el seguimiento y la evaluación continua, permite que, al llegar al final del periodo lectivo en diciembre, la evaluación esté avanzada, en todos los casos, en –al menos- un 80%. Estas dos circunstan-cias, más las limitaciones que se han explicado anteriormente, condicionan de forma casi unívoca el periodo óptimo en que se puede situar en el calendario la iniciativa señalada: el periodo com-prendido entre mediados de diciembre (tras el puente de diciembre) y el final del primer cuatri-mestre (a finales de enero).

4. Oportunidades, propuesta y procedimiento

Tras realizar y consensuar al finalizar el curso 2012-13 el análisis que se ha resumido en el aparta-do anterior, se llegó al acuerdo de añadir, con carácter experimental, la posibilidad de realizar un proyecto, dentro de la especialidad de Ingeniería del Software, que comprometiera a varias de las asigna-turas de esta especialidad que se imparten en el primer cuatrimestre. Como se ha visto, las limita-ciones y riesgos eran importantes, pero también se valoraron las oportunidades que se abrían, tanto para los estudiantes como para el profesorado, al integrar las disciplinas que la organización docente separa, en torno a proyectos en los que haya que poner en juego los diferentes conocimientos, enfo-ques y técnicas que permiten resolver los proble-mas. Por otra parte, esta disposición se basaba en dar continuidad al esfuerzo de implantación de las metodologías activas. Además, convirtiendo el riesgo en oportunidad, la exigencia de una coordi-nación en un entorno flexible ofrecía posibilidades de diálogo e intercambio de información entre los profesores orientada a aportar elementos ligados a la resolución de los proyectos, considerados de forma integral.

Finalmente, los principales elementos que carac-terizan la propuesta probada durante dos cursos, con carácter piloto, han sido seis:

• La realización del proyecto es voluntaria y su calificación complementa las obtenidas en las asignaturas implicadas. Desde esta base se acordó que la calificación obtenida en el pro-yecto sería adicional (y no sustitutiva) a la lo-grada de manera convencional en las asignatu-ras. Esto es, todos los estudiantes serían califi-cados sobre el 100% y, al margen -siempre y cuando hubieran aprobado- decidirían sobre la posibilidad de llevar a cabo el proyecto, cuya calificación vendría a sumarse a la ya obteni-da.

• El proyecto debe realizarse exclusivamente dentro de la primera convocatoria, de forma que el proceso se cierre con las calificaciones de Enero, antes del comienzo del segundo cua-trimestre. Para poder acogerse a esta posibili-dad deberán haber superado las asignaturas de la especialidad en que se encuentren matricu-lados por el método de evaluación continua antes del comienzo de las vacaciones navide-ñas.

• Las asignaturas implicadas pueden ser entre dos y cuatro, pero siempre deben incluir, como mínimo, Ingeniería del Software II o Diseño de Bases de Datos.



13

• La participación en la iniciativa se restringe a los estudiantes que estén cursando la especia-lidad de Ingeniería del Software.

• El proceso de asignación de proyectos pasa por una serie de pasos que incluyen la propuesta por parte de los estudiantes, el acuerdo sobre el alcance del trabajo, entregables, plazos y dedicación estimada, así como el modelo de seguimiento.

• En cuanto a la dimensión del proyecto, se de-cidió tener dos referencias ligadas a la estima-ción de dedicaciones y la potencial compensa-ción en las calificaciones. Se distinguen dos ti-pos de proyectos en función del esfuerzo esti-mado (60 ó 100 horas). Los proyectos de 60 horas permiten un incremento de calificación máximo total de cuatro puntos (en un aprove-chamiento completo de la dedicación, esto es, si se les puntúa esa trabajo con un 10). Para los proyectos de 100 horas (en los que tiene que estar implicados como mínimo tres asignatu-ras), se podrá obtener un máximo de 7 puntos. Los puntos obtenidos se distribuyen y acumu-lan, según el proyecto, entre las asignaturas implicadas de la forma que los profesores de-terminen, entre las distintas asignaturas, su-mándose a la obtenida previamente

Estas condiciones se hacen públicas al principio del periodo lectivo y se vuelven a recordar cuando se acerca el final del cuatrimestre. Por supuesto, también se recuerdan al profesorado implicado, en particular si se produce algún cambio o incorpora-ción. Además se explicita que, dado el carácter complementario del proyecto, su efectivo desarrollo queda condicionado a que las circunstancias del curso permitan su viabilidad.

5. Desarrollo y resultados de la experiencia piloto

En las dos promociones en las que se ha ofertado esta posibilidad (13-14 y 14-15) han optado por realizar el proyecto únicamente cinco estudiantes de un total de 30 posibles, si bien hay que matizar que el porcentaje sería algo más elevado (alcanzando cerca de un 25% del total) si nos limitamos a consi-derar exclusivamente a los estudiantes que no tenían ninguna asignatura de cursos anteriores lo que, evidentemente, restringe y desaconseja, la posibilidad de aprovechar esta oportunidad.

Durante el curso las expresiones de interés han sido claramente superiores a las que se han concre-tado llegadas las fechas de adoptar la decisión. Si bien todavía no estamos en condiciones de hacer un diagnóstico consolidado podemos apuntar una serie de hipótesis respecto a las causas de este fenómeno.

La primera, y más pausible, tiene que ver con el hecho de que un número importante de estudiantes han logrado unos resultados académicos que valo-ran como suficientes y, llegado el final del cuatri-mestre, prefieren optar por un periodo de descanso dilatado y no comprometerse y complicarse las vacaciones, más aún tras la acumulación de pruebas y trabajos que lleva aparejado el final de los perio-dos lectivos cuando se trabaja con modelos de evaluación continua. De hecho, en todos los casos, los estudiantes que han aprovechado esta oportuni-dad ya habían obtenido calificaciones de nota-ble/sobresaliente en las asignaturas escogidas.

En cuanto a la distribución de los proyectos en función de las asignaturas, cabe destacar que en los cinco la asignatura Sistemas Web ha formado parte del proyecto (la distribución puede verse en el cuadro 3).

P1 P2 P3 P4 P5 ISO-II * * * * DBD * * * Sistemas Web * * * * *

Cuadro 3: Asignaturas por proyecto Por otro lado, la propuesta planteada no ha ido

acompañada de un impulso proselitista, ya que se ha considerado –hasta el momento- que era preferi-ble trabajar con estudiantes altamente motivados a tener que ejercer una actividad tractora complicada en un proceso que no está dirigido por ningún docente en particular. Además, el hecho de que el proyecto se defina a partir de la propuesta realizada por el estudiante descarta de partida a aquellos que tengan poca iniciativa o confianza en su capacidad de concebir retos de interés y calado.

Relativizando la posibilidad de sacar conclusio-nes definitivas de la experiencia de estos dos cursos podríamos realizar algunas reflexiones que pueden ser de interés, tanto para la especialidad de Ingenie-ría del Software, como para otras en que se quiera llevar a la práctica una experiencia similar.

La primera es que el camino recorrido resulta transitable, si bien es suficientemente costoso para que sólo razones estratégicas y compartidas aconse-jen recorrerlo. Entre las razones estratégicas se encontrarían el potenciar la especialidad, mejorando su imagen de marca y aumentando los lazos de colaboración e intercambio de información entre el profesorado.

Los estudiantes que han realizado el proyecto lo han valorado de forma muy positiva, si bien es destacable su nivel de compromiso general y su alto desempeño académico. Que, por otra parte, parece necesario para que el proceso de seguimiento, autorización y calificación no sea excesivamente costoso.



14

Por otro lado, uno de los aspectos de reflexión más valiosos derivados de la experiencia proviene de constatar la dificultad que han tenido los estu-diantes para argumentar en qué medida iban, a priori, a utilizar conceptos, notaciones, técnicas y habilidades provenientes de una u otra asignatura. Esto es, sacados del contexto de la asignatura y enfrentados al problema, no tienen claro de dónde proceden los elementos que van a poner en juego. Teniendo en cuenta el perfil (motivación y resulta-dos) de los estudiantes participantes, cabe pensar que este es un reto para la especialidad, vista como un conjunto. Afrontarlo, en el marco de la coordi-nación, puede dotar de una mayor transversalidad e integración a las asignaturas.

Por otro lado, un elemento de dificultad que ha llevado a disuadir a algunos estudiantes de aprove-char la posibilidad y a otros a retrasar el inicio del proyecto, ha sido la necesidad de partir, siempre, de una propuesta del estudiante. Pensamos que la experiencia adquirida permite plantear un proyecto tipo a partir de un problema-reto común, en la línea promovida por la metodología ABP, si no para todos los estudiantes, al menos para aquellos que no quieren/pueden/saben proponer un problema ade-cuado. Este proyecto vendría caracterizado por la necesidad de diseñar e implantar una base de datos, dentro del contexto del desarrollo de una aplicación web, utilizando un framework de desarrollo (para java o php) y tomando como referencia el patrón MVC. Preferiblemente utilizando repositorios de código preexistente y un gestor de versiones, tanto para el código como para la documentación, alinea-do con los utilizados en Ingeniería del Software. En cada promoción se puede proponer un problema-reto concreto e, incluso (aunque esta opción tiene dificultades de gestión por explorar) permitir su relación en equipos de entre dos y tres personas.

6. Discusión y motivación de líneas de actuación futuras

Antes de entrar en la descripción de la acogida de la propuesta, tanto por parte de estudiantes como de los profesores, cabe adelantar que no hubiera sido posible sin en el esfuerzo inicial de diálogo y acuerdo entre el conjunto de profesores implicados. Por tanto, vaya por delante, que el consenso entre profesorado y dirección es una condición sine qua non.

Tras dos cursos de puesta a prueba de la expe-riencia diseñada, los resultados obtenidos permiten hacer una reflexión sobre el grado de consecución de los objetivos pretendidos, la adecuación de las decisiones que se adoptaron en el diseño y el interés de dar continuidad a la iniciativa, incorporando elementos de ajuste y mejora, tanto en las metas a

alcanzar, como en las actuaciones que permitan lograrlas.

En cuanto a los objetivos, entendemos que en el momento actual es más conveniente un análisis puramente cualitativo, dada la limitación del núme-ro de participantes. Este análisis debe centrarse en el reconocimiento de la opinión de los participantes, tanto profesorado, como estudiantes. La conclusión de este análisis pasaría, en última instancia, por la decisión de dar continuidad o no a la experiencia. Con este fin, discutiremos las objeciones más evidentes que puede encontrar un observador im-parcial. Vaya por delante que la constancia en el propósito llevará a los proponentes a continuar en la senda marcada, al menos durante un curso acadé-mico más, tras la asunción de tres medidas de ajuste que, pensamos, pueden redundar en una mejora del valor de la acción propuesta.

Se presenta a continuación los aspectos señala-dos: opiniones del profesorado y estudiantes, objeciones y ajustes.

Opiniones del profesorado. Dados los fundamen-tos de la propuesta, escasamente invasivos, y que no conllevan exigencias importantes de coordina-ción durante el curso, ni esfuerzos significativos de corrección y tutoría, el profesorado implicado no ha sentido forzado su espacio académico, ni ha notado un aumento de dedicación, lo que ha permitido que mantenga una disposición abierta y colaboradora, que se proyecta hacia el futuro.

Opiniones de los estudiantes. Los estudiantes perciben de forma positiva la oportunidad que les brinda la propuesta y, durante el cuatrimestre, mantienen un importante grado de interés, canali-zado a través de preguntas recurrentes sobre el proyecto. Llegado el final del cuatrimestre, la mayor parte ven diluidas sus buenas intenciones, bien por exigencias académicas más prioritarias (en el caso de los estudiantes con más dificultades), bien por las perspectivas de un merecido descanso navideño, en el caso de muchos de los que ya han logrado sus objetivos académicos.

Objeciones. La primera y más evidente objeción haría referencia a un elemento fundamental de la propuesta: ¿si es bueno (conveniente) no debería ser obligatorio? La respuesta es directa: las circuns-tancias actuales convertirían, de facto, en inviable la propuesta de un proyecto obligatorio de estas características. Sólo en aquellos planes de estudio que hayan integrado específicamente en su defini-ción este tipo de proyectos (y las restricciones de matrícula y organización que de ellos se derivan) se puede exigir de forma sostenida a los estudiantes la realización de trabajos de estas características. Y, dicho sea de paso, el que sea (potencialmente) bueno no quiere decir que sea ni la única, ni la mejor forma de hacer las cosas. No hay más que ver



15

que son una reducida minoría los planes de estudio con proyectos de estas características, habiendo quedado reducido mayoritariamente el esfuerzo explícito de integración transversal al proyecto de fin de grado. A partir del análisis anterior, sólo existen dos op-ciones: que sea voluntario o que no sea. Excluida la segunda, queda por ajustar el grado y orientación de la voluntariedad. Es evidente que este diseño lleva a que únicamente los estudiantes altamente motiva-dos escojan este camino. Por otro lado, no es infre-cuente que estos estudiantes hayan obtenido ya unas calificaciones suficientemente buenas sin necesidad de hacer el proyecto transversal, con lo que la motivación basada en la recompensa concre-tada en un aumento de la nota aún es menos efecti-va. En este aspecto sí que cabría una orientación alternativa: orientar el proyecto hacia los estudian-tes que, por no haber logrado el nivel de desempeño exigible en las actividades convencionales, deban complementar el trabajo de forma “voluntaria” (motivados por la necesidad de aumentar su califi-cación hasta el aprobado).

La segunda objeción más importante tiene que ver con la caracterización del proyecto en sí: ¿no sería más conveniente un proyecto clara y específi-camente definido, modularizable, de manera que los estudiantes completaran aquellas partes asociadas a las asignaturas en que estuviesen matriculados? De esta forma, dependiendo de la matrícula, el estu-diante llevaría adelante una u otra parte del proyec-to. Aquí la respuesta tiene que ver con la fundamen-tación metodológica del proyecto a desarrollar: Se trata de que el estudiante, utilizando de forma integrada sus conocimientos de la especialidad, cubra todas las fases del proceso de resolución de un problema de ingeniería del software: desde el análisis y el diseño, hasta el desarrollo, las pruebas y la implantación. Esto es difícilmente compatible con soluciones prediseñadas que, por ingeniería inversa, llevan a una especificación prácticamente cerrada basada en los requerimientos marcados por el profesorado

Ajustes propuestos. La reflexión sobre la expe-riencia y las sugerencias y críticas recibidas nos han llevado a centrarnos en dos líneas de actuación futura que nos parecen prometedoras: la primera, relacionada con la coordinación académica, la segunda con la orientación de los proyectos a realizar.

En cuanto a la coordinación, hemos comprobado que es muy importante. Por un lado, por razones prácticas: información a los estudiantes, referencia para el profesorado implicado, centralización de la recepción de propuestas y entregables, y facilita-ción del proceso de calificación. Por otro, para canalizar de vuelta la información que se va gene-

rando en todos los pasos y permitir integrar algunas lecciones aprendidas en las asignaturas de la espe-cialidad. En este caso, la propuesta de mejora es muy concreta: se plantea que el/la coordinador/a de la especialidad añada a sus funciones ordinarias las relacionadas con la coordinación del proyecto integrado.

Respecto a la orientación de los proyectos, cree-mos que se puede conseguir una mejora sustancial en el número de participantes si, en vez de que ellos mismos propongan el problema a resolver, se les ofrezcan un número limitado de problemas-reto (entre uno y tres) de entre los que tengan que esco-ger el que prefieren abordar. Esto abriría la puerta a tres mejoras: reducir la incertidumbre y el retraso en los momentos iniciales del proyecto, facilitar la creación de equipos motivados por una vocación común de resolver el problema y poder extraer materiales, reflexiones y lecciones aprendidas que pudieran compartirse de forma general en el ámbito del profesorado y de los estudiantes de la especiali-dad. Quizás esta opción de socialización del cono-cimiento es la que tiene un mayor potencial como elemento motivador en la continuidad de la expe-riencia. Además, este cambio permitirá el desarrollo de proyectos en equipo, posibilidad hasta el mo-mento no considerada y que está alineada con uno de los puntos fuertes percibidos por los estudiantes en las aproximaciones ABP [1,4,5,9,10].

7. Conclusiones Hemos revisado los resultados de la puesta en

marcha, durante dos cursos, de una experiencia piloto de realización de proyectos transversales inspirados por la voluntad de fomentar la iniciativa del estudiante en la aplicación integrada de los contenidos de las asignaturas de la especialidad Ingeniería del Software.

A pesar de las importantes limitaciones que han condicionado el diseño de la propuesta y de la modestia de los resultados obtenidos hasta el mo-mento, el enfoque pragmático seguido ha permitido mantener unos niveles de satisfacción suficiente en los implicados, sin introducir disfunciones en el resto de los agentes afectados. Esto permite, tras la pertinente reflexión crítica y el estudio de posibles mejoras, dar continuidad a la línea de trabajo em-prendida. Las mejoras a incorporar en el futuro serán tres: reforzar la coordinación, ofrecer un número reducido de problemas-reto marco y facili-tar el desarrollo de los proyectos en equipo.

Consideramos que, en la situación actual, sigue siendo conveniente que este tipo de proyectos sea voluntario, concebido con mucha flexibilidad, y orientado específicamente a estudiantes con inicia-tiva y claramente motivados. Especialmente indica-



16

do para aquellos que se encuentren cómodos en el uso de las metodologías activas y que valoren positivamente el aprendizaje y el trabajo que, con carácter preceptivo, han debido culminar en los proyectos ABP.

Agradecimientos El trabajo presentado no hubiera sido posible sin la colaboración y la implicación de los profesores y estudiantes de la especialidad de Ingeniería del Software. Por otra parte, los comentarios de los revisores de JENUI han resultado también muy importantes para una reorientación y mejora del enfoque de este artículo.

Referencias [1] Olatz Arbelaitz Gallego, José I. Martín

Aramburu y Javier Muguerza Rivero: Apren-dizaje cooperativo y basado en proyectos en la asignatura Arquitectura de Computadores. ReVisión, vol. 6, núm. 2, septiembre de 2013.

[2] Cristina Barrado, Raúl Cuadrado, Luis Del-gado, Fernando Mellibovsky, Enric Pastor, Marc Pérez, Xavier Prats, Jose I. Rojas, Pa-blo Royo, Miguel Valero: Una experiencia de unificación de asignaturas para desplegar PBL (y las quejas que originó). En ReVisión, vol. 6, núm. 2, Septiembre de 2013.

[3] José Miguel Blanco, Imanol Usandizaga y Arturo Jaime: Gestión de Proyectos en el Grado en Ingeniería Informática: del PBL a la espiral de proyectos. ReVisión, vol. 7, núm. 3, septiembre de 2014.

[4] María José García García, Juan José Escriba-no Otero y Ma Cruz Gaya López: Experiencia de aplicación de ABP al Grado de Ingeniería Informática. En Actas de las XX Jornadas de Enseñanza Universitaria de Informática, Je-nui 2014, pp. 125-132, Oviedo, julio de 2014.

[5] Alfredo Goñi, Jesús Ibáñez, Jon Iturrioz y Jo-sé Ángel Vadillo: Aprendizaje Basado en Proyectos usando metodologías ágiles para una asignatura básica de Ingeniería del Soft-ware. En Actas de las XX Jornadas de Ense-ñanza Universitaria de Informática, Jenui 2014, pp. 133 – 140, Oviedo, julio 2014.

[6] Monserrat Maritxalar y José Miguel Blanco: Proyecto Docente en la Facultad de Informá-tica de la Universidad del País Vasco. En Ac-tas de las Jornadas de Intercambio Docente, JIED-2013, pp. 27-34. Servicio Editorial de la UPV/EHU, 2013.

[7] Joe Miró Julià: De las creencias a los princi-pios: ejemplo de diseño de una asignatura. Revisión, vol. 6, núm. 2, septiembre de 2013.

[8] Joan Navarro, Xavi Canaleta, David Vernet, Nuria Costa, Xavi Solé y Virginia Jiménez. Motivación, desmotivación, sobremotivación y daños colaterales. En Actas de las XX Jor-nadas de Enseñanza Universitaria de Infor-mática, Jenui 2014, pp. 467 – 474, Oviedo, julio 2014

[10] Pablo Sánchez y Carlos Blanco. Implantación de una metodología de aprendizaje basada en proyectos para una asignatura de Ingeniería del Software. En Actas de las XVIII Jornadas de Enseñanza Universitaria de Informática, Jenui 2012, pp. 41 – 48, Ciudad Real, julio 2012

[11] José Ángel Vadillo, Imanol Usandizaga, Al-fredo Goñi y José Miguel Blanco: Análisis de los resultados de implantación ABP en un Grado de Ingeniería Informática. En Actas de las XXI Jornadas de Enseñanza Universita-ria de Informática, Jenui 2015, Andorra la Vella, julio 2015.

[12] Miguel Valero-García: PBL (Piénsalo Bien antes de Liarte). ReVisión, vol. 5, núm. 2, Di-ciembre de 2012.



17

La enseñanza de la Ciberseguridad en el Grado enIngeniería Informática

José Ant. Gómez HernándezDepartamento de Lenguajes y Sistemas Informáticos

Universidad de GranadaGranada

[email protected]

ResumenLa Ciberseguridad es un bien a proteger dado su im-pacto a nivel político, social, económico e individual.Una parte importante la misma descansa en la cons-trucción y usos seguros de los sistemas informáticos. Sería necesario que todos nuestros graduados ad-quieran unos conocimientos básicos relativos a segu-ridad para abordar su trabajo profesional con la res-ponsabilidad necesaria y bajo los estándares reconoci-dos. El posicionamiento de la ponencia es que para pre-venir los problemas más frecuentes de seguridad esnecesario ligar la enseñanza de la tecnología juntocon la forma segura de uso. Esto significaría que de-bemos, no solo incluir aspectos de seguridad informá-tica en materias específicas, si no que además debe-mos incluir conocimientos de seguridad en otras ma-terias básicas de cara a construir sistemas seguros quegeneren confianza en los consumidores. Por supuesto, el punto más conflictivo es establecerun equilibrio entre los contenidos propios de una ma-teria y su uso de forma segura.

AbstractCybersecurity is an asset to protect given their impacton the political, social, economic and individuallevels. An important part of it rests on the construc-tion and secure use of computer systems.It's important that all our graduates acquire basicknowledge on security to address their professionalwork with the necessary responsibility and under re-cognized standards..This paper states that to prevent the most common se-curity issues is necessary to link the teaching of tech-nology along with the secure use. This would meanthat we should not only include aspects of security inspecific subjects, but it also must include security ele-ments in other basic subjects in order to build securesystems that generate consumer confidence.

Of course, the most controversial point is to establisha balance between the own contents of a subject andthe secure elements inserted.

Palabras claveCiberseguridad, cibercrímenes, enseñanza.

1. MotivaciónLa Ciberseguridad es un bien a proteger dado su

impacto a nivel político, social, económico tanto a ni-vel de estados u organizaciones como individual.Gran parte de nuestro mundo descansa en la construc-ción y usos seguros de los sistemas informáticos so-bre los que realiza una amplia variedad de actividadescotidianas, especialmente en países desarrollados tec-nológicamente.

En este sentido, comentar algunas cifras para ver lamagnitud del problema. En [10] para 2014 se estimael coste del cibercrimen en 400.000 millones de dola-res, lo que supone entre un 15% y un 20% del dineroque se mueve en Internet. Las principales causas deesta brutales perdidas provienen de [9]: el 68,32 %debido a phishing, un 66,48% a malware, el 50.14%por intentos de hacking, un 43,54% por ingeniería so-cial, un 43,89% por perdida de dispositivos móviles,25,28% de los trabajadores (insiders), 21,88% de In-yección SQL, etc.

No solo hay que tener en consideración los aspec-tos económico, sino también sociales y personales.Por ejemplo, va en aumento delitos como el ciberaco-so o el sexting, que afectan especialmente a nuestrosjóvenes, parte de cuya solución pasa por una educa-ción en seguridad, la construcción de sistemas y he-rramientas destinadas a evitarlos. Sin dejar de men-cionar aspectos estratégicos relacionados con ataquesa infraestructuras críticas, o que afectan a la privaci-dad como las brechas de datos (últimamente crecien-tes en número y volumen).

En España este fenómeno también es creciente talcomo podemos ver el primer informe sobre Cibercri-



18

minalidad presentado por el Ministerio del Interior[11]. Además, hay que resaltar que el número de ata-ques sufridos por España en 2014 fue de 70.000 loque nos posiciona en tercer lugar tras EEUU y ReinoUnido [6] . Debemos resaltar que un 95% de estos de-litos [5] quedan impunes por diferentes causas: noson denunciados, o encuentra problemas tecnológicosy/o legales.

Como podemos ver, el incremento y volumen delcibercrimen son lo suficientemente grandes comopara no abordar el problema con rapidez y contunden-cia. En especial, si deseamos consolidar el uso de lasNuevas Tecnología por la mayoría de la población.Como se indica en [4], solo un 53% de los usuariosde Internet declaran que compran bienes o serviciosonline, un 48% realiza operaciones bancarias en línea,y el 20% vende bienes o servicios. Este aspecto tam-bién esta reconocido por su importancia en la Estrate-gia de Ciberseguridad Nacional [12].

La estructura de la ponencia aborda en el Apartado2 cómo ha quedado la enseñanza de la Seguridad enlos Grados de Ingeniería Informática en España y, es-pecialmente, en la Universidad de Granada. En elApartado 3, se presenta y justifica una propuesta demejora para solucionar algunos problemas. En elApartado 4, se verán algunos ejemplos concretos deasignaturas afectadas por la propuesta. Para terminarcon un resumen de la propuesta realiza en la ponen-cia.

2. La enseñanza de la seguridad

2.1. La seguridad en los Grados en Informática

Todos leímos en su momento multitud de veces elBOE 187/2009 [2] que establece la recomendacionespara la solicitud de títulos de Ingeniería Informática.En el Apartado 3 del Anexo I, se relacionan las com-petencias que todos los estudiantes deben adquirir,entre las que aparece “ Capacidad para diseñar, desa-rrollar, evaluar y asegurar la accesibilidad, ergono-mía, usabilidad y seguridad de los sistemas, serviciosy aplicaciones informáticas, así como de la informa-ción que gestionan”. Volviendo a aparecer el término“seguridad” tanto en el módulo de rama como en losde especialización.

He marcado en negrita el elemento que desde mipunto de vista se ha reflejado de manera insuficienteen el plan de estudios de Grado en Ingeniería Infor-mática en la Universidad de Granada, y posiblementeen otros, como trataré de justificar en breve.

Para la adquisición de competencias relacionadascon la Ciberseguridad se ha optado por incluir ciertonúmero de asignaturas dedicadas al tema en todos losplanes de estudio, tal como se puede ver el en magni-

fico trabajo de Ramió [14] a través del proyectoMESI.

Si bien la situación de la enseñanza de la Seguridadha mejorado respecto de los planes de estudios ante-riores, es actualmente a todas luces insuficiente, má-xime cuando en algunos casos estas asignaturas sonbien optativas, bien troncales pero solo se cursan enalguna mención concreta y, por tanto, no es vista portodos los alumnos del título.

En [13] se propone la creación de una titulaciónpropia en seguridad para la formación de profesiona-les en esta materia. Desde mi punto de vista esta pro-puesta es muy interesante pero solo cubre una partedel problema. La seguridad informática no es solocuestión de profesionales de la seguridad, es algo quenos afecta a todos los que usamos y/o construimos so-ftware. Por tanto, debemos buscar una solución quepermita cubrir unas competencias básicas en seguri-dad a todos los alumnos de nuestros grados.

2.2. La docencia de la seguridad en el Grado de Ingeniería Informática de Granada

En el caso concreto del Grado en Ingeniería Infor-mática de la Universidad de Granada, se pasa a co-mentar que asignaturas específicas sobre Seguridad seestablecieron así como una breve descripción de suscontenidos.

Seguridad y Protección de Sistemas Informáticosobligatoria en la mención de Tecnologías de la Infor-mación. Esta dedicada en gran parte a la criptografía,si bien cubre algunos aspectos de seguridad en redesy comunicaciones, identidad digital, privacidad en In-ternet y comercio electrónico.

Seguridad en Sistemas Operativos optativa de lamención de Ingeniería del Software. Asignatura queimparto, se diseño para completar la parte de seguri-dad vista en la asignatura de Sistemas Operativos desegundo curso. Además, trata cubrir otros aspectos dela seguridad que los estudiante de la mención de Inge-niería del Software no ha visto, como son: desarrollode software seguro, malware, informática forense.

Criptografía y Computación optativa en la men-ción de Computación y Sistemas Inteligentes. Comosu propio nombre indica aborda los aspectos de cifra-do de la información

Además, también deben incluirse los contenidosde seguridad de la asignatura de Sistemas Operativosque suelen incluirse en cursos básicos sobre la mate-ria, como son básicamente autorización y control deacceso.

A la luz de lo indicado, es notorio que no hay unaasignatura específica de seguridad básica que cursentodos los estudiantes del Grado y que exponga lacomplejidad y amplitud del tema.

A continuación trataré de esbozar una propuestaque cubra de manera razonable estas deficiencias en



19

seguridad y que tenga una implementación flexibledentro de los diferentes marcos curriculares estableci-dos.

3. Una propuesta de mejoraLa propuesta que se presenta esta destinada, como

comentábamos en los párrafos anteriores, a que todosnuestros estudiantes alcancen una competencias bási-cas de seguridad necesarias para construir sistemassoftware seguros tal como demanda la sociedad.

Esta propuesta trata de alcanzar este objetivo sinnecesidad de hacer una reforma del plan de estudiospara incluir nuevas asignaturas. Reforma que seríacostosa, compleja y tardaría en poder aplicarse. Ade-más esta propuesta no es incompatible, al contrariocomplementaria, de la situación actual donde hayasignaturas específicas de seguridad en las diferentesmenciones, o con la implantación de un título propioen seguridad.

Se trata de plantear una serie de competencias bási-cas de seguridad como competencias transversales deforma que se cubran en asignaturas ya existentes (enlugar de pretender crear nuevas asignaturas). Es decir,dedicar parte los contenidos de asignaturas ya exis-tentes a abordar aspectos básicos de seguridad. Estoel algo que en algunos caso ya se hace parcialmentepero que habría que potenciar y coordinar.

Es evidente que esto presenta un problema en elque ya habrá pensado el lector: cómo incluyo compe-tencias nuevas en asignaturas que ya de por sí esta so-brecargadas. Las respuesta no es ni sencilla, ni única.Es evidente que supone un gran esfuerzo de coordina-ción a nivel de título en que debemos valorar queequilibrio en la formación de nuestro estudiantes da-mos a dos aspectos contrapuestos en muchos casos:inclusión de conceptos/tecnologías avanzados frente aconceptos/tecnologías que hagan más seguros los sis-temas que pretendemos construir.

Como es evidente y pretendía dejar manifiesto enla Introducción de la ponencia, mi postura es que engeneral considero necesario sacrificar la inclusión dealgunos avances tecnológicos para facilitar la inclu-sión de elementos de seguridad. A menudo vemoscomo las empresas en una veloz carrera por ofrecernuevas soluciones tecnológicas de cara a abarcar cuo-tas de mercado dejan atrás aspectos de seguridad, loque tiene consecuencias nefastas. El grado de pene-tración de competencias de seguridad en las asignatu-ras dependerá del grado de sensibilización del profe-sorado hacia el tema sin dejar atrás las competenciaslegales establecidas para las asignaturas que en la ma-yoría de los casos hemos aumentado para cubrir lacarga crediticia.

Evidentemente, no se trata de que todos los alum-nos sean profesionales de la Seguridad Informática,

pero si que conozcan, se sensibilicen y sean capacesde abordar los problemas que se producen al no tener-la en cuenta. Esto les permitirá eliminar de entradadeterminados defectos de sus construcciones softwarey facilitar la comunicación en equipos multidiscipli-nares con profesionales de la seguridad.

La propuesta que podemos resumir como “debe-mos ligar la enseñanza de la tecnología con su uso deforma segura”. Este lema ser extrapolable a todos losniveles docentes donde se enseñe tecnología. Porejemplo, deberíamos enseñar a nuestros adolescentesno solo a utilizar un navegador, sino a utilizar de for-ma segura un navegador. Lo mismo sería aplicable aluso seguro de redes sociales, dispositivos móviles,etc.

A nivel universitario, esta propuesta se alinea contrabajos previos como [7, 8, 16], donde se realizan di-ferentes propuestas de integrar la Seguridad en el cu-rrículum, pero que desgraciadamente no son muy nu-merosas ni parecen haber arraigado lo suficiente.

Otro elemento importante, una vez concienciadosde la necesidad de incluir competencias de seguridaden nuestras asignaturas, es: en qué sentido debo mo-dificar mi asignatura para incluir dichas competen-cias.

Para responder a esta cuestión, tendríamos dos lí-neas de actuación. La primera enfocada al desarrolloy construcción de software seguro, que afectaría a lasasignaturas relacionadas con la programación e Inge-niería del Software. La segunda, desde el punto devista de hacking, ver cuales son las amenazas másfrecuentes y estudiar las soluciones para paliar o anu-lar dichas amenazas. Vamos a dar, en el Apartado si-guiente, ejemplos concretos de contenidos que debe-ría abordarse en asignaturas ya establecidas y que ac-tualmente se hacen de manera baja o nula, al menosen el Grado de la Universidad de Granada.

4. Asignaturas afectadas por la propuesta

Vaya por adelantado la aclaración de que algunoselementos de seguridad ya se ven el algunas asignatu-ras pero a veces no están sistematizados y dependende la concienciación del profesor correspondiente.Por lo que la propuesta presentada va más en la líneade sistematizar contenidos y distribuir competencias.

Para ayudarnos en [3] podemos encontrar la listade las 25 errores software más usuales que los progra-madores deberían mitigar o eliminar. Estos errores es-tán agrupados en tres categorías (interacción inseguraentre componentes, gestión arriesgada de recursos, ydefensas porosas) que vamos a despiezar en funciónde las asignaturas en los que se podrían incluir.

Las primeras asignaturas sería las relacionadas conla Ingeniería del Software (como Fundamentos de In-geniería del Software, de 2º curso), donde no se cubre



20

una metodología de desarrollo software que tenga encuenta la seguridad como un requisito no funcional.En múltiples conversaciones con mis compañeros re-conocen la necesidad pero me indican que no se ma-terializa por falta de tiempo.

Las asignaturas básicas de programación (Funda-mentos de Programación y Metodología de la Progra-mación, de primer curso) son las candidatas naturalespara introducir conceptos fundamentales de progra-mación segura (o defensiva) destinados a eliminarvulnerabilidades en la etapa de codificación, comopor ejemplo, desbordamiento de búfer.

Otras asignaturas afectadas derivadas de las princi-pales amenazas en sistemas, son las asignaturas deprogramación web. Los sistemas web están expuestosa un elevado número de amenazas que el alumnodebe conocer y saber paliar bien manualmente bienutilizando algún framework de desarrollo que lo haga.

Estas consideraciones pueden extenderse comoejemplos de prácticas a otras asignaturas, por ejem-plo, de Big Data que nos pueden ayudar a procesargrandes volúmenes de información dispar con los al-goritmos adecuado.

En los subapartados siguientes, vamos a desarrollaralgunos de los aspectos anteriormente mencionadossolo en las asignaturas que creo directamente afecta-das.

4.1. Asignaturas de programación

En las asignaturas de programación se incluiríanmuchos de los elementos que caen en el segundo gru-po de errores etiquetado con el nombre de “Gestiónarriesgada de recursos” que incluiría los ítems: copiade búferes sin comprobar las entradas (Buffer Over-flow), limitación inadecuada de un nombre de caminoa un directorio restringido (Path traversal), uso defunciones potencialmente peligrosas, cálculo inco-rrecto del tamaño de un búfer, cadenas con formatoincontrolado o desbordamiento de enteros. Muchos de estos elementos se ven en las programa-ción básicas por lo cual lo único que deberíamos ha-cer es darles consistencia y ligarlas con la seguridaddel programa/sistema en construcción. Quizás un elemento que debería incluirse es la utili-zación de alguna herramienta para el análisis estáticodel código resultante en los supuestos de programa-ción. Esto se puede hacer como parte de las prácticasy no debería ser muy costoso en recursos.

4.2. Asignaturas de Ingeniería de Software

La mejor forma de evitar ataques (que no hacenmás que aprovechar vulnerabilidades) es el desarrollode software seguro desde sus inicios. Para ello es ne-cesario el uso de una metodología de desarrollo soft-ware que contemple la seguridad desde sus inicios.

Esta necesidad se recoge en [16], donde se describe laasignatura de Seguridad de Sistemas Software enmar-cada dentro de la especialidad de Ingeniería del Soft-ware. La propuesta citada es perfectamente válida parauna especialización en desarrollo de software, peroresponde a un enfoque diferente a adoptado en mipropuesta: no beneficiaría a todos los estudiantes delGrado y duplica una asignatura. Por tanto, la propues-ta presentada, va en la dirección de tener la seguridadinmersa en las asignaturas básicas de Ingeniería delSoftware. Valga como ejemplo de la importancia de laconstrucción de software seguro el reciente y luctuo-so accidente de un Airbus A400M debido a un proble-ma de integración software. Entre los contenidos básicos a incluir tendríamos eluso de una metodología segura y el uso de herramien-tas de análisis, verificación y prueba de software se-guro. En estas asignaturas sería más costosa la inte-gración pues supondría en muchos casos el cambiocompleto de metodología software utilizada y al quepuedo imaginar mas reticencias por parte del profeso-rado. Creo que sin duda los beneficios en la seguridaddel software que produzcan nuestros futuros estudian-tes lo merece. Se pueden incluir contenidos del grupo de “defen-sas porosas” de los 25 errores comunes del softwareentre los que se incluirían: perdida de autenticaciónen funciones críticas, perdida de autorización, falta decifrado de datos sensibles, o asignación incorrecta depermisos para recursos críticos.

4.3. Asignaturas de desarrollo web

El grupo de “interacción insegura entre componen-tes” incluye mayoritariamente aspectos relacionadoscon el desarrollo web, a saber: neutralización inade-cuada de elementos especiales en las órdenes SQL(SQL injection), neutralización inadecuada de entra-das en la generación de páginas web (Cross-sitescripting), carga sin restricciones de archivos con ti-pos peligrosos, falsificación de solicitudes cruzadas(Cross-Site Request Forgecy - CSRF), redirección deURLs a sitios no confiables, o exposición de informa-ción a través de mensajes de error.

También serían elementos potenciales a incluir, al-gunos de segundo grupo “gestión arriesgada de recur-sos”, a saber, la descarga de código sin comprobaciónde integridad, y la inclusión de funcionalidad desdeuna esfera de control no confiable, por ejemplo, códi-go móvil.

Es evidente la dificultad de incluir en dos o tresasignaturas de 6 créditos la descripción de todos loselementos citados, pero sería aconsejable que losalumnos al menos conociesen de que tratan y, al me-nos, cómo evitarlos en los casos más comunes. Ade-mas de tener presente que debería que trabajar conprofesionales del tema cuando desarrolla aplicacio-



21

nes/sitio web de forma profesional. Desgraciadamen-te me he encontrado con algún alumno en la asignatu-ra de Seguridad que imparto en cuarto curso, que es-taba haciendo el desarrollo de sitio web con acceso auna base de datos para una organización y estos tér-minos tan siquiera le sonaban.

Aquí es también posible una distribución de conte-nidos entres las numerosas asignaturas sobre desarro-llo web incluidas en los nuevos planes. Por otro lado,en las prácticas de estas asignaturas se pueden plan-tear proyectos conjuntos con otras asignatura, comola que imparto de Seguridad en Sistemas Operativos,para realizar teste de penetración de sitios web, porejemplo.

4.4. Asignaturas de sistemas operativos

Tradicionalmente, las asignaturas generales de siste-mas operativos suelen incluir algún tema teórico deseguridad, que incluye una introducción a la misma, ysuele centrarse generalmente en aspectos de autentifi-cación y control de acceso. A esto puntos, habría que añadir algunos elementosfundamentales y que no son muy difíciles de alcanzarya que se pueden incluir de manera natural en lasprácticas de la asignatura. Me refiero a la gestión deactualizaciones del sistema operativo y las aplicacio-nes, la gestión de listas blancas (white lists), y restric-ción de privilegios de administrador a los usuariosque lo necesitan. Estos elementos aseguran una re-ducción del orden del 70% en la presencia de amena-zas, tal como se indica en [1]. Estos elementos pueden completarse, en la medidaque el temario práctico lo permita en la parte de ad-ministración del sistema con gestión de copias de se-guridad (una medida contra el ransomware), y endu-recimiento del sistema operativo (OS hardening comomedida para reducir el frontera de ataque).

5. ConclusionesPuesta de manifiesto la importancia creciente de la

construcción de sistemas informáticos seguros de caraa satisfacer las necesidades presentes y futuras de laSociedad de la Información, se ha pretendido con-cienciar la necesidad de una formación básica en ma-teria de ciberseguridad para todos los estudiantes delGrado en Informática.

Además, se propone un modelo que permitiría in-cluir competencias de seguridad en los actuales pla-nes de estudios de forma transversal sin necesidad deuna modificación estructural de los mismos, sino queafecta al diseño de contenido de asignaturas ya exis-tente.

También se ha puesto de manifiesto como este mo-delo depende de una coordinación transversal de loscontenidos que si bien exige esfuerzo por parte delprofesorado es fácilmente modularizable para separar

dichas competencias en asignaturas y cuyo resultadosería la formación profesionales concienciados con laconstrucción de sistemas seguros.

Referencias[1] Australian Defence Signals Directorate (DSD),

Strategies to Mitigate Targeted CyberInstrusions – Mitigation Details, Oct. 2012.

[2] BOE, resolución de 8 de junio de 2009 de laSecretaría General de Universidades, nº 187 de2009, 4 Agosto de 2009.

[3] Steve Chistey (Ed.), CWE/SANS Top 25 MostDangerous Software Errors, CommonWeakness Enumeration, Sep. 2011.

[4] Comisión Europea, "Ciberdelincuencia: Losciudadanos de la UE, preocupados por laseguridad de la información personal y lospagos en línea". Bruselas 9/6/2012.http://europa.eu/rapid/press-release_IP-12-751_es.htm?locale=en.

[5] Jesús Duva, “El 95% de los ciberdelitoscometidos quedan impunes”, El País, 4/5/2014.http://politica.elpais.com/politica/2014/05/03/actualidad/1399117342_852720.html.

[6] Europa Press, "España sufrió más de 70000ataques cibernéticos, la cifras más alta trasEEUU y Reino Unido", Madrid, 5/2/2014.http://www.europapress.es/nacional/noticia-espana-sufrio-2014-mas-70000-ataques-ciberneticos-cifra-mas-alta-eeuu-re-20150205115531.html.

[7] Trudy Howles, Carol Romanowski, SumitaMishra y Rajendra K. Raj, “A Holistic,Modular Approach to Infuse Cyber Securityinto Undergraduate Computing DegreePrograms”, Annual Symposium on InformationAssurance (ASIA 2011), Albany NY, June 2011.

[8] Cynthia E. Irvine, Shiu-Kai Chin, y DeborahFrincke, "Integrating Security into theCurriculum" (1998). Electrical Engineering andComputer Science. Paper 84.http://surface.syr.edu/eecs/84.

[9] ISACA, State of Cybersecurity: Implicationsfor 2015. An ISACA and RSA ConferenceSurvey, RSA Conference, 2015.http://www.isaca.org/cyber/Documents/State-of-Cybersecurity_Res_Eng_0415.pdf.

[10] McAfee, Net Losses: Estimating the GlobalCost of Cybercrime. Economic impact ofcybercrime II , McAfee, Junio de 2014.http://www.mcafee.com/us/resources/reports/rp-economic-impact-cybercrime2.pdf.

[11] Ministerio del Interior, "Avance de los datosestadísticos de 2013 relativos a lacibercriminalidad" , 2013.



22

http://europa.eu/rapid/press-release_IP-12-751_es.htm?locale=en

http://europa.eu/rapid/press-release_IP-12-751_es.htm?locale=en

http://www.mcafee.com/us/resources/reports/rp-economic-impact-cybercrime2.pdf

http://www.mcafee.com/us/resources/reports/rp-economic-impact-cybercrime2.pdf

http://www.isaca.org/cyber/Documents/State-of-Cybersecurity_Res_Eng_0415.pdf

http://www.isaca.org/cyber/Documents/State-of-Cybersecurity_Res_Eng_0415.pdf

http://surface.syr.edu/eecs/84

http://www.europapress.es/nacional/noticia-espana-sufrio-2014-mas-70000-ataques-ciberneticos-cifra-mas-alta-eeuu-re-20150205115531.html



http://politica.elpais.com/politica/2014/05/03/actualidad/1399117342_852720.html

http://politica.elpais.com/politica/2014/05/03/actualidad/1399117342_852720.html

http://www.interior.gob.es/prensa/balances-e-informes/2013.

[12] Presidencia de Gobierno, Esquema deCiberseguridad Nacional, Gobieno de España2013.http://www.lamoncloa.gob.es/documents/20131332estrategiadeciberseguridadx.pdf.

[13] Jorge Ramió, "Introducción de las Enseñanzasde Seguridad Informática en los Planes deEstudio de las Ingenierías del Siglo XXI",JENUI 2001.

[14] Jorge Ramió, Informe gráfico de la tesisdoctoral “La enseñanza universitaria enseguridad TIC como elemento dinamizador dela cultura y la aportación de confianza en lasociedad de la información en España”. León,12 de diciembre de 2013.http://www.criptored.upm.es/guiateoria/gt_m001i1.htm.

[15] David G. Rosado, Carlos Blanco, Luis EnriqueSánchez, Eduardo Fernández-Medina, y Mario

Piattini, "La Seguridad como una asignaturaindispensable para un Ingeniero del Software",JENUI 2010, pgs. 205-212.http://upcommons.upc.edu/revistes/bitstream/2099/11778/1/a25.pdf.

[16] Blair Taylor, Harry Hochheiser, ShivaAzadegan, y Michael O’Leary, "Cross-siteSecurity Integration: Preliminary Experiencesacross Curricula and Institutions", Proceedingsof the 13th Colloquium for InformationSystems Security Education, Seattle, WA June1- 3, 2009.

[17] Georgory White and Georgory Nordstrom.1997. "Security across the curriculum: usingcomputer security to teach computer scienceprinciples". En Internet besieged, Dorothy E.Denning and Peter J. Denning (Eds.). ACMPress/Addison-Wesley Publishing Co., NewYork, NY, USA 519-525.



23

http://upcommons.upc.edu/revistes/bitstream/2099/11778/1/a25.pdf

http://upcommons.upc.edu/revistes/bitstream/2099/11778/1/a25.pdf

http://www.criptored.upm.es/guiateoria/gt_m001i1.htm

http://www.criptored.upm.es/guiateoria/gt_m001i1.htm

http://www.lamoncloa.gob.es/documents/20131332estrategiadeciberseguridadx.pdf

http://www.lamoncloa.gob.es/documents/20131332estrategiadeciberseguridadx.pdf

http://www.interior.gob.es/prensa/balances-e-informes/2013

http://www.interior.gob.es/prensa/balances-e-informes/2013

Evaluación mediante encuestas de la importancia de disponerde un repositorio de código individual, público y compartidopara los estudiantes de Grado de Informática en la región de

las Islas Baleares

Carlos Guerrero Judit Jiménez Isaac Lera Antoni Jaume-i-Capó Carlos JuizDepartament de Matemàtiques i Informàtica.

Universitat de les Illes Balears07122 Palma de Mallorca

{carlos.guerrero,judit.jimenez,isaac.lera,antoni.jaume,cjuiz}@uib.es

Resumen

Un gran número de prácticas que realizan los estu-diantes de informática durante su carrera se basan enel desarrollo del software. El almacenamiento más na-tural para este tipo de productos son los repositorioso forjas de código. La calidad de los desarrollos delalumno es una tarjeta de presentación excelente paralas posibles empresas que lo contratarán en el futuro.De hecho, cada vez son más las empresas que estudianel código desarrollado por sus candidatos como crite-rio de selección. Pero este tipo de trabajos no son losúnicos que pueden servir de evidencias de la calidadde un estudiante y, por ejemplo, memorias de prácticasy otros trabajos escritos también podrían formar par-te de esta carta de presentación. Este artículo analizala opinión de alumnos, profesores y empresas sobre lautilidad de disponer de portafolios virtuales individua-les para cada alumno en los que se almacenen todoslos trabajos llevados a cabo durante sus estudios. Pa-ra ello, se pasaron cuestionarios a alumnos, profesoresy representantes de empresas para evaluar el impactoque podría tener implantar un portafolio de estas ca-racterísticas disponible para los alumnos del Grado deInformática.

Abstract

A large number of works that computer science stu-dents perform during their career are based on softwaredevelopment. The most suitable systems to storage the-se works are sourceforge systems. The quality of the-se student’s developments is an additional advantatgewhen they will be hired by a company. In fact, compa-nies are increasingly using the software code as a se-lection critera for candidates. But these type of worksare not the only ones which can be used as evidence of

the quality of a student, for example, reports and otherwritten works could be also considered by companies.In this article, we analyze the views of students, tea-chers and companies about the usefulness of individualvirtual portfolios including all the work performed bya student during its studies. We have analyzed the ans-wers to questionnaires to students, teachers and com-panies in order to evaluate the potential impact of im-plementing a portfolio for computer science students.

Palabras claveForjas de código, Portafolios virtuales, Inserción labo-ral, Coordinación de asignaturas.

1. IntroducciónLas exigencias para que los recién egresados se in-

corporen al mercado laboral son cada vez mayores.Uno de los grandes problemas con los que se encuen-tran es el hecho de no disponer de experiencia laboraly no poder aportar evidencias sobre sus competenciasy capacidades reales. Por lo que las empresas tienencomo único criterio de selección el expediente acadé-mico de los recién titulados. Pero cada vez son más lasempresas que solicitan a los nuevos candidatos ejem-plos de programas desarrollados por ellos, bien comoaportaciones a proyectos particulares, o bien en formade prácticas durante la carrera. Todo esto son argumen-tos a favor de disponer de un portafolio individual paracada alumno, donde pudiera recoger todos los trabajosque ha ido realizando a lo largo de sus estudios. Estotendría una gran utilidad para ellos y podría servir decarta de presentación a la hora de ingresar en el mundolaboral.

El hecho de disponer de un lugar donde revisar todos



24

los trabajos y prácticas de un alumno puede beneficiar,a parte de a ellos mismos y a las empresas, a los profe-sores que les imparten docencia, pues tendrían eviden-cias de los conocimientos reales que tienen sus alum-nos y podrían, mediante el análisis de estos trabajos,detectar carencias en su formación y mejorar la coordi-nación entre asignaturas. Por tanto, consideramos queel hecho de disponer de estos portafolios virtuales po-dría beneficiar a alumnos, profesores y empresas.

Antes de emprender el inicio de un proyecto de estaenvergadura hemos considerado interesante evaluar ycontrastar nuestra opinión con todos los actores invo-lucrados. Para ello se han redactado unos cuestionariosdonde se busca evaluar la utilidad de los portafoliosy que han sido contestados por alumnos, profesores yempresas. En este artículo presentamos el análisis delas respuestas obtenidas de estos cuestionarios.

El artículo presenta inicialmente algunos trabajos re-lacionados con el uso de portafolios en la Sección 2.Posteriormente, en la Sección 3, se presenta el dise-ño y el proceso de realización de los cuestionarios. Enla Sección 4 se analizan las respuestas de los cuestio-narios. Finalmente se presentan las conclusiones y lostrabajos futuros que surgen de los resultados analiza-dos.

2. Estado del arteEl estudio y análisis de los portafolios es muy am-

plio y hay un gran número de trabajos de investigaciónpublicados sobre esta temática. Pero en la mayoría deellos la utilidad que se les da es principalmente la eva-luación y, en la mayoría de casos, limitada a una únicaasignatura. La novedad de nuestra propuesta radica enla utilidad que tendría para el alumno disponer de unportafolio con todos los trabajos de la carrera, con la in-tención de facilitar su incorporación al mundo laboral.Como segunda ventaja, los profesores podrían mejorarla coordinación entre asignaturas y detectar de formamás rápida carencias entre los alumnos que forman ungrupo o asignatura, gracias a que podrían analizar lostrabajos llevados a cabo por los estudiantes en otrasasignaturas y en cursos anteriores.

Como ya hemos dicho, la utilización del portafoliocomo herramienta de evaluación en una asignatura hasido estudiada y está contrastada en muchos trabajosya publicados como podemos ver, por ejemplo, en eltrabajo de Gracia y Pinar [3]. En otras ocasiones, sehan utilizado los portafolios para evaluar partes de unaasignatura, como sería el caso presentado en el trabajode Escudero [1], donde son utilizados para la evalua-ción de las prácticas de una asignatura. Este tipo deaplicación también se presenta en el trabajo de Arbe-laitz [2]. Pero en todos estos casos, siempre nos encon-tramos con una utilidad meramente evaluativa.

Existe algún trabajo, como el de Sánchez [4], que yaanticipan la importancia y beneficios de disponer de unportafolio que incluya todos los trabajos de un alumno,en este caso, como evidencia en la acreditación de títu-los. Pero en cualquier caso, en dicho trabajo no se llevaa cabo un análisis de todas las ventajas que se despren-den de poder disponer de este tipo de herramientas.

3. Diseño del estudioPara llevar a cabo el estudio se planteó un esquema

de investigación cualitativa basado en la contestaciónescrita de preguntas de respuesta libre. Los cuestiona-rios fueron contestados por profesores, alumnos y em-presa. El ámbito de dichas encuestas se limitó a la Uni-versitat de les Illes Balears y a empresas de la isla deMallorca.

El diseño del estudio empezó con la redacción detres encuestas distintas para cada uno de los grupos(estudiantes, profesores y empresas). A pesar de quelos enunciados de las encuestas variaban mínimamen-te, las preguntas estaban destinadas a obtener el mismotipo de información en las tres encuestas. A continua-ción mostramos las preguntas que se realizaron:

• ¿Considera que consultar los trabajos y prácticasdesarrollados por un estudiante puede ayudar a:los profesores en sus clases; a las empresas en laselección de empleados; a los estudiantes?

• En caso afirmativo, ¿qué mejora/ayuda aportaría?• ¿Qué tipo de material resultaría interesante incluir

en el repositorio de información del alumno?: Có-digo fuente desarrollado por el estudiante; memo-ria y documentación de los programas desarrolla-dos por el estudiante; trabajos de búsqueda y re-colección de información del estudiante llevadosa cabo de forma autónoma; documentos de análi-sis, diseño y otras fases del ciclo de desarrollo desoftware; resolución de problemas y actividadesde clase; otro tipo de material.

• ¿Cómo considera que debería de estar publica-da esta información? Haga referencia a cuestio-nes como la privacidad, herramientas de consulta,canales de publicación, etc.

• ¿Cómo considera que debería organizarse el por-tafolio para que su consulta fuera fácil y útil?¿Qué tipo de búsquedas debería de ofrecer la he-rramienta?

• ¿Qué tipo de herramientas consideraría más in-teresantes para implementar este tipo de portafo-lios?

El cuestionario fue diseñado inicialmente por unúnico profesor. Una vez redactado, se sometió a un pro-ceso de validación por expertos. Se distribuyó entre ungrupo de profesores colaboradores del estudio quienes



25

se encargaron de revisar que la redacción de las pre-guntas fuera clara y estuviera alineada con el tipo deinformación que se quería obtener de su realización.

El siguiente paso fue la selección de las personas en-cuestadas. La selección de los profesores y estudiantesa encuestar se realizó de forma aleatoria. El número deestudiantes de los estudios de informática durante elcurso 2014/15 es de 426 y el de profesores que impar-ten clase en los estudios es de 50. Se optó por seleccio-nar 12 alumnos de forma aleatoria que cubrían los cua-tro cursos de los estudios y 12 profesores que cubríanlas tres áreas de conocimiento involucradas mayorita-riamente en los estudios de informática. Los 12 pro-fesores seleccionados no tenían ninguna vinculacióncon el estudio, para evitar que sus opiniones estuvie-ran condicionadas de antemano.

Por el contrario la selección de las empresas no sehizo de forma aleatoria ya que se contactó directamen-te con las empresas con las que ya se había colabora-do en alguna ocasión. Se contactó con tres empresasdistintas, todas ellas dedicadas al sector de las nuevastecnologías y con importantes departamentos de desa-rrollo. En todas ellas, se solicitó la posibilidad de quela encuesta fuera contestada tanto por jefes de equiposde trabajo formados por informáticos, como por em-pleados involucrados en la selección del personal deperfil informático.

3.1. Realización de las encuestas

En una primera fase los cuestionarios se distribuye-ron entre las personas escogidas mediante el envío decorreo electrónico. Las encuestas iban acompañadas deuna pequeña introducción y contextualización del es-tudio que se estaba realizando. Una vez enviados, seesperó un tiempo de tres semanas para la recogida delas contestaciones. Tras ese periodo, se obtuvieron 8contestaciones de alumnos, 5 de profesores y 4 de em-presa.

En el caso de los alumnos 6 de las encuestas respon-didas correspondieron a alumnos de cuarto curso y 2de ellas a alumnos de tercer curso. Tres de ellas erande alumnos del itinerario de tecnologías de la informa-ción y 5 del itinerario de ingeniería de la computación.

En el caso de los profesores, las encuestas recogidascorrespondieron a tres profesores del área de Cienciasde la Computación e Inteligencia Artificial y dos a Ar-quitectura y Tecnología de la Computación. En ambosgrupos, cubrían tanto casos de docencia en primeroscursos como en últimos.

Finalmente, en el caso de las encuestas de las empre-sas, las cuatro encuestas correspondían a tres empre-sas, una dedicada a los videojuegos, otra al turismo yotra a un portal de contacto entre profesionales y clien-tes. Entre las cuatro cubrían personal correspondiente

a la gestión y dirección de equipos de desarrollo y per-sonal de recursos humanos encargados de la seleccióndel personal o incluso involucrado en ambos tipos detareas.

4. Análisis de resultadosEl análisis de los resultados recoge las conclusiones

a las que se han llegado tras el estudio de las respuestasa los cuestionarios. Cabe recordar que los cuestiona-rios están formados por 6 preguntas de respuesta librey que han sido pasados a tres actores distintos. El análi-sis se agrupa por preguntas en un primer nivel. Dentrode cada pregunta, se analizarán las coincidencias y di-ferencias entre las contestaciones de cada uno de lostres grupos de encuestados, profesores, alumnos y em-presas.

4.1. Utilidad de un portafolio virtualEn esta apartado vamos a analizar las respuestas de

la pregunta ¿Considera que consultar los trabajos yprácticas desarrollados por un estudiante puede ayu-dar a: los profesores en sus clases; a las empresas enla selección de empleados; a los estudiantes?. Esta pri-mera pregunta tenía como objetivo averiguar la opiniónsobre la utilidad de disponer de los trabajos realizadospor un alumno de informática a lo largo de su carrerauniversitaria centralizados en un portafolio virtual.

Esta pregunta ha sido contestada de forma positiva.Todos los entrevistados han considera muy interesantedisponer del código fuente, trabajos y proyectos desa-rrollados por los alumnos a lo largo de su vida universi-taria. De hecho, incluso algunas de la respuestas dadasdesde la empresa, han indicado que en sus procesos deselección ya solicitan en alguna ocasión este tipo dematerial a sus futuros empleados, valorando de formapositiva el hecho de que los alumnos dispongan de unrepositorio de código propio donde tengan almacena-dos proyectos individuales y autónomos, o bien prácti-cas realizadas durante la carrera.

Es necesario puntualizar que uno de los alumnos, apesar de considerar interesante esta alternativa, indi-ca que la utilidad del mismo solo tendría sentido paraprácticas realizadas durante tercero y cuarto curso dela carrera. Esto lo justifica debido a que las prácticasque se realizan durante los dos primeros cursos de losestudios no son de una complejidad tan grande comola de los últimos cursos.

4.2. Aplicaciones de un portafolio virtualúnico

La segunda pregunta de los cuestionarios se planteócon el objetivo de descubrir las posibilidades que les



26

ofrecería a cada sector el hecho de disponer de las prác-ticas realizadas por los estudiantes. Para ello se formu-ló la segunda pregunta de la siguiente manera: En casoafirmativo, ¿qué mejora/ayuda aportaría?.

Para los profesores, la mayor utilidad de estas he-rramientas es la posibilidad de mejorar la coordinaciónentre asignaturas. El hecho de disponer de las prácticasy trabajos llevados a cabo por los estudiantes a lo largode sus estudios, permite al profesor tener una idea másexacta de su grupo de alumnos, pudiendo de esta formaadaptar los contenidos de la asignatura al nivel de susestudiantes. Por el mismo motivo, sería una herramien-ta ideal para evitar repeticiones entre asignaturas y de-tectar carencias o conceptos menos asentados entre elgrupo y poder actuar en consecuencia para mejorarlos.

Otro punto destacable es el hecho de que los pro-fesores consideraron que tener una herramienta de es-te tipo les podría facilitar la realización de prácticascoordinadas entre asignaturas, de forma que una únicapráctica pudiera servir para evaluar más de una asigna-tura. Estos proyectos coordinados pueden incluso ha-cer más atractivas asignaturas que a veces cuestan mása los alumnos, si esas prácticas se combinan con las deuna asignatura más atractiva para el alumno.

También se planteaba la posibilidad de reutilizarprácticas de otros alumnos de cursos anteriores comobase de posibles ampliaciones o modificaciones. De es-ta forma se podría cubrir la competencia de enfrentarseal mantenimiento de código desarrollado por terceros,El mantenimiento de código es una práctica muy habi-tual en el ámbito laboral pero difícil de trabajar durantela carrera.

Igualmente, los profesores encuentran interesanteesta herramienta para poder contrastar las dimensionesy complejidad de otras tareas llevadas a cabo por elalumno, para poder adaptar las propias de su asignatu-ra a esas dimensiones. Algún profesor también indicaque puede ser interesante, según el tipo de repositorioque se utilice, el conocer la evolución de las prácticasa lo largo de su desarrollo y no únicamente el resulta-do final. Dicho de otra forma, si por ejemplo, se utilizaun gestor de versiones de código para almacenar lasprácticas de desarrollo, el profesor será capaz de verla evolución de todo el trabajo y la temporización delmismo. Por último, también citan como importante elhecho de poder controlar de forma más sencilla el pla-gio entre trabajos. Indican que sería interesante que laherramienta ofreciera mecanismos antiplagio sobre lostrabajos que se compartieran en el portafolio virtual.

El grupo de los alumnos da una gran importancia ala herramienta como sistema de soporte ante pérdidasde información o de las prácticas de cursos anteriores.También indican que si el sistema dispone de un buenmecanismo de búsqueda podría ser mucho más senci-llo localizar ciertas partes de su trabajo en cursos ante-

riores.Un punto importante que también resaltan los estu-

diantes es que este tipo de herramientas les podrían fa-cilitar el hecho de poder consultar prácticas de otrosalumnos de forma que podrían aprender de ellos. In-cluso, facilitando el incorporar mejoras en sus futurasprácticas a raíz de las ideas obtenidas de la revisión deprácticas de compañeros. Esto ayudaría a mejorar lacompetencia de lectura de código fuente de otros pro-gramadores.

Los estudiantes también indican que podría sermuy interesante reutilizar sus prácticas y actividadescon algún fin social, enfocando sus prácticas a unaprendizaje-servicio (ApS). De esta forma, los trabajoscompartidos podrían ser reutilizados por terceros paradar solución a algún tipo de problema de la comunidad.

También explican algunos estudiantes que estas he-rramientas podrían romper con el efecto de experien-cia cero que se encuentran muchas veces al buscar unprimer trabajo. Con un portafolio donde incluyeran to-dos sus trabajos desarrollados durante los estudios, po-drían suplir esa falta de experiencia con una evidenciade sus capacidades productivas. Igualmente, esto lleva-ría a que los estudiantes aumentaran el rendimiento yla calidad de sus trabajos, ya que al estar disponibles aterceros podría hacer que cuidaran más sus trabajos.

Finalmente, un estudiante aportó una idea bastanteinteresante sobre el proceso de inserción laboral de losestudiantes universitarios. Si las empresas dispusierande este material, las empresas podrían no limitarse aesperar que posibles candidatos a sus puestos de traba-jos acudieran a sus ofertas de trabajo, si no que tambiénpodrían tener un rol más activo en la incorporación detalento a sus empresas mediante procesos de escrutinioentre los alumnos a través de sus trabajos académicos,y que las empresas pudieran seleccionar activamenteestudiantes a los que presentar ofertas de trabajo. Estepunto lo consideramos muy interesante ya que actual-mente no puede ser llevado a cabo de ninguna manera,al menos en nuestra universidad.

En tercer lugar, analizamos las respuestas dadas porlas personas del sector empresarial. Cabe destacar quealguna de las empresas ya indicó que actualmente ensus procesos de selección solicitan a los candidatosproyectos o código de programas que hayan realizado,o bien durante sus estudios, o bien de forma indepen-diente. Así que de entrada, podemos ver que disponerde este portafolio sería una forma de cubrir unas ne-cesidades que ya algunas empresas tienen. Entre losaspectos más destacados, el conjunto de las encues-tas mostraban un interés por conocer la forma en queprograman sus futuros empleados, conociendo de an-temano la calidad, pulcritud y el orden del código quedesarrollan los candidatos.

Desde las empresas también indicaron que el tener



27

una visión de todo el trabajo llevado a cabo por un can-didato, les sirve para conocer sus intereses particula-res en alguna tecnología y los conocimientos concre-tos que tienen en cada una de las tecnologías que hanutilizado a lo largo de su vida. Con esta información,les sería mucho más sencillo el poder tomar decisio-nes sobre la contratación del personal, especialmenteen casos en los que tienen candidatos de valía similar.Además, una vez contratados, podrían determinar deforma más precisa los equipos de trabajo donde asig-nar al nuevo empleado y planificar mejor la formacióninterna de sus empleados, ya que sabrían en qué áreastienen unas debilidades mayores de formación. Inclu-so, les proporcionaría información importante para in-corporar alguna tecnología nueva en su empresa en laque el candidato tuviera un alto grado de experiencia.

Obviamente, disponer de todos estos trabajos pro-porciona una idea más clara de los conocimientos delcandidato. Por tanto, a las empresas les sería tambiénmás fácil detectar posibles incongruencias o exagera-ciones en los currículums.

4.3. Selección de tipos de actividades a al-macenar

El objetivo de la tercera pregunta del cuestionarioera descubrir qué tipos de trabajos podrían ser intere-santes incluir en el portafolio. Para ello se enumeraronuna serie de tipos de actividades (programas desarro-llados, memorias y documentaciones, trabajos de bús-queda de información, documentos de análisis y dise-ño, problemas resueltos, trabajos y proyectos) y unacategoría libre para indicar posibles casos no contem-plados entre los anteriores.

En el caso de menor interés se sitúan los problemasresueltos. Ninguno de los tres protagonistas (profeso-res, alumnos y empresas) demuestran un verdadero in-terés en que se almacenen los ejercicios o problemasresueltos durante la carrera. Uno de los motivos másimportante es el hecho de que esto no marcará diferen-cias entre alumnos, ya que normalmente las solucionesa los mismos serán muy parecidas, si no iguales.

Se extrae que los trabajos más interesantes a alma-cenar en el portafolio son los de desarrollo de código,especialmente en el caso en que las personas aspirena ocupar un puesto de desarrollador. De esta forma sepodría tener una visión de las capacidades de abstrac-ción, diseño descendente de programas, calidad de có-digo, etc. de cada uno de los estudiantes.

Se considera también bastante importante el hechode disponer de las memorias y documentaciones quehayan desarrollado los alumnos a lo largo de sus estu-dios, ya sea como elemento complementario a un tra-bajo, o como resultado único de un trabajo realizado.De esta forma se podrá apreciar el nivel de competen-

cia escrita que posee un estudiante y la claridad con laque se expresa y representa sus razonamientos y cómoafronta los problemas. Igualmente se puede compro-bar si el estudiante presenta la buena práctica y rutinade documentar los trabajos que realiza.

Los tres grupos opinan de forma diferente a la ho-ra de valorar la importancia de incluir los documentosrelacionados con el proceso de ingeniería del softwa-re asociado a un desarrollo de un programa. Estamoshablando de documentos de análisis, diseño, etc. Losprofesores y empresas consideran muy útil disponer deeste tipo de documentos para poder comprobar las ca-pacidades de abstracción, análisis, etc. Por el contrario,los alumnos indican que solo consideran importantedisponer de estos documentos en el caso de que acom-pañen al código desarrollado. Desde nuestro punto devista, esto podría venir explicado por el hecho de queno todos los alumnos encuestados son de último cursoy puede ser que aún no sean conscientes de la nece-sidad e importancia de este tipo de documentación encualquier proceso de desarrollo, ya no sólo en los mé-todos más tradicionales, sino también en los conocidoscomo métodos ágiles.

En lo que se refiere a trabajos autónomos relaciona-dos con la búsqueda y recolección de información, nosencontramos con que el nivel de interés expresado porlos encuestados en este apartado es relativamente esca-so. No están muy convencidos de la utilidad de guardareste tipo de material, por lo que la conclusión a la quellegamos es que no es necesario almacenar este tipo detrabajos.

Finalmente, se facilitó un espacio en la encuesta paraque los encuestado indicaran si consideraban de interésalmacenar algún otro tipo de trabajo o documentaciónque no se hubiera indicado en las opciones anteriores.Las aportaciones de los encuestados en este punto fue-ron muy distintas. Desde el profesorado se consideraque puede ser interesante almacenar las presentacionesque llevan a cabo los alumnos en clase. Más concre-tamente las diapositivas utilizadas por los alumnos, deforma que se pueda observar, por ejemplo, la capacidadde síntesis. Una extensión a esto, podría ser el registroy almacenamiento de un vídeo de la presentación delalumno. De esta forma, se podrían incluso comprobarlas competencias orales.

Desde el sector empresarial, indican la importan-cia de incluir en el repositorio no únicamente los tra-bajos realizados como trabajos de la propia universi-dad. Consideran que podría ser muy interesante quelos alumnos aportaran a este repositorio trabajos querealicen de forma autónoma. De esta forma, se puedecomprobar la inquietud de los estudiantes y su parti-cipación activa, por ejemplo, en proyectos de softwa-re libre, en becas de colaboración, investigación y queaportan un valor añadido al candidato. También con-



28

sideran que podría ser interesante disponer del expe-diente académico en dicho repositorio y que tambiénincluyera las notas de las distintas prácticas y trabajosrealizados, incluso, los comentarios de las correccio-nes.

Finalmente, el grupo de los alumnos considera in-teresante que se puedan almacenar las referencias y elmaterial suplementario que utilizan para la realizaciónde los trabajos, prácticas, etc. De esta forma, podríangenerar una pseudo-biblioteca virtual que les sirvierade consulta a ellos en el futuro, o a otros alumnos quese encuentren con actividades similares.

En resumen, podríamos considerar que de formaglobal, se le da una mayor importancia a poder incluiren el portafolio los resultados de los trabajos de desa-rrollo y las memorias y documentación generadas enestos procesos de desarrollo y en otros tipos de traba-jos/proyectos. Y lo que se podría descartar totalmenteson los trabajos relacionados con la resolución de pro-blemas y ejercicios de una asignatura y los de búsqueday recolección de información.

4.4. Características del portafolio virtual

La cuarta pregunta se planteó con el objetivo de eva-luar las caraterísiticas técnicas de la herramienta queimplementaría el portafolio virtual. Para ello se enun-ció la pregunta ¿Cómo considera que debería estar pu-blicada esta información? Haga referencia a cuestio-nes como la privacidad, herramientas de consulta, ca-nales de publicación, etc..

El análisis de este punto lo separaremos en dos apar-tados. El primero de ellos hace referencia a la tecnolo-gía para implementar la herramienta de portafolio. Eneste punto, todos los actores coinciden en las conclu-siones, considerando que se debe de tratar de una he-rramienta en línea, basadas en almacenamiento en lanube y con acceso principalmente desde un ordenadorpersonal. Por el tipo de aplicación, no consideran in-teresante poder acceder a la aplicación desde disposi-tivos móviles. También se indica que la gestión y cus-todia de los datos, debería de ser responsabilidad de launiversidad. Así que el encargado de mantener y des-plegar la herramienta debería ser la propia universidad.

En cuanto a los temas de privacidad, existen diver-sidad de opiniones según el grupo consultado. No seaconseja, de forma general, que sea un acceso público.Se propone que el alumno tenga la capacidad de ges-tionar los permisos de acceso. Esto facilitará al alumnopoder mostrar únicamente los trabajos que consideremás meritorios, teniendo la posibilidad de no mostrarlos trabajos que no sean de calidad suficiente. Esta ideano surge únicamente de los estudiantes, principales in-teresados en poder tener el control de qué trabajos mos-trar y cuales no, sino también de los otros dos sectores,

profesores y empresas. Aunque alguno de los profeso-res si que desearía poder consultar los trabajos pasadosde sus alumnos para tener una idea más clara del nivelde la clase.

De forma general, la opinión es que la gestión de laprivacidad se realice por parte del alumno y que debe-ría de basarse en niveles de privilegios según el tipo deusuario. Los tipos de usuarios podrían ser, creadores,compañeros de clase, profesores que imparten clase alalumno, profesores que no imparten clases, empresasen las que el alumno está en un proceso de selección uotro tipo de relación con la empresa y empresas en ge-neral. El tipo de privilegios sobre el portafolio vendríaúnicamente definido como permiso de lectura o no, yaque no tiene sentido que se produzcan modificacionessobre el portafolio, si no son realizadas por el propioalumno propietario del trabajo.

Los alumnos consideran interesante poder almace-nar junto a los trabajos las notas y los comentariosrecibidos por los profesores. También indican que lostrabajos a los que asignen permisos de lectura gene-ral puedan ser visualizados por cualquier persona queacceda al sistema, sin necesidad de identificación niregistro, para así facilitar el acceso a los datos de unalumno. De igual forma, sería muy interesante dispo-ner de un perfil de cada alumno donde se pudieran vertodos sus trabajos y que el alumno fuera también capazde editar un formato de currículum en línea que acom-pañara a su perfil y donde pudiera enlazar los conoci-mientos que indica en su currículum con los trabajosrelacionados que haya realizado sobre dicha capacidado competencia.

Por el lado de la empresa, la puntualización más im-portante es que todas las empresas que quieran acce-der a dicha información deberían de firmar un contratode confidencialidad para poder tener acceso al sistema.Igualmente, se puntualiza que sería interesante dispo-ner de un acceso a todo el proceso de desarrollo delos trabajos de los alumnos y no únicamente acceso ala versión entregada para su evaluación. Dicho de otraforma, que la herramienta debería de tener un controlde versiones y que el alumno debería de ir confirman-do sus avances de forma periódica en la herramienta amedida que va realizando los trabajos.

En el caso de los profesores, las necesidades expre-sadas son muy parecidas a las anteriores, pero indican-do que el coordinador de los estudios pueda tener ac-ceso a toda la información de todos los alumnos. Yademás, que los profesores que dan clase a un alumnopuedan acceder a todo el portafolio completo de losalumnos independientemente de los permisos de acce-so que el alumno haya configurado.



29

4.5. Organización del portafolio y bús-queda de trabajos

La siguiente pregunta del cuestionario iba encami-nada a conocer el tipo de búsquedas sobre los traba-jos almacenados que desearían hacer los distintos en-cuestados y, en consecuencia, detalles de cómo organi-zar la información dentro del repositorio. Para ello, seenunció la siguiente pregunta: ¿Cómo considera quedebería de organizarse el portafolio para que su con-sulta sea fácil y útil? ¿Qué tipo de búsquedas deberíade ofrecer la herramienta?. Las respuestas analizadascoinciden en su mayor parte entre los tres sectores im-plicados, así que pasaremos a hacer el análisis en glo-bal en lugar de separarlo en tres partes.

Según la gran mayoría de encuestados, los trabajosdeberían de estar organizados en forma jerárquica si-guiendo una serie de niveles organizados de la siguien-te forma: alumno, año académico, curso, asignatura,tipo de trabajo. Y que las consultas se puedan hacersobre cualquiera de estos cinco atributos y sobre cual-quier combinación de los mismos.

Adicionalmente, sería interesante disponer de ciertametainformación adicional sobre cada uno de los tra-bajos almacenados en el portafolio. Esta informaciónadicional incluiría los autores o estudiantes que parti-ciparon en la elaboración del trabajo, las horas dedica-das, los lenguajes o tecnologías utilizadas, la fecha, lanota de la actividad, los comentarios del profesor sobreel trabajo, los objetivos del mismo y las competenciastrabajadas. Sobre cada uno de los campos de esta me-tainformación adicional también se deberían de habili-tar facilidades de búsqueda. También sería interesantedisponer de un sistema de etiqueta de trabajos sobre elque también se pudieran realizar búsquedas.

4.6. Tecnología a utilizar en el portafoliovirtual

Finalmente, la última pregunta iba dirigida a averi-guar las tecnologías que proponían los distintos acto-res. Para ello la pregunta que se realizó fue ¿Qué ti-po de herramientas consideraría más interesantes pa-ra implementar este tipo de portafolios?.

De las respuesta analizadas se extrae la necesidadde crear una herramienta que integre otros serviciosexternos. Esto se debe a que se sugieren distintas he-rramientas de almacenamiento en función del tipo detrabajo que se vaya a almacenar en el portafolio. Porejemplo, para el almacenamiento del código de traba-jos de desarrollo se sugiere la utilización de sistemascomo Bitbucket, GitHub o similar, donde se encuen-tran implementados sistemas de control de versiones yde almacenamiento de código fuente. Las característi-cas de estos sistemas son ideales para almacenar estetipo de información, pero dificulta el almacenamiento

de otros tipos de trabajos. Así que por ejemplo, pa-ra almacenar documentaciones y trabajos escritos seríamucho más conveniente el uso de herramientas comoGoogle Drive, Dropbox o similar.

En cualquier caso, parece claro que todos los tra-bajos se deberían de almacenar en sistemas de muydiferente tipo en función del trabajo a almacenar, pe-ro todos ellos basados en la nube y que existiera unaaplicación paraguas que se encargara de integrar todosestos sistemas y de añadir las características de priva-cidad, de gestión de metainformación, de implementa-ción de las búsquedas y de la gestión de los perfiles ycurrículums de los estudiantes.

En relación a las herramientas de gestión del códi-go, se indica que sería muy interesante que estos repo-sitorios dispusieran de características de visualizacióngráfica del código, o dicho de otra forma, que resaltaralas palabras claves, cambiara de color según el tipo deinstrucción, etc. Igualmente, y desde el sector empresa-rial, se aporta la idea de integrar algún sistema de aná-lisis de código, para medir la calidad del código pro-ducido por cada estudiante, al estilo de jetbrains.com.También consideran interesante el poder disponer deLive Demos que les permitan la ejecución de los pro-gramas desarrollados por los estudiantes y no limitarsea analizar el código obtenido.

4.7. Reflexión

Consideramos oportuno igualmente incorporar eneste artículo una reflexión sobre las utilidades que losautores consideramos podrían ser interesantes y quesurgen de disponer de una herramienta de portafoliovirtual de los estudiantes, pero que no han sido indica-das por ninguno de los encuestados.

En primer lugar, pensamos que para el profesorado,y más en particular para la propia institución universi-taria, el disponer de este tipo de herramientas les apor-taría ciertos beneficios a la hora de evaluar la calidadde los estudios, ya que dispondrían de forma unificaday personalizada para cada alumno, de un gran núme-ro de elementos de evaluación de sus asignaturas. Eldisponer de estos elementos de evaluación y, en conse-cuencia, tener la posibilidad de analizarlos, ayudaría adetectar problemas en el plan de estudios, carencias co-munes entre los estudiantes y detectar si se cubren lascompetencias de los estudios. Por tanto, la calidad delos estudios podría mejorar gracias al hecho de dispo-ner de estos portafolios virtuales. Todo este tipo de ma-terial podría presentarse como evidencias en los proce-sos de acreditación de los títulos.

Finalmente, también nos ha llamado la atención queninguno de los entrevistado haya indicado la posibili-dad de dar un cariz más social a estos repositorios. Lomás cercano a esta idea ha sido el hecho de considerar



30

interesante almacenar junto a los trabajos los comenta-rios que ha realizado el profesor a la corrección del tra-bajo. Pero nosotros pensamos que también podría serinteresante disponer de retroalimentación de cualquierusuario del portafolio, de forma que los trabajos pue-dan ser comentados entre distintos usuarios, comparti-dos entre ellos o incluso cualificados con sistemas depuntuación/me gusta. Incluso, que otros alumnos pue-dan incorporar en un repositorio particular e indepen-diente trabajos llevados a cabo por otros alumnos, peroque por su calidad, otros alumnos desean conservar ensus registros personales para poder aprender de ellos.Con todo esto, se podría incluso llegar a asignar valo-res de influencia a cada uno de los alumnos, al igualque hacen algunos sistemas de almacenamiento de ar-tículos como es el caso de ResearchGate.

5. Conclusión

En este artículo se ha presentado un análisis de laopinión de profesores, empresas y alumnos en relacióna la utilidad de disponer de un portafolio individual pa-ra cada estudiante de informática en el que se inclu-yan trabajos que el alumno desee utilizar como cartade presentación a la hora de buscar trabajo. El trabajose ha basado en la realización de encuestas en los tresgrupos de personas involucrados.

Del análisis de las respuestas, se ha puesto de mani-fiesto la utilidad del portafolio a la hora de evaluar laidoneidad de un candidato recién egresado para cubrirun puesto vacante en una empresa. Una aplicación adi-cional que algunos profesores consideran interesantespara el portafolio la de mejorar la coordinación entreasignaturas gracias a que los profesores tendrían unavisión más clara y real de los alumnos que forman par-te de sus clases, facilitando la detección de carencias ylagunas entre sus alumnos y adaptando de forma máscorrecta los contenidos de una asignatura.

Una vez comprobada la utilidad de un portafolio deestas características, el trabajo futuro debe centrarse enel desarrollo de una herramienta que sirva de integra-dor de diversos sistemas de almacenamiento en la nu-be. Existen un gran número de sistemas especializadosen almacenar distintos tipos de productos o trabajos(proyectos de desarrollo con el código fuente, docu-mentación, etc.). Sería necesario analizar las ventajase inconvenientes de cada uno y seleccionar una solu-ción concreta para almacenar cada uno de los tipos detrabajo que realiza un alumno. Finalmente, sería nece-

sario integrar todos estos sistemas dentro de un siste-ma desarrollado con el fin específico de gestionar estosportafolios, gestionar el control de acceso a los traba-jos, facilitar la organización y búsqueda de los trabajosy la creación de perfiles personales de los estudiantesdonde puedan mostrar sus trabajos e incluir informa-ción a modo de currículum.

Agradecimientos

Este trabajo está financiado parcialmente por el pro-yecto PID141511- Ús de repositoris de codi com acarpeta d’aprenentatge per a estudiants d’informàtica,dentro de la convocatoria de ayudas a proyectos de in-novación y mejora de la calidad docente de la Univer-sitat de les Illes Balears del año académico 2014-15.

Agradecer la participación en las encuestas de losalumnos de los estudios de Grado en Informática de laUIB y a los profesores del Departamento de Matemá-ticas e Informática, al igual que a las empresas que hanayudado con sus aportaciones (Habitissimo SL, Logi-travel Group y Kitmaker Entertainment SA).

Referencias[1] Gerard Escudero, Sebastian Tornil, Pedro Gomis,

Antoni Perez-Poch, and Samir Kanaan. Innova-ciones docentes en un proceso de mejora continuapara una asignatura de fundamentos de programa-ción en ingeniería industrial. XIV Jornadas de En-señanza Universitaria de la Informática (JENUI).Universidad de Granada, 2008.

[2] Olatz Arbelaitz Gallego, José I. Martín Aramburu,and Javier Muguerza Rivero. Aprendizaje coope-rativo y basado en proyectos en la asignatura arqui-tectura de computadores. Revista de Investigaciónen Docencia Universitaria de la Informática, 2(2),2013.

[3] Joaquín Gracia Morán and MA Pinar Sepúlveda.Una experiencia práctica de evaluación por com-petencias mediante el uso del portafolio del es-tudiante y su impacto temporal. Revista de For-mación e Innovación Educativa Universitaria. Vol,2(2):76–86, 2009.

[4] Fermín Sánchez. Evidencias para acreditar una ti-tulación de grado. Actas de las XX JENUI. Oviedo,9(11), 2014.



31

Cambio a metodología de clase inversa en una asignatura

obligatoria

Sílvia Terrasa Barrena Gabriela Andreu García Departament de Informática de Sistemas y

Computadores

Departament de Informática de Sistemas y

Computadores

Universitat Politècnica de València Universitat Politècnica de València

Valècia Valècia [email protected] [email protected]

Resumen

Adaptarse al nuevo carácter de nuestros estudiantes

implica un cambio en las metodologías docentes

utilizadas. Una experiencia piloto basado en el uso

de la metodología denominada clase inversa (flip-

teaching) ha sido desarrollada durante el último

curso académico en la Universitat Politècnica de

València (UPV). La experiencia cuenta con la

colaboración de la Escuela Técnica Superior de

Ingeniería Informática (ETSINF) en la que todas las

asignaturas obligatorias de segundo curso de grado

han participado.

El presente trabajo describe la experiencia particu-

lar llevada a cabo en la asignatura Fundamentos de

los Sistemas Operativos (FSO). En primer lugar se

expone el contexto de FSO para continuar plante-

ando la estrategia utilizada y los resultados acadé-

micos obtenidos. Además se realiza una reflexión

sobre la necesidad del cambio del rol del profesor y

del alumno en el aula, para poder adaptarse a la

metodología flip. El papel finaliza presentando

conclusiones desde dos puntos de vista los alumnos

participantes y los profesores implicados.

Abstract

Adapt to the new character of our students involves

a change in teaching methodologies. A pilot project

based on the use of the methodology flip-teaching

has been developed during the last academic year at

the Polytechnic University of Valencia (UPV).

This experience has the support of the School of

Engineering (ETSINF). All compulsory subjects of

second degree course have participated in the

experience.

This paper describes the particular experiment

carried out in the course Fundamentals of Operating

Systems (FSO). First the context of FSO is exposed

to continue considering the strategy followed and

academic results. Also it reflects about the need to

change the role of teacher and student in the

classroom, to adapt to the methodology flip-

teaching. The paper concludes by presenting the

findings of participating students and teachers

involved.

Palabras clave

Flip-Teaching, aula inversa, clase inversa.

1. Introducción

El uso generalizado de las nuevas tecnologías entre

los jóvenes estudiantes en estos últimos años, ha

provocado un cambio en las metodologías docentes.

El profesorado ha realizado esfuerzos significativos

por incorporar material digital a su labor docente

adaptándose así a lo que unos “jóvenes tecnológi-

cos” reclamaban e innovando para conseguir captar

su atención y tratar de motivarlos en aras de un

buen aprendizaje. Además los estudiantes universi-

tarios actuales y en particular los que cursan grados

de ingeniería, muestran una mayor preferencia por

adquirir conocimiento “practico-útil” frente al

conocimiento teórico y se encuentran más motiva-

dos cuando trabajan las materias desde un punto de

vista aplicado.

Prácticamente todos los estudiantes universitarios

disponen de su propio portátil o Tablet y es habitual

que lo lleven consigo a las clases magistrales y

practicas de laboratorio. Tanto las Tablets, como los

portátiles e incluso el teléfono móvil son capaces de

almacenar gran cantidad de información y les

permite disponer de libros y material de estudio a

cualquier hora y prácticamente en cualquier lugar.

Esto supone una flexibilización de los espacios y

tiempos en los que los estudiantes pueden dedicarse

a trabajar sus materias o profundizar en ellas. Re-

cientemente se ha producido un incremento consi-

derablemente de los espacios con disponibilidad de



32

Wifi e internet permitiendo la transmisión de in-

formación y la comunicación sea prácticamente

instantánea. Esto hace posible que los estudiantes

puedan trabajar en grupos y colaborar en la resolu-

ción de tareas a pesar de encontrarse a grandes

distancias unos de otros o fuera de su centro de

estudio.

Estas cualidades exigen del profesorado una reno-

vación organizativa de sus asignaturas y una re-

flexión sobre como introducir el uso del material

digital en su labor docente. Se trata de mejorar,

facilitar y potenciar la adquisición de conocimiento

con ayuda de la tecnología sin abandonar aquellos

mecanismos tradicionales que dotaban a los alum-

nos de buenas cualidades profesionales. Este equi-

librio entre metodologías significa un reto impor-

tante para el docente.

En general, al profesorado le aterra la posibilidad

de que un uso inadecuado de la tecnología en la

etapa de aprendizaje conduzca a generalizar los

comportamientos de actuar sin pensar en nuestros

jóvenes. Como parte de nuestras funciones educati-

vas está el conseguir que aprendan a razonar a

pensar a deducir a inferir. Se trata de que adquieran

la habilidad y capacidad de seguir aprendiendo de

poder adaptarse a entornos diferentes [4]. En cierto

modo, los docentes tememos que con el uso de las

herramientas tecnológicas nuestros jóvenes se

habitúen a hacer “Click” o seleccionar opciones y

esperar a ver que sucede. Mientras que según las

metodologías tradicionales lo adecuado sería co-

menzar por razonar y tras lo cual seleccionar el

“Click” más adecuado.

Además con el uso del computador llegó la interac-

tividad, necesitamos obtener repuestas rápidas ante

una solicitud. Estamos acostumbrados a realizar

preguntas y obtener respuestas prácticamente inme-

diatas. A que tras una respuesta que no nos satisface

o inadecuada para la situación propuesta volver a

formularla de otra manera, a que el ordenador nos

sugiera como hacerlo. La interactividad es parte de

nuestra vida cotidiana. Existe una tendencia genera-

lizada de cuando surge una duda preguntar a inter-

net en vez de esperar a plantear la duda en el aula.

Con todos estos condicionantes el perfil de nuestros

estudiantes ha cambiado. Esto nos lleva a la nece-

sidad de poner en marcha nuevas metodologías

docentes y nuevas relaciones profesor-alumno. El

esquema tradicional basado principalmente en

clases magistrales puramente expositivas no incen-

tiva al alumno actual y desmotiva su participación

en el aprendizaje. Los nuevos elementos exigen un

cambio de rol en el aula tanto del alumnado como

del profesorado. En definitiva se trata de que el

alumno consiga un aprendizaje más efectivo y por

ende más satisfactorio.

Frente a estas exigencias del alumnado muchas

universidades españolas han comenzado a destinar

recursos y esfuerzos a los denominados proyectos

de innovación docente. Con ello se pretende apo-

yar al profesorado universitario a realizar los

cambios de rol en el aula. Se trata en la mayoría de

los casos de evaluar previamente cual puede ser el

modelo educativo apropiado para un determinado

contexto. En concreto la Universitat Politécnica de

Valencia (UPV) durante el curso 2014-2015 ha

destinado una gran cantidad de recursos para la

puesta en marcha de una experiencia piloto basada

en el modelo educativo de “aula inversa” o “ flip-

teaching”.

En este trabajo presenta la experiencia piloto de la

asignatura Fundamentos de Sistemas Operativos

(FSO) de 2º año de Grado en Informática dentro de

este curso piloto. Este artículo expone la metodo-

logía previa utilizada en FSO mediante evaluación

continua, los conceptos en los que se basa el flip-

teaching, la experiencia realizada junto con la

critica recibida por parte de los alumno, finalizando

con las conclusiones sobre la experiencia y algunos

aspectos a tener en cuenta para el futuro.

2. FSO una Materia Dinámica

Con la llegada del grado y las nuevas titulaciones

comienzan a implantarse los modelos de evaluación

continua en las asignaturas universitarias. Las

propias escuelas universitarias desde sus decanatos

comienzan a exigir al profesorado que ponga en

marcha este modelo de evaluación. En concreto en

la Escuela Técnica Superior de Ingeniería Informá-

tica (ETSINF) de la UPV se redactan recomenda-

ciones que deben llevarse a cabo para evaluar a los

alumnos. Estas recomendaciones son aprobadas en

su junta permanente y después de varios cursos se

han convertido en una obligación más que una

recomendación. De una manera resumida las reco-

mendaciones sugieren:

a) Que hayan varios actos de evaluación para

cada materia con un mínimo de tres.

b) Que se valore la participación del alumno en

el aula y en el laboratorio

c) Que todas las actividades que realice el alum-

no en la asignatura contribuyan con un porcentaje a

configurar su nota final.

Además, los modelos de evaluación seguidos por

cada asignatura deben aparecer en la guía docente

de la asignatura y está debe ser publica.



33

Por otra parte, hemos de ser conscientes que las

nuevas titulaciones de grado también aparecen las

competencias. Debemos asegurarnos de que nuestra

modelo docente es adecuada para la consecución

de un conjunto de competencias, tanto específicas

como transversales. Además en el reparto de horas

lectivas de las asignaturas de grado aparecen dife-

renciadas la teoría de aula (TA), teoría de seminario

(TS) y prácticas de laboratorio (PL).

Todo ello conllevo al profesorado de FSO a plante-

ar una asignatura sin perder su identidad y remar-

cando los conceptos propios de la misma que cum-

pliese estos nuevos requisitos. En esta primera

adaptación a grado ya percibimos la necesidad de

darle un mayor enfoque practico-útil, comentado

anteriormente, a nuestra materia con el objetivo de

conseguir una mayor motivación en nuestros alum-

nos.

FSO es una asignatura obligatoria del grado de

Ingeniería Informática de 2º curso (semestre A) con

6 créditos (2.25 TA+2.25 TS +1.5 PL). En la reali-

dad FSO se desarrolla durante 15 semanas con 90

minutos de TA, 90 minutos TS y durante 10 sema-

nas con 90 minutos de PL. Los objetivos principa-

les propuestos para FSO son:

Estudiar los conceptos básicos, técnicas funda-

mentales, y organización de los Sistemas Opera-

tivos (S.O.)

Comprender las diferentes políticas que guían la

implementación de un S.O.

Conocer los servicios proporcionados por los

Sistemas Operativos. Desarrollar aplicaciones

utilizando llamadas al sistema

Adquirir destreza, al menos a nivel de usuario,

en el manejo de un sistema operativo

Fig. 1: En FSO se trabajan los conceptos a tres

niveles.

FSO no es una materia fácil ni de impartir por el

profesorado ni de asimilar por los estudiantes. Se

trata de la primera asignatura de sistemas operati-

vos que abordan nuestros alumnos en el grado y por

lo tanto en ella ven todas las barreras de enfrentarse

a nuevas temáticas. Nos propusimos plantear para

FSO un modelo de docencia donde el alumno

recorriese de una manera fluida la distancia que hay

desde el concepto a la puesta en práctica del mismo.

Se trata de estimular la necesidad de aprender

mediante la aplicabilidad.

Para ello nuestro método de trabajo trata de poner

de manifiesto al alumno que “ los conceptos teóri-

cos aparecen en la realidad y somos capaces de

ponerlos a funcionar”. Por tanto, trabajamos los

conceptos a tres niveles en una misma semana: en

TA realizamos una descripción conceptual y des-

criptiva del concepto, en TS mostramos herramien-

tas disponibles para llevar a cabo su implementa-

ción y les proponemos a los alumnos desarrollos de

ejemplos donde se utiliza el concepto. La figura-1

muestra estos tres niveles de trabajo, mientras que

en la figura-2 se expone el material utilizado para

uno de los conceptos trabajados como es la creación

de procesos (llamada fork()).

Figura 2: Ejemplo del material utilizado en los

tres niveles con la llamada fork().

Respecto a la evaluación llevado a cabo se trata

de una evaluación continua donde se realizan dos

ejercicios de evaluación escritos que configuran el

70% de la nota final, los ejercicios propuestos

durante las clases teóricas contribuyen con un 10%

y las prácticas de laboratorio que se evalúan direc-

tamente en las sesiones de laboratorio con el 20%.

Las conclusiones de la puesta en práctica de esta

dinámica son las siguientes:

Aumento de la partición de los alumnos en el

aula.

Buenos resultados de presentados y aprobados.

Necesidad de una fuerte sincronización entre las

clases de teoría, seminarios y prácticas.

Aumento del rendimiento de los alumnos en

prácticas.

La evaluación continua de prácticas requiere

gran esfuerzo del profesorado en el laboratorio.

La contribución a la nota final de todos los es-

fuerzos que realiza el alumno consigue un ma-

yor número de aprobados y dificulta la obten-

ción de Matrícula de Honor.



34

La figura 3, muestra los resultados de evalua-

ción obtenidos durante el curso 2012-2013: EE1

y EE2 hace referencia a los ejercicios de eva-

luación escritos, mientras que laboratorio y cla-

se hacer referencia a las notas de las prácticas de

laboratorio y aula.

Fig. 3 Estadísticas de actos de evaluación.

En este contexto aparece la experiencia piloto de

clase inversa de la UPV y FSO se une a dicha

experiencia.

3. Clase Inversa: Idea básica

El concepto de clase inversa fue consolidado por

Jonathan Bergmann y Aaron Sams [1], [2] (2007) y

se basa en modificar la estructura tradicional de las

clases haciéndola mas cooperativistas e intercam-

biando las tareas. Así la palabra inversa hace refe-

rencia a que aquellas tareas que tradicionalmente se

dejaban como trabajo fuera del aula para los alum-

nos ahora se realizan conjuntamente en el aula con

la supervisión del profesor [4]. Sin embargo el

alumno debe dedicar tiempo a asimilar los conteni-

dos más teóricos y que tradicionalmente comprend-

ían gran parte de las clases magistrales fuera del

aula. El material teórico debe ser proporcionado

por el profesor en formato digital, tipo videos,

podcast, documentos, etc. mientras que la respon-

sabilidad de trabajarlo recae sobre el alumno.

El papel del profesorado en la clase inversa es más

exigente que en la tradicional [3]. Durante el tiem-

po de clase el profesor debe estar observando

continuamente a sus alumnos, proporcionándoles

información relevante en el momento y evaluando

sus trabajos. Además debe despertar el interés del

alumno incentivando su participación en el aula y

proporcionándole un material atractivo para su

estudio.

Para que el modelo educativo de clase inversa tenga

éxito, el compromiso de los estudiantes ha de ser

mayor que en el método tradicional. El aula inversa

exige que los estudiantes realicen un trabajo previo

a la asistencia a clase acorde con la propuesta

realizada por el profesor. El aprovechamiento y la

efectividad de las clases presenciales dependen en

gran medida de que el alumno haya visto el video o

leído el documento propuesto. Las clases inversas

son mucho más enriquecedoras para los estudiantes,

que las tradicionales, ya que les permite plantear

sus preguntas y defender su razonamientos a la vez

que son orientados por el profesor.

Algunas de las ventajas que pueden encontrar en

este modelo educativo son:

Se crea un ambiente colaborativo y participati-

vo en el aula que involucra profesor- alumno.

Se ajusta mejor a ritmos de trabajo diferentes

ya que el alumno puede visionar e incidir so-

bre el material teórico tantas veces como lo

crea necesario.

Permite al profesor identificar con facilidad

aquellos conceptos sobre los que lo alumnos

deben incidir.

Permite al docente trabajar con la diversidad.

El profesorado comparte información y cono-

cimiento de forma más directa e involucra a

los estudiantes en el proceso formativo.

4. La Experiencia Piloto en FSO

Durante el curso 2014-2015 la Universitat

Politècnica de Valencia puso en marcha una

experiencia piloto basada en aula inversa. De forma

consensuada entre el profesorado que manifestó

interés y las escuelas implicadas se definió unos

requisitos que debía cumplir los grupos implicados

en esta experiencia. Los requisitos del grupo

fueron:

El número de alumnos del grupo debía ser de

entre 25 y 30. Frente a los 60-70 alumnos que

tiene un grupo normal en clase magistral.

Los alumnos debían seleccionar de forma vo-

luntaria su adscripción a aula inversa y com-

prometerse con la experiencia.

El sistema de evaluación debía ser el mismo

para todos los alumnos de la asignatura con

independencia de si eran de la experiencia pi-

loto o no. Este requisito nos permitía comparar

el rendimiento entre metodologías.

Estas restricciones permiten controlar la

experiencia, hace que los resultados sean

extrapolables y comparables con los obtenidos en el

resto de grupos. Con todo esto también se quería

garantizar el poder extender la metodología de clase

inversa a un amplio espectro de asignaturas si los

resultados eran relativamente satisfactorios. La

UPV puso a disposición del profesorado

herramientas para digitalizar las clases magistrales



35

así como el asesoramiento de profesionales que

trabajan en el Instituto de Ciencias de la Educación

(ICE). El ICE asesoró al profesorado en el diseño

de las actividades a desarrollar tanto en el aula

como las vinculadas a los contenidos digitales.

4.1. Clase flip en FSO

Con el planteamiento descrito en el apartado an-

terior, la Escola Tècnica Superior d'Enginyeria

Informàtica (ETSINF) puso en marcha un grupo

piloto de clase inversa en todas las asignaturas

obligatorias de segundo curso de la titulación de

Grado en Ingeniería Informática. A estos grupos se

les denominó grupos flip.

Para analizar los resultados cuantitativos y cualita-

tivos de los grupos flip hay que tener en cuenta la

organización docente de la ETSINF y en concreto

el contexto de FSO:

El número total de grupos docentes de FSO

fue de 7: 1 grupo ARA con docencia en ingles,

1 grupo con docencia en valenciano, 5 con do-

cencia en castellano y un grupo flip.

El número de alumnos por grupo fue de 10 pa-

ra el grupo flip, 35 alumnos para el grupo

ARA y entre 55-65 para el resto de los grupos

de la asignatura.

Las pruebas y métodos de evaluación fueron

los mismos para todos los alumnos que cursa-

ron la asignatura FSO. En concreto durante es-

te curso académico la asignatura se evaluó a

partir de tres conceptos: seguimiento en el aula

aporta un 10% a la nota final, trabajo en el la-

boratorio con un 20% y 2 pruebas de evalua-

ción escrita que representan el 70% (30% y

40%).

La dinámica de trabajo que se siguió en el aula flip

fue la siguiente:

1. Proporcionar material digital al alumno: Antes

de cada clase presencial, se les proporcionaba

a los alumnos el material para que prepararan

los aspectos teóricos que se trabajarían en cla-

se. El material consistió principalmente en

documentos en digital de tamaño reducido

donde se abordaba un único concepto y en vi-

deos que contenían la grabación de una clase

magistral.

2. Crear un ambiente de debate: Los 15 primeros

minutos de cada clase se dedicaban a la inter-

vención de los alumnos. Durante este tiempo

se les preguntaba sobre el material visualizado

o leído y se incentivaba la participación de los

alumnos así como el planteamiento de dudas.

3. Extraer conclusiones: Tras el debate el profe-

sor resaltaba aspectos significativos y extraía

conclusiones.

4. Trabajo participativo: Los 70 minutos restan-

tes de la clase se dedican a la resolución con-

junta de problemas y ejercicios. Durante este

tiempo se trabajaba tanto individualmente con

cada alumno como en grupo de tres según el

tipo de ejercicios.

5. Resultados académicos

cuantitativos y cualitativos

Tanto desde el punto de vista estrictamente

académico como desde nuestra experiencia do-

cente personal, consideramos un éxito los resul-

tados obtenidos en la experiencia piloto de clase

inversa en la asignatura de FSO.

En cuanto a los resultados académicos, el ren-

dimiento medio en el grupo flip y la nota media

del grupo es muy superior al del resto de los

grupos de FSO como se puede observar en la fi-

gura-4. Incluso el grupo flip supera la media del

grupo de alto rendimiento o grupo ARA.

Fig. 4 Rendimiento grupo flip de FSO

Obviamente si comparamos el número medio de

alumnos en el resto de grupos (55-65 alumnos)

es mucho mayor y por tanto hay que ser preca-

vidos con el resultado del del grupo flip. Eviden-

temente con 10 alumnos en clase es más fácil

que funcione cualquier metodología. En este

punto es cuando es necesario introducir los re-

sultados cualitativos, que si bien pueden resultar

subjetivos y parciales, es necesario tenerlos en

cuenta al valorar la experiencia.

Como se puede ver en el video [5] los estudian-

tes que participaron en la experiencia piloto

están totalmente convencidos de los siguientes

aspectos referidos a la clase inversa:

El planteamiento de la docencia inversa, les

exige (y les permite) llevar al día las asignatu-

ras.

El esfuerzo inicial, que supone el cambio de

hábitos, es recompensado con creces con los

resultados obtenidos.



36

El formato preferido por los estudiantes son

los videos, prefieren ver que leer.

La percepción que tienen sobre los conoci-

mientos adquiridos es que los han adquirido

de forma gradual lo que les ha llevado a una

mayor profundización y por tanto no se les ol-

vidarán tan fácilmente.

A la hora de enfrentarse a las pruebas escritas,

se han sentido mucho más preparados y por

tanto tranquilos.

Todos ellos esperan poder disponer en el futu-

ro del máximo número de asignaturas con esta

metodología docente.

6. Conclusiones y expectativas

El presente trabajo ha descrito la experiencia piloto

del uso d clase inversa en la Universitat Politècnica

de València, más concretamente, en la asignatura de

Fundamentos de Sistemas Operativos.A la vista de

los resultados, la experiencia ha sido totalmente

satisfactoria, tanto desde el punto de vista de los

estudiantes, como desde el punto de vista de los

profesores implicados.

Podemos concluir que el cambio de metodología

exige de un gran esfuerzo del profesorado tanto de

planificación como de atención en las clases

presenciales. Además requiere del continuo diseño

de actividades adecuadas y del desarrollo de

material interactivo y visual. La experiencia ha

permitido una mayor dedicación a alumno que se

siente supervisado por su profesor mientras realiza

tareas como ejercicios y problemas. Además, estos

mecanismos participativos refuerzan la consecución

de algunas competencias transversales que se nos

exigen y que son complicadas de conseguir cuando

disponemos de muchos alumnos en el aula.

Los estudiantes han visto muy positivo el cambio

del rol del profesor en el aula, que ha pasado de ser

un mero comunicador de conocimiento a estar muy

implicado en que el alumno consiga su aprendizaje.

Las clases son más dinámica tras liberar al profesor

de exponer los contenidos teóricos permitiendo el

diálogo de forma más natural. Con la metodología

tradicional la mayor interacción con el profesor se

realizaba fuera del aula en tutorías personalizadas.

La principal duda planteada tanto por profesores

como por alumnos es cómo poner en marcha esta

metodología en un grupo ordinario con 55-60

alumnos que no han seleccionado previamente

metodología flip. Para poder poner de manifiesto

este hecho, nos hemos embarcado en un nuevo reto

para el curso 2015-2016, poner metodología flip en

un grupo ordinario de FSO sin acotar el número de

alumno.

7. Referencias

[1] Bergmann, J., & Sams, A. Flipped Learning:

Gateway to Student Engagement. Internatio-

nal Society for Technology in Education,

2014

[2] Bergmann, J., & Sams, A. Flip your Classro-

om.International Society for Technology in

Education, 2012.

[3] Flipped Learning Network. (2014). The four

pillars of F-L-I-P. Flipped Learning Net-

work. Retrieved from

http://flippedlearning.org/cms/lib07/VA0192

3112/Centricity/Domain/46/FLIP_handout_F

NL_Web.pdf.

[4] García-Barrera A., El aula inversa: cambian-

do la respuesta a las necesidades de los estu-

diantes. Avances en Supervisión Educativa,

nº19, Noviembre 2013.

[5] Jornada Sobre Clase Inversa en UPV: Inter-

vención de los alumnos, 19 de enero de 2015.

Vídeo disponible en

https://media.upv.es/player/?id=28da4efa-

57a1-9548-85d2-

9578a136c37b&autoplay=true



37

http://flippedlearning.org/cms/lib07/VA01923112/Centricity/Domain/46/FLIP_handout_FNL_Web.pdf



Organizando la docencia y el aprendizaje con Symbaloo

Adelaida Delgado Domínguez Departament de Matemàtiques i Informàtica

Universitat de les Illes Balears

Palma de Mallorca [email protected]

Resumen

En este artículo se proporcionan ideas de cómo orga-

nizar recursos interesantes ligados a la docencia y al

aprendizaje, así como a la gestión de los mismos,

utilizando Symbaloo para facilitar y hacer más agra-

dable y cómodo su uso a profesores y a alumnos.

Abstract

This article gives ideas on how to organize the re-

sources of interest related to learning and teaching,

and managing them using Symbaloo to facilitate and

make use for teachers and students more enjoyable

and visual.

Palabras clave

Curación de contenidos, entorno personal de aprendi-

zaje, PLE, escritorio virtual, marcadores sociales,

páginas de inicio personalizadas, portfolio.

1. Introducción

En este artículo se presentan ideas y ejemplos, para

docentes y alumnos, sobre la utilización de Symba-

loo, un servicio que permite organizar los recursos en

línea en una sola página o tablero denominado

webmix (configurable como página de inicio en el

navegador) y compartirlo con otros.

Symbaloo significa “montaje” en griego. Los ele-

mentos que conforman un webmix son los bloques,

los cuales se pueden personalizar con colores o imá-

genes, y también con el texto sobrepuesto que se

desee hacer visible. Un bloque puede ser un enlace a

una página web, un enlace a una fuente de noticias

RSS (en tal caso en la parte superior aparecerá un

icono naranja identificativo de RSS y al pulsar sobre

el bloque las noticias se mostrarán en la zona central

del webmix), un widget (mini aplicación como por

ejemplo una calculadora, un reloj, un calendario, una

agenda, información del tiempo…), un medio incrus-

tado (por ejemplo un video de Youtube, una presenta-

ción de Slideshare, un documento de Google Dri-

ve…) o un enlace a otro webmix.

Para facilitar su distinción, los bloques se pueden

agrupar en conjuntos, proporcionando un color de

fondo y un nombre a tal agrupación, o incluso juntar

los que deseemos en un único bloque de tipo grupo,

cuyos elementos aparecerán en una ventana flotante

al pulsar sobre el bloque de grupo.

Con una misma cuenta en Symbaloo se pueden

crear tantos webmixes como deseemos (cada uno

aparecerá en una pestaña).

A través de las preferencias se puede escoger el

motor de búsqueda para la casilla central, decidir si

los enlaces se abren o no en una nueva pantalla y

también elegir qué webmix se abrirá por defecto al

entrar en Symbaloo.

Otras posibilidades de personalización de los

webmixes son la elección de un fondo de pantalla, el

cambio de tamaño (adición o eliminación de filas y

columnas de bloques) o el icono que aparece en la

pestaña.

Los webmixes creados se pueden compartir en la

propia galería de Symbaloo haciéndolos públicos.

También se pueden enviar por correo electrónico u

obtener el código necesario para incrustarlos en una

web o en un blog. Además también se pueden com-

partir por Facebook y Twitter.

A continuación se muestran algunas ideas del uso

que profesores y alumnos le podrían dar a Symbaloo

y algunos ejemplos de webmixes.

2. Ejemplos de uso por profesores

2.1. Organización de los recursos

didácticos, actividades, exámenes…

de una asignatura para los alumnos



38

Symbaloo resulta muy cómodo para organizar un

curso con sus temas, actividades, exámenes, etc. Los

documentos de texto, vídeos y presentaciones se

pueden incrustar (una vez que ya estén en línea y se

hayan compartido obteniendo el enlace correspon-

diente). Los bloques se pueden agrupar por temas

utilizando un fondo de un color determinado, o tam-

bién se podrían agrupar todos los recursos para un

mismo tema en un solo bloque de tipo grupo. Aparte

de documentos, vídeos y presentaciones también se

podrían incorporar enlaces a tests de autoevaluación,

encuestas de satisfacción, enlaces a marcadores

sociales como Mister Wong1 con la bibliografía de la

asignatura, enlaces a repositorios de código como

Github2.

En la Figura 2 se puede ver un ejemplo de un curso

organizado por los propios creadores de Symbaloo

para aprender a utilizarlo. Contiene abundantes ví-

deos incrustados, así como enlaces a páginas web y

un examen.

Si deseamos hacer cambios en un webmix cuando

ya se ha publicado, hay que indicar que se ha actuali-

zado para que todos los usuarios puedan visualizarlos.

El uso de Symbaloo, con el propósito de organizar

los recursos para un curso o asignatura, no está reñido

con el uso de una plataforma educativa como Mood-

le3. Ambos se pueden combinar, aportando Moodle el

control de entregas de tareas, la obtención de infor-

mes de actividad de los alumnos, la obtención de

1 http://www.mister-wong.es/ 2 https://github.com/ 3 https://moodle.org/?lang=es

calificaciones, aviso de eventos, etc. y enlazando con

Symbaloo para ofrecer una organización mucho más

visual y atractiva de los recursos.

2.2. Maletín de herramientas TIC

Este webmix contendría aquellos recursos que nos

permitan estar al día y utilizar tecnologías de la

información y comunicación (TIC) para nuestra labor

docente. Ejemplos de agrupaciones de bloques serían:

Enlaces a redes sociales. Estos servicios ofrecen

un espacio virtual para escribir y compartir con-

tenidos multimedia con personas de intereses

similares. Podemos incluir enlaces tanto a redes

sociales horizontales tipo Facebook4, Twitter

5,

Google+6…, como a redes sociales verticales

creadas para docentes, como por ejemplo Edu-

caNetWork7 , Internet en el Aula

8, Redes Socia-

les Educativas9… o LinkedIn

10 para estar en

contacto con otros profesionales.

Enlaces a nuestros servicios de correo electróni-

co webmail, como por ejemplo Gmail11

o

Outlook12

.

4 http://www.facebook.com/ 5 http://www.twitter.com/ 6 https://plus.google.com/ 7 http://educanetwork.org/ 8 http://internetaula.ning.com/ 9 http://eduredes.ning.com/ 10 https://www.linkedin.com/ 11 https://mail.google.com/ 12 https://mail.live.com/

Figura 1: Ejemplo de la organización de los recursos de un curso con vídeos incrustados y

examen



39

Enlaces a herramientas de edición de contenidos

para generar nuestros propios recursos para

nuestras asignaturas. Aquí se podrían incluir edi-

tores de blogs (Blogger13

, WordPress14

, Edu-

blogs15

, …), generadores de webs (Joomla16

,

Jimdo17

, Webbly18

, …), herramientas ofimáticas

(Office online19

, Zoho20

, Google Docs21

, Libre

Office22

, …), editores de presentaciones en línea

(Prezi23

, Powtoon24

, Voki25

, Photopeach26

, …),

editores de imágenes o de infografías (Pixlr27

,

iPiccy28

, Piktochart29

, …), editores de ví-

deo/screencasts y utilidades (Present.me30

,

Screenr31

, Clipconverter32

, …), editores de au-

dio/podcasts y utilidades (vozMe33

, Spreaker34

,

media.io35

, …), generadores de wikis (Wikispa-

ces36

, …, generadores de líneas de tiempo (Di-

pity37

, …), …

Enlaces a repositorios de contenidos (galerías),

que nos puedan servir para obtener recursos do-

centes o para difundir los nuestros. Aquí po-

13 https://www.blogger.com/ 14 https://wordpress.com/ 15 https://edublogs.org/ 16 http://www.joomla.org/ 17 http://es.jimdo.com/ 18 http://www.weebly.com/ 19 https://office.live.com/ 20 https://www.zoho.com/ 21 https://docs.google.com/ 22 https://es.libreoffice.org/ 23 https://prezi.com/ 24 http://www.powtoon.com/ 25 http://www.voki.com/ 26 http://photopeach.com/ 27 https://pixlr.com/ 28 http://ipiccy.com/ 29 http://piktochart.com/ 30 https://present.me/content/ 31 https://www.screenr.com/ 32 http://www.clipconverter.cc/es/ 33 http://vozme.com/index.php?lang=es 34 https://www.spreaker.com/ 35 http://media.io/ 36 https://www.wikispaces.com/ 37 http://www.dipity.com/

dríamos tener enlaces a repositorios de blogs

educativos (academiblogs38

, …), galerías de do-

cumentos (Scribd39

, Isuu40

, …), galerías de pre-

sentaciones en línea (Slideshare41

, SlidePlayer42

,

…), galerías de imágenes (MorgueFile43

, pixa-

bay44

, freeimages45

, Flickr46

, …), repositorios de

podcats (ivoox47

, …), galerías de vídeo (Youtu-

be48

, Animoto49

, … )

Enlaces a servicios de almacenamiento en la nu-

be (Dropbox50

, Onedrive51

, …)

Enlaces a gestores bibliográficos (CiteUlike52

,

Bibsonomy53

, Mendeley54

, …)

En la Figura 2 se puede ver un ejemplo de webmix

con las diferentes herramientas TIC agrupadas por

categorías (fila superior e inferior), y utilidades

diversas (en el centro). Pulsando en cualquiera de los

grupos aparecen las herramientas que lo componen en

una ventana flotante, tal como se puede apreciar en la

Figura 3.

Nuestro maletín de herramientas tendrá además la

versatilidad de estar accesible desde cualquier orde-

nador conectado a internet, Smartphone o tableta.

38 http://academicblogs.org/ 39 https://es.scribd.com/ 40 http://issuu.com/ 41 http://es.slideshare.net/ 42 http://slideplayer.es/ 43 http://www.morguefile.com/ 44 http://pixabay.com/es/ 45 http://www.freeimages.co.uk/ 46 https://www.flickr.com/ 47 http://www.ivoox.com/ 48 https://www.youtube.com/?hl=es&gl=ES 49 https://animoto.com/ 50 https://www.dropbox.com 51 https://onedrive.live.com/about/es-es/ 52 http://www.citeulike.org/ 53 http://www.bibsonomy.org/ 54 https://www.mendeley.com/

Figura 2: Ejemplo de un maletín de herramientas agrupadas por categorías



40

2.3. Organización de herramientas para

la gestión de las asignaturas

Organizar una asignatura e impartirla se puede

concebir como un proyecto y así adaptar las buenas

prácticas de gestión de proyectos de la guía del

PMBOK ® (Project Management Body of Knowled-

ge) del PMI ® (Project Management Institute).

PMBOK estructura los procesos en una tabla donde

las columnas son el ciclo de vida de un proyecto y las

filas son las áreas de gestión (integración, alcance,

tiempo, costes, calidad, recursos humanos, comuni-

caciones, riesgos, adquisiciones e interesados).

El grupo de investigación MiProSoft (Millora i

Innovació de Projectes Software) de la UIB (Univer-

sitat de les Illes Blaears) aplicó la guía PMBOK para

elaborar la guía MiProDOC [2], que es un método de

actuación sistemático para dar soporte a la organiza-

ción y gestión de las asignaturas que ha de impartir

un profesor.

Esta guía cubre el ciclo de vida de una asignatura:

planificación (establecimiento de las necesidades de

infraestructura, alcance, cronograma, plan de comu-

nicación, indicadores de satisfacción…), impartición

(realización de las actividades docentes de acuerdo al

plan establecido), monitorización y seguimiento

(observación de si ha sido posible cubrir el alcance

determinado en el tiempo previsto y con la calidad

esperada, y realización de los cambios necesarios

para solucionar las incidencias surgidas) y cierre

(recopilación de las lecciones aprendidas y propuesta

de sugerencias de mejora para el próximo curso).

En el otro eje la guía cubre aquellas áreas de ges-

tión de las que es responsable el profesor (otras como

costes o riesgos no se incluyen por ser más compe-

tencia de la institución).

Para facilitar la aplicación de esta guía se creó un

entorno personal de gestión docente [1] utilizando

Symbaloo y así poder manejar desde una única

interfaz todos los recursos digitales y herramientas

propuestos (en base a la experiencia de sus autores),

agrupados en diferentes categorías. Las agrupaciones

creadas son:

Herramientas transversales, las cuales al ser de

propósito general, se pueden utilizar en cualquier

área de gestión. Engloban herramientas ofimáti-

cas (procesadores de textos para elaborar planti-

llas, herramientas para elaborar la presentación

de la asignatura a los alumnos, hojas de cálculo

donde resumir la dedicación que tendrán los di-

ferentes alumnos en el grupo de prácticas,…)

como Zoho Docs55

u OpenOffice56

, servicios de

marcadores sociales (para guardar enlaces a

otras universidades, blogs de interés, colegios u

organismos oficiales….) como Diigo57

, Mis-

terWong58

o CiteUlike59

, y herramientas de al-

macenamiento en la nube para almacenar y

compartir recursos como Dropbox60

, Google

Drive61

u OneDrive62

.

Herramientas de gestión del alcance. Aquí se in-

cluyen herramientas para dibujar relaciones (de

cada asignatura con las otras materias del plan

de estudio, entre asignaturas, entre competencias

de asignaturas) como Flowchart63

, herramientas

para crear mapas mentales (por ejemplo para

identificar los requisitos del proyecto docente)

como MindMup64

, o herramientas para represen-

tar de forma jerárquica la EDT (Estructura Deta-

llada de Trabajo) como WBS Chart Pro65

.

Herramientas de gestión del tiempo. Una vez

confeccionada la lista de actividades hay que se-

cuenciarlas y distribuirlas sobre el calendario

lectivo de sesiones creando un cronograma o un

diagrama de Gantt, para ello pueden ser útiles

herramientas como Google Calendar66

o Gant-

ter67

. Además hay herramientas colaborativas

que sirven para ayudar a los equipos en la plani-

ficación y gestión de sus tareas como Asana68

o

Trello69

.

Herramientas de gestión de las comunicaciones.

Para planificar las reuniones de coordinación

docente resulta muy útil Doodle70

. Para la co-

municación diaria entre componentes del equipo

55 http://www.zoho.com/docs/ 56 http://www.openoffice.org/es 57 https://www.diigo.com 58 http://www.mister-wong.es 59 http://www.citeulike.org 60 http://www.dropbox.com 61 http://www.google.com/drive 62 http://onedrive.live.com 63 http://flowchart.com 64 https://www.mindmup.com/#m:new 65 http://www.criticaltools.com/wbsmain.htm 66 https://www.google.com/calendar 67 http://www.gantter.com 68 http://www.asana.com 69 https://trello.com 70 http://doodle.com

Figura 3. Expansión de los bloques de grupo de

edición de presentaciones



41

docente se puede utilizar Skype71

o Google Han-

gouts72

. Aquí también se podrían incluir los sis-

temas de gestión de aprendizaje como Moodle73

,

Dokeos74

o ILIAS75

, o herramientas de trabajo

colaborativo que dan soporte y mejoran la co-

municación y coordinación entre las partes in-

teresadas como Wiggio76

o Redbooth77

.

Herramientas de gestión de la calidad. Para rea-

lizar una encuesta con un conjunto de indicado-

res que midan la satisfacción de los alumnos con

respecto a la asignatura se pueden utilizar he-

rramientas de gestión de formularios como So-

crative78

que permite obtener los resultados en

tiempo real o Wufoo79

que permite la activación

de las encuestas para un período de tiempo de-

terminado.

En la parte central del webmix se agruparon las

herramientas transversales mientras que las herra-

mientas de cada área de gestión se dispusieron por

filas y colores, tal como se puede ver en la Figura 4.

71 http://www.skype.com/es 72 https://www.google.es/hangouts 73 https://moodle.org 74 http://www.dokeos.com 75 http://www.ilias.de 76 http://wiggio.com 77 https://redbooth.com 78 http://socrative.com 79 http://www.wufoo.com

2.4. Organización de las presentaciones,

tareas, proyectos, blogs… de los

alumnos/grupos

Los profesores podrían usar Symbaloo para hacer

un webmix con los enlaces a cada cartera del

alumno/grupo. La cartera podría ser una carpeta en la

nube (Dropbox, GoogleDrive u otros servicio) que

contuviera diferentes elementos de evaluación (pre-

sentaciones realizadas, tareas, proyectos…). O inclu-

so la cartera podría ser a la vez un webmix del

alumno/grupo con todos esos elementos. O en vez de

enlazar con todo un conjunto de actividades de cada

Figura 4: Ejemplo de entorno de gestión docente

Figura 5: Ejemplo de organización de los trabajos

de los alumnos con sus nombres



42

alumno, podría enlazar simplemente con el proyecto

o práctica de la asignatura.

Desde el webmix del profesor se enlazaría median-

te bloques, cada uno con el nombre del

alumno/grupo, e incluso se podría utilizar sus fotos o

avatares como icono diferenciador. En la Figura 5 se

puede ver un ejemplo de webmix con enlaces a traba-

jos de los alumnos en línea.

En caso de utilizar más de un bloque para cada

alumno/grupo (para enlazar con cada uno de los

diferentes trabajos en vez de enlazar con la carpeta

que los contenga) existe una herramienta denominada

Picslice80

que permite específicamente recortar imá-

genes para Symbaloo que ocupen más de un bloque

(se puede consultar un tutorial en Youtube sobre

cómo hacerlo81

). En la Figura 6 se puede ver un

ejemplo de una imagen recortada para varios bloques.

2.5. Curación de contenidos

Symbaloo puede resultar también muy útil para la

curación de contenidos ya que posee una galería de

webmixes que los usuarios han hecho públicos (se

pueden añadir etiquetas para identificar mejor la

temática) y de esa manera podemos ahorrar mucho

tiempo reutilizándolos. Podemos encontrar webmixes

de muchísimos temas con una gran selección de

recursos interesantes, como por ejemplo recursos para

aprender inglés82

, un curso sobre creación de presen-

taciones eficaces83

, recursos sobre rúbricas84

, herra-

80 http://picslice.com/ 81 https://www.youtube.com/watch?v=dz-Vg80dOnA 82 http://www.symbaloo.com/mix/recursosenglish1 83 http://www.symbaloo.com/mix/presentacioneseficaces 84 http://www.symbaloo.com/mix/rubricas3

mientas asociadas a Twitter85

, etc. Los resultados se

pueden obtener mediante la búsqueda por palabra

clave y filtrar por país, valoración, nivel de populari-

dad.

En vez de utilizar una cuenta en Symbaloo genéri-

co la podemos crear en Symbaloo EDU y así se nos

ofrecerá una selección de bloques y webmixes intere-

santes para Educación.

Además también podemos echar un vistazo al

webmix de la semana que se publica en Facebook86

y

allí dar a conocer los nuestros.

Si a medida que vamos creando webmixes con en-

laces temáticos nos resulta incómodo desplazarnos

por las diferentes pestañas, se puede crear un meta-

webmix, es decir un webmix que contenga los enla-

ces a otros webmixes.

3. Ejemplos de uso por alumnos

3.1. Creación de un PLE

“Un entorno personal de aprendizaje o PLE está

constituido por el conjunto de herramientas, fuentes

de información, conexiones y actividades que cada

persona utiliza de forma asidua para aprender.” [1].

Teniendo en cuenta además que una de las

competencias transversales de los estudios de la

Ingeniería informática es la “Capacidad para la

búsqueda de recursos y de gestión de la información

en el ámbito de la informática”, Symbaloo puede

ayudar para la organización de todos esos recursos

que un estudiante de informática necesite tener a

mano durante sus estudios universitarios y posterior-

mente.

Lo ideal sería inicialmente crear un mapa mental

plasmando todos los elementos que han de conformar

el PLE, como se puede ver un ejemplo en la Figura

887

, y luego utilizar Symbaloo para organizarlos por

grupos y colores, con los enlaces correspondientes e

iconos representativos.

85 http://www.symbaloo.com/mix/twitterherramientas 86 https://www.facebook.com/symbaloo.es 87 http://agujademarear.blogspot.com.es/p/mi-ple.html

Figura 6: Ejemplo de uso de una imagen recortada

para identificar visualmente un conjunto de bloques

Figura 7: Ejemplo de visualización del contenido de

un bloque RSS



43

No hay que olvidar que Symbaloo tiene la posibili-

dad también de insertar bloques tipo RSS que permi-

ten estar al día de las novedades de fuentes de noti-

cias y blogs, y cuyos titulares aparecen en la parte

central del webmix, tal como se puede apreciar en la

Figura 7. E incluso se podría enlazar con un webmix

tipo RSS donde todos los elementos estarían forma-

dos por titulares de las fuentes RSS seleccionadas.

Otra facilidad para construir el PLE es buscar blo-

ques en la base de datos de Symbaloo.

El PLE se puede enriquecer no sólo con enlaces a

webs sino también con enlaces a documentos alma-

cenados en la nube, enlaces a las redes sociales del

alumno, enlaces a su correo electrónico,… además de

poder incrustar vídeos, presentaciones, documentos,

hojas de cálculo, y disponer de widgets como traduc-

tores, buscadores, etc.

El PLE construido con Symbaloo además se puede

configurar como página de inicio del navegador.

La idea de construir un PLE no sólo es aplicable a

los estudiantes sino también a los profesores de cara a

su formación continua, ya que como dijo John Cot-

ton Dana “quien se atreve a enseñar nunca debe dejar

de aprender”.

3.2. Creación de un portfolio digital

“Un portfolio digital, en términos generales, se re-

fiere a una recopilación de documentos que pueden

mostrar diferentes aspectos globales o parciales de

una persona (personales, académicos, profesiona-

les...) o de una organización (objetivos, organigrama,

productos...) los cuales han estado seleccionados y

organizados de forma reflexiva y deliberada y presen-

tados en formato digital (texto, imágenes, animacio-

nes, simulaciones, audio y vídeo); podríamos decir

que es una manera de presentar una identidad en

forma digital.”88

A través de la creación de un portfolio el alumno es

más consciente de sus aprendizajes. En el portfolio

puede ir guardando todos los trabajos realizados para

una asignatura, o para cada una de ellas, o aquellos

más representativos que puedan ir conformando su

currículum para buscar empleo en un futuro.

En la Figura 9 podemos ver un ejemplo de utiliza-

ción de Symbaloo para presentar de una manera

atractiva y muy visual un portfolio personalizado con

imágenes de su autora.

3.3. Organización de los recursos para

preparar una actividad, un proyecto,

trabajo final de grado…

De manera individual o en grupo (utilizando una

misma cuenta de Symbaloo) los alumnos pueden ir

archivando todos aquellos recursos necesarios para

desarrollar un tema o llevar a cabo una actividad

concreta.

88 http://es.wikipedia.org/wiki/Portfolio_digital

Figura 8: Ejemplo de mapa mental de un PLE



44

A medida que el alumno va navegando por la red y

ve algún recurso que le resulta valioso, o que sim-

plemente intuye que puede ser interesante para explo-

rarlo en más detalle después, puede incorporarlo muy

fácilmente a un webmix mediante un complemento

instalado en el navegador. Así pues no tiene más que

desplegar el menú contextual y elegir la opción “add

to symbaloo”, modificar el nombre y/o color si lo

desea e indicar en qué webmix se va a incorporar.

4. Conclusiones

Symbaloo ofrece un amplio abanico de posibilida-

des tanto para profesores como alumnos, individuales

o en grupo. Desde la creación de un webmix con

nuestro favoritos hasta cursos completos en línea,

presentación de actividades o trabajos de los alumnos

o simplemente para guardar enlaces con información

complementaria para distintos contenidos que este-

mos trabajando en nuestras asignaturas.

De manera muy sencilla podemos mejorar la apa-

riencia y facilidad de uso de nuestra lista de recursos

en línea y también fomentar la organización y estruc-

turación de la información por parte de nuestros

alumnos y también la nuestra.

Por otra parte también podemos utilizar Symbaloo

para contribuir al conocimiento social compartiendo

nuestros webmixes en su galería.

Referencias

[1] Adell Segura, J. & Castañeda Quintero, L. Los

Entornos Personales de Aprendizaje (PLEs):

una nueva manera de entender el aprendizaje.

En Roig Vila, R. & Fiorucci, M. (Eds.) Claves

para la investigación en innovación y calidad

educativas. La integración de las Tecnologías

de la Información y la Comunicación y la In-

terculturalidad en las aulas. 2010.

[2] Mas, A., Mesquida, A.L., Delgado, A. Entorno

personal de gestión docente en universidades.

En Information Systems and Technologies

(CISTI), 2014

[3] Mas, A., Mesquida,A.L., Gilabert, J.M. Apply-

ing PMBOK® to teaching management in uni-

versities. En Information Systems and Technol-

ogies (CISTI), 2012.

Figura 9: Ejemplo de presentación de un portfolio con Symbaloo



45

http://digitum.um.es/xmlui/handle/10201/17247



2 0 1 5jenui2015.uols.org/app/assets/files/JENUI2015_Actas_Simposio... · 2 0 1 5 Actas del...

Documents

Transcript of 2 0 1 5jenui2015.uols.org/app/assets/files/JENUI2015_Actas_Simposio... · 2 0 1 5 Actas del...