Nueva carrera de informática

Ayer el Consejo Superior de la Universidad Nacional de Quilmes, el pleno, por unanimidad aprobó la propuesta de creación de la carrera y el plan de estudios propuesto para la Licenciatura en Desarrollo de Software.
Personalmente participé de algunas de las discusiones de plan de estudios de esta carrera y puedo decir que el plan está muy bien (al menos para mi gusto). Un detalle a destacar es el nombre de la carrera, el cual refleja claramente el foco: Desarrollo de Software. Esto marca un diferencia respecto de la mayoria de las carreras de informática que suelen hacer referencia a Análisis de Sistemas, Sistemas de información, Informática, Computación, etc,. etc.
Esta licenciatura comprende 10 semestres, con un total de 41 materias semestrales (de distintas cargas horarias), los primeros 4 semestres serán de materias comunes a la TPI (16 en total). En los siguientes 6 semestres, hay 4 materias obligatorias y 3 optativas que sirven tanto para la licenciatura como para TPI, 2 materias que se cursan con la Diplomatura en CyT, y 16 materias nuevas, exclusivas de la Licenciatura.
¡Mis felicitaciones a Fidel a todo el equipo de TPI por este gran hito!

Mi enfoque hacia la arquitectura de software

Cuando me tocó estudiar este tema formalmente como alumno, recuerdo que lo hice desde la perspectiva del proceso unificado. Luego por iniciativa propia estudié el tema desde otras perspectivas/fuentes. Pero creo que lo que realmente me hizo entender el tema fue poner manos a la obra. Con esto en mente, hace unos dias me senté a preparar mis clases sobre este tema para mi materia de UNQ. Revisé algunas fuentes tradicionales, notas personales  y algunas fuentes más recientes y pensé algunos ejercicios para hacer con lo alumnos de cara a intentar bajar a concreto algunas cosas que pueden llegar a resultar abstractas.

Como mencioné en un post anterior, decidí encarar el tema presentando un problema, el cual nos fue guiando por los atributos de calidad hacia la arquitectura como disciplina. Luego en una segunda clase, vimos algunas definiciones formales y estilos de arquitectura con algunos ejemplos concretos razonando sobre código las implicancias de cada estilo. La tercer clase la decicamos a ver algunas técnicas concretas para atacar la definición de arquitectura de una aplicación. Finalmente en una cuarta clase, los alumnos realizaron presentaciones de ciertos estilos de arquitectura utilizando el mismo enfoque que habiamos utilizando previamente para presentar otros estilos.

Como material de estudio complementario a lo visto en clase elegí:

En algunas clases posteriores volveremos sobre algunas temas de arquitectura (por ejemplo para analizarla en el contexto de distintas metodologias de desarrollo), pero ya como cuestión colateral y no como tema central de una clase.

Introducción a la arquitectura de software

El lunes pasado empezamos a meternos en temas técnicos, más precisamente en cuestiones de diseño de alto nivel, cuestiones comunmente llamadas de arquitectura. A diferencia de la mayoría de la bibliografía decidí saltar las definiciones y presentar el tema a partir de una problemática concreta siguiendo algunas ideas de Mike Cohn y Less Bass.

En clases anteriores habíamos trabajado sobre modelado de negocio, identificación de user stories y especificaciones en forma de features (bdd), para esto trabajamos con un material que yo mismo preparé hace un par de años para un workshop que dicté en un Agile Open.

Cuando realizamos este workshop en clase habíamos debatido sobre algunas user stories que no seguian el criterio INVEST, cosas del estilo «Como responsable de soporte del sistema quiero que el acceso a la base de datos se haga utilizando el componente XYZXYZ» o «Como responsable máximo de la aplicación quiero que la misma esté disponible 99.999% del tiempo«. En su momento clasificamos estas stories como system stories (acorde a la propuesta de Mike Cohn). La particularidad de las system stories es que resultan transversales a todo el sistema. Una forma en que me gusta caraterizar estos distintos tipos de stories es diciendo:

  • Las user stories describen lo que el sistema debe HACER, o mejor dicho lo que deben permitir hacer al usuario.
  • Las system stories describen lo que el sistema debe SER, o sea, describen propiedades del sistema.

Estas propiedades del sistema son inherentemente transversales a las user stories. En una época eran llamadas requerimientos no funcionales y luego fueron renombradas como atributos de calidad que es el nombre técnico con el que se las referencia en la actualidad. En alguna bibliografía recuerdo haberlas visto caraterizadas como *ilities, en referencia al sufijo que suelen tener: scalability, availability, security, portability, interoperability, testeability, etc, etc.

