Recomendaciones para alumnos de MeMo2

Como de costumbre en cada cuatrimestre intentamos incorporar mejoras en base al feedback recibido el cuatrimestre anterior. Entre esas mejoras vienen algunas recomendaciones para los alumnos:

  • Dado que gran parte del trabajo de la materia es en grupo te recomendamos que ya de entrada coordines con otros alumnos para conformar grupos 3 integrantes.
  • La materia se dicta en modalidad virtual con lo cual es mandatorio para cursarla contar con sistema de audio (parlante y micrófono). Asimismo es importante que cuentes con cámara.
  • Si aún no tienes una cuenta @fi.uba.ar es un buen momento para que la tramites.
  • La materia tiene un flujo importante de mails durante la época de trabajos grupales con lo cual podría resultar muy útil (y conveniente) aprender a armar filtros en tu herramienta de correo electrónico.
  • En la materia utilizamos Git y Ruby pero no dedicamos tiempo de clases a enseñar ninguna de estas dos herramientas, por ello si aún no estas familiarizado con estas herramientas te recomendamos que comiences a estudiarlas a la brevedad.
  • Si sos alumnos de Ingeniería Informática y como tal debes cursar Técnicas de Diseño (75.10) te recomendamos que leas este artículo donde explicamos que MeMo2 no es TDD.
  • Más allá de las 6 horas de clases semanales (de asistencia obligatoria), la materia suele demandar una dedicación semanal constante de otras ~6 horas semanales de trabajo/estudio fuera del horario de clase todas las semanas. Durante las primeras semanas puede que sea un poco menos y durante las últimas semanas puede que sea un poco más.
  • Es muy importante que asistas las primera clase, pues ahí explicamos varias cuestiones sobre la dinámica de la materia y la modalidad de evaluación. Si por alguna razón no puedes asistir por favor comunícate conmigo a la brevedad.

Antes cualquier duda puedes contactarme por aquí.

FIUBA: MeMo2 no es TDD

Escribo esta líneas para potenciales alumnos de mi materia y por ello agrego un poco de contexto para los lectores ajenos a FIUBA. En FIUBA se dictan actualmente dos carreras relacionadas a sistemas/informática/computación. Por una lado está la Licenciatura en Análisis de Sistemas y por otro la Ingeniería en Informática. Son dos carreras separadas, no es que la licenciatura es un paso intermedio de la ingeniería. Son dos carreras distintas, totalmente independientes pero que comparten varias materias.

La materia que yo dicto actualmente se llama Métodos y Modelos en la Ingeniería de Software 2 (código 95.21). Comúnmente es conocida como MeMo2. Es una materia que surgió a partir de la reforma 2015 del plan de estudios de la carrera de Licenciatura en Análisis de Sistemas. En el plan anterior había dos materias de ingeniería de software, una enfocada en cuestiones de análisis (Análisis de la Información – 75.09, comúnmente conocida como AnInfo) y otra enfocada en cuestiones de diseño (Técnicas de Diseño – 75.10, comúnmente conocida como TDD). Estas dos materias eran compartidas entre ambas carreras. Con el nuevo plan de estudios de la licenciatura se actualizó la visión de la ingeniería de software y esa dos materias (75.09 y 75.10) fueron reemplazadas por dos materias nuevas (95.20-MeMo1 y 95.21-MeMo2) que apuntan a cubrir con distinto nivel de profundidad todas las actividades de la ingeniería de software. Adicionalmente también se agregaron temas de ingeniería de software a otras materias del plan. De esta forma MeMo2 quedaba exclusivamente para la Licenciatura y TDD exclusivamente para la ingeniería.

En este contexto yo armé la materia MeMo2 en base al programa de la licenciatura. Cuando comencé a dictar la materia tuve muy pocos alumnos pues el plan era nuevo. Al poco tiempo, el Departamento de Computación decidió que mi materia, MeMo2, del plan de la licenciatura, era equivalente a TDD del plan de la ingeniería, una decisión polémica a mi parecer. Esto implicó que mi materia sea formal y simultáneamente MeMo2 y TDD. Yo siempre consideré esta decisión muy polémica ya que en términos formales los programas de TDD y MeMo2 tienen muy poco en común (a simple vista no más de un 30%).

