Categoría: academia

Cierre de cuatrimestre en UNQ, quinta promoción

La semana pasada terminó el cuatrimestre en UNQ y con ello mi quinto cuatrimestre dictando Elementos de Ingeniería de software.

Este cuatrimestre tuvo algunas particularidades entre las que destaco 2:

Respecto del cuatrimestre anterior la materia no tuvo cambios significativos, pues si bien se sumó Pablo, ya nos conocíamos desde hacía años y compartimos la misma filosofía en lo que respecta a los temas de la materia.

Un cambio que sí me pareció muy importante fue el contar con un espacio en el campus virtual de la universidad. Esto nos sirvió para compartir el contenido y también para realizar algunas actividades complementarias a las clases presenciales.

Otro cambio positivo fue el uso de videos para explicar algunas cuestiones técnicas que no son el foco de la materia. Así logramos utilizar mejor el tiempo de clase.

Entre los puntos que surgieron en la retrospectiva de la materia se destacaron:

  • Es muy distinto cuando damos feedback por mail a cuando lo damos en persona => reemplazar el feedback via mail por feedback en video
  • Algunas de las clases con formato «clase magistral» resultaron poco entretenidas => intentar cambiarlas por clases con dinámicas o al estilo «from the back»
  • En algunas clases comenzamos haciendo un ejercicio de relajación lo cual gustó mucho => hacerlo más seguido
  • Enviar tareas lo más temprano posible
  • Mantener los videos sobre temas técnicos
  • Mantener las clases con dinámicas
  • Mantener el uso de la máquina virtual para simplificar la configuración de ambiente y herramientas
  • Mantener las visitas de gente de la industria.

Para cerrar comparto algunos números frios:

  • Alumnos anotados: 9
  • Alumnos aprobados: 8 (el alumno que abandonó lo hizo la tercer semana de clase debido a que sufrió un accidente que impidió asistir a clase por un período prolongado)
  • Nota final promedio: 8,5
  • Total de clases: 31
  • Visita de profesionales de  la industria: 2, DiegoF y Fer Di Bartolo (¡gracias muchachos!)

eis-5-cohorte

Un pizca de mundo real en la academia

Continuando con lo planteado en el post «La universidad me mintió» quiero compartir algunos casos de materias en las que se pone al alumno en situación bastante similares a las del mundo real.

Comienzo con algunos casos que me involucran.

Elementos de Ingeniería de Software, Universidad Nacional de Quilmes

Las últimas 5 semanas de la materia, los alumnos trabajan en equipos de dos personas en la construcción de un producto, organizados en iteraciones semanales y utilizando prácticas de Scrum y XP. En la cuarta iteración los hacemos rotar de manera que trabajen en el producto de equipo.

Algoritmos y programación 3, Universidad de Buenos Aires

El trabajo final de la materia suele ser la construcción de un video juego utilizando POO y Java. De cara a simplificar las complejidades de la construcción de la interface de usuario y el manejo de threads, hemos construido un mini-framework que se encarga de estas cuestiones y permite que los alumnos se enfoquen mejor en la construcción del modelo de objetos de dominio. Este mini-framework está intencionalmente incompleto y carece de cietos puntos de extensibilidad (también intencionalmente) lo cual en cierto modo obliga a los alumnos a leer el código del micro framework y modificarlo.

Taller de Programación 2, Universidad de Buenos Aires

Según comentó Dario en el post inicial, en la materia Taller de Programación 2, de la carrera de Ingeniería Informática de la Universidad de Buenos Aires, los alumnos deben trabajar sobre código heredado. Festejo esto, pues cuando yo cursé esa materia no dinámica no era esa, sino que trabajamos directamente sobre «código nuevo».

Práctica de desarrollo software, Universidad Nacional de Quilmes

