Etiqueta: fiuba

Sistema de gestión de trabajos prácticos

A mediados del año pasado se me acercaron dos alumnos de FIUBA, con la intención de que los dirigieran en el desarrrollo de su trabajo profesional de fin de carrera. La propuesta que traían no me convenció, pero en lugar de decirles que no, les hice una contra oferta y trabajar en una idea que tenia en mente desde hace un tiempo: una herramienta de gestión para de trabajos prácticos de programación. La idea no era del todo novedosa, pues ya había en nuestra misma facultad dos materias que ya tenian un sistema similar. Al mismo tiempo, puse una seria de condiciones respecto del producto final y de la forma de trabajo:

En cuanto al producto, pedí las siguientes cuestiones

  • Pruebas unitarias y de aceptación automatizadas
  • Alto porcentaje de cobertura
  • Cumplimiento de las convenciones de código del lenguaje utilizado
  • Implementación con tecnologias abiertas

Respecto de la forma de trabajo les pedí:

  • Enfoque iterativo incremental con iteraciones semanales
  • Proceso de trabajo tipo Scrum
  • Visibilidad contínua

Con buen criterio los muchachos se tomaron un par de dias para pensarlo y finalmente aceptaron.

Hoy al cabo de 21 iteraciones, estamos a punto de salir en producción. Estamos arrancando el cuatrimestre y vamos a utilizar el sistema para gestionar los dos primeros trabajos prácticos de este cuatrimestre.

En próximos post compartiré más detalles del proyecto.

Agile en la academia, mi experiencia

En este tema tenemos dos cuestiones:

  1. La aplicación de técnicas agile en la enseñanza (más allá de cual sea la materia de estudio)
  2. La enseñanza de agile como un enfoque de la ingeniería de software.

En mi caso tengo experiencia en ambas cuestiones.

En Algoritmos y Programación 3 (Universidad de Buenos Aires) nuestro foco de estudio es la programación orientada a objetos pero incluimos en el programa de la materia algunas prácticas comunes en el movimiento agile como ser TDD e integración contínua. Esto se debe a que en la actualidad no concebimos la construcción de software orientado a objetos sin el uso de estas prácticas.

Por otro lado, en Elementos de Ingeniería de Software (Universidad Nacional de Quilmes) el enfoque de ingeniería que enseñamos es el enfoque Agile. Es necesario mencionar que el objetivo de esta materia es proveer, a un técnico en programación, herramientas suficientes para llevar adelante el desarrollo de un sistema de software. La discusión de porqué el enfoque Agile y no otros, es tema de otro post. Al mismo tiempo la forma en que se dicta la materia tiene varias técnicas de agiles como ser:

  • La materia se encuentra dividida en iteraciones, al final de cada una los alumnos presentan un entregable y se realiza un retrospectiva sobre la forma en que se ha dictado la materia
  • El entregable puede ser un informe, software, un documento de diseño o una evaluación
  • Los alumnos se auto organizan para llevar adelante las distintas asignaciones
  • Cada alumno lleva un backlog de sus tareas, que es priorizado por el docente y estimado por cada alumno
  • Si al final de la iteración el entregable de un alumno no cumple con el criterio de done previamente acordado, entonces el docente puede decidir:
    • «cancelar el proyecto», lo que básicamente significa que el alumno ha pedido la materia)
    • agregar al backlog items distintos o adicionales para compensar/suplir el entregable incompleto

Asimismo hay dos cuestiones que nos parecen centrales más allá del enfoque agile:

  • Los proyectos de software se desarrollan dia a dia y eso mismo hacemos en la materia. Hay que trabajar todas las semanas. Esto resulta en ocasiones «chocante» para los alumnos que muchas veces están acostumbrados a simplemente asistir a clase y sólo trabajar/estudiar la semana previa a un exámen. 
  • Un factor importante para el éxito de cualquier proyecto es la comunicación y el manejo de expectativas. Durante toda la materia hacemos mucho incapié en esto. Por eso, si un alumno piensa no asistir a una clase, tiene la obligación de avisar previamente al resto de la clase. No hace falta que dé explicaciones, simplemente decir «No asistiré a clase». Esto permite que el docente puede planificar mejor las actividades de la clase sabiendo con cuantos alumnos contará.

Aqui dejo algunos links a posts anteriores que agregan más información sobre lo mencionado aquí:

Nota: este post surgió a partir de una consulta de mi colega Juan Gabardini quien me mencionó una iniciativa de gobierno de Medellín para la enseñanza de método ágiles en las universidades. Gracias Juan.

Academia e Ingeniería de software

Desde que empecé a dictar la materia de Ingeniería de Software en UNQ, comencé a prestar mayor atención a los diferentes enfoques para enseañar esta disciplina. En Agiles 2012 y luego en mi reciente viaje a Venezuela pude hablar con gente de diversas instituciones y confirmar la teoría que aquí expongo.

