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 AyDOO 2018 @ UNTREF

La semana pasada cerramos el curso 2018 de Análisis y Diseño Orientado a Objetos en UNTREF. Personalmente creo que en términos organizativos fue una de las mejores ediciones. Estos son los puntos destacados del cuatrimestre:

  • 12 inscriptos: 7 aprobados, 2 abandonos, 1 desaprobado y 2 con final pendiente
  • La nota promedio de cierre de cursada fue 6,6/10
  • La evaluación general de la materia realizada por los alumnos (vía encuesta anónima) fue de 8,3/10.
  • El tiempo promedio semanal dedicado por los alumnos a la materia fuera del aula fue de 10 hs
  • El equipo docente estuvo conformado por Diego Marcet, Lucas Campaner y yo

Entre los puntos a mejorar los alumnos destacaron:

  • Necesidad de mayor claridad en la consigna de los ejercicios
  • Necesidad de unificar algunos criterios de corrección.

Casi con seguridad este fue el último cuatrimestre de esta materia, ya que la misma pertenece al viejo plan de estudios que está siendo reemplazado. Es por esto que me parece interesante aprovechar para compartir algunas estadísticas históricas a lo largo de los últimos 3 años:

  • La evaluación general de la materia evolucionó constantemente en forma positiva, al igual que la claridad de los contenidos y la dinámica de clases.
  • Al mismo tiempo la cantidad de inscriptos y la nota formal de aprobación muestran una disminución.
  • Al cabo de 3 años la evaluación general de los fue 7,9 (promedio) mientras que la nota promedio de aprobación fue 7.5.
  • El promedio general de aprobados de la materia fue de 75% (en el 25 % restante están los que no aprobaron durante la cursada y que tal vez aprobaron en un fecha posterior o en un examen libre).

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.

Promediando el cuatrimestre en AyDOO @ UNTREF

Hemos completado la séptima semana de clase de Análisis y Diseño Orientado a Objetos en UNTreF. Este cuatrimestre viene con varias novedades.

En primer lugar tuvimos un cambio de equipo el cual esta conformado por: Diego Marcet (egresado de FIUBA con quien tuve el gusto de trabajar profesionalmente en diversas ocasiones y que está definitivamente en mi Dream Team) y Lucas Campaner (estudiante de UNTreF y uno de los mejores ex-alumno de la materia).

Otra novedad fue el cambio de la herramienta de soporte, comenzamos a utilizar Canvas LMS, una herramienta que yo ya venía utilizando en otras materias.

Finalmente la novedad a mi parecer más importante es el cambio en la dinámica de la clases. Este cuatrimestre estamos dividiendo la clase en 2 partes. En la primera vemos algo de teoría, atendemos consultas o resolvemos algún ejercicio en forma conjunta utilizando el proyector. En la segunda nos dedicamos a programar. Planteamos alguna consigna y programamos en grupos de tres, haciendo lo que podríamos denominar como “trio-programming” (o pair-programming con trios en lugar de pares). Al mismo tiempo los docentes vamos rotando por los equipos atendiendo dudas, debatiendo diseños y programando.

Esta semana, hicimos un retrospectiva con la intención de tener un feedback formal de los alumnos y detectar oportunidades de mejora. El feedback fue muy positivo y los alumnos destacaron el hecho de programar en clase. Entre los puntos accionables que salieron de la retrospectiva están:

  • Tener una semana sin tareas. En la dinámica que llevamos los alumnos tienen tareas todas las semanas lo cual hace que la materia tenga un ritmo intenso. Suele ocurrir (como en cualquier contexto de aprendizaje) que los alumnos deben reentregar alguna tarea y eso complica aún más la dinámica ya de por si intensa. En ese contexto los alumnos sugirieron tener una semana sin tareas para que quienes estén adeudando algo puedan ponerse al día.
  • Mejorar el material de estudio sobre diagramas de secuencia que actualmente resulta insuficiente.
  • Ajustar el tiempo de requerido por la materia y la dinámica de reentregas. Si bien en nuestro diseño de la materia esperábamos una dedicación extra-clase de 6 horas semanales, los alumnos reportaron estar invirtiendo unas 10 horas. Parte de las cuales resulta consecuencia de las múltiples reentregas que tienen algunas tareas. En este sentido acordamos que cada tarea tendrá solo una reentrega.