Hoy en día mi materia sigue siendo formalmente MeMo2 y TDD pero en términos reales en su contenido es MeMo2. Esto hace que en habitualmente alumnos de la ingeniería vengan a cursar mi materia con una determinada expectativa (contenidos de TDD) pero se encuentran con algo distinto (contenidos de MeMo2).

Comparto una tabla comparativa de los programas de ambas materias, resaltando en verde los temas de TDD que cubrimos en MeMo2.

Cierre del segundo cuatrimestre 2020 en MeMo2@fiuba

Terminamos nuestro segundo cuatrimestre en modalidad 100% online. Fue un cuatrimestre muy particular, porque más allá de la virtualidad, tuvimos un cuatrimestre partido: por la situación de pandemia el inicio de clases en 2020 se retrasó y eso impactó en todo el calendario quedando el segundo cuatrimestre partido en 2. La primera parte terminó a mediados de diciembre permitiendo completar 12 semanas de clase. La segunda se retomó en febrero y contempló 4 semanas de clases para así completar las correspondiente 16 semanas de clases del cuatrimestre. Este particionamiento generó ciertas incomidades tanto para alumnos como para docentes.

Por otro lado, al margen de la particulidad del calendario y la virtualidad, este cuatrimestre hicimos 2 cambios mayores en la dinámica del TP2.

En primera instancia, no escribimos una descripción detalla de consigna. Previamente solíamos darle a los alumnos una especificación funcional de la aplicación a desarrollar en forma de pruebas de aceptación, las mismas no eran completas pero daban un nivel de detalle suficiente para marcar el comportamiento y alcance esperado. Este cuatrimestre cambiamos esto pues nos parecía que en cierto modo era una situación demasiado ficticia en el sentido que esas pruebas de aceptación no son típicamente provistas por el cliente/usuario sino que se desarrollan conjuntamente (equipo de desarrollo + usuarios) a medida que “se va descubriendo” el software a construir. En línea con esto, este cuatrimestre no les dimos las pruebas de aceptación, hicimos un product discovery y luego dejamos que cada equipo haga el trabajo de descrubimiento con su Product Owner (miembro del equipo docente). Obviamente que puertas adentro, todos los product owners (o sea el equipo docente) acordamos y alineamos ciertos puntos centrales de cara a intentar asegurar que todos los grupos construyan la misma aplicación más allá de algunas diferencias en términos de reglas de negocio. Esto trajo de la mano ciertas situaciones de negociación y trabajo de más ida y vuelta entre product owner y equipos de desarrollo, lo cual fue intencional para llevar a la práctica el slicing de funcionalidades. Respecto de este cambio, nos gustó y seguiremos con esta estrategia pero somos concientes que es necesario realizar algunos ajustes en la dinámica.

El segundo cambio importante requiere explicar un poco el contexto. Típicamente el TP2 tiene 3 ejes: alcance/funcionalidad, proceso y diseño/implementación. Previamente cada equipo de alumnos tenia un docente asignado que trabaja sobre los 3 ejes, proveía definiciones funcionales (tomando un rol típicamente de Product Owner), verificaba el cumplimiento del proceso (más en onda PMO que facilitador) y finalmente hacía seguimiento/evaluación de las cuestiones de diseño/implementación. Este cuatrimestre dividimos estas responsabilidades/ejes. Por un lado cada equipo tuvo asignado un docente que se encargaba del seguimiento del proceso y jugaba el rol de product owner proveyendo definiciones funcionales y validando su aprobación. Por otro lado, otro docente (yo en este caso) se encagó de la guíar técnicamente a todos los equipos y hacer el seguimiento y correcciones de diseño e implementación. También nos gustó este cambio y por ello vamos a mantenerlo.

Algunos otros cambios de menores que hicimos fueron que recortamos algunos temas (como escalamiento de agile y performance tests) e incluimos algunos nuevos. En realidad no es que agregamos nuevos temas sino que agregamos práctica de algunos temas que solo dábamos teoricamente como infra as code y contenedores.

