Notas sobre los trabajos finales de carrera en informática/computación

Notas sobre los trabajos finales de carrera en informática/computación

Durante este cuatrimestre he recibido varias consultas sobre trabajo finales de carrera tanto en FIUBA como en UNTREF.

En UNTreF los alumnos deben hacer un Trabajo final Integrador mientras en FIUBA los alumnos pueden optar por Trabajo Profesional o una Tesis. En este artículo quiero centrarme en el Trabajo Profesional de FIUBA que es equivalente al Trabajo Final Integrador de UNTreF. En otro post trataré el tema de la tesis.

Antes que nada aclaro: lo que escribo aquí no es información oficial de ninguna carrera. Esto es un resumen Es información que yo he recopilado a partir de charlas informales con otro

Algunas cuestiones generales sobre este TFI/TP son:

  • Puede hacerse en forma individual o grupal.
  • Se espera que insuma un esfuerzo aproximado de unas 200 horas por estudiante.
  • Es necesario un profesor que dirija el trabajo.
  • El estudiante debe presentar una propuesta formal con el aval de su director.
  • No existe una lista de temas para el trabajo, en ocasiones los profesores/directores tienen algunas propuestas.
  • Se espera que el trabajo integre los contenidos y habilidades adquiridas durante la carrera.
  • El trabajo no es un trabajo práctico de una materia, es un trabajo final de carrera con lo cual las complejidad y alcance deberían ser mayores a los de un trabajo práctico de una materia.
  • Típicamente el trabajo consiste en algún tipo de desarrollo. No es mandatorio que el desarrollo sea alto totalmente nuevo, la novedad o desafío puede estar en la forma de resolución, en las tecnologías utilizadas o algunas otra cuestión de índole ingenieril.
  • Una fuente interesante de ideas que suelo recomendar es el Technology Radar que publica periódicamente la gente de Thoughtworks

Espero estas líneas resulten de utilidad.

Notas Retro, memo2@Fiuba

De cara a identificar oportunidades de mejora en la dinámica de la materia, ayer hicimos la primera retrospectiva del cuatrimestre. Hicimos el clásico keep-fix-try. Comparto algunos de los ítems más destacados:

Keep:

  • Dinámica de trabajo con GitLab
  • Bibliografía propuesta
  • Videos
  • Dinámica de interacción en la lista de correo de la materia

Fix:

  • Algunos ejercicios llevaron más tiempo de lo que se esperaba.
    • Es cierto, puntualmente 2 de las 8 tareas realizadas hasta el momento, insumieron más de las 6 horas estimadas.
    • Realmente es difícil saber cuanto tiempo le llevará a los alumnos completar un ejercicio, lamentablemente nos equivocamos en la estimación.
    • No hay mucho que podamos hacer al respecto de esto más que intentar estimar mejor.
  • Las consignas de algunos ejercicios fueron publicadas sin estar lo suficientemente pulidas, lo cual implicó que se fueran refinando mientras los alumnos ya estaban trabajando.
    • Es cierto que hubo algunos errores en las consignas, pero al mismo tiempo nos parece bien ir refinando las consignas en forma colaborativa a medida que se trabaja pues es lo que ocurre en el mundo real.
    • Nos llevamos como tarea, hacer algún mecanismo de review previo a la publicación para intentar que las consignas lleguen a la publicación estando más pulidas.

Try:

  • Que la retrospectiva la facilite alguien externo a la materia
    • Lo evaluaremos
  • Proveer una configuración Docker (como alternativa al vagrant que ya compartimos)
    • Lo evaluaremos
  • Hacer revisiones de código entre estudiantes
    • Lo evaluaremos

Al finalizar les pedimos a los estudiantes que evalúen a modo de termómetro los temas y la dinámica de la materia. Los resultados fueron muy positivos, ambas cuestiones dieron en promedio por encima de 8 (imagen adjunta)

Preparando MeMo2 2019

La primera novedad que tenemos es la extensión del equipo, 5 ex-alumnos de la materia se suman como colaboradores. Esperamos que esto nos ayude a mejorar los tiempo de corrección y tener una mirada del curso más cercana a los alumnos.

