Recibido 4 Abr 2016
Aceptado 2 May 2016
ReCIBE, Año 5 No. 3, Noviembre 2016

Seguimiento de proyectos de programación. Una aplicación de GitHub en la educación


Programming Projects Monitoring. Using Github on Education


Javier Salazar Zárate1
Javier.salazar@eduklip.com

Blanca Hidalgo Ponce2
bhidalgo@espoch.edu.ec

Narcisa Salazar Alvarez2
nsalazar@espoch.edu.ec

Byron Vaca Barahona2
bvacab@espoch.edu.ec

1eduKlip, Ecuador.
2Escuela Superior Politécnica de Chimborazo, Ecuador.

Resumen: Esta investigación desarrolla y propone un método para la ejecución y se-guimiento de los proyectos de fin de curso de las materias de lenguajes de programación en carreras de Ingeniería Electrónica soportado tecnológica-mente por GitHub. El objetivo es obtener un método que permita mejorar la calidad de los proyectos. Para la validación del nuevo método se realiza un contraste entre dos grupos de estudiantes, el primer grupo utilizando el mé-todo tradicional de ejecución de proyectos y el segundo utilizando el método propuesto. Los resultados muestran que a pesar que la aplicación del nuevo método demanda de un esfuerzo adicional por parte del docente, evidente-mente mejora el proceso de seguimiento de los proyectos de fin de curso: facilitando el trabajo colaborativo, permitiendo una evaluación objetiva, visi-bilizando los hábitos de estudio de los estudiantes, transparentando y auto-matizando las actividades inherentes a la ejecución de proyectos de softwa-re, potenciando el seguimiento y la guía a los estudiantes.

Palabras clave: Propuesta metodológica, Seguimiento de proyectos, Proyecto de fin de curso, Método [MESEPP], sistema de versionamiento [Github], lenguajes de programación.

Abstract: This research develops and proposes a method for the execution and monitoring of end course projects for programming languages topics imparted on Electronics Engineering Bachelor Degrees, this supported technologically by Github. The goal is to obtain a method to improve the quality of projects. To validate the new method, a contrast between two groups of students was done, for the first group the traditional method for project execution is used and for the second group, the new method is applied. The results show that even though the application of the new method de-mands an additional effort for the teacher, it evidently improves the monitoring pro-cess of the end course projects by making collaborative work easy, allowing an ob-jective evaluation, making visible student’s habits, automating and making transpar-ent the inherent activities of software projects execution, enhancing the student’s monitoring and guidance.

Keywords: Methodological proposal, Project monitoring, End course project, method [MESSEP], Version control system [Github], Programming languages

1. Introducción

La utilización del proyecto de fin de curso en carreras de ingeniería es perti-nente, sin embargo su aplicación trae consigo algunos problemas. El proyec-to es un trabajo en equipo, sin embargo, algunos estudiantes siguen reali-zando un esfuerzo individual. El proyecto es un proceso, sin embargo, los proyectos se visibilizan al docente en un único día designado para la presen-tación del proyecto.

Entendiendo las particularidades de un proyecto de Lenguajes de Progra-mación, en el que un programa de computadora, con líneas de código apor-tadas por cada uno de los miembros del equipo, es el producto resultante, el presente trabajo de investigación pretende definir, proponer y validar un mé-todo para el seguimiento del proyecto de fin de curso, con el fin de mejorar la calidad de los proyectos.

Como un apoyo tecnológico y a la vez como una parte integrante del mé-todo, se utiliza “GitHub”, la plataforma para versionamiento de archivos más popular del mercado de software y de uso gratuito para proyectos de código abierto.

Con el desarrollo del trabajo se pretende dar respuesta a la siguiente pre-gunta de investigación:

¿Permitirá un método de seguimiento de proyectos de fin de curso apli-cado en la materia de Lenguajes de Programación y soportado por GitHub, mejorar la calidad de los proyectos en carreras de Ingeniería Electrónica en la Escuela Superior Politécnica de Chimborazo?

A pesar de que la estimación de la calidad es subjetiva para diferentes es-cenarios, el presente trabajo sugiere una rúbrica para la ponderación de la calidad de un proyecto de fin de curso en las materias de Lenguajes de Pro-gramación.

En la sección 2 se conceptualiza a un método y se describe a GitHub, su importancia y los estudios relacionados en el ámbito de la educación. En la sección 3 se presenta y detalla el método propuesto, en la sección 4 se des-cribe la metodología utilizada en el estudio para la aplicación y validación del nuevo método, en la sección 5 se discuten los resultados del estudio y fi-nalmente en la sección 6 se presentan las conclusiones.

2. Antecedentes