Por otro lado Javí comentó que en la materia Práctica del Desarrollo de software, de la Licenciatura en Desarrollo de Software de la Universidad Nacional de Quilmes tiene la idea de trabajar sobre un producto/servicio a lo largo de los varios cuatrimestres.

Algunos otros

Más allá de estos 4 casos, he oído de algunas iniciativas en esta dirección en la Universidad Nacional de Tres de Febrero y en la Universidad Nacional de La Matanza, pero no tengo detalles suficientes como para compartir.

Proyecto T: definición de tecnología

Hace un tiempo empecé a trabajar con un conjunto de alumnos de UNQ en su trabajo final de carrera. El mismo consiste en la construcción de una aplicación para gestión de una sala de guardia de un hospital público.

Una de las decisiones que tenemos que tomar  al comienzo del proyecto es la tecnología a utilizar.

Intentando dejar de lado las preferencia personales, hay algunas consideraciones importantes para esta decisión:

  1. Dado que el contexto del proyecto es un institución pública donde el presupuesto es realmente acotado es necesario que la tecnología a utilizar no requiera el pago de licencias.
  2. Dado que se espera que el sistema tenga una vida «más larga» que el tiempo de desarrollo es muy posible que una vez completado el sistema, alguien más debe encargarse del mantenimiento. Sumado a que trabajeremos con alcance variable es posible que en un futuro el product owner deba conseguir más gente para agregar nuevas funcionalidades. Por esto es necesario que sea fácil conseguir programadores con conocimiento de dicha tecnología.
  3. La tecnología elegida debería estar lo suficientemente estable y contar con herramientas que faciliten la resolución de situaciones técnicamente comunes en un proyecto como el planteado y no de larga sesiones de investigación y resoluciones de problemas técnicos.
  4. Dado que seguimos estando en un contexto académico, la tecnología a utilizar debería permitirnos aplicar ciertas buenas prácticas que los alumnos aprenden a lo largo de la carrera.

Con estos puntos de partida ya podemos empezar a eliminar algunas candidatos.

  • En primer lugar podemos descartar tecnología Microsoft  por (1).
  • Al mismo tiempo y pesar de que me causa cierta pena, creo que (2) deja afuera Smalltalk.
  • Creo que (2) y (3) dejan afuera a cosas tales como Erlang

La lista de candidatos es aún bastante larga y al mismo tiempo con sólamente un lenguaje no llegamos a ningún lado. Es necesario considerar lenguaje + frameworks, lo cual nos podría llevar a la siguiente lista de candidatos:

  • Php, tal vez sea por sus orígenes «informales», creo que las convenciones y herramientas aún no están claramente unificadas, hay varios alternativas (Symphony, Cake, etc) y a mi parecer ninguna se ha establecido. Sumado a que el lenguaje no me gusta.
  • Python + Django, lo usé y no me gustó, creo que Django tiene demasiada magia negra.
  • Java, ¡ja!  ¿cual de sus n variantes? No lo sé, creo que en un punto casi todas cumplen con las premisas iniciales. simplemente descartaría el uso de contenedores pesados (EJB).
  • Hermanitos de Java ya sea Scala o Groovy, que más allá de las particularidades que ofrecen como lenguajes, ambos proveen un conjunto de herramientas muy interesante y que simplifican varias cuestiones cuestiones cotidianas que tal vez en java requieren un esfuerzo de configuración/xml realmente pesado.
  • Ruby, Rails tiene demasiada magia negra, pero creo Padrino definitivamente es un opción válida.
  • JavaScript sin duda está en ascenso y si bien apenas he ido más allá de jquery es algo que me tienta mucho

Algo que me parece inevitable para este contexto de aplicación es el uso de Javascript del lado del cliente manejando toda la lógica de presentación y dejando en el server sólo servicios de negocio, entonces el punto sería con qué construir estos servicios.

Ahora bien, más allá de mis gustos, la realidad es que la aplicación la tienen que construir los alumnos y llegado a este punto son ellos quienes deben tomar la decisión considerando todo lo aquí expresado.

