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.

Ingeniería de Software: materiales de estudio

Hace un par de semanas un colega docente me hizo una consulta porque tenia que comenzar a dictar una materia de Ingeniería de Software. Hicimos una llamada vía skype y le conté sobre el enfoque que suelo usar en mis materias sobre dicha temática. Al final de la charla quedamos en que le compartiría los materias de estudio que utilizo y de ahí la idea de este post.

En primer lugar un poco de contexto. Yo dicto dos materias de Ingeniería de software una en UNTREF y otra en UBA (Facultad de Ingeniería). La materia de UNTREF se llama efectivamente Ingeniería de Software mientras que la de UBA se llama Métodos y Modelos en la Ingeniería de Software 2 (memo2). Más allá de las diferencias de nombres, el contenido de ambas materias es muy parecido y la dinámica de cursada y aprobación es la misma (está descripta en este paper).  Al mismo tiempo hay que destacar que en ambos casos los alumnos llegan luego de haber cursado previamente alguna otra materia de Ingeniería de Software más introductoria, con lo cual ya tienen cierta idea de un proceso de desarrollo y han leído/estudiado algunos de los clásicos como No Silver Bullet y el SWEBoK.

Explicado el contexto vamos al contenido. En ambos casos tomamos como base el libro Construcción de Software: una mirada ágil (aunque no lo leemos completo). Complementariamente tenemos los siguientes materiales (no todos son de “consumo obligatorio” y en algunos casos se referencia un libro, pero no pedimos leerlo completo sino algunos capítulos en particular):

Adicionalmente tenemos algunos material de nivelación sobre temáticas que se supone vieron en materias anteriores:

Debo mencionar que esta lista de materiales está en constante evolución.

Cierre de cuatrimestre en MeMo2 @ FIUBA

La semana pasada finalizamos el segundo cuatrimestre de la materia con dos diferencias muy importante respecto de cuatrimestre anterior:

  • Se sumó Emilio Gutter al equipo docente.
  • Hubo un total de 20 alumnos (el primer cuatrimestre hubo solo 3)

Comparto algunos números frios:

  • 20 inscriptos: 3 abandonos, 17 aprobados
  • Nota promedio de aprobación: 8,1
  • 3 visitas de la industria
  • 1 clase especial
  • 2 invitados de la industria
  • 8 cuestionarios
  • 8 katas/ejecicios

Algunos otros números surgidos de la encuesta interna de la materia:

  • Cantidad de respuestas: 16
  • Evaluación general de la materia: 8,25 / 10
  • Claridad de los docentes: 4,25 / 5
  • Dinámica de clases: 4,4 / 5
  • Materiales de estudio: 4,3 / 5
  • Dedicación semanal promedio fuera de clases (horas): 7.8

Finalmente están los números resultantes de la encuesta oficial del departamento de computación:

  • Cantidad de respuesta: 14
  • Opinion general de la materia: 4,14 / 5
  • Dificultad de la materia: 3,57 / 5
  • Nivel de las clases: 4,2 / 5

Personalmente estoy muy contento con este resultado aunque sabemos que tenemos algunas cuestiones a mejorar:

  • Rearmar algunas clases: generar más videos para poder incorporar actividades más interactivas en las clases presenciales
  • Ajustar las fechas de los TPs
  • Clarificar al comienzo del cuatrimestre los criterios de aprobación/evaluación

Para cerrar dejo algunas fotos tomadas en algunas clases:

Sobre los trabajos finales de carrera

Reciente algunos alumnos vinieron a consultarme para que los dirija en la realización de sus trabajos finales de carrera. Luego de repetir los mismo por tercera vez decidí ponerlo por escrito.

Mi condición para dirigir un trabajo es que el desarrollo del mismo se haga bajo las siguientes condiciones:

  • El trabajo se plantea como un proyecto de alcance variable, esfuerzo fijo y calendario ajustable (pero no mucho). El esfuerzo está dado por lo que determina el reglamento de la institución. Respecto del calendario, la institución suele poner un tiempo límite pero en general es mucho mayor del necesario. Adicionalmente mi idea de calendario es que el trabajo esté listo en un plazo máximo de medio año.
  • No dirijo trabajos de alumnos que no hayan sido alumnos en alguna de mis materias. El trabajo final es un proyecto “one-shot”, y la dupla alumno-director es en cierto modo como un equipo.  Resultaría muy arriesgado para un proyecto one-shot formar equipo con gente que no se conoce previamente.
  • Desde el punto de vista metodológico trabajamos a lo XP con iteraciones semanales.
  • A partir del momento que se inicia el desarrollo, se trabaja a un ritmo constante durante un período de ~16 semanas (un cuatrimestre).
  • Previo al comienzo de desarrollo hay un fase de setup/envisioning de aproximadamente 1 mes (a esfuerzo variable)
  • Una vez completado el desarrollo, hay un período de ~1 mes para terminar de redondear las cuestiones formales para la presentación del trabajo.

Para empezar recomiendo a los alumnos crear un GoogleDoc y empezar a escribir la propuesta de trabajo, no toda la propuesta pero si la parte de lo que sería la visión de proyecto.

Un tercio de cuatrimestre en MeMo2@Fiuba

Hemos completado la sexta semana de clase y estoy conforme con como viene saliendo la materia. Tenemos 18 alumnos firmes, uno en la cuerda floja y uno que abandonó en la segunda semana.

La semana pasada hicimos una retrospectiva y las conclusiones fueron muy buenas a mi juicio. Entre los puntos positivos mencionados por los alumnos estuvieron los videos, la actividad de programación en clase, el material de lectura y el feedback dado en las correcciones de las tareas. Entre los action ítems resultantes acordamos trabajar en los siguientes 3:

  • Habilitar un espacio en el campus para debatir las preguntas de los cuestionarios
  • Seguir agregando más videos al material de estudio de forma de poder utilizar más tiempo de clase para actividades interactivas
  • Procurar que las preguntas de los cuestionarios que sean de tipo verdadero/falso tengan un campo de justificación

El Perfil de los alumnos de MeMo2 @ Fiuba

La semana pasada comenzaron las clases y de cara a conocer fehacientemente el perfil de los alumnos hice una breve encuesta. Comparto aquí algunos de los resultados.

Respecto de la condición laboral, el 70% trabaja y mayoritariamente lo hace en una actividad afín a la carrera.

Respecto de la cantidad de materias que están cursando este cuatrimestre, la mayoría (55%) contestó 3. Es un número “conservador” pero inferior a la cantidad que prescribe el plan de estudios formal. Esto podría ser una explicación para el hecho de que en general son muy pocos los que completan la carrera en el plazo estipulado por el plan.

Un dato que me llamo mucho la atención es la gran dispersión en la cantidad de materias aprobadas: el alumno con menos materias aprobadas tiene 10, mientras que el alumno con más materias aprobadas tiene 27. Una explicación posible para esto es que quienes tienen más materias, han cursado varias de las electivas, mientras que quienes tienen menos, han cursado solo las obligatorias para llegar a esta materia.

Finalmente, la última pregunta apuntaba al rol en el que les gustaría desempeñarse profesionalmente a largo plazo. Me alegró ver que la gran mayoría eligió roles técnicos.