Un método, como lo define la Real Academia de la Lengua es el “modo de decir o hacer con orden, modo de obrar o proceder, hábito o costumbre que cada uno tiene y observa” (Real Academia Española, 2001), puede ser definido como el “camino o procedimiento viable para conseguir un fin propuesto” (Gutiérrez, 2006; citado en Coria, et al. 2013) y difiere del concepto de metodología definido como “el estudio de los métodos” (Bunge, 2005). Un método refiere la forma en la que se puede realizar una actividad, tarea o trabajo para alcanzar un objetivo particular. Para ello un método puede pertenecer a alguno de los tipos existentes en las diferentes áreas de conocimiento (Sierra, 2001). El pre-sente estudio propone entonces una forma de abordar la ejecución y segui-miento de los proyectos de fin de curso en la materia de lenguajes de pro-gramación. Como parte integrante del método se incorpora la herramienta Github.

GitHub es una plataforma web comercial lanzada en el año 2008 (Yu, Yin, Wang, & Wang, 2014), diseñada para facilitar el almacenamiento centralizado, la trazabilidad y colaboración sobre archivos de proyectos. En su esencia Gi-tHub registra los cambios que han ocurrido en el tiempo en uno o varios archivos, con la finalidad de recuperar, en el futuro, versiones específicas de ellos, esta es una característica propia de un sistema de control de versiones (Chacon S, 2014).

El corazón de GitHub es Git, una herramienta gratuita y de código abierto que se encuentra en la categoría de sistemas de control de versiones distri-buido (Git, 2015). Actualmente GitHub mantiene más de 28.1 millones de re-positorios (GitHub, Inc., 2015) y en la línea de software soporta proyectos de importancia mundial en una gran variedad de lenguajes de programación (Ray, Posnett, Filkov, & Devanbu, 2014).

Based on the previous statement, despite the vast quantity of tools to help urban modeling, there is a lack of tools devoted to simulate study-cases focusing in city operation, instead of its mere visualization; since modern tools frequently focus in 3D simulation and do not have enough power to deal with issues regarding how chaotic and erratic a real city is.

This first stage of this city simulator is aimed at the repGitHub es gratuita para la ejecución de proyectos de código abierto y re-quiere de un pago periódico para proyectos de ámbito privado.

Hoy en día la plataforma es muy popular en las comunidades, especial-mente de desarrolladores. Individuos y corporaciones utilizan GitHub como la herramienta primaria para el control y versionamiento de sus proyectos de software.

En este tipo de proyectos los miembros de un equipo se benefician de la plataforma logrando estrategias efectivas para coordinar los proyectos, me-jorando sus habilidades técnicas, e inclusive gestionando su reputación (Dabbish, Stuart, Tsay, & Herbsleb, 2012).

En el ámbito de la educación existen algunas experiencias documentadas acerca del uso de GitHub. Y aunque esta plataforma no está diseñada espe-cialmente para la educación, su "naturaleza social y colaborativa, es un re-curso consistente con la ideología de educación liberal" (Shaffer, 2013).

Sus creadores conscientes del impacto que la plataforma puede tener en el área de la educación han puesto a disposición un portal educativo, en el cual se estima que son ya 1.200 cursos y 70.000 estudiantes registrados para beneficiarse del servicio (Sawers, 2014).

Si bien por su origen, el uso de GitHub en la educación parecería tener un campo de acción limitado a las carreras y materias dedicadas al desarrollo de software, algunos autores (Zagalsky, Feliciano, Storey, Zhao, & Wang, 2015), consideran que el uso de estas herramientas de versionamiento de código no debería estar restringido únicamente a estas áreas.

En el presente estudio se propone un método que incorpore a GitHub co-mo el componente tecnológico que soporte el seguimiento de los proyectos de fin de curso. Las experiencias positivas del uso de GitHub y Git existen-tes en el ámbito de la educación (Xu, 2012), en la carrera de Ciencias de la Computación (Lawrance, Jung, & Wiseman, 2013) y específicamente en materias de lenguajes de programación (Josh, 2014), motivan y respaldan su elección para la nueva propuesta.

3. Propuesta

Entendido el objetivo de un método y habiendo respaldado el uso de la plataforma GitHub basado en experiencias positivas de su uso en el ámbito de la educación, en la siguiente sección se presenta la propuesta de un mé-todo para el seguimiento de proyectos de fin de curso en materias de Len-guajes de Programación utilizando GitHub. Al nuevo método se lo ha deno-minado como MESEPP.

3.1 Procedimiento

El procedimiento sugiere el conjunto de pasos secuenciales sugeridos al docente para el proceso de seguimiento y evaluación de los proyectos de fin de curso. Los artefactos nombrados como parte del procedimiento serán detallados más adelante.