Por otro lado, en la retro y en la encuesta de fin de curso, detectamos algunos puntos a ajustar entre los que se destacan dos: la gran dedicación requerida para el TP2 y la forma de dar feedback del código en las correcciones del TP2. Tomamos ambas cuestiones considerando que:

  1. En algunos casos hubo falta de foco durante el TP2 que llevó a invertir esfuerzo en funcionalidades no necesarias.
  2. Incluso cuando haya cuestiones que no esten bien al revisar el código hay que buscarle la vuelta en la redacción del feedback para también destacar algunos puntos positivos, pues siempre hay algo positivo para destacar y es necesario destacarlo para mantener la motivación del equipo,

Un tema intersante para descatar es que el primer cuatrimestre que no tuvimos abandonos. Los 21 alumnos que asistieron la primera clase, completaron la materia.

Ya para cerrar comparto algunas estadísticas:

  • Evaluación general del curso: 8.6 / 10
  • Claridad de los docentes: 4.3 / 5
  • Conocimiento de los docentes: 4.9 / 5
  • Dinámica de clases: 4.1 / 5
  • Materiales de estudio: 4.1 / 5
  • Dedicación promedio extra clase: 9.7 hs. semanales
  • Conformidad con la nota de aprobación: 4.3 / 5
  • Cantidad de tareas individuales: 38 (incluyendo 10 cuestionarios y 7 ejercicios de programación además de lecturas y videos)
  • Visita de la industria: Mariano Simone (gracias totales)
  • Nota promedio de aprobación de la materia: 7.9

Infra definida para el TP2 de MeMo2 @ fiuba

Después de varias averiguaciones y algunas pruebas de concepto ya tenemos bastante encaminado el diseño del pipeline e infraestructura del TP2. El sistema a construir consta de dos aplicaciones/artefactos: un bot de telegram y una web-api.

El bot de telegram lo vamos a correr en kubernetes, más precisamente en el servicio de Kubernetes de Azure utilizando la opción Azure for Students ofrecida por Microsoft, la cual incluye 100 dólares de crédito y no requiere de tarjeta de crédito.

Las web-api la vamos a correr en Heroku pero en lugar de usar el modelo de runtime tradicional de Heroku, vamos a correr la aplicación en un contenedor. Esto es: en lugar de hacer push del código fuente directo a Heroku, lo que hacemos es construir una imagen Docker y luego indicar a Heroku que corra un contenedor basado en esa imagen.

Si bien, en términos de infraestructura a bajo nivel, el bot y la api van a correr en distintos runtimes, a nivel proceso ambas aplicaciones correran como un contenedor Docker. Al mismo tiempo el proceso de build y deploy va a ser el mismo para ambas aplicaciones, ofreciendo al equipo de desarrollo una experiencia de trabajo uniforme. En un escenario real es poco probable utilizar una estrategia de este estilo, porque tener dos plataformas de runtime implica un mayor costo operacional pero en nuestro contexto creemos que puede resultar interesante para mostrar explícitamente a los estudiantes como, a partir de ciertas técnicas, es posible lograr un buen nivel abstracción de la infraestructura.

El pipeline de CI/CD lo implementaremos con GitLab utilizando la suscripción Gold que GitLab ofrece para contextos educativos.

Un detalle que me parece relevante mencionar es que, si bien vamos a utilizar productos/servicios de determinados vendors, tenemos la intención de mantener la menor dependencia posible con caraterísticas específicas/propietarias de cada vendor.

En siguientes artículos explicaré como será el modelo de ambientes y pipelines que armaremos tomando esta infraestructura de base.

Preparando la infra para el TP de MeMo2 @fiuba