Por otro lado estamos ajustando la planificación y el contenido para hacer hacer más foco en cuestiones diseño y programación.

Según nos indica el sistema de inscripción parece que este cuatrimestre tendremos record de alumnos, hay momento hay 27 inscriptos.

En términos de herramientas seguiremos trabajando con Ruby y GitLab pero extendemos el uso de GitLab, o sea, más allá de la funcionalidad de repositorios e integración continua, utilizaremos también las funcionalidades de issue tracking.

Cierre del segundo cuatrimestre 2018 en MeMo2

Completamos la tercera edición de MeMo2. El resultado es raro, por un lado nuestra sensación como equipo docente es que la materia fluyó mucho mejor que el cuatrimestre anterior (lo cual en cierto modo se refleja en mejores notas de aprobación) pero otro lado, las encuestas incluyeron algunos puntos negativos. Hubo alumnos que manifestaron que el contenido de la materia no les resultó interesante. Es poco lo que podemos hacer sobre esto, pues el contenido viene principalmente dado por el plan de estudio. Personalmente me resulta curioso porque el contenido de la materia tiene mucho que ver con el ejercicio profesional y de hecho todos los encuestados indicaron que el contenido les pareció actualizado. Por otro lado hubo quejas respecto de las interacciones con los alumnos lo cual se debió en gran medida al hecho de que todas las comunicaciones las hacemos por medio de la lista de correo de la carrera, incluso las que implican aplazos en la materia. A esto se suma el uso de algunas expresiones/frases que han sonado poco amables. Ya hemos hecho nuestra retrospectiva interna de cátedra y hemos identificado algunos puntos de acción para mejorar este tema el próximo cuatrimestre. Adicionalmente, yo personalmente voy a trabajar en intentar mejorar mis expresiones. Más allá de estas cuestiones, estos son los números fríos para la estadística:

  • Evaluación general del curso (según encuesta interna): 7.8 / 10
  • Opinión general de la materia (según encuesta del departamento): 3.5 / 5
  • Claridad de los docentes (según encuesta interna): 4.6 / 5
  • Conocimiento de los docentes (según encuesta interna): 4.6 / 5
  • Dinámica de clases (según encuesta interna): 4.5 / 5
  • Materiales de estudio (según encuesta interna): 3.6 / 5
  • Dedicación promedio extra clase (según encuesta interna): 6 hs. semanales

Repensando los trabajos prácticos

Si analizamos los trabajos prácticos que suelen hacerse en las carreras de informática como si fueran proyectos, veríamos que en general están planteados en términos de:

  • Alcance fijo: el docente define todo lo que hay que hacer y no negociable
  • Tiempo fijo: el docente indica la fecha de entrega, la cual generalmente tampoco es negociable
  • Esfuerzo variable: el docente no fija el esfuerzo que debe invertirse para completar el trabajo. Esto suena razonable, ya que habiendo fijado las otras dos variables es de esperar que esta sea ajustable.

Todos los trabajos prácticos que hice durante mi carrera de grado y postgrado fueron así y por lo que suelo hablar con mis alumnos, esto sigue siendo así. Duramente mucho años en las materias que estuve como docente también usábamos esta estrategia pero desde hace unos años hemos cambiado.

Actualmente en las dos materias de ingeniería de software que dicto utilizamos una estrategia distinta:

  • Esfuerzo fijo: les pedimos a los alumnos una dedicación semanal de 6 horas efectivas, extra clase por persona
  • Tiempo fijo: trabajamos durante 3 iteraciones, cada una de 1 semana de duración
  • Alcance variable: hay una lista de ítem/funcionalidades priorizadas y cada equipo estima y asume un compromiso en base a lo que consideran que podrán completar. Incluso si llegan a completar el compromiso, no tienen “penalización” de nota