1. El docente de la materia de Lenguajes de Programación realiza la pla-nificación del proyecto de fin de curso. Para ello completa el ARTEFACTO 01: Definición de proyecto.

2. El docente realiza un taller de capacitación de GitHub, de 3 horas de duración. En el taller se realizan las siguientes actividades:

  • Presentación del ámbito de la herramienta, su objetivo, utilidad, pro-yectos importantes soportados por la plataforma. El objetivo es moti-var al estudiante en el uso de la plataforma.
  • Creación de cuentas individuales de los estudiantes en el portal de Gi-tHub.
  • Instalación de la herramienta GitHub de escritorio para el sistema ope-rativo de preferencia del estudiante.
  • Creación de un proyecto por equipo en la plataforma y vinculación de cada uno de los miembros.
  • Explicación y práctica del uso de la herramienta GitHub para escritorio.
  • Inclusión del docente como miembro de cada uno de los equipos.

3. Entrega del ARTEFACTO 02: Manual de GitHub a los estudiantes co-mo complemento de la capacitación y como una fuente de consulta y referencia para los estudiantes.

4. El docente envía a un estudiante definido como el líder del equipo el ARTEFACTO 03: Definición de equipo, el mismo que es completado y enviado de regreso al docente.

5. El docente instala la aplicación GitHub para escritorio en el sistema operativo de su preferencia.

6. Desde el día acordado como la fecha de inicio del proyecto el docen-te diariamente, en lo posible a la misma hora del día, realiza las si-guientes actividades:

  • Descarga la última versión de cada uno de los proyectos de sus estudiantes.
  • Revisa los cambios realizados de manera individual por cada miembro del equipo.
  • Llena la información del ARTEFACTO 04: Retroalimentación.
  • Una vez completada la revisión, envía por correo electrónico las retroalimentaciones a cada uno de los estudiantes. Los correos electrónicos serán los definidos en el ARTEFACTO 03: Definición de equipo. Es deseable realizar el envío por correo electrónico por ser un medio de comunicación personal. GitHub en su esquema gratuito expone de manera pública toda la información, mecanis-mo inconveniente para el envío de retroalimentaciones. Su exposi-ción pública podría causar perjuicios por parte de otros miembros del mismo equipo, de otros equipos o de personas externas al proceso.
  • El docente completa el ARTEFACTO 05: Registro de avance en las secciones individual y grupal para este día de revisión.
  • En el caso que en el día de revisión exista un aporte grupal o indi-vidual de gran impacto o de interés técnico/pedagógico, el docen-te incluye esta información en un formato de pregunta en el ARTEFACTO 06: Cuestionario final.

7. El día definido como fecha de fin de ejecución del proyecto, el docen-te realiza la última revisión de los proyectos y envía las últimas retro-alimentaciones.

8. En las fechas comprendidas entre la fecha de fin de ejecución del proyecto y la fecha de presentación final, el docente llena el ARTEFACTO 07: Rúbrica de evaluación en su sección “Durante la eje-cución del proyecto”. El docente utiliza para ello la información reco-lectada en el ARTEFACTO 05: Registro de avance.

9. El docente valida que el ARTEFACTO 06: Cuestionario final se encuen-tre completo para cada uno de los equipos y estudiantes, en caso contrario lo completa en base al trabajo de seguimiento realizado so-bre cada uno de los proyectos.

10. Se realiza la presentación final de los proyectos en la fecha definida para dicho evento. Se entrega a los estudiantes el tiempo definido pa-ra la presentación y defensa del proyecto.

11. Luego de la presentación, el docente realiza al menos una pregunta in-dividual a cada uno de los miembros de los equipos. La pregunta es tomada del ARTEFACTO 06: Cuestionario final. De ser necesario el docente realiza las preguntas adicionales que crea necesarias.

12. El docente llena el ARTEFACTO 07: Rúbrica de evaluación en la sec-ción “Presentación de proyecto”. Utiliza para ello la técnica de obser-vación durante la presentación y la ronda de preguntas.

13. Una vez realizadas las presentaciones finales, el docente totaliza los valores del ARTEFACTO 07: Rúbrica de evaluación. El valor resultante es el grado de calidad del proyecto de cada equipo en su componen-te individual y grupal. Este valor que representa un porcentaje de 0% a 100% puede ser correspondido con la calificación final del proyecto. Así si un estudiante ha obtenido un valor del 70% para un proyecto cuya puntuación haya sido planificada para 10 puntos el puntaje co-rrespondiente del estudiante será de 7.

3.2 Artefactos

En la siguiente sección se caracterizan cada uno de los artefactos men-cionados como parte del procedimiento:

Artefacto 01 - Definición de proyecto. Documento detallado del proyecto sugerido a todos los equipos de trabajo, incluyendo la siguiente información:

  1. Título del proyecto.
  2. Objetivos de la aplicación (software).
  3. Objetivos en la materia.
  4. Descripción general de la aplicación.
  5. Requerimientos específicos.
  6. Fecha de inicio del proyecto.
  7. Fecha de fin del proyecto.
  8. Presentación final, incluyendo fecha, hora, lugar y condiciones.
  9. Método, describiendo el procedimiento detallado a los estudiantes, la forma de trabajo, las acciones que se esperan de ellos y la rúbrica de evaluación a utilizarse para la valoración del proyecto.

Artefacto 02 - Manual de GitHub. Manual detallado de GitHub, incluyendo pantallas de la aplicación de escritorio, instrucciones para la creación de cuentas en el servicio web, creación del proyecto, estrategia de contribución y colaboración sobre el proyecto y resolución de conflictos.

Artefacto 03 - Definición de equipo. Documento de definición de un equipo y sus miembros, incluyendo la siguiente información:

  1. Equipo: Número de identificación única del equipo
  2. Líder: Apellidos y nombres del miembro líder del equipo.
  3. Integrantes: Detalle de cada uno de los integrantes del equipo,
    inclu-yendo: Código del estudiante, apellidos, nombres, nombre preferido, email y usuario GitHub.

Artefacto 04 - Retroalimentación. Documento que concentre las retroalimen-taciones diarias entregadas a cada uno de los miembros de los equipos, incluyendo la siguiente información:

  1. Equipo: Número de identificación única del equipo.
  2. Retroalimentaciones: De cada uno de los estudiantes, incluyendo: Apellidos y nombres, fecha y texto de la retroalimentación.

Artefacto 05 - Registro de avance. Documento que permita registrar el avan-ce grupal e individual de cada uno de los equipos, incluyendo la siguiente información:

  1. Equipo: Número de identificación única del equipo.
  2. Avance sobre el total del proyecto: Registro, en valor porcentual, del avance que el grupo realiza por día sobre el 100% esperado del pro-yecto.
  3. Actividad individual: Registro por día de la actividad de cada miembro respecto al resto de los integrantes, utilizando las ponderaciones: alta, media, baja y ninguna.
  4. Observaciones: Observaciones importantes a resaltar en el avance in-dividual de los miembros del equipo.

Artefacto 06 - Cuestionario final. Documento que recoge para cada miem-bro del equipo al menos una pregunta de importancia a ser preguntada y respondida el día de la presentación, incluyendo para cada estudiante:

  1. Apellidos y nombres.
  2. Antecedentes: Contextualizar la pregunta.
  3. Pregunta.
  4. Ámbito de respuesta: Enmarcar el ámbito de la posible respuesta es-perada

Artefacto 07 - Rúbrica de evaluación. Documento que permite ponderar el grado de calidad de los proyectos de fin de curso. La rúbrica tiene dos momentos de evaluación. El primero es durante la ejecución del proyecto y en él se pondera el 80% del total. Un segundo momento es el día de presen-tación final del proyecto, en este se pondera el 20% del total. En cada uno de estos momentos se tienen índices tanto a nivel grupal como a nivel indi-vidual.

Las siguientes tablas presentan el detalle de la rúbrica:

Tabla 1. Rúbrica de evaluación. Componente grupal durante la ejecución del proyecto. Rúbrica de evaluación. Componente grupal durante la ejecución del proyecto.

Tabla 2. Rúbrica de evaluación. Componente individual durante la ejecución del proyecto. Rúbrica de evaluación. Componente individual durante la ejecución del proyecto.

Tabla 3. Rúbrica de evaluación. Componente grupal en la presentación del proyecto. Rúbrica de evaluación. Componente grupal en la presentación del proyecto.

Tabla 4. Rúbrica de evaluación. Componente individual en la presentación del proyecto Rúbrica de evaluación. Componente individual en la presentación del proyecto

4. Metodología

En la presente investigación se ha considerado como grupo de estudio a los estudiantes de la materia de Lenguajes de Programación de las carreras de Ingeniería Electrónica de la Facultad de Informática y Electrónica de la Escuela Superior Politécnica de Chimborazo (ESPOCH). Cada semestre exis-ten nuevos estudiantes matriculados, por lo que esta población se la puede entender como de número indefinido.

Con el procedimiento se pretende validar que la aplicación del nuevo mé-todo permite mejorar la calidad de los proyectos de fin de curso. La Tabla 5 resume las características de los grupos muestrales tomados para la investigación.

Tabla 5. Grupos muestrales seleccionados para el estudio. Grupos muestrales seleccionados para el estudio.

