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.

 

 

 

Cierre de cuatrimestre en UNQ (2015-2)

Un nueva cursada a ha terminado. Más allá de algún accionable menor surgido del feedback del cuatrimestre anterior no hicimos cambios relevantes este cuatrimestre.

Tuvimos 15 inscriptos (entre ellos 1 recursante) de los cuales 2 abandonaron la materia mientras que los otros 13 restante completaron la materia y aprobaron.

La nota promedio de aprobación fue 8.4/10 y el grado de conformidad de los alumnos con la nota obtenido fue 4.2/5.

La evaluación general de los alumnos según la encuesta anónima de cierre de la materia fue de 8.9.

A diferencia de cuatrimestres anteriores, en la retrospectiva de cierre de la materia no surgieron puntos relevantes (tal vez sea porque utilizamos una dinámica de retrospectiva nueva). Más aún algunos de los pocos puntos que surgieron, tuvieron opiniones distintas, o sea: algunos alumnos los consideraron como cosas a cambiar mientras que otros los consideraron como puntos importantes a mantener. Entre los pocos puntos que tomamos para mejorar/probar están:

  • Mejorar el feedback de las katas
  • Programar alguna kata en clase
  • Hacer alguna review online durante el desarrollo del TP final

Personalmente confirmo una vez más mi sensación de que realmente hemos logrado una muy buena materia en el sentido de que me hemos logrado una dinámica que nos ha permitido ayudar a los alumnos a incorporar nuevos conceptos y herramientas para su desarrollo profesional y académico.

Comparto aquí la foto de cierre y algunos de los videos de los TP finales:

eis_unq_20152

 

Automatización de pruebas en AS400, fin de la historia

Como mencioné tiempo atrás, en octubre comencé a trabajar en un proyecto para automatizar pruebas de una aplicación RPG/AS400. He completado mi participación en el proyecto, logramos dejar una arquitectura de pruebas funcionando con un par de casos automatizados, ahora está en manos del propio equipo de desarrollo continuar agregando nuevos casos.

El siguiente gráfico resume la arquitectura implementada:

test_as400

La arquitectura está armada de forma tal que un tester puede agregar fácilmente nuevos casos sin tener que meterse mucho en el código. Algo de código obviamente va a ser necesario escribir pero por la forma en que todo quedó armado (con template methods) es realmente poco lo que hay que codear.

Los casos de pruebas se generan con FitNesse y luego el gluecode/driver utiliza dos librerías de IBM: una para invocar funciones nativas en AS400 que se encargan de hacer el setup del ambiente con los datos iniciales y otra para la creación de las colas MQ y para leer/escribir en dichas colas.

Como la aplicación y los tests están codeados en distintas tecnología y almacenados en distintos repositorios, el servidor de integración continua (jenkins) quedó configurado para correr el set de tests ante cada commit y también en forma periódica 3 veces al día.

Estoy conforme con el resultado de nuestro trabajo, al mismo tiempo creo que fue un lindo desafío que me permitió aprender un poquito del mundo AS400. Ahora está en manos del codear más pruebas y sacar valor al trabajo realizado.

 

 

 

 

Blue Green Deployment

En las últimas 2 semanas me encontré explicando la técnica de despliegue Blue/Green más de 5 veces. Cuando tomé conciencia de ello decidí hacer un video explicativo de modo de poder utilizarlo también en mis clases. Espero resulte de utilidad.

Ansible vs Puppet: mi opinión

Hace unos días escribí sobre el camino que recorrí con las herramientas de automatización de infraestructura y mencioné que luego de haber usado Puppet y Ansible, he decidido quedarme con este último. Esta decisión se debe principalmente a las cuestiones:

  • El DSL de Ansible me resultó mucho más amistoso que el de Puppet
  • Para trabajar en modo «standalone» Ansible incluye en su core un conjunto de utilidades/tareas que a mi me resultan muy útiles y que no están en el core de Puppet (a menos que uno instale módulos adicionales).
  • El modo de funcionamiento «push» de Ansible me gusta más que el modo pull de Puppet.

Resalté algunas partes de la frases anteriores para dejar bien en claro el nivel de subjetividad de las mismas.

Mi propuesta para el AOC 2016

Según el procedimiento de inscripción, tengo que responder 3 preguntas, asi que aquí voy.

¿Qué puedo aportar yo al evento?

Quiero aportar un entregable, algo concreto que trascienda los 3 días de conferencia y a los participantes de la misma. En concreto quisiera generar otro libro repitiendo y reutilizando la experiencia del libro Experiencias Ágiles que escribimos en el AOC anterior. No tengo del todo claro cuál sería el contenido de este libro, de mínima podría ser un conjunto de experiencias igual que el libro anterior, pero creo que tal vez podríamos generar algo un poco más rico como por ejemplo un catálogo de técnicas. Independientemente del tema, me gustaría llegar al evento con el contenido bastante avanzado para asi intentar cerrarlo durante el evento y evitar así una carga de trabajo post-evento. Si mi postulación es seleccionada imagino empezar a trabajar en enero. Creo que en primer lugar haría una convocatoria de autores y luego en conjunto con los que decidan participar deberíamos definir la cuestión del contenido.