Sobre las prácticas técnicas y “las otras”

Hace un par de días circuló por la red un frase de Ivar Jacobson: Kill All Methods — Free the Practices“. Esto nos resonó mucho dentro de nuestro equipo de investigación en UNTreF porque nuestra temática de trabajo está enfocada en  prácticas de desarrollo de software.

En términos generales entendemos que en el desarrollo de software hay dos grandes grupos de prácticas cuyos nombres aún no terminamos de cerrar pero que por el momento venimos denominando practicas técnicas y prácticas organizacionales. Esta clasificación/agrupamiento de prácticas no es algo necesariamente novedoso, de hecho Bertrand Meyer en su libro Agile! habla de prácticas técnicas y organizacionales. Por otro lado, en el reporte anual de Agile de Version One se habla “técnicas ágiles” y “prácticas de ingeniería”.

En el contexto de nuestra investigación las prácticas organizacionales son aquellas practicas aplicables en diversas disciplinas porque no requieren conocimiento específico de la disciplina porque tratan sobre la forma en que el equipo de organiza para realizar su trabajo.  Un ejemplo de este grupo de prácticas son las de gestión de proyectos, las cuales pueden aplicarse tanto en un proyecto de desarrollo de software como un proyecto de construcción civil.

Las prácticas técnicas son prácticas particulares de la disciplina y que generalmente no aplican (o pierden sentido) en el contexto de otra disciplina. Un ejemplo de esto podrían ser las prácticas de versionado de código en desarrollo de software.

Continuará…

Cierre de cuatrimestre en Ingeniería @ UNTreF

La semana pasada cerramos el cuatrimestre en la materia Ingeniería de Software en UNTreF. Fue mi tercer cuatrimestre en la materia y personalmente estoy muy conforme con el resultado. Algunas particularidades de este cuatrimestre fueron:

  • Tuvimos un cambio en el equipo docente, Diego Marcet (@diemarcet) reemplazó a Pablito Tortorella (@pablitux)
  • Cambiamos el campus virtual que usamos como herramienta de soporte, pasamos de Eliademy a Canvas.
  • Hicimos algunos ajustes en el programa, incluyendo algunos temas nuevos relacionados principalmente a cuestiones de control de calidad y gestión de la operación
  • Tuvimos dos clases especiales: una sobre modelos de calidad dictada por Sergio Villagra y otra dictada por Fernando Pelliccioni quien compartió la forma de trabajo de su equipo de desarrollo en Bitprim

En términos estadísticos:

  • 8 inscriptos, 1 abandono, 7 aprobados
  • La nota promedio de cierre de cursada fue 8,9
  • La evaluación general de la materia realizada por los alumnos (vía encuesta anónima) fue 8,3

Entre los puntos a mejorar que identificamos en el cierre de la materia destacamos:

  • Mejorar la consigna de la tarea de performance testing
  • Agregar un video introductorio a JMeter
  • Revisar el envió de notificaciones del campus (varios reportaron que la notificaciones les llegaban con mucho retraso)
  • Repetir el ejercicio del elefante carpaccio que fue de las mejores actividades de la materia
  • Comenzar antes con el desarrollo del trabajo final
  • Intentar que las tareas individuales se hagan sobre la misma base de código que el trabajo final
  • Hacer una introducción técnica a Padrino
  • Probar haciendo que las iteraciones del trabajo final sean de 2 semanas

Primeros egresados UNTreF

El pasado miércoles por la tarde tuve la oportunidad de asistir a la defensa del trabajo final de carrera de los dos primeros egresados de la carrera de Ingeniería en Computación de la Universidad Nacional de Tres de Febrero: Fernando Scorpiniti y Fernando Degirmenntjis. Adicionalmente fui jurado evaluador de uno de estos trabajos. Más allá de lo que esto representa para los egresados y sus familias, este es un gran hito para la carrera e incluso para la universidad. Mis felicitaciones a ambos Fernandos.

PD: Curiosamente también fui jurado evaluador del trabajo de primer egresado de la Tecnicatura en Programación de UNQ, ¡que loco!