A partir del análisis de estos atributos de calidad en el caso particular de la aplicación en cuestión, es que uno determina ciertas tácticas para cumplir con ellos. En un paso posterior buscaremos un estilo de diseño que nos ayichude implementar las tácticas elegidas.

Veamos un ejemplo concreto. Trabajando en conjunto con nuestro product owner identificamos una system story que hace referencia a cierta disponiblidad de la aplicación. Para intentar asegurar la disponiblidad deberiamos en primer lugar utilizar alguna táctica para ser capaz de detectar fallas en la aplicación que puedan llegar a interrumpir el servicio (fault detection). Al mismo tiempo deberiamos contar con alguna táctica que determine como accionar en caso de detectar que el servicio ha sido interrumpido, o está por ser interrumpido (fault recovery). Complementariamente podriamos utilizar alguna táctica para intentar evitar las fallas (fault prevention).
Algunas tácticas posibles para encarar estas tres cuestiones son:

  • Fault detection: ping/echo y heartbeat
  • Fault recovery: voting, reduncancy y shadow operation
  • Fault prevention: removal from service, transaction y process monitor.

(no traduje estas estrategias para facilitar la búsqueda en caso que alguien pretenda ahondar en el tema)

Finalmente una vez elegidas las tácticas concretas, se elige un estilo de arquitectura de que nos permita implementarlas.

Todo este proceso aqui descripto forma parte de lo que denominamos «Definición de arquitectura».

Continuará…

Sobre los primeros egresados de TPI

Como mencioné anteriormente, tuve el honor de ser invitado a formar parte del jurado de evaluación del trabajo de inserción profesional de Nahuel Garbezza, egresado de la primera promoción de la Tecnicatura en Programación Informática de UNQ. Los otros miembros del jurado fueron Nicolás Passerini  y Hernán Wilkinson.

Además de ser un gran honor, fue una experiencia interesante. El trabajo en cuestión consistió en desarrollar una herramienta de BDD para Pharo Smalltalk (algo así como un análogo a Cucumber). Una vez aceptada la propuesta de ser jurado recibí el trabajo y lo fuí leyendo a medida hacia algunas pruebas con la herramienta y revisaba el código. El trabajo estaba muy bien escrito, lo cual no me extraña, ya que la directora del trabajo fue Gabi Arévalo. Desde el punto de vista técnico la herramienta estaba muy bien, con un amplio set de pruebas automatizadas y una cobertura del modelo por encima del 70%.

La defensa del trabajo tuvo lugar el viernes pasado a continuación de la defensa de Federico Sawady, el otro egresado de esta primera camada de TPI.

El trabajo de Federico (dirigido por Fidel) consistió en la implementación de un sistema de tipos para el lenguaje Gobstones que es utilizado en las primeras materias de programación en TPI.

Las defensas consistieron en presentaciones de 45 minutos seguidas por preguntas/comentarios de los jurados y del público en general. Entre el público se encontraban profesores, alumnos, familiares, autoridades de la universidad y gente de la Fundación Sadosky.

Mis felicitaciones a los egresados y al equipo de dirección de TPI por el gran trabajo que estan haciendo.

Primeros egresados de la tecnicatura en programación (UNQ)

El viernes próximo la Tecnicatura en Programación Informática de UNQ (carrera de la que soy docente) tendrá sus primeros dos egresados: Federico Sadaway y Nahuel Garbezza. Será a partir de las 18 horas cuando ambos alumnos defiendan sus correspondientes trabajos finales de carrera (formalmente llamados trabajo de inserción profesional).

El trabajo de Federico se titula «Formalización e implementación de un sistema de tipos para el lenguaje de programación Gobstones» personalmente no estoy muy familiarizado con Gobstones, solo se que se utiliza en las primeras materias de programación de la carrera.

Por su parte el trabajo de Nahuel se titula «Desarrollo dirigido por comportamientos en Pharo Smalltalk» y con este sí que estoy bastante familiarizado ya que soy uno de los jurados evaluadores.

Por el momento no voy a entrar en más detalles, solo les digo que si desarrollan en Pharo, el trabajo de Nahuel puede resultarles de gran interés. Luego de la defensa dedicaré unas lineas más extensas la experiencia de ser jurado y también al trabajo de Nahuel.

Sobre el curso de Ingeniería de Software de Berkeley

Hace un tiempo comenté que estaba tomando un curso online de la Universidad de Berkeley ofrecido en la plataforma online de la Universidad de Standford. Ayer rendí el último examen y lo completé.