A partir de la pandemia el segundo cuatrimestre de 2020 en FIUBA quedó partido: 12 semanas en 2020 y 4 semanas en 2021 con un receso entre 21 de diciembre y 8 de febrero. Este receso nos dio la posibilidad de intentar innovar en ciertos aspectos del trabajo práctico final de la materia. El objetivo de este trabajo es poner en práctica de forma integral todo lo visto en la materia con un importante foco en cuestiones de proceso. En este sentido hay una parte del proceso (principalmente relacionada a configuration management) que históricamente hemos dejado un poco marginada principalmente por restricciones de infraestructura.

Típicamente el trabajo final consiste en el desarrollo y despliegue de una aplicación que comprende una API Rest y un bot de Telegram. Todo esto trabajando en una dinámica de Extreme Programming lo cual implica: BDD, TDD, Integración continua, despliegue continuo, automatización de pruebas, trabajando muy de cerca con el usuario, armando criterios de aceptación, etc, etc.

Hasta el momento venimos trabajando con Ruby + PostgreSQL, desplegando a cuentas gratuitas de Heroku y utilizando GitLab como plataforma de desarrollo (gestión de backlog, repositorio, CI/CD, etc). Debo agradecir aquí a Jetbrains (que provee gratuitamente sus herramientas a nuestros alumnos) y a GitLab (que no dio una licencia gold de su plataforma).

El servicio de Heroku está muy bien, pero su modelo de plataforma como servicio nos abstrae de ciertas cuestiones que nos gustaría que los alumnos vieran más de cerca, principalmente en lo que tiene que ver con manejo de la infraestructura de como código. En este sentido, estamos considerando ir hacía Kubernetes, eso implicaría mínimamente escribir los descriptores de pods, deployments, configmaps, etc, etc. No le vamos a pedir a los alumnos que hagan todo esto por su cuenta (pues implicaría que se ponga a aprender kubernetes lo cual excede por mucho el alcance de la materia), sino que lo haremos en forma conjunta (equipo docente y alumnos). Ahora bien, para dimensionar los recursos tenemos que considerar los siguientes puntos:

  • Son 7 grupos
  • Cada grupo necesita al menos 2 ambientes (test y prod)
  • Cada ambiente requiere al menos un pod para la api, un pod para bot y una base de datos (en principio de tipo relacional)
  • Nos gustaría contar también con alguna solución de logging centralizado tipo ELK pero no es algo imprescindible

Toda la infra de deployment ya la tenemos resuelta con GitLab.

La intención inicial es usar algún servicio cloud que nos provea Kubernetes y base de datos “as a Service”. La idea es no tener que pagar por esto, ya que al ser una universidad pública no podemos pretender que los alumnos pagen por esto y mucho menos vamos a pedirle a la universidad pagar por esto. Obviamente que una opción es que lo paguemos los docentes (opción que no descarto) pero me parece que puede ser una buena oportunidad algún cloud provider de colaborar con la formación de potenciales futuros empleados/clientes y de paso hacer un poco de marketing.

En próximos post iré compartiendo a medida que vayamos avanzando en el armado de todo esto.

Sobre nuestra dinámica de aula invertida

En las dos materias que dicto (UBA y UNTreF) utilizamos la misma dinámica de clases. la cual está basada en una estrategia de aula invertida con técnicas de educación centrada en el alumno y evaluación constante. Más allá de las definiciones formales, y en términos concretos, esto implica que cada tema que estudiamos en la materia consta de tres instancias: estudio, aplicación y evaluación.

Aclaración: en las siguiente secciones cuando digo aula me refiero al tiempo/espacio compartido sincrónicamente entre alumno y docente en forma semanal

1. Estudio

Ocurre fuera del aula, el alumno debe sentarse a estudiar, típicamente viendo uno o varios videos o leyendo un texto. Esto reemplaza la típica clase magistral donde el docente expone pasando diapositivas. Es justamente este tipo de clases las que convertimos en videos y que los alumnos consumen fuera del aula.

2. Aplicación

Esto ocurre dentro del aula y puede tomar distintas formas dependiendo del tema en particular, pero siempre intentamos que sea una actividad interactiva. Puede que sea una sesión de mob-progamming o alguna actividad de simulación (como el Pizza Game) utilizando alguna herramienta de soporte como Miro, Mentimeter, Kahoot o similares.

3. Evaluación

