Preparando Ingeniería de Software 2 @ FIUBA

Preparando Ingeniería de Software 2 @ FIUBA

Desde hace un tiempo estoy trabajando en preparar la materia Métodos y Modelos en la Ingeniería de Software 2 (95.21) perteneciente al nuevo plan de la Licenciatura en Análisis de Sistemas de la Facultad de Ingeniería de la UBA.

Formalmente el programa de la materia incluye una importante gama de temas que van desde procesos de adquisición hasta métodos de evaluación de arquitectura pasando por operaciones y sistemas de tiempo real.

La materia otorga 6 créditos y tiene una carga horaria de 6 horas semanales. Si bien aún no lo hemos hablamos explícitamente es muy posible que la materia se dicte en 2 clases semanales de 3 horas cada una.

Como primer paso tomamos el programa formal y lo desglosamos en capítulos/módulos que agrupan los principales temas.

En términos de enfoque pedagógico la idea es seguir con la misma estrategia que en la materia anterior (Métodos y Modelos en la Ingeniería de Software 1) el cual es muy similar al enfoque  que utilizo en UNTreF.

Continuará…

 

Pase: de Algo3 a MeMo2

Pase: de Algo3 a MeMo2

Después de más 15 años como parte del equipo docente liderado por Carlos Fontela y a cargo de la materia Algoritmos y Programación 3, este año emprenderé un nuevo camino.

Resulta que a partir de la implementación del nuevo plan de estudios de la Licenciatura hay que empezar dictar nuevas materias y eso requiere del nombramiento de nuevos docentes o de la reubicación de los docentes existentes. Este segundo caso es el mío.

En particular en el segundo cuatrimestre de este año debe comenzar a dictarse la materia Métodos y Modelos en la Ingeniería de Software 2 (a.k.a. MeMo2). Como su nombre lo sugiere, esta nueva materia es la continuación de Métodos y Modelos en la Ingeniería de Software 1 (a.k.a. MeMo1) que es una materia (hoy en día) equivalente a la materia Análisis de la Información del plan anterior. MeMo1 empezó a dictarse hace un par de cuatrimestres y su equipo docente está liderado por Sergio Villagra. Para asegurar cierta consistencia entre MeMo1 y MeMo2, Sergio también estará involucrado en MeMo2. Por mi parte, durante este primer cuatrimestre estaré participando de MeMo1 y trabajando en el armado de MeMo2.

Debo admitir que dejar Algo3 no fue una cuestión fácil. Si bien el equipo docente de Algo3 ha ido variando a lo largo de todos estos años, somos varios los que llevamos más de 10 años trabajando juntos. Creo que justamente es esa combinación del “núcleo de veteranos” con “la sangre de los nuevos colaboradores” y el compromiso de mejora continua de todo el equipo, lo que ha motivado a que la materia este en una constante evolución. Al mismo tiempo armar y dictar MeMo2 representa un gran desafío y una importante oportunidad de crecimiento en mi carrera docente y es por ello que acepté el pase.

Me voy de Algo3 muy contento de haber trabajado con ese gran equipo docente e infinitamente agradecido a Carlos Fontela por haberme invitado a sumarme al equipo allá por el año 2000.

Cierre de algo3 (2016)

Terminamos un año de cambios:

  • Eliminamos la distinción clase teórica / clase práctica y pasamos a tener dos clases, ambas de índole teórico/prácticas
  • Cambiamos la dinámica de las clases a hacia un enfoque más “from the back”, algo que ya veníamos haciendo en forma más leve y este años aumentamos la apuesta
  • Como parte del punto anterior fomentamos el trabajo en clase con las computadoras, intentando programar durante la clase

Si bien conceptualmente estoy completamente convencido de que este enfoque es el más apropiado para esta materia, creo que la puesta en práctica no fue lo suficientemente buena, creo que tuvimos varias falencias de coordinación interna entre los docentes. La parte positiva es que esto nos deja un buen espacio mejorar 😉

The BEST exam EVER!!!!

El lunes pasado tuvimos mesa de examen en Algo3 y el examen que tomamos fue el mejor que vi en mi vida entera. El examen consistió en un ejercicio práctico, cada alumno estaba con su computadora y le entregamos un conjunto de clases que resolvían un problema dado. La consigna era simple: analice el código y mejorelo. Luego de cierto tiempo (unos 30 minutos) un docente se sentaba con cada alumno para hablar con él sobre las mejoras realizadas.

Obviamente el código entregado tenía una serie de “cochinadas” algunas muy groseras y otras menores. La expectativa era que los alumnos fueran capaces:

  1. Identificar las “cochinadas”
  2. Explicar los problemas que las mismas podrían acarrear
  3. Proponer modificaciones a la solución para remover “las cochinadas”
  4. Implementar esas propuestas en código

A mi me tocó evaluar a dos alumnos y el método me pareció simplemente genial, pues con preguntas muy concretas uno podía determinar si el alumno había incorporado, o no,los conceptos centrales de la materia.

Debo felicitar a Pablo Massuh y Gabi Devoto que fueron los ideólogos de este examen.

Reflexiones sobre la Enseñanza de la Ingeniería de software

