Luego de dos ediciones 100% virtuales volvemos a la presencialidad. Si bien la universidad habilitó la presencialidad plena, nuestra idea es tener un esquema híbrido. En principio estamos planificando al menos 4 clases presenciales y las restantes online.
En términos de contenido, no planeamos novedades.
En términos de la dinámica de las clases esperamos hacer un mix de lo que eran nuestras clases presenciales pre-pandemia y nuestras clases online de la pandemia.
Un cambio que estamos evaluando es respecto del trabajo grupal de la materia. Personalmente tengo la idea de que el trabajo tenga un complejidad funcional y técnica un poco mayor que lo que veníamos haciendo, de forma tal que nos habilite a poner en práctica algunas cuestiones que hasta el momento solo estudiábamos de forma más superficial.
Finalmente cierro con algunos datos relevantes para quienes tengan pensado cursar la materia este 2022:
La materia se dictará en modalidad híbrida y que la asistencia es obligatoria.
Semanalmente son 4 horas de clase y adicionalmente hay que dedicar como mínimo otras 4 horas de estudio (según reportan los alumnos suelen dedicar unas ~7 horas extra clase)
Utilizamos Git pero no enseñamos Git
Programamos con Ruby pero que no enseñamos Ruby
Damos por sabido todo lo visto en la materias anteriores, pero definitivamente lo más relevante es lo visto en las materias «Algoritmos y Programación (1,2 y 3)» y «Diseño y Arquitectura de Sistemas«
La materia que dicto (tanto en UBA como en UNTReF) es Ingeniería de Software, pero dado que la «Ingeniería de Software» es un rótulo tan amplio, no basta con decir eso para transmitir qué es lo que realmente estudiamos.
Razonablemente alguien podría pensar que toda materia nombrada como «Ingeniería de Software» debería cubrir los temas descriptos en el Software Engineering Body of Knowledge (SWEBoK). Esto es lo que intentamos hacer en las materias Ingeniería de Software 1 y 2 (conocidas informalmente como memo1 y memo2) de la Licenciatura en Análisis de Sistemas de la UBA. Pero esto muchas veces no es así.
En algunas casas de estudio la materia «Ingeniería de Software» solo cubre una parte de esos temas del SWEBoK. Un caso de esto parece ser la materia Ingeniería de Software de la carrera de Licenciatura en Ciencias de la Computación de la UBA, la cual está muy enfocada en cuestiones de diseño y programación orientada a objetos y sin tratar varios temas de SWEBoK.
También está el caso de algunas carreras que no tienen ninguna materia llamada Ingeniería de Software, sino que cuentan con materias particulares para las distintas disciplinas que componen la Ingeniería de Software (análisis, diseño, programación, testing, etc). Este es el caso de la carrera Ingeniería en Informática de la UBA.
También tenemos el caso carreras que cuentan con materias específicas para algunas de las distintas disciplinas de la Ingeniería de Software y al mismo tiempo tienen una materia Ingeniería de Software que cubre los temas restantes de la Ingeniería de Software que no cubre ninguna materia particular como ser muchas veces las cuestiones de proceso, trabajo en equipo y metodologías de desarrollo. Este el caso de la carrera Ingeniería en Computación de UNTreF.
Más allá de todas estas variantes, hay una cuestión que quiero destacar respecto de la forma en que dictamos las materias MeMo1 y MeMo2 en UBA. Ambas materias pretenden cubrir todas las disciplinas de la Ingeniería de Software, en ambas materias se estudia desde requerimientos hasta puesta en marcha pero con mayor profundidad en distintos temas. MeMo1 tiene un mayor foco en las cuestiones iniciales de los proyectos, como ser visión, requisitos, etc, pero aún así trata cuestiones de metodología, arquitectura, etc. Y un punto central: se hace implementación, o sea, los alumnos tienen que programar y poner lo que programan en un ambiente «símil producción». Esto me parece que es fundamental para cerrar el «feedback loop», recién al poner nuestra aplicación en producción sabemos cuán bueno ha sido nuestro trabajo en requisitos y demás tareas de la ciclo de desarrollo. Por otro lado en MeMo2 también cubrimos todo el ciclo pero con un mayor foco en ciertas cuestiones que MeMo1 toca de forma más superficial. En particular en MeMo2 ponemos mucho foco en proceso de desarrollo, el ciclo de BDD/TDD, CI/CD, Configuration Management y dinámica de equipo.
Particular no solo por ser en modalidad online sino también porque participaron del curso estudiantes externos a la carrera. Esto último es parte de una iniciativa de «abrir la universidad» que comenzamos hace ya un tiempo.
Algunos números descriptivos de este cuatrimestre:
Comenzamos con 10 estudiantes y terminamos con 9
La nota promedio de aprobación fue 8
Tuvimos 35 tareas individuales incluyendo videos, lecturas, cuestionarios y ejercicios de programación
Hicimos un trabajo grupal que duró 5 semanas trabajando en equipos de 3
Luego de 15 semanas de clases online, la última clase la hicimos en modo mixto: parte del curso reunido presencialmente y parte del curso en forma online. En 4 cuatrimestres de pandemia es la primera vez que hacemos una clase en esta modalidad y esta experiencia confirmó mi sospecha: es preferible estar todo el curso en un mismo medio, ya sea online o presencial, pero todos juntos.
Para la reunión presencial, a pesar de estar todos vacunados, seguimos algunos protocolos básicos: todos con tapabocas, ventanas abiertas, etc.
Como de costumbre la última clase estuvo dedicada a una actividad de cierre tipo retrospectiva. De esa actividad sacamos 3 accionables:
Armar una base de conocimiento (con una wiki o documento compartido) donde docentes y alumnos vayan colaborando con preguntas/respuestas frecuentes.
Enviar el checkpoint con las tareas semanales apenas terminada la clase.
Grabar las clases que sean más «teóricas»
Finalmente algunos números de las encuestas de fin de curso:
El miércoles pasado cerramos un cuatrimestre atípico debido principalmente a la situación de pandemia. En términos formales tuvimos dos particularidades: todas las clases fueron virtuales y la duración del cuatrimestre fue de 14 semanas (y no de 16 como es habitualmente). Una curiosidad (o no tanto) es que de no ser por la pandemia es posible que el curso no se hubiera dictado ya que solo tuvimos 2 alumnos que estaban en condiciones formales de cursar la materia y con ese número es común que la universidad no abra el curso principalmente por la escasez de aula (tema muy polémico). Pero la situación de pandemia «nos sacó» del aula y de las restricciones asociadas. Es así que aceptamos en el curso algunos alumnos a los que les faltaba alguna correlativa y también a gente externa a la universidad. Esto último fue un experimento para «abrir» la universidad y que ahora terminado el curso, creemos que fue muy positivo.
Comparto algunas métricas del curso:
14 clases
31 tareas individuales incluyendo lecturas, videos, ejercicios de programación y cuestionarios
1 trabajo grupal
1 invitado de la industria
Cantidad de alumnos inscriptos 5
Cantidad de alumnos aprobados 5
Nota promedio de aprobación: 8.8
Dedicación promedio extra-clase por alumno por semana: ~6 horas
Ya está definido que este año tendremos que dictar la materia en modalidad completamente a distancia y por ello tendremos que hacer algunos ajustes en la dinámica de las clases y de la materia en general. Al mismo tiempo tenemos ciertas dudas sobre la cantidad de alumnos que cursarán.
Por esto es que hemos habilitado este formulario para llenen que los alumnos interesados en cursar Ingeniería de Software este segundo cuatrimestre de 2020 y de esta forma poder hacer una planificación con menos incertidumbre. Quisiéramos que llenen este formulario todos los alumnos que tengan intención de cursar la materia incluso cuando no reúnan todas las correlativas necesarias.
De paso compartimos aquí algunos detalles de la forma en que dictamos la materia:
Intentamos cubrir los temas de la materia con materiales de estudio actualizados y herramientas de uso de frecuente en la industria
Para las cuestiones de programación utilizamos Ruby
Como herramienta de soporte para las tareas de programación y el trabajo grupal utilizamos GitLab
La materia requiere una dedicación semanal de entre 4 y 6 horas adicionales al tiempo de clase
La dinámica de evaluación es continua, con tareas semanales que incluyen lecturas, videos, ejercicios de programación y cuestionarios.
Este artículo describe formalmente la dinámica de la materia
Aquí pueden encontrar varios sobre el dictado de la materia en cuatrimestres anteriores
Ayer terminamos Ingeniería de Software en UNTreF, fue la primera edición de la materia con el nuevo plan de estudio. Este cambio de plan de la carrera no trajo muchos cambios a nuestra materia particularmente, pero si hubo importantes cambios en la materias previas y posteriores a la nuestra, lo cual nos llevó a ajustar algunas clases y la profundidad de algunos temas.
Otra novedad de este cuatrimestre fue que contamos con un alumno en el equipo docente (FerGainey), lo cual a mi entender siempre es un aporte de valor pues aporta una visión distinta a la que tenemos los que dejamos de ser alumnos hace mucho tiempo.
Comenzamos la materia con 10 alumnos y la terminamos con 8, todos aprobados. La nota promedio de aprobación fue 9 (con desvío 1).
Comparto algunos números de la encuesta de fin de curso:
Evaluación general de la materia: 8,5 / 10
Claridad de los docentes 4,5 / 5
Conocimientos de los docentes sobre los temas de la materia 4,8 / 5
Comparativamente este cuatrimestre ha sido el mejor puntuado desde 2016 que fue cuando yo me sumé a la materia.
Entre los ítems destacados que surgieron de la retrospectiva de cierre con los alumnos están:
Mejorar la consigna y material de estudio de algunas de las tareas
Mejorar el feedback escrito en la corrección de las tareas individuales
Mejorar el feedback al final de cada iteración del trabajo grupal
Incluir clases sobre nuevos temas (por ejemplo seguridad informática)
Hacer actividades técnicas/de programación en clase
Personalmente me voy muy conforme con el resultado del cuatrimestre y con varias ideas para el próximo año. Creo que logramos una muy buena química alumnos-docentes a lo largo del cuatrimestre.
Este cuatrimestre será la primera vez que dictemos la materia en el contexto del nuevo plan de estudios. Esto implica ciertos cambios a nivel contenido respecto de lo que veníamos dando en años anteriores. Estos cambios tienen más que ver con cambios generales a nivel del plan de estudios que con cambios en el contenido particular de nuestra materia.
Más allá de los cambios de contenido, planeamos mantener la modalidad de cursada, eso es:
Modalidad de aula invertida
Como consecuencia del punto anterior hay una constante carga de trabajo fuera del aula (~6 horas semanales)
Trabajo y evaluación constante a lo largo de toda la cursada
Según nos indica el sistema de inscripción, tendremos unos 10 alumnos, un excelente número para poder establecer un ambiente de confianza entre los alumnos y los docentes.
Las clases serán los días miércoles, de 18 a 22 horas (inicio puntual) en el aula 307 de la sede Caseros 1.
Ayer cerramos el cuatrimestre de la materia Ingeniería de Software. Fue un cuatrimestre un poco atípico, pues a mediado de cuatrimestre no nos gustó como estaba fluyendo la materia y por ello hicimos un ajuste importante en la planificación. Creemos que con esto logramos corregir el rumbo y finalmente cerramos la materia satisfactoriamente. Comparto algunos números del cuatrimestre.
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):
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