Mi recomendación para los alumnos fue: tomense un rato para googlear las cosas que aquí menciono si es que no las conocen. Si alguna de las alternativas les tienta más que otra y no la conocen, entonces bajense lo que sea necesario e intenten escribir una pruebas unitaria y hacer una página que sume 2 números. Eso debería darles cierta idea de dónde se están metiendo.

Comienzo de nuevo proyecto, llamémosle T

En estos días estoy por comenzar un nuevo proyecto, llamémosle T. Se trata de un trabajo de inserción profesional que voy a co-dirigir con Fidel. El trabajo será desarrollado por dos alumnos de la carrera y el objetivo es construir un sistema de gestión para la sala de guardia de un hospital. El proyecto surgió a partir de una necesidad detectada por Luis, un médico, jefe de guardia de un hospital del conurbano.

Como suelo recomendar para todos los trabajo finales de carrera, la idea es gestionar el proyecto como de alcance variable, lo cual requiere una trabajo muy cercano con el product owner para asegurar una correcta priorización de funcionalidades y un rápido feedback a medida que estas se van completando.

Continuará…

 

 

La universidad me mintió

Durante toda la carrera me hicieron trabajar sobre «proyectos nuevos» en el sentido que siempre puse la primera línea de código. Al mismo tiempo, los proyectos terminaban cuando aprobaba la materia y el código nunca más era tocado por nadie más, más allá de mi y mis compañeros de grupo.

Estas situaciones llevadas al «mundo real» resultan ser ficticias, rara vez escribimos código para que nunca más sea tocado. Y al mismo tiempo muchas veces nos toca trabajar sobre código ya existen que ha sido desarrollado por alguien más, a quien tal vez nunca conozcamos y que podria incluso vivir al otro lado del globo.

Lo triste es que esto es moneda común en los ámbitos académicos. Son contados los casos en los que los alumnos tienen que trabajar sobre código existente. Ojo, no me refiero a trabajar con librerías, algo que sí es común, sino a trabajar sobre código fuente de un aplicación desarrollada por alguien más. También resulta poco común que el código escrito por un grupo de alumnos, tenga «vida» más allá de la aprobación del trabajo.

Pasando en limpio:

  • En la academia los alumnos trabajan sobre proyectos/productos empezando de cero.
    Pero en la industria muchas veces nos toca trabajar sobre proyectos/producto ya existentes.
  • En la academia los alumnos trabajan sobre productos durante un período «corto» de tiempo y una vez completado el alcance originalmente acordado no vuelven a tocarlo.
    Pero en la industria los productos evolucionan y luego de su versión inicial son modificados cientos/miles de veces a lo largo de su vida útil.

Con este planteo lo que quiero decir es que es necesario que la academia tome conciencia de esta situación y haga algo al respecto. Conozco algunas iniciativas que ya están trabajando en esta línea, pero eso será parte de otro artículo.

Continuará…

La satisfacción de la inquietud

La semana pasada en el contexto del trabajo final de Algo3 dimos la clase de MVC de cara a que los alumnos puedan empezar a trabajar en la parte de vista y controlador.  A los poco días recibí un mail de un alumno de uno de mis grupos con la siguiente consulta:

Queríamos consultarle si hay alguna forma apropiada de hacer testing para la parte de vista del proyecto, ya que desde que nos pusimos a trabajar con la misma la cobertura de código del proyecto bajó notablemente.

Sinceramente la consulta me sorprendió para bien y me causó una gran satisfacción ver que un alumno tenga este tipo de inquietudes ya desde los primeros años de la carrera.

Trabajos finales de carrera: como plantearlos