El enfoque utilizado para enseñar Ingenieria de Software depende de carrera que uno analice, ya que cada carrera le da distinta relevancia al tema. Hay carreras en las que simplemente hay una o dos materias de Ingeniería de Software, mientras que otras tienen una materia por cada disciplina de la Ingeniería de Software. En este sentido la Tecnicatura en Programación de UNQ pertenece al primer grupo, ya que solo tiene una materia del tema (la que dicto yo ;-)). Por su parte, la Ingeniería informática de UBA está en el otro extremo, tiene una materia por cada disciplina: Análisis, Diseño, Administración de Proyectos, Arquitectura, Calidad, etc, etc.

El enfoque utilizado influye, como es de esperar, en los contenidos impartidos. Si uno cuenta con varias materias, es posible tratar distintos enfoques y técnicas con un nivel de profundidad interesante, pero si uno cuenta con sólo 1 o 2 materias, entonces se ve en un dilema: estudiar un único enfoque con cierta profundidad o bien ser más generalista y estudiar varios enfoques de forma más superficial. En la tecnicatura de UNQ solo tenemos una materia de Ingenieria de Software y la estrategia elegida fue centrarnos en un sólo enfoque (el de los métodos ágiles) aunque hacia el final de la materia hacemos una breve mención de waterfall y UP. Esta decisión estuvo motivada por el hecho de que pretendemos que al finalizar la carrera, el alumno pueda llevar adelante un proyecto de punta a punta y para ello creemos más valioso conocer un enfoque en detalle que conocer varios enfoques de forma superficial.

En base a lo que he hablado, leido y compartido con colegas de distintas instituciones, me da la impresión que en la actualidad la mayoría de las instituciones (en América del Sur) enseñan Ingeniería de Software utilizando un enfoque «tradicional» basado en los clásicos de Somerville y Pressman o bien se inclinan a un enfoque un poco más concreto y se basan en el Proceso Unificado. Adicionalmente en algunos casos se dictan materias complementarias (optativas generalmente) donde se ven enfoques alternativos (agile, waterfall, etc, etc).

Si algún lector no comparte esta visión, me gustaria que expusiera su opinión.

15 GB gratuitos en Dropbox…

Dropbox está llevando a cabo un concurso entre instituciones académicas. Cada institución gana puntos por cada alumno que se registra en DropBox y al mismo tiempo esos puntos se traducen en espacio para los alumnos de la institución. Desconozco cuales son las instituciones que participan ni tampoco como es el proceso para sumar una institución, pero se que la UBA está participando.

Si eres alumno de la UBA y quieres ganar 15 GB, entonces puedes registrarte aqui: https://www.dropbox.com/spacerace. Si ya tienes una cuenta en Dropbox, no importa también puedes reclamar tus 15 GB asociando tu cuenta fiuba a tu cuenta actual de Dropbox.

 

Publicidad FIUBA

Es común al transitar por la ciudad encontrarse con publicidades de universidad privadas, sobre todo en los periodos de inscripción. Recuerdo incluso haber visto una publicidad de una universidad privada en televisión (quienes hayan visto los Simpson en canal Fox seguramente sepan a que me refiero :-)).

Pero con las universidad públicas es distinto (al menos en Argentina), generalmente no hacen ningún tipo de publicidad a menos que se trate de actividades de extensión o de posgrado. Por eso es que el viernes pasado me sorprendí cuando a la salida del subte me encontré con un afiche publicitando las carreras de grado de Fiuba.

Cierre de cuatrimestre a puro TDD (algo3, 1c-2012)

Y se fué uno más, pero distinto y para bien. En líneas generales mantuvimos la misma modalidad que los cuatrimestres anteriores, pero creo que en esta ocasión hemos manejado mejor los tiempos y hemos resultado «más convincentes» en algunas cuestiones.

Entre los cambios del curso Jueves-tarde sumamos un nuevo colaborador docente: Diego Marcet, graduado de la casa, ex-alumno de la materia y ex-compañero mio de trabajo en Southworks.

Otro de los cambios implementados fue el uso del campus virtual (basado en Moodle) para la publicación del material de estudio. Yo personalmente fuí un poco más allá y lo utilicé para manejar la interacción con mis grupos vía los foros. La ventaja que le veo al uso de foros tiene que ver con que la resulta muy cómodo visualizar el hilo completo de la conversación.

A mi parecer la particularidad más destacada (al menos de nuestro curso) fue el fuerte incampié que hicimos en el uso de TDD, lo cual dió sus frutos en el trabajo final, donde varios alumnos desarrollaron gran parte de trabajo usando esta técnica.  Es más, la cantidad de pruebas unitarias de los TP finales fue record en el caso de los TPs que yo corregí: me entregaron TPs con más de 200 pruebas unitarias, llegando a niveles de cobertura llegando al 80%.