¿Qué espero recibir del evento?

Espero encontrarme con otros practicantes para compartir experiencias en el desarrollo de software y también momentos de esparcimiento.

¿Quien soy?

Soy NicoPaez, un Ingeniero de Software formado en la Universidad de Buenos Aires. Practico basquet, me gusta escribir y jugar al TEG. Soy docente universitario y trabajo en la industria del software formalmente desde hace unos 15 años.

Agile Open Camp 2016: abierta la inscripción

La semana pasada se anunció la apertura de las inscripciones para el AOC 2016. Resulta que este año el procedimiento de inscripción tiene algunas particularidades.

A diferencia de otros eventos el AOC tiene un límite «duro» de asistentes pues es un evento 3 x 24,  o sea son 3 días completos donde todos  los participantes se alojan en un mismo lugar y comparten espacios las 24 horas. En la primera edición hubo mucha gente que quedó fuera por falta de vacantes. Si bien para esta segunda edición se contará con una mayor cantidad de vacantes también se espera una mayor cantidad de interesados en participar debido a gran repercusión que tuvo la primera edición. Es por esto que el grupo organizador ha decido experimentar con un sistema de inscripción alternativo al simple «orden de llegada» utilizado en la primera edición. El mecanismo a utilizar está explicado en este breve video de Tommy, unos de los miembros fundadores del evento.

En forma resumida la idea es: cada interesado en participar debe postularse indicando porque le interesa participar y que tiene para aportar. Luego cada uno de los 3 fundadores del evento revisa las postulaciones y selecciona 2. Los seleccionados se inscriben en el evento comprando su entrada y tienen derecho a elegir otros dos postulantes cada uno. El proceso se repite hasta completar la cantidad de vacantes disponibles.

Personalmente me gusta la idea de que las entradas se repartan en base a cierto criterio de «aporte de valor» en lugar de el simple orden de llegada. Veremos que tal sale, por mi parte ya me voy poniendo a escribir mi postulación.

 

Reflexiones sobre la automatización de pruebas

La semana pasada dicté junto a @dfontde un taller de automatización de pruebas. Entre la audiencia tuvimos principalmente desarrolladores.

Obviamente uno de los temas que tratamos fue la automatización de pruebas a nivel de Interface Gráfica de Usuario (GUI). De hecho cada vez que dicto este taller la gente suele venir con la expectativa de encontrar la bala de plata para poder automatizar pruebas exclusivamente a nivel GUI. Mi posición al respecto es siempre la misma: ¿en verdad que quieres automatizar pruebas a ese nivel?.  A lo largo del taller trabajamos fuertemente sobre la cuestión de a qué nivel automatizar las pruebas y muchos suelen convencerse que puede resultarles más conveniente trabajar la automatización a nivel del API/Servicios.

Las pruebas a nivel GUI suelen ser frágiles (cambios mínimos en la GUI pueden romper las pruebas) y costosas de ejecutar (ya que requieren instanciar la aplicación completa). Pero al mismo tiempo pueden ser la única opción de automatización, ya que prueban la aplicación en modo caja negra, no importa como esté construida la aplicación pues simplemente se interactúa con ella desde afuera. Este es un punto muy relevante para el caso de aplicaciones legacy, que muchas veces han sido construidas sin características de testeabilidad. Más allá de estos argumentos que son clásicos y pueden encontrarse en la bibliografía hay algunas cuestiones adicionales que se han puesto de manifiesto en los últimos años.

  • Por un lado cada vez son más comunes las famosas SPAs (Single Page Application), muchas veces basadas en frameworks «client-side»como AngularJS. Esto implica una creciente cantidad de código JavaScript. Este tipo de aplicaciones no suele ser tan simple de automatizar a nivel GUI pues no todas las herramientas no se lo bancan bien. Pero al mismo tiempo aparece un nuevo nivel de automatización posible: pruebas unitarias de los componentes JavaScript.
  • Por otro lado, los frameworks de desarrollo / generadores de código «server-side» como Spring-Boot ya incluyen como parte de sus funcionalidades una propuesta para la codificación de pruebas automatizadas a nivel de API e incluso en algunos casos se encargan de generar el código de algunas de estas pruebas.

En mi opinión estas dos cuestiones refuerzan necesidad de repensar cualquier intento de automatización de pruebas a nivel GUI. Y quiero ser muy claro en cuanto a esto: no estoy diciendo que no se automaticen pruebas a nivel GUI, sino simplemente que no me parece una buena estrategia que el grueso de las pruebas automatizadas sea a nivel GUI. Creo que hay que pensar en una estrategia de automatización más integral que incluya pruebas a distintos niveles. Esto nos permitirá tener una mejor cobertura con un esfuerzo mucho menor y repartido entre los distintos perfiles del equipo (tengamos presente que el testing no es sólo responsabilidad de los testers).