El grupo del periodo marzo – agosto 2014 y el grupo del periodo marzo – agosto 2015 serán referidos en esta y en las siguientes secciones simple-mente como Periodo 2014 y Periodo 2015 respectivamente.

Nótese que a pesar de que las Escuelas de Ingeniería Electrónica de las cuales se han tomado los grupos de estudio son diferentes, las condiciones de las muestras son iguales:

  • El número de estudiantes es de 28 para los dos grupos.
  • Los dos grupos reciben tanto en el primero como en el segundo semestre las mismas materias, los mismos contenidos y el mismo número de horas semanales en cada una de las materias.
  • Antes del primer semestre los estudiantes de los dos grupos reci-ben el mismo curso de nivelación.
  • Para la materia de Lenguajes de Programación I, en la cual se ha realizado el presente estudio, los contenidos que se dictan en la materia son idénticos, el docente es el mismo y su metodología de trabajo es igual para ambos grupos.
  • Se ha tenido especial cuidado que el periodo estacional del año sea el mismo de marzo – agosto en los dos grupos de estudio.

Con estas condiciones se ha querido lograr que los factores exógenos tengan una baja probabilidad de afectación a los resultados del estudio, garantizando que la diferencia entre los dos grupos sea únicamente el méto-do utilizado para la ejecución y seguimiento de los proyectos de fin de curso.

En el Periodo 2014 se ha utilizado un esquema tradicional para el segui-miento de los proyectos de fin de curso, en el cuál, el docente envía el proyecto, los estudiantes definen el tiempo que dedican al proyecto y el ritmo de avance. Siempre tienen a disposición al profesor en horas de consulta para resolver sus inquietudes. El docente percibe el avance individual y grupal sobre el proyecto con revisiones realizadas en sus horas de clase. El proyecto se presenta en un día específico al final del semestre a través de una exposición que incluye diapositivas, una exposición oral y la presentación del programa computacional.

En el Periodo 2015 se ha utilizado el método propuesto, aplicando su pro-cedimiento y utilizando cada uno de sus artefactos. El método ha sido aplicado por un total de veinte y dos (22) días, periodo total de ejecución del proyecto de fin de curso.

Para el experimento, un proyecto ha sido enviado a todos los equipos del Periodo 2014 y otro proyecto diferente ha sido enviado a todos los equipos del Periodo 2015. Esta diferencia en los proyectos ha sido intencional para evitar que los estudiantes del Periodo 2015 refieran o copien los proyectos del año anterior y se incurra con ello en un error del experimento. Sin embar-go los proyectos para los dos periodos, han sido definidos para presentar similares características y complejidad en sus requerimientos de implementación.

El instrumento de evaluación utilizado para calcular la calidad de los pro-yectos de fin de curso en los dos grupos, es la rúbrica de evaluación que representa a su vez el ARTEFACTO 07: Rúbrica de evaluación del método propuesto.

5. Resultados

Una vez aplicado el método tradicional en el grupo de estudiantes del Periodo 2014 y aplicado el método propuesto en el grupo de estudiantes del Periodo 2015, los resultados son los siguientes:

Media del grado (%) de calidad alcanzado en los proyectos de los periodos 2014 y 2015.

Figura 1. Media del grado (%) de calidad alcanzado en los proyectos de los periodos 2014 y 2015.

La Figura 1 muestra que el grado de calidad del Periodo 2014 con un valor del 41% es mayor que el ponderado para el Periodo 2015 que apenas alcanza un valor del 33%. Basado en estos valores cuantitativos se puede afirmar que la utilización del método propuesto en el Periodo 2015 no mejoró la cali-dad de los proyectos.

A primera vista esto haría suponer también que el método tradicional para el seguimiento y evaluación de proyectos es mejor que el propuesto, sin embargo, una lectura más detalla permite discutir y analizar que:

  1. Para el Periodo 2014 la ponderación es subjetiva, debido a que se tie-ne menos información disponible para el docente. Las revisiones de aula y la presentación final son insuficientes para tener una percepción objetiva del trabajo individual y grupal de los estudiantes. La rúbrica de evaluación es llenada con base a esta subjetividad y puede ser so-brevalorada.
  2. Para el Periodo 2015 el método propuesto brinda objetividad, ofre-ciendo al docente una trazabilidad completa del trabajo individual y grupal de sus estudiantes, no sólo en periodos cortos de aula o en la presentación final del proyecto sino durante todo el periodo de ejecu-ción del proyecto. Esta visibilidad del trabajo de los estudiantes recae en una ponderación más acertada, más real, que evita sobrestimar el trabajo de estudiantes que no aporten con el proyecto, de equipos donde un estudiante sea el único ejecutor o de equipos que distribu-yan ineficientemente su esfuerzo o su tiempo. La rúbrica de evaluación es llenada con base a toda esta evidencia y sus resultados pueden disminuir considerablemente respecto a una ponderación subjetiva.

