Terminamos el cuatrimestre y me alegra tener la sensación de que seguimos mejorando. Continuamos con el horario matutino de 8 a 11, excelente. Y mantuvimos el mismo porcentaje de clases presenciales/virtuales.

Como siempre hicimos un par de ajustes respecto del cuatrimestre anterior, algunos de ellos basados en el feedback de los alumnos y otros surgidos del equipo docente.

• Uno de los ajustes más importantes fue ser más explícitos sobre la «programación colaborativa» (mob y pair programming), por momentos pedimos explícitamente que no programen en solitario. Esto generó cierta «incomodidad» entre algunos alumnos por verse obligados a coordinar horarios con sus compañeros para hacer algunas tareas. Pero creemos que el resultado fue muy positivo ya que percibimos que se trabaron menos con cuestiones técnicas lo que les permitió terminar las tareas en menos tiempo y con menos grado de «frustración».
• Una novedad fue que para los trabajos grupales, agregamos un facilitador «externo» para las retrospectivas al final de cada iteración iteración. O sea: cada grupo ya tenia un docente en el rol de Product Owner y a eso agregamos un segundo docente que solo se sumaba para facilitar las retrospectivas.
• Otro de los ajustes, no tan visible para los alumnos, tuvo que ver con la infraestructura que utilizamos para el trabajo final debido a algunos cambios en Okteto. Básicamente dejamos de utilizar Okteto y directamente pusimos (casi) todo a correr en nuestro propio cluster Kubernetes en Digital Ocean.
• También pusimos un poco más de foco en las cuestiones relacionadas a la operación o mejor dicho lo que suele llamarse «build for operations»
• Finalmente, estrenamos un nuevo trabajo final que nos trajo renovados desafíos para el equipo docente.

Tanto en la retrospectiva final como en la encuesta de cierre, tuvimos feedback muy positivo de los alumnos. Comparto algunos números de la encuesta:

• La encuesta fue contestada por la totalidad de los alumnos que completaron el curso (11)
• La evaluación general de la materia (en promedio) dio 9.0, lo cual es mayor que el cuatrimestre anterior (8,8).
• Respecto del porcentaje de clases presenciales/virtuales, 10 alumnos lo consideraron apropiado mientras que solo 1 hubiera preferido más virtualidad.
• Las otras dimensiones de evaluación de la materia también resultaron muy positivas: claridad de los docentes: 4,7/5; Conocimientos de los docentes: 5 /5; Dinámica de las clase: 4,6/5; Materiales de estudio: 4/5.
• La dedicación semanal a la materia extra clase dio un promedio de 8,7 lo cual me parece puede estar un poco distorsionado por la últimas semanas en las que los alumnos trabajaron en el trabajo final.
• El NPS nos dio 63 (esta es una métrica que puede tomar valores en el rango -100 +100)

Algunos otros números del cuatrimestre:

• Comenzamos la materia con 13 alumnos dos de los cuales abandonaron aproximadamente a mitad de cuatrimestre. Finalmente completaron la cursada 11 alumnos. Luego todos aprobaron el final.
• Tuvimos 40 tareas individuales que incluyeron: lecturas, videos, cuestionarios y ejercicios de programación
• Tuvimos 1 tarea para trabajar en parejas y dos trabajos grupales con grupos 3 o 4 alumnos
• La calificación promedio de aprobación fue 7,1

Resulta curioso que si bien los números de la encuesta dieron mejor que el cuatrimestre anterior, la calificaciones fueron más bajas, un fenómeno para analizar.

Respecto de la dedicación, el análisis de la información reportada por los alumnos nos indica que:

• La dedicación promedio extra-clase por persona sin considerar los trabajos grupales fue de 65 horas
• La dedicación promedio extra-clase por persona para los trabajos grupales fue tp1: 6 horas y tp2: 14 horas
• En términos generales la dedicación extra-clase promedio por persona a lo largo de toda la materia fue de 7,7 horas semanales.

La facultad de Ingeniería de Universidad de Buenos ofrece dos carreras en el área de sistemas: Ingeniería en Informática y Licenciatura en Análisis de Sistemas. Son dos carreras distintas en el sentido que la licenciatura no es un paso intermedio de la ingeniería. Pero obviamente hay ciertas materias que son «compartidas» por ambas carreras, típicamente las materias de algoritmia, estructura de datos, sistemas operativos y algunas materias de ciencia básica.

En mí época de alumno (allá por comienzos del siglo) ambas carreras compartían dos materias de ingeniería de software que se llamaban: Análisis de Información y Técnicas de Diseño. Tal como los nombres lo sugieren, una estaba centrada en cuestiones de requisitos y la otra en cuestiones de diseño y ambas se cursaban secuencialmente. En el año 2015 la licenciatura modificó su plan de estudio y entre otras cuestiones cambio estas materias reemplazándolas por Métodos y Modelos de la Ingeniería de Software 1 y 2 (comúnmente conocidas como MeMo1 y MeMo2). Por su parte la ingeniería continua aún hoy en día con las mismas dos materias que cursé yo hace 20 años.

Las dos nuevas materias introducidas por la licenciatura están pensadas en línea con la forma en que se desarrolla el software actualmente: de manera iterativa e incremental. Esto implica que en ambas materias se estudia «lo mismo» con distinto pero con distinto foco/profundidad. Ambas materias cubren las distintas actividades del desarrollo de software (requisitos, análisis, diseño, gestión, programación, prueba, etc, etc).

La primera materia (MeMo1) tiene más foco en las primeras actividades del proceso de desarrollo pero cubriendo también cuestiones de diseño, programación y despliegue. La segunda materia (MeMo2) tiene más foco en las cuestiones «del tramo final» incluyendo programación testing, gestión de ambientes y despliegues. Obviamente que hay cierta superposición teórica de temas y es intencional: cuestiones que en una materia tal vez se ven en solo teoría en la otra se ven en la práctica.

A partir de la iniciativa de la Facultad de Ingeniería de rehacer los planes de estudio de todas las carreras, junto a Carlos Fontela y Sergio Villagra comenzamos a trabajar en un propuesta para la enseñanza de la Ingeniería de Software de cara a determinar una estrategia unificada para las 2 carreras. Dado que ambas carreras tienen un perfil distinto, el desafío estaba en determinar el núcleo mínimo común para ambas carreras permitiendo que luego cada carrera acorde a su perfil pueda profundizar contenidos/materias adicionales según considere necesario. En lo que resta de este artículo voy a compartir algunos de los puntos que me parecen más importantes de la propuesta en la que trabajamos.

Antes de hablar de potenciales materias y sus contenidos, hay 2 premisas que tomamos como puntos de partida:

1. Hay contenidos de ingeniería de software que deben ser abordados en forma temprana y transversalmente en todo el plan de estudio. Ejemplos de esto son prueba unitaria automatizada y versionado.
   
2. La ingeniería de software debe cubrir todo el proceso de desarrollo, desde la formulación de la idea hasta la puesta en producción. Lo primero es algo muy aceptado y muy presente en la bibliografía, podríamos incluso llamarlo Ingeniería de Requisitos. Lo segundo es algo un poco más polémico y menos habitual en la academia pues incluye cuestiones como despliegues, ambientes, infraestructura y hasta algunas cuestiones operación, lo que comúnmente se engloba bajo el término «DevOps».

Continuará….