El curso me gustó, aprendí algunas cosas y reforcé otras, pero debo decir que esperaba algo distinto. El título del curso era «Software Engineering for SaaS» , pero de SaaS se vió muy poco. Respecto a esto algunos alumnos opinaban que el hecho de usar Ruby/Rails ya cumplia con el contenido de SaaS. Yo personalmente no comparto, creo que Ruby/Rails es un solo un framework, muy productivo sin duda, pero que implementa patrones que han estado en uso por varios años como MVC y Active Record y que pueden o no usarse para hacer aplicaciones SaaS. Al mismo tiempo, temas como escalabilidad, que resultan muy relevantes en aplicaciones SaaS, apenas fueron mencionados.

Más allá de los contenidos, me gustó mucho la dinámica y tengo ganas de hacer algo similar ofreciendo parte del contenido de la materia que estoy dictando en UNQ.

Aventura gráfica made in Argentina (ex-FIUBAs)

La semana pasada me llego un mail de compañero de Francisco Saenz contandome del lanzamiento de Reversion, una aventura gráfica desarrollada por un conjunto de alumnos de Fiuba: Francisco (mi compañero), Fernando y Facundo.

Estos tres muchachos se conocieron en su época de estudiantes en Fiuba, luego de un par de años fundaron la empresa 3F Soluciones en el contexto de la cual desarrollaron este juego. El año pasado, Francisco y Fernando estuvieron de invitados en mi materia en UNQ donde contaron sobre el surgimiento de la empresa, su forma de trabajo y el proceso de desarrollo de este juego. Todos quedamos facinados con la presentación y muy expectantes al lanzamiento del juego que se llamaria Reversion.

Bien, finalmente el momento llegó, desde hace unos está disponible para descarga el primer capítulo de Reversion. Tal vez lo más llamativo del juego es que está ambientado en Argentina y pueden reconocerse en las distintas pantallas escenas inconfundibles de pasajes de Buenos Aires.

Dado que los juegos no son mi fuerte, les dejo el link al anuncio escrito por los creadores y para quienes les interes el backstage, les recomiendo ver el blog que escribe el equipo de desarrollo.

Mis felicitaciones al equipo de 3F y ojala les vaya muy bien con esta iniciativa, chau, ¡ me voy a jugar!

Primer cuatrimestre 2012: ¡largamos!

Asi es, largamos y casualmente en esta ocasión el cuatrimestre comenzó al mismo tiempo en FIUBA y en UNQ. Curiosamente la mi mátricula de alumnos se invirtió respecto del cuatrimestre pasado: mientras que en Ing. de Software (UNQ) tengo menos alumnos (pasé de 15 a 7) en Algo3 (FIUBA) tenemos alrededor de 50 alumnos (casi el doble que el cuatrimestre anterior).

El comienzo fue bastante movido, de hecho las clases comenzaron la semana pasada y recien ahora me pude hacer un tiempo para escribir un par de líneas. Algo interesante es que en ambas materias noto una mejora respecto del cuatrimestre anterior:

  • En Algo3, a pesar de tener más alumnos, las cantidad de consultas sobre el TP0 se redujeron notablemente. Lo cual a mi entender tiene que ver con 2 cuestiones: el enunciado del TP fue menos ambiguo y al mismo tiempo las explicaciones en clase previas a la entrega del TP0 fueron lo muy claras.
  • En Ing. de software, me asignaron un aula ¡excelente!: pizarra blanca enorme, mesas altas con ruenas y banquetas. Por otro lado tengo un alumno del  cuatrimestre pasado que me va a estar dando una mano como colaborador, lo cual espero nos permita tener un mejor seguimiento de los alumnos.

Si bien las materias tratan sobre distintos tópicos, en ambos casos estamos poniendo un importante énfasis en las pruebas: TDD, BDD, etc.

Otro punto común es que en ambos casos vamos a estar utilizando como herramienta de apoyo la plataforma Moodle.

Particularidades de UNQ / TPI

La tecnicatura en programación de UNQ, cuenta con una lista de correo en la que están suscriptos todos los alumnos y docentes de la carrera. Esto no es gran cosa, pero lo que sí me parece una particularidad interesante es que todos los comienzos de cuatrimestre el director de la carrera (Pablo Martinez López, mejor conocido como Fidel)  manda un mail de bienvenida que siempre comienza una frase de una Pink Floyd

«Welcome, my son,  Welcome to the machine.», Welcome to the Machine – Wish You Were Here, Pink Floyd

Esta frase precede a la presentación del director y a una lista de consejos/explicaciones enfocadas en los ingresantes, pero que siempre vienen bien para todos recordar. Este cuatrimestre la citada frase resulta aún más apropiada dada visita de Roger Water. Al mismo tiempo este cuatrimestre Fidel decidió agregar una segunda frase al mail de bienvenida, la cual me parece excelente:

«A fool’s brain digests philosophy into folly, science into superstition, and art into pedantry. Hence University education.», George Bernard Shaw, Irish dramatist & socialist (1856 – 1950)

Lo cual en castellano sería algo como: «El cerebro de un tonto convierte filosofía en tonterías, la ciencia en superstición y el arte en pedantería. Por eso una educación universitaria.»

Say no more.

Planificando Ing. de Software 2012

En base a la experiencia del último cuatrimestre, el feedback de los alumnos y algunas ideas que vengo trabajando desde hace ya un tiempo, este primer cuatrimestre de 2012 viene con varios cambios.

En primer lugar voy a dar un enfoque más práctico, o sea, vamos a programar, aunque aún no decido si Java, Smalltalk o Ruby (creo que es algo que puedo dejar decidir a los alumnos).

En segundo lugar voy a hacer algunos cambios en la profundidad de los contenidos: más agile, más calidad/testing y menos UP. De hecho no quiero dedicar más de 3 clases a UP y posiblemente algún trabajo individual (un questionario posiblemente).

En tercer lugar, pero no por ello menos importante, voy a dictar la materia en forma iterativa. Esto es un tema que he hablado con colegas en reiteradas ocaciones: bien probado está que el desarrollo iterativo es una de las prácticas de ingeniería de software más aceptadas y utilizadas en la actualidad, pero sin embargo la ingeniería de software sigue enseñanadose en forma secuencial. Entonces mi idea es dividir la materia en iteraciones, entre 4 y 6. Cada una de ellas time-boxed, con un entregable concreto. En cada iteración veremos todas las actividades del proceso de desarrollo, profundizando un poco más en cada iteración, al final de cada iteración tendremos un entregable de valor.

La excepción será primer iteración, que será más corta y en la que nos centraremos (al igual que el cuatrimestre pasado) en entender las particularidades de la disciplina. El entregable de esta primer iteración será el setup del portfolio individual (en futuros post voy a desarrollar este punto).

Cada una de las siguientes iteraciones tendrá un ejecutable de código con sus correspondientes pruebas, algunas de las cuales serán especificadas como parte de la consigna y otras deberán ser diseñadas por los alumnos.

Adicionalmente a la entrega de final de iteración, tendremos también algunas entregas intermedias.

Otro de los cambios será la utilización de un build server para verificación de los entregables.

También tengo la intención de utilizar una plataforma virtual, la cual espero nos permita tener una mejor dinámica de intercambio en el curso. Ya realicé el pedido al departamento con lo cual solo me queda esperar que acepten la petición, pues en general la plataforma virtual está solo disponible para la materias de las carreras virtuales.

Otro agregado de color que pienso hacer el tema «ejercicio profesional». Con este nombre pretendo englobar varios consejos para el desempeño profesional como por ejemplo: como armar un CV, como prepararse para una entrevista laboral, etc, etc.

Al mismo tiempo quiero mantener varias de las prácticas del cuatrimestre anterior como por ejemplo el envio de mail de resumen después de cada clase, la planificación y estimación de las tareas por parte de los alumnos y visibilidad contínua sobre las asistencia a clase. Este última  práctica tiene que ver con que si un alumno piensa faltar a clase, debe comunicarlo previamente, el obejtivo de esto es que se acostumbren a dar visiblidad a su equipo. También voy a repetir la experiencia de invitar a profesionales de la industria a contar sus experiencias (para este cuatrimestre ya tengo el compromiso de Manuel Trejo de Kinetia)

Por último estoy evaluando distintas alternativas tecnológicas para intentar grabar las clases, pero no estoy seguro que pueda implementar esto.

Si algún futuro alumno lee esto puede que se pregunte ¿pero cuanto voy a tener que trabajar para aprobar esta materia? Recuerdo que una vez un profesor me dijo que para hacer una carrera univesitaria hay que dedicar al menos la misma cantidad de horas de estudio que la cantidad de horas de clase. Yo no creo que para esta materia sea necesario tanto. Considerando que tenemos entre aproximadamente 5 horas netas de clase, estimo que con dedicar unas 3 horas semanales extra clase, deberia ser suficiente. Pero ojo, hablo de 3 horas netas, podes parate para ir al baño, tomar un vaso de agua o preparar el mate, pero nada de mail, ni chat, ni SMS, ni facebook, son 3 horas estudio posta.

Las clases empiezan en dos semanas y tengo muchas expectativas. Ya les iré contando más a medida que avance.