En mi actividad profesional cotidiana me desempeño como ingeniero de software ocupando distintos roles y realizando distintas tareas dependiendo de las particularidades del proyecto de turno. Por ello cuando en 2011 tomé a mi cargo la materia Elementos de Ingeniería de Software en la Universidad Nacional de Quilmes busqué una dinámica de dictado de la materia que efectivamente pudiera preparar a los alumnos para desempeñarse profesionalmente en esta disciplina.

Personalmente considero que la ingeniería de software es una actividad naturalmente industrial, y en este sentido me parece fundamental que su enseñanza tenga un enfoque práctico puesto que la ingeniería de software teórica resulta insuficiente para el ejercicio profesional de la disciplina.

Curiosamente mi formación  en Fiuba no tuvo este enfoque. Como alumno tuve un conjunto de materias de índole más bien teórica y  tiempo después otras materias de tipo taller donde se suponía ponía en práctica la teoría aprendida tiempo atrás. Esto me parece perjudicial para el alumno, pues a la hora de estudiar la teoría, la misma se aprende “en el aire” sin ponerla en práctica. Luego, tiempo más tarde se cursa un taller, pero al llegar al taller uno ya se olvidó de la teoría “supuestamente aprendida”. Exactamente esto me pasó con el tema de estimación: en una materia me enseñaron los diversos métodos de estimación pero nunca me pidieron estimar, simplemente me pidieron describirlos en un examen escrito. Tiempo después cuando cursé el taller y tuve que estimar, tuve que volver a estudiar los métodos y fue ahí, a la hora de aplicarlos, que me surgieron mil dudas. Algo similar me ocurrió con las cuestiones de testing y calidad.

Otra curiosidad de mi carrera (y que también se repite en otras casas de estudio) es que cursé en primera instancia una materia de análisis y luego una de diseño, como si fueran dos actividades disjuntas (un punto sin duda debatible). Hasta ese momento carecía de una visión general del proceso de desarrollo de software, cosa que aprendí tiempo más tarde en la materia de gestión. Creo que resulta muy dificil (y poco conveniente) enseñar técnicas de análisis y diseño sin contar con el marco general de un proceso de desarrollo. En este sentido me parece interesante el enfoque de la Universidad Nacional de Quilmes, donde primero se ofrece una materia introductoria a la Ingeniería de Software que brinda al alumno una visión general de la disciplina, con un enfoque muy práctico y luego en siguientes cuatrimestres se ofrecen materias específicas para cada actividad: Ingeniería de requerimientos, Gestión de proyectos, Arquitectura de software, etc, etc.

Respecto del enfoque práctico, en concreto creo que es necesario hacer el ejercicio de construir/extender un pieza de software de cara a poner en práctica toda la teoría y técnicas enseñadas, tengo la sensación que enseñar ingeniería de software a partir de lecturas, cuestionarios y ejercicios conceptuales es insuficiente para formar profesionales de la informática y como dije antes el hacer estas actividades en materias separadas no me parece apropiado.

Creo que algunas de estas cuestiones han sido consideradas en el nuevo plan de la Licenciatura en Sistemas de la FIUBA (aunque no estoy seguro de hasta que punto). Espero también que estas cuestiones sean consideradas en el próximo plan de estudios de la carrera de Ingeniería Informática de FIUBA.

 

 

 

Sobre el TP final de algo3 (2015-1)

A fines de mayo lanzamos el TP final de Algo3. En el curso de los miércoles tenemos poco más de 30 alumnos repartidos en equipos de 3 integrantes, cada equipo con un docente tutor. En mi caso soy tutor de 4 equipos.

Este cuatrimestre el trabajo prácticos se llama AlgoCraft y como su nombre lo sugiere es una variante del clásico juego StarCraft.

Como de costumbre desde el comienzo del trabajo práctico configuré un Jenkins para que los alumnos pudieran hacer integración continua. Esto también me permite tener métricas de su trabajo. Este cuatrimestre incorporé PMD al conjunto de tareas ejecutadas en el proceso de integración continua. PMD es un herramienta que entra en la categoría de “Linter” y como tal, lo que hace es analizar el código fuente realizando un conjunto de verificaciones relacionadas al cumplimiento de estándares y buenas prácticas de programación del lenguaje en cuestión.

algo3_20151

Expectativas para el nuevo cuatrimestre en FIUBA

Esta semana comenzó el cuatrimestre en FIUBA. En el curso 3 (miércoles) tenemos poco más de 40 alumnos 2 de los cuales son de intercambio (uno de Colombia y otro de Francia). Respecto del equipo docente, quedó conformado por DiegoM, PabloRM y yo, lo cual no dá prácticamente unos 15 alumnos por docente, un número no tan malo tratándose de UBA, sobre todo si tenemos en cuenta que según la política de la facultad la relación debería ser de 1 docente cada 20 alumnos.

Como de costumbre, la gran mayoría de los alumnos (~85%) son de la carrera de ingeniería informática.

En términos generales no tenemos planificadas grandes innovaciones para este cuatrimestre, pero en particular en el curso de los miércoles intentaremos realizar más actividades de programación en clase, ya que según pudimos relevar en la primera clase, muchos alumnos podrían asistir a clase con sus computadoras personales.

fiuba_2015