La evaluación ocurre también fuera del aula y dependiendo del tema puede ser un ejercicio de programación y/o un cuestionario.

De esta forma cada tema es estudiado y evaluado individualmente. Luego complementariamente tenemos dos trabajos integradores donde los alumnos trabajan en equipos y ponen en práctica todos los temas ya estudiados de forma integrada.

Cierre de un cuatrimestre atípico en MeMo2@fiuba

Cerramos el cuatrimestre de MeMo2@fiuba en una modalidad 100% online y en términos resumidos creemos que estuvo muy bien.

Como herramientas de soporte utilizamos Jitsi para las clases online, Canvas LMS como aula virtual y GitLab como plataforma de desarrollo. En términos descriptivos este cuatrimestre tuvimos:

  • 22 inscriptos, 1 abandono, 21 aprobados
  • 46 tareas individuales que incluyeron 7 ejercicios de programación y 12 cuestionarios con sus correspondientes lecturas y videos
  • 2 trabajos grupales, uno de alcance variable y esfuerzo fijo y otro de alcance fijo y esfuerzo variable
  • 2 visitas de profesionales: Pablo Najt y Matias Gorostegui, gracias a ambos

Más allá de los números hay dos cuestiones interesantes que los alumnos destacaron. Por un lado la predisposición de los docentes para mejorar clase a clase lo cual quedó evidenciado en el hecho de que al final de cada clase les pedimos a los alumnos completar una breve encuesta para tener feedback específico de la clase. Por otro lado la buena adaptación de la materia a la modalidad online, de hecho algunos alumnos nos destacaron como la materia que mejor se adaptó. Siendo sinceros, creemos que no hicimos demasiados cambios para la modalidad online básicamente porque ya teníamos la materia planteada en un modalidad híbrida e invertida, basada fuertemente en el uso del aula virtual y mucho material en video.

De acuerdo a nuestra encuesta interna del curso tuvimos casi los mismos números que el cuatrimestre anterior:

  • Evaluación general del curso: 8.5 / 10
  • Claridad de los docentes: 4.3 / 5
  • Conocimiento de los docentes: 4.8 / 5
  • Dinámica de clases: 4.3 / 5
  • Materiales de estudio: 4.2 / 5
  • Dedicación promedio extra clase: 8.5 hs. semanales
  • Conformidad con la nota de aprobación: 4.4 / 5
  • Nota promedio de aprobación de la materia: 7.8

Por otro, en términos de feedback más general surgido de las encuestas y de la actividad de cierre, nos encontramos con algunos temas recurrentes (como usar python en lugar ruby y tener más cuidado al dar feedback de los ejercicios) y algunos otros temas nuevos (como agregar material sobre object-relation mapping y ver las cuestiones de configuration management antes del TP1).

Finalmente, puertas adentro del equipo docente creo que el trabajo fluyó que en cuatrimestre anteriores y en parte me parece que se debe a implementamos una reunión de de sincronización semanal (la weekly).

Consideraciones para elegir un trabajo final de carrera

En las carreras de informática en Fiuba no hay, a mi entender, una definición lo suficientemente clara sobre los trabajos finales de carrera. Hay documentación, pero no hay una materia (como ocurre en otras universidades) donde los alumnos sean asesorados o tengan algún tipo de seguimiento. El alumno debe encontrar un director para su trabajo y acordar con él un tema.

En este contexto suelo recibir varias consultas de los alumnos y uno de los primeros consejos que les doy es que dejen en claro el objetivo personal que persiguen con el trabajo. Con esto no me refiero a la temática del trabajo sino a su expectativa personal, doy tres posibles ejemplos:

  • Recibirse y listo: la realización del trabajo final es requisito para recibirse y puede que el alumno quiera puntualmente eso. No tiene ninguna expectativa adicional. En este sentido el trabajo final es, en términos de transcendencia, como cualquier otro trabajo práctico de la carrera: una vez evaluado, ha cumplido su objetivo: la aprobación; entonces se archiva y nunca nadie lo vuelve a tocar.
  • Iniciar un emprendimiento: dado que el trabajo final requiere típicamente al menos un cuatrimestre de trabajo, puede ser una oportunidad interesante para aprovechar y hacer que ese trabajo final sea el puntapié inicial de un potencial emprendimiento.
  • Hacer un aporte a la comunidad: otra opción interesante para aquellos con intención de que su trabajo final tenga transcendencia más allá de la aprobación de la carrera es hacer algún tipo de aporte ya sea desarrollando una aplicación para una alguna institución, colaborando con un proyecto open source existente o incluso generando un nuevo desarrollo open source.