La última innovación a mencionar es la práctica de integración contínua. Si bien este tema lo vemos en la teoría desde hace varios cuatrimestres, este año fui más allá y levante un servidor de integración contínua para mis alumnos (lamentablemente no tenía una gran infraestructura, asi que solo lo pude hacer para los 3 grupos a mi cargo). El proceso de build incluyó: compilación, ejecución de pruebas y medición de cobertura.

Si bien no hicimos la dinámica de retrospectiva global, yo hice una más reducida con los alumnos de mis grupos y el feedback fué muy positivo: solo surgieron algunas cosas menores para mejorar que comentaré en un próximo post.

Fiuba los cria y el Azure los junta

El miercoles pasado estuve dictando un entrenamiento sobre Windows Azure en las oficinas de Microsoft Argentina. No voy referirme en este post ni al entrenamiento y ni a azure sino a un par de reencuentros que viví  (aqui y aqui hay algo de información más específica del evento).

Resulta que entre la audiencia del curso me reenccontré con tres viejos conocidos de FIUBA.

Guille Rugilo, docente de Arquitectura de Software. Si mal no recuerdo a Guille lo conocí cursando Física 1, aproximadamente en el año 1999. Luego compartimos un par de materias más. En el año 2003/2004 trabajamos juntos en Millenium 3, luego volvimos a hacerlo en Huddle Group (lugar en el que Guille sigue trabajando actualmente).

El segundo reencuentro fue con Nico Padula. Nico fue alumno de Algo3 y luego se sumo al equipo docente. Por aquella época yo trabajaba en Huddle y cuando decidí irme, lo postulé a Nico para que me reemplazara. Desde entonces Nico trabaja en Huddle.

El tercero y último personaje es Pablito Roca. Otro ex alumno (y también ex docente de Algo3). Actualmente Pablito es docente de Taller de programación 1, una de las materias mejor dictadas en Fiuba.

Como si fuera poco, el anfitrion del evento fue Ariel Schapiro, otro personaje Fiuba con quien cursé parte de mi carrera y en parte resposable de que yo me haya sumado en Southworks.

«Los ingenieros son la Victorinox de la sociedad»

Hace unos dias un colega me compartió este artículo del cual extracté el título de este post. La frase pertenece a Adolfo Guitelman, vicepresidente del Centro Argentino de Ingenieros.

Algunos datos estadísticos que aporta el artículo son:

  • En la argentina se estima que hay un ingeniero cada 6600 habitantes mientras que en paises como Israel y China hay 1 cada 1500.
  • Actualmente se reciben unos 6000 ingenieros por año, de los cuales el 32% egresa de la UTN
  • El tiempo promedio para que un ingeniero se reciba es de ocho o nueve años
  • En FIUBA, durante 2011, egresaron unos 450 ingenieros
  • En ITBA durante 2011, egresaron 240 ingenieros industriales

 

¿Incluiran esas cifras a ingenieros agronomos? No creo

¿E ingenieros en sistemas/informática/computación? Estimo que si

Desafio de diseño: objetos inteligentes (resolución)

(continuación de Desafio de diseño: objetos inteligentes)

Hay varias formas de atacar este problema de la “testeabilidad”.

La primera opción que muchas veces viene a la mente, es hacer públicos los métodos privados y testearlos unitariamente. Si desde el punto de vista práctico esta opción puede parecer viable, cuando la miramos desde el punto de vista conceptual resulta incorrecta, pues dichos métodos son conceptualmente privados y no seria correcto cambiar su visibilidad para solo probar la clase. Si estuvieramos trabajando con C# Visual Studio nos ofrece una alternativa basada en reflexion para acceder a miembros privados de la clase, pero conceptualmente esto sigue siendo incorrecto.

Si pensamos el problema un poco más, nos daremos cuenta que puede que la clase tenga algunos problemillas de responsabilidades. Para ser más explícitos, tiene demasiadas responsabilidades: decidir si moverse y en caso positivo hacerlo, decidir si disparar y en caso positivo hacerlo, etc, etc. Bueno, si asumimos este diagnostico entonces hemos dado el primero paso: identificar el problema.

Repensemos la cuestión una vez más. Una clase que toma muchas decisiones (si X, si Y, si X, etc) y hace muchas cosas (X, Y, Z, etc). Cada una de esas cuetiones las hemos encapsulado en un método privado de cara a tener un código más legible. ¿y si fueramos un paso más allá? ¿Que tal si convertimos cada uno de ese métodos privados en una clase? De esta forma tenenemos una clase con la lógica de movimiento, otra clase con la lógica de disparo y asi sucesivamente. Así nuestro objeto inteligente tiene mucho menos código y su responsabilidad está limitada a coordinar “las estrategias” de movimiento, disparo, etc, etc. Al mismo tiempo cada estrategia puede ser testeada independientemente.

Bueno, este ha sido el primer desafio, próximamente vendrán algunos más.