5.1 Componente grupal

La rúbrica tiene componentes de evaluación tanto grupal como individual. La Figura 2 presenta la comparación entre los componentes grupales de los 2 periodos de estudio. Nótese que el valor máximo que pueden alcanzar las barras del gráfico es de 70%, porcentaje sugerido por MESEPP para este componente grupal.

 Componente grupal de calidad proyectos periodo 2014 y 2015

Figura 2. Componente grupal de calidad proyectos periodo 2014 y 2015

En la Figura 2, al igual que en la Figura 1, se puede afirmar que el grado de calidad sigue siendo mejor para el Periodo 2014 con un valor del 26% por encima del Periodo 2015 con un valor del 17%. Y mientras estos valores cuantitativos permiten realizar esta afirmación, la diferencia de objetividad entre los dos periodos antes discutida, permite considerar el punto de vista que, los resultados en el Periodo 2015 simplemente evidencian con objetivi-dad la ineficiencia del trabajo en equipo de los estudiantes.

Line split considering angle α for denoting the maximum deviation

Figura 3. Line split considering angle α for denoting the maximum deviation

Desglosando el componente grupal, tal como lo presenta la Figura 3, se puede evidenciar que en los dos 2 periodos los estudiantes reparten inefi-cientemente el esfuerzo del proyecto con un valor ponderado del 2% sobre 20%. Esto significa que dentro de un mismo equipo hay estudiantes que hacen más esfuerzo y completan más cantidad de funcionalidad del proyec-to, mientras que otros aportan poco o en ocasiones nada al proyecto.

La repartición del tiempo se ha ponderado mejor para el periodo 2014 con un valor de 6% sobre 20% con respecto al 2% del periodo 2015. Un equipo es mejor ponderado cuando realiza avances periódicos, progresivos y sos-tenidos del proyecto.

Se puede observar sin embargo que estas ponderaciones de la repartición del tiempo son bajas para los dos periodos, lo que da a notar que los estu-diantes no reparten bien su tiempo, y como se analizará más adelante, tien-den a realizar el mayor esfuerzo en los últimos días del periodo designado para la ejecución del proyecto.

Y así como los índices de repartición de esfuerzo y de tiempo refieren la eficiencia con la que los estudiantes ejecutan el proyecto, el índice del cum-plimiento presentado en la Figura 3 refiere la eficacia, referida como la capa-cidad de los estudiantes de cumplir con todos los requerimientos.

En esta valoración, la percepción de cumplimiento también fue mayor para el periodo 2014 con un valor del 9% sobre 20% contra el valor del 6% sobre 20% del periodo 2015. Nótese así mismo que estos valores son bajos, pues en ninguno de los 2 periodos los estudiantes, en promedio, cumplieron si-quiera el 50% de los requerimientos solicitados para sus proyectos.

5.2 Componente individual

La Figura 4 presenta la calidad de los proyectos en su componente indivi-dual, para los dos 2 periodos en estudio. En el gráfico el valor máximo de las barras puede alcanzar el 30% que es el valor sugerido por MESEPP para este componente.

. Componente individual de calidad de los proyectos periodo 2014 y 2015.

Figura 4. . Componente individual de calidad de los proyectos periodo 2014 y 2015.

Con la Figura 4 se puede afirmar que en lo que respecta al componente individual, es decir el trabajo por estudiante, el periodo 2015 presenta mejo-res resultados con un valor del 16% siendo un punto porcentual mayor res-pecto al 15% del periodo 2014.

Nótese sin embargo, que esto no significa que todos los estudiantes ha-yan hecho un mejor trabajo. La información detallada recogida en el periodo 2015, visibiliza que el trabajo destacado de unos pocos estudiantes ha ele-vado el valor de la media presentada en la figura.

Índices del componente individual de calidad de proyectos periodo 2014 y 2015

Figura 5. Índices del componente individual de calidad de proyectos periodo 2014 y 2015

Si desglosamos este componente individual, Como se presenta en el la figura 5, podemos notar que para el periodo 2015 la calidad del código es superior con un valor de 11% sobre 20% por encima del valor de 8% sobre 20% del periodo 2014. El índice de código indica que los estudiantes han utilizado los conceptos de programación enseñados en clase y los han utili-zado bien.

Por otro lado el índice que pondera el desenvolvimiento individual de los estudiantes en su presentación final fue mejor para el periodo 2014 con un valor de 7% sobre 10% por encima del valor de 5% sobre 10% del periodo 2015.

5.3 Información enriquecida periodo 2015