Esta es una clasificación muy genérica que no cubre todos los casos. De hecho mi propio trabajo final no entra en ninguna de estas categorías. De todas formas creo que plantearse la pregunta de las expectativas personales puede ser muy útil para definir el tema y sobre todo para armar el plan de trabajo.

Cierre del segundo cuatrimestre 2019 @MeMo2

Completamos una edición más de la materia, en términos estrictos es la quinta, pero dado que la primera solo tuvo 2 alumnos, estoy más inclinado a considerar que esta fue la cuarta.

Personalmente estoy muy conforme con el resultado y flujo de la materia. Y sin duda esto fue posible gracias a un equipo docente conformado por varios ex-alumnos. Además de Emi y yo como docentes nombrados, contamos con la colaboración de JoaquínC, TomasZ, JazminF, AldanaR, NachoI y PabloR. Gracias totales a todo el equipo.

Comenzamos el cuatrimestre con 21 inscriptos en guaraní, pero 2 de ellos nunca asistieron a clase. De los 19 que asistieron la primera semana, 2 abandonaron antes del comenzar con los trabajos grupales. Los 17 restantes completaron la materia.

En términos generales no hicimos cambios mayores respecto de lo que fue el primer cuatrimestre. Tuvimos:

  • 18 tareas individuales que incluyeron varios ejercicios de programación y unos 10 cuestionarios con sus correspondientes lecturas y videos
  • 2 trabajos grupales, uno de alcance variable y esfuerzo fijo y otro de alcance fijo y esfuerzo variable
  • 2 visitas de profesionales de la industria, Fede Diaz y Diego Sánchez, gracias a ambos

En feedback de los alumnos fue muy positivo y entre los accionables de mejora identificamos:

  • Hacer algún repaso tipo cierre de cada tema luego del cuestionario comentando los puntos destacados
  • Dar lecturas más cortas / enfocadas
  • Hacer una actividad para que los alumnos presenten sus propias experiencias profesionales
  • TP: Intentar que las iteraciones sean de jueves a jueves
  • TP: Durante el TP2 dedicar los lunes a repasar/acordar las especificaciones y ejemplos

Finalmente comparto algunas estadísticas de la encuesta final del curso completada por los alumnos (estos números son de la encuesta interna, los resultados de la encuesta que realiza el departamento aún no están disponibles):

  • Evaluación general del curso: 8.5 / 10
  • Claridad de los docentes: 4.7 / 5
  • Conocimiento de los docentes: 4.9 / 5
  • Dinámica de clases: 4.1 / 5
  • Materiales de estudio: 4.1 / 5
  • Dedicación promedio extra clase: 9 hs. semanales
  • Confirmidad con la nota de aprobación: 4.1 / 5

La nota promedio de aprobación de la materia fue 8 (desvío 0.96).

Estadísticas del nuevo cuatrimestre en MeMo2

Ya hemos completamos la segunda semana de clases. Tenemos 18 alumnos y un equipo docente con 2 profesores y 6 colaboradores, con lo cual deberíamos poder tener un flujo de seguimiento mejor que el cuatrimestre pasado.

Comparto aquí algunas estadísticas del perfil de alumnos que resultan llamativas:

  • Más del 70% de los alumnos ya están trabajando en alguna actividad afín a la carrera
  • Hay una variación muy grande en la cantidad de materias aprobadas: el alumno con más materias aprobadas tiene 33, mientras que el que tiene menos tiene 17

Condición laboral

Cantidad de materias aprobadas

Cantidad de materias aprobadas