Muchas carreras de informática tienen como parte del plan de estudios la realización un trabajo final. En FIUBA se le llama Trabajo Profesional, mientras que en UNQ se le llama Trabajo de Inserción Profesional.
En general este trabajo final (por usar un nombre genérico) consiste en realizar lo que podria ser un trabajo de campo acorde al perfil del futuro egresado. He conocido muchos casos en los que la realización de este trabajo se estira en el tiempo mucho más de lo que debiera. Es por ello que he decido escribir este artículo para compartir algunas recomendaciones.
El trabajo final es un proyecto y como todo proyecto tiene 3 variables:
  • Esfuerzo: cantidad de horas que vas a trabajar
  • Calendario: cuanto tiempo calendario lleva desde el comienzo hasta que se termina
  • Alcance: el tamaño de lo que vas a hacer
En todo proyecto, el cliente fija una variable, el equipo de desarrollo fija otra y finalmente la tercera se va regulando. En ocasiones la gente quiere fijar las 3 variables y las cosas terminan generalmente mal.
Para el caso del trabajo final tenemos:
  • Esfuerzo: ya viene preestablecido por la Universidad, para el caso de UNQ/TPI son entre 100 y 180 horas.
  • Calendario: para el caso de UNQ/TPI, suena razonable un calendario de entre 4 y 6 meses.
  • Alcance: aquí está la clave, si fijas el alcance, diciendo: Quiero hacer un sistema X que tenga las funcionalidades a,b,c,,etc. sonaste, porque no sabes a ciencia cierta cuanto esfuerzo va a requerir y mucho peor si es un tema que no conoces o una tecnologia nueva. Entonces para mi la clave es definir el trabajo final de manera que el alcance sea variable. Esto requiere una atención especial al manejo de prioridades, pues aunque el alcance sea variable, uno debe asegurarse de hacer algo que entregue valor. Esta es una forma de trabajo muy utilizada en los proyectos con métodos ágiles y en general la cuestión camina bastante bien. Yo ya he dirigido trabajos en UBA usando esta estrategia y doy fe que camina.
Hagamos ahora algunas cuentas para bajar a tierra. Supongamos que yo quiero hacer mi trabajo en 6 meses, entonces, tendría:
180 horas de esfuerzo (máximo determinado por el reglamento) / 6 meses = 30 horas al mes
Lo cual si lo paso a semanas, estamos hablando de trabajar 7,5 horas por semana ¿bastante razonable no?
Algunas aclaraciones importantes:
  • Ojo #1: estas horas son horas tipo Pomodoro, nada de telefonito, mensajitos, facebook, etc, etc. Son horas que me siento a laburar y laburo. (quien cursaron Ing. de soft saben a qué me refiero)
  • Ojo #2: no todos los temas permiten definir un proyecto de alcance variable. Cuando el tema es investigar XXX, puede resultar más dificil. Pero si el tema es construir un software que haga ZZZ, entonces es muuuuyyyy factible poder trabajar con alcance variable.
  • Ojo #3: encarar un proyecto de esta forma, puede resultar un poco más demandante, dado que para cumplir con la fecha y esfuerzo planteado, es necesario tener un ritmo de trabajo constante, lo cual también requiere un involucramiento docente constante.
Estos dos mis dos centavos de aporte al tema.

Impresiones del Primer Workshop del Proyecto Uqbar

El proyecto Uqbar es una iniciativa que agrupa a investigadores, profesionales y docentes de diversas instituciones Argentinas relacionadas a la informática. El sábado pasado se realizó el primer Workshop de Uqbar en las instalaciones de la Universidad Nacional de San Martín.

Debido a otros compromisos personales no pude participar del evento completo, pero las sesiones que ví me resultaron muy interesantes.

Yo facilité una sesión titulada «Testing: el gran ausente» en la que expuse mi visión sobre relevancia que se da a este tema tanto en la industria como en la academia. Fue muy gratificante ver que gran parte de la audiencia compartía mi visión.

No usé slides durante me sesión sino que directamente escribí algunas notas en la pizarra. Comparto a continuación algunos links a artículos que escribí que exponen los puntos que traté en la sesión:

Trabajos finales de carrera: mi enfoque de dirección

Como docente universitario en ocasiones me han ofrecido dirigir  o co-dirigir trabajos finales de carrera. El hecho de aceptar o no siempre está sujeto a dos cuestiones: que el tema del trabajo me resulte interesante y que los alumnos se comprometan a trabajar de acuerdo a ciertas normas entre las cuales destaco:

  1. El trabajo debe desarrollarse de forma iterativa e incremental
  2. El desarrollo debe hacerse utilizando integración continua
  3. El producto debe contar con pruebas automatizadas tanto unitarias como funcionales que provean una cobertura superior al 80%
  4. El código debe respetar los estándares de desarrollo de la tecnología utilizada
  5. El código resultante debe ser open source.
  6. A lo largo de todo el proyecto haremos reuniones (presenciales o virtuales) de seguimiento del proyecto

Estas cuestiones tienen que ver con asegurar la calidad del trabajo resultante, una cuestión que a mi parecer es una de las responsabilidades más importantes del director. Sin duda puede que haya otras técnicas/estrategias para asegurar la calidad del trabajo resultante, pero las aquí mencionadas son las que yo personalmente considero más efectivas.

Al mismo tiempo, puede que el tema del trabajo no justifique el uso de las técnicas aquí mencionadas, pero ocurre que justamente, los temas que me suelen interesar son los que sí requieren/justifican las cuestiones aquí mencionadas.

Obviamente que cada trabajo requiere una revisión de esto items, pues puede que en el contexto específico de un trabajo algunos de los ítems mencionados no tenga sentido o que al contrario, sea necesario incluir algunos ítems adicionales.

Testing de software: mi percepción en la industria y la academia

Este es un tema que vengo trabajando desde hace tiempo. Como parte de mi carrera fue muy poco lo que ví al respecto. Vi algo de prueba unitaria en la materia de objetos. Tuve una materia de calidad (Calidad en desarrollo de software) que me resultó muy interesante, pero que estaba más enfocada en cuestiones de proceso, por lo cual fue muy poco lo que vimos de pruebas.

Más allá de eso, mi actividad profesional me llevó a ir metiéndome en el tema. Por un lado, el trabajar con prácticas ágiles de ingeniería me llevó a meterme en temas de automatización de pruebas funcionales/de regresión. Por otro lado, el trabajar como consultor revisando/diagnosticando aplicaciones, me llevo a interiorizarme en cuestiones de pruebas de stress. Luego, inquietudes personales me llevaron a reforzar un poco más la parte teórica. Finalmente, este último año que he estado trabajando en cuestiones de continuous delivery profundicé en cuestiones de automatización de prueba con distintas herramientas.

Más allá de las cuestiones académicas, tengo la percepción que parte de la industria no toma seriamente el testing. He visto muchas empresas que ven a las personas que hacen testing como «ciudadanos de segunda clase». En esos contextos, las personas que hacen testing, son los que menos cobran, los que «menos saben» y los que menos requisitos tienen para acceder al puesto. Esas mismas empresas son las que suelen hacer casi todo su testing en forma manual.

En cierto modo esto plantea el dilema del huevo o la gallina: «La academia no presta atención al testing porque la industria no lo considera relevante o la industria no pone foco en testing avanzado porque la academia no prepara profesionales en testing».

Luego de algunas charlas de intercambio mantenidas durante Agiles 2013 me decidí a hacer algo al respecto de la situación aquí descripta. Por un lado, empecé a trabajar en conjunto con mis colegas de Kleer (más particularmente con JuanG) para dictar una serie de Talleres de Pruebas automatizadas. Por otro lado, en el contexto académico, tengo la intención de dictar una materia de Testing junto con PabloT en UNQ.

Algo de todo esto voy a estar presentando el sábado próximo en el contexto de mi sesión en el Workshop 2013 de Uqbar.