Para el Periodo 2015, gracias a los datos registrados por el docente en el Artefacto 05 - Registro de avance, se puede obtener información adicional valiosa del avance del proyecto. La Figura 6 presenta una gráfica que evi-dencia el trabajo de los equipos (Ei) en el Periodo 2015.

Porcentaje total de requerimientos del proyecto cubiertos por los equipos (Ei) del día 1 al día 22 del periodo 2015

Figura 6. Porcentaje total de requerimientos del proyecto cubiertos por los equipos (Ei) del día 1 al día 22 del periodo 2015

Observando el trabajo de todos los equipos, se puede decir que el trabajo del equipo 1 (E1) es un caso excepcional. Realiza un trabajo dedicado desde el día 1 hasta el día 13, día en el que completa ya el 80% del proyecto.

El equipo 3 (E3) realiza un trabajo incremental la última semana y en ella completa ya el 70% del proyecto.

El resto de equipos presentan un patrón de ejecución similar: no realizan ningún avance sino hasta los últimos días, en donde completan un bajo por-centaje del proyecto menor o igual al 40%.

Esta información evidencia los hábitos en la ejecución de los proyectos por parte de los estudiantes, donde las actividades se realizan en los últimos días acordados con el docente. En esos escasos días, el esfuerzo y el tiem-po son insuficientes para cubrir con el 100% de los requerimientos exigidos por el proyecto.

Nótese sin embargo que la recolección de esta información adicional en el Periodo 2015 implica también la inversión de tiempo y esfuerzo adicional por parte del docente.

6. Conclusión

El estudio ha permitido evidenciar que la utilización del método MESEPP mejora el seguimiento de los proyectos de fin de curso, potenciando el pro-ceso de educación, facilitando el trabajo colaborativo, permitiendo una eva-luación objetiva, visibilizando los hábitos de estudio de los estudiantes, transparentando y automatizando las actividades inherentes a la ejecución de proyectos de software.

Para MESEPP GitHub es un componente fundamental. Con la herramienta, los estudiantes pueden mantener versionados sus proyectos y pueden po-tenciar su trabajo en equipo. El código aportado por cada estudiante, el nú-mero de aportes por día, la cantidad de líneas nuevas, editas y eliminadas por cada estudiante, son evidencias que se registran de manera automática con el uso de la herramienta.

Sin embargo la calidad de los aportes de los estudiantes, el avance por-centual día a día sobre el 100% de requerimientos del proyecto, así como la retroalimentación que debe ser entregada a cada estudiante, son todas ellas tareas que la plataforma GitHub desconoce y que no pueden ser automatiza-das por ella, por tanto requieren del criterio, del tiempo y del esfuerzo del docente.

Ese sobre esfuerzo, de 1 a 3 horas diarias, que debe realizar el docente puede representar un limitante para el uso de un método como el sugerido en la realidad del aula. Sin embargo la creatividad del docente dueño de la ma-teria para obtener colaboración de sus pares, de ayudantes de cátedra o de estudiantes de semestres superiores, podría solventar estas incomodidades intrínsecas en el nuevo método. Encontrar estas u otras estrategias en pos de la captura, análisis y valoración basada en evidencias es fundamental para mejorar la calidad del producto y del proceso de ejecución de los pro-yectos de fin de curso.

The Protégé did not manifest any oxymoron regarding the ontological model we produced as a general constructor for virtual cities. The ontology presented in this paper has the potential to model up diverse kinds of cities. Nevertheless, regarding any unconsidered aspect in current ontology; it would be very easy to include additional categories or relations in the ontology.

Entre otras ventajas, el método MESEPP ha permitido visibilizar los hábi-tos de estudio y el verdadero trabajo que realizan los estudiantes para la ejecución de los proyectos. Se evidencia un trabajo sin una distribución equi-tativa entre los miembros del equipo y cuyo mayor esfuerzo se concentra en los días próximos a la finalización del tiempo fijado para su ejecución. Esta información progresiva y detallada recolectada con el uso de MESEPP per-mite al docente realizar una ponderación objetiva de sus estudiantes.

Debido a esta objetividad, las valoraciones de la calidad de los proyectos utilizando MESEPP han disminuido comparadas con las obtenidas con el método tradicional. Ocurre entonces que sin información y sin evidencias el docente tiende a sobrevalorar el esfuerzo individual y grupal de los estudian-tes otorgándoles una ponderación mayor.