Y particularmente en este cuatrimestre hicimos un primer trabajo práctico con las modalidad previamente descripta y tenemos un segundo trabajo práctico planteado de forma distinta:

  • Alcance fijo: está definido el conjunto de funcionalidades a completar
  • Tiempo variable: cada equipo decide cuando tiempo tomará para completar las funcionalidades. Trabajamos en iteraciones de duración fija, pero equipo decide la cantidad de iteraciones que utilizará. Idealmente creemos que el trabajo puede completarse 2 iteraciones, pero les damos a los alumnos la posibilidad de utilizar 4 o incluso 5 iteraciones
  • Esfuerzo variable: cada equipo elige cuanto esfuerzo pondrá en cada iteración. De esa forma en una iteración dada que coincida con fecha de examen de otra materia podrían poner poco esfuerzo y luego compensarlo en una iteración posterior.

Personalmente estoy muy convencido y contento con la estrategia TEfAv (tiempo y esfuerzo fijos, alcance variable). Y tengo mucha expectativa con este nuevo experimento de AFTEV (alcance fijo, tiempo y esfuerzo variable).

El desafió de Enseñar a Diseñar

El desafió de Enseñar a Diseñar

Desde mi comienzo en la carrera docente siempre he estado en materias que en mayor o menor medida han incluido la temática de diseño de software. Cuando estaba en Algo3 y AyDOO era diseño a nivel de clases, ahora en MeMo2 cubrimos un poco de diseño a nivel de clases y también diseño de más alto nivel (arquitectura e infraestructura). Enseñar a diseñar es una tarea que me parece muy difícil. De entrada debemos decir que no hay diseños “malos” o “buenos”, sino que un diseño podrá ser más o menos conveniente dependiente del contexto. Un diseño es consecuencia de un conjunto de decisiones, diseñar es decidir, elegir. Pensando en el proceso de diseño veo al menos 3 pasos:
  1. Entender el contexto, el problema a resolver, las restricciones y necesidades. Esto es lo que Kazman denomina Architectural Drivers.
  2. Entendido el contexto hay que identificar las decisiones relevantes que deben tomarse.
  3. Finalmente para cada decisión relevante hay que analizar las posibles alternativas y elegir una. Esto puede implicar hacer algunas pruebas de concepto para poder tomar decisiones con evidencia que las respalde.
El punto 1 cae dentro del área denominada ingeniería de requerimientos y cuenta con un amplio cuerpo de conocimiento. El punto 2, ya es más complejo y más allá del cuerpo de conocimiento requiere de experiencia, lo cual es bastante difícil de transmitir. El punto 3 también reviste de complejidad pero creo que en general es más fácil que el punto 2. A mi parecer identificar opciones y evaluarlas para decidir es una trabajo en esencia muy ingenieril. A comienzo de año estábamos hablando con mi colega docente Diego Marcet sobre los criterios de corrección de un ejercicio de AyDOO y lo vimos:
Pretender que en un cuatrimestre académico alguien aprenda a diseñar es demasiado ambicioso, o sea, se puede enseñar algún método/heurística pero pretender dominarlo y generar buenos resultados puede ser difícil. Por ello ajustamos nuestro objetivo para centrarnos en dar a los alumnos herramientas para ser capaces de detectar las decisiones importantes y al mismo tiempo que sean capaces de detectar decisiones inapropiadas para un contexto dado.
De cara a este objetivo trabajamos bastante sobre código ajeno, o sea, analizando y extendiendo código existente. Continuará….

Preparando la tercera edición de MeMo2 (95.21 / 75.10)

Se acerca un nuevo cuatrimestre y como de costumbre estamos haciendo ajustes en la planificación de la materia. Comparto aquí algunos datos importantes para aquellos alumnos que estén evaluando anotarse en nuestro curso este segundo cuatrimestre de 2018.

  • La materia se dictará lunes y jueves de 19 a 22.
  • El equipo docente estará conformado por Emilio Gutter y por quien escribe.
  • Estimamos que los alumnos deberán dedicar aproximadamente unas 7 horas de trabajo semanal extra-clase.
  • Mantendremos la misma propuesta pedagógica, la cual implica: clase invertida y trabajo continuo todas las semanas.
  • Continuaremos trabajando con el mismo stack de herramientas/tecnologías (Ruby, Padrino, GitLab, Heroku) e intentaremos agregar algo de Infraestructura como Código y Monitoreo.
  • Tendremos dos trabajos prácticos grupales.

Más allá de todo esto, estamos realizando varios ajustes a las clases.