El componente de retroalimentación incluido en MESEPP ha tenido una respuesta positiva de los estudiantes, ellos han considerado las observacio-nes para mejorar su proyecto y corregir su camino a tiempo cuando la alter-nativa de solución escogida por ellos no ha sido la más adecuada. Con la ejecución de esta investigación se evidencia la importancia de un método como el propuesto. Si MESEPP no es el método más apropiado para un docente debido al sobre esfuerzo que implica su aplicación, de to-das maneras el docente debería encontrar un método, que al igual que el sugerido, le entregue las evidencias suficientes para poder realizar un segui-miento y una valoración objetiva de los proyectos de fin de curso. Sin infor-mación y evidencia suficiente no se puede medir bien, y sin una correcta medición no se puede mejorar la calidad del proceso y del producto final de la ejecución de los proyectos.

Referencias

Bunge, M. (2005). Buscar la filosofía en las ciencias sociales. México: Siglo XXI Editores.


Chacon S, S. B. (2014). Pro Git Second Edition. Apress.


Coria, A., Pastor, I., & Torres, Z. (2013). Propuesta de metodología para elaborar una investigación científica en el área de Administración de Negocios. México: Revista científica Pensamiento y Gestión.


Git. (2015). Git - Fast version control. Recuperado el 2 de agosto de 2015, de Git: https://git-scm.com/


GitHub, Inc. (2015). Twbs Bootstrap. Recuperado el 10 de octubre de 2015, de https://github.com/twbs/bootstrap


Josh, D. (2014). GitHub + University: How College Coding Assignments Should Work. Recuperado el 13 de octubre de 2015, de joshldavis.com/2014/01/19/github-university-how-college-assignments-should-work/


Lawrance, J., Jung, S., & Wiseman, C. (2013). Git on the Cloud in the Classroom. 44th ACM technical symposium on Computer science education. Denver: ACM.


Ray, B., Posnett, D., Filkov, V., & Devanbu, P. (2014). Large Scale Study of Programming Languages and Code Quality in Github. 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering. Hong Kong: ACM.


Real Academia Española. (2001). Diccionario de la lengua española. Recuperado el 25 de Julio de 2015, de Real Academia Española: http://lema.rae.es/drae/?val=método


Sawers, P. (11 de Febrero de 2014). GitHub wants schools to collaborate on code. (The next web, Inc.) Recuperado el 3 de octubre de 2015, de The Next Web: http://thenextweb.com/insider/2014/02/11/github-wants-schools-collaborate-code/


Shaffer, K. (26 de Mayo de 2013). Push, Pull, Fork: GitHub for Academics. Recuperado el 23 de abril de 2015, de HybridPedagogy: http://www.hybridpedagogy.com/journal/push-pull-fork-github-for-academics/


Sierra, R. (2001). Técnicas de investigación social. Teoría y ejercicios. Madrid: S.A. EDICIONES PARANINFO.


Xu, Z. (2012). Using Git to Manage Capstone Software Projects. Seventh International Multi-Conference on Computing in the Global Information Technology. Venice, Italy: IARIA.


Yu, Y., Yin, G., Wang, H., & Wang, T. (2014). Exploring the Patterns of Social Behavior in GitHub. 1st International Workshop on Crowd-based Software Development Methods and Technologies. Hong Kong: ACM Press.


Zagalsky, A., Feliciano, J., Storey, M.-A., Zhao, Y., & Wang, W. (2015). The Emergence of GitHub as a Collaborative Platform for Education. 18th ACM Conference on Computer Supported Cooperative Work & Social Computing. Vancouver, BC, Canada.


Notas biográficas:

Javier Salazar Zárate Javier Salazar Zárate. Ingeniero en Sistemas Informáticos; Magister en Informática Educativa; Ar-quitecto de Software. Consultor de tecnologías para desarrollo web. Fundador de eduKlip, una startup educativa de base tecnológica en Ecuador.



Blanca Hidalgo Ponce Blanca Hidalgo Ponce. Ingeniero en sistemas; Magister en informática aplicada y diplomada en manejo de información a través de internet en la ESPOCH. Coordinadora del programa de maestría en interconectividad de redes IPEC-ESPOCH. Miembro del grupo de investigación en la ingeniería de software GrIISoft –FIE-ESPOCH.



Narcisa de Jesús Salazar Narcisa de Jesús Salazar Doctora en Matemática; Master en Informática Aplicada; Docente de Cálculo Matemático y Probabilidades de la ESPOCH; Directora de las Maestrías en Informática Aplicada y de Matemática Básica; Vicedecana Facultad de Informática y Electrónica de la ESPOCH.



Miguel Lares Byron Vaca Barahona. Doctor en Tecnologías Educativas: e-learning y gestión del conocimiento en la Universidad Roviera i Virgili (España). Miembro del grupo de investi-gación “Applied Research Group in Education and Technology (ARGET)”.







Licencia de Creative Commons

Esta obra está bajo una licencia de Creative Commons
Reconocimiento-NoComercial-CompartirIgual 2.5 México.