Autor: NicoPaez

Ingenieria de software: ¿existe tal cosa?

¡Que pregunta! Se podrán imaginar que siendo profesor de una materia con este nombre mi respuesta es sí.

Pero no todo el mundo piensa lo mismo. Una de las personas que cuestiona la existencia de dicha disciplina no es más ni menos que David Parnas, quien el pasado octubre publicó un artículo titulado: «Software Engineering – Missing in Action: A Personal Perspective». En dicho artículo Parnas repasa brevemente el surgimiento del término ingeniería de software y expone ciertas razones por la cuales duda de que el desarrollo de software tenga el caracter de ingenieria. El artículo me resultó por demás interesante, ya que también toca a la pasada cuestiones como ingenieria vs. ciencia, la estructura de la profesión y la educación del profesional del software.

Sumando a este argumento, mi colega Gabriel Falcone me compartió hace un tiempo este video de la conferencia Scotland Ruby, donde disertante afirma:

«Software engineering as it is taught in universities simply does not work. It does not produce software systems of high quality, and it does not produce them for low cost. Sometimes, even when practiced rigorously, it does not produce systems at all. That is odd, because in every other field, the term engineering  is reserved for methods that work.»

¡uffff! Duro, pero bastante realista. En realidad si uno mira el video completo (unos 45 minutos), se encuentra que en realidad el punto de este individuo es que lo que realmente funciona para construir software son los métodos ágiles y que mucha gente tilda a los métodos ágiles como «anti-ingenieriles». A pesar de no compartir algunos de los puntos expuestos en este video, la sesión me gustó y la recomiendo (de hecho he sacado algunos bullets para mis clases).

Personalmente creo que existe la ingenieria de software como disciplina, pero con una concepción distinta a la que le dan muchas universidades (en general a nivel académico hay cierta «creencia» de que por llamarse ingenieria debe tener una fuerte carga de ciencia básica,cosa que no comparto). Al mismo tiempo creo que es aún una disciplina joven ya que las prácticas/métodos que aumentan la probalidad de éxito de los proyectos – y que por ende podrian poner a la ingenieria de software a la altura de las otras ingenierias- recien se han comenzado a popularizar en los últimos 5 años.

Planes de estudio de informática, RedUNCI y ConFeDI

Por estos dias me encuentro trabajando con miembros de las comisiones curriculares de las carreras de informática de FIUBA preparando una propuesta para ser presentada en el contexto de la iniciativa de unificación de las carreras de informática llevado adelante por RedUNCI y ConFeDI.

RedUNCI (es la Red de Universidad Nacionales con Carreras de Informática) y ConFeDI (Consejo Federal de Decanos de Ingeniería) son dos instituciones argentinas referentes en lo que hace a informática (la primera) e ingeniería (la segunda).

Resulta que en 2009, el Ministerio de Educación decidió «estandarizar» las carreras de informática para lo cual convocó a estas dos instituciones. El resultado fue la resolución 786/2009 la cual define 5 carreras en el área de informática:

  1. Licenciatura en ciencias de la computación
  2. Licenciatura en sistemas
  3. Licenciatura en informática
  4. Ingeniería en Informatica/sistemas
  5. Ingeniería en Computación
La mencionada resolución define las incumbencias y ciertos contenidos curriculares mínimos (y de bastante  alto nivel) de cada carrera. Para la definición de las licenciaturas se tomó como referencia la visión de la RedUNCI mientras que para las ingenierias se tomo como referencia ConFeDI. Esto llevó a que si bien en todos los casos estamos y hablando de carreras de «computación/informática/sistemas» (o pongan el nombre que les guste) hay hoy en dia diferencias incluso en los contenidos minimos. Las licenciaturas estan estructuradas en 6 áreas de conocimiento:
  1. Ciencias Básicas
  2. Teoría de la Computación
  3. Algoritmos y Lenguajes
  4. Arquitectura, Sistemas Operativos y Redes
  5. Ingeniería de Software, Bases de Datos y Sistemas de Información
  6. Aspectos Profesionales y Sociales
Al tiempo que las ingenierías están estructuradas siguiendo la filosofia del Confedi según la cual toda ingeniería se constituye de 4 áreas:
  1. Ciencias Básicas
  2. Tecnologías básicas
  3. Tecnologías aplicadas
  4. Complementaria
Esto plantea un inconveniente no menor a instituciones como FIUBA que dictan licenciatura e ingeniería.
Es en parte por ello que en la actualidad RedUNCI y ConFeDI estan liderando una iniciativa para identificar los contenidos mínimos comunes para todas las carreras de informática.
En linea con todo esto, FUIBA ha elaborado en los últimos años nuevos planes de estudio tanto para la licenciatura y la ingenieria. Estos nuevos planes de estudio (que aún no estan vigentes) fueron elaborados por las correspondientes comisiones curriculares en forma independiente.
A continuación les dejo los links a la resolución del ministerio y las propuestas de nuevos planes de informática de FIUBA.

Resolución  786/2009 del Ministerio de Educación.

Propuesta de Nuevo Plan de estudios Ingeniería Informática

Propuesta de Nuevo plan de estudios Licenciatura en Análisis de Sistemas

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.

Relevamiento de la enseñanza de POO

Hace un par de dias comencé a trabajar en un artículo sobre la enseñanza de la programación orientada a objetos. En particular sobre la forma de encarar la primer materia de orientación a objetos, pues en la actualidad es común que dicho tema se trate en más de una materia, pero mi foco está en la primer materia, aquella que presenta los conceptosl s fundamentales de OO (polimorfisto, ocultamiento de information, etc, etc). Como parte de este trabajo he creado una encuesta para relevar como es este tema tratado en las distintas carreras. Lo ideal hubiera sido enviar la encuesta a profesores de distintas universidades/institutos, pero lamentablemente no tengo contacto en todas las universidades, con lo cual se me ocurrió hace una encuestas para ser llenada por los alumnos, contestando como fue que cada uno aprendio POO. Es cierto que de este modo seguramente obtenga varias respuestas sobre una misma institución, por eso es fundamental que quien complete la encuesta indique su institución para asi poder filtrar la información.

Por eso les pido a los lectores si pueden tomarse 2 minutos para completar las 6 preguntas de la encuesta y difundirla entre sus conocidos. Los links son:

Muchas gracias!

Build Server Gratuito en la nube: TravisCI

Ayer descubrí TravisCI, un build server gratuito y open souce para proyectos open source. Si bien no tiene en principio todos los features de Jenkins (en cuanto a reportes, notificaciones, etc, etc) cumple bien su trabajo de build server.

Trabaja integrado con GitHub y para disparar los build utiliza un hook the Github. Ofrece soporte para los siguientes lenguajes: Clojure, Erlang, Groovy, Java, Node.js, Perl, PHP, Python, Ruby y Scala.

Lo probé con mi proyecto SWTFederation y la verdad que me sorprendió lo simple que fue la configuración.

Espero les resulte útil.

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.

Interesante curso de Ingenieria de Software

La semana pasada empecé un curso online ofrecido por la Universidad de Standford en forma gratuita. El nombre del curso es Software Engineering for Software as a Service. El mismo tiene una duración de 5 semanas y es dictado por dos profesores de Berkeley: Armando Fox y Dave Patterson. El curso tiene foco en métodos agiles y la parte técnica está basada en Ruby on Rails.

La dinámica del curso consiste en clases teóricas en formato de video de 10 minutos de duración en promedio.  Al mismo tiempo hay un libro (pago, cuesta unos 10 dólares) escrito por los profesores del curso. La plataforma onlien también cuenta varios foros de discusión. En cuanto al aspecto práctico, hay 4 tareas de programación con un timeframe de 1 semana y por otro lado tambien hay 3 Quiz a lo largo de todo el curso.Según los profesores, alumnos anteriores han reportado una carga de trabajo semanal de entre 5 y 10 horas para completar el curso.

Luego de completar la primer semana, estoy muy entusiasmado, hasta el momento nada nuevo para mi, pero a pesar de ello me gusta la forma en que estan presentados los temas.

No estoy seguro si aún es posible sumarse al curso, pero de todas formas los video son de acceso público.

Les dejo el link al curso: https://www.coursera.org/saas.

¡Que lo disfruten!

Sobre C# y Ruby

Esta es la continuación del post que publiqué ayer, pero que en realidad es más bien una precuela.

Resulta que la semana pasada estaba hablando con unos colegas de Algo3 sobre tecnologia y comenté mi amistosa incursión en Ruby. Ante esto, uno de mis colegas me tildó de panquequearme, pues la mayor parte de mi carrera he argumentando a favor de C# y la plataforma .NET en general.  Hoy por hoy y para una gran cantidad de aplicaciones prefiero inclinarme hacia Ruby, no porque me parezca más apropiado sino porque me siento más cómodo (incluso a pesar de conocer mucho menos). Pero esto no me convierte en panquete, pues mi cambio de opinion no fue ni reiterado ni en corto plazo de tiempo.

Recuerdo que la primera vez que me acerqué a Ruby fue durante 2006, cuando trabajando en Snoop me tocó participar en un proyecto en el cual el cliente nos pedia definir su plataforma y nos había pedido explícitamente evaluar .NET, Java y Ruby. Al cabo de 3 semanas de trabajo nuestra recomendación fue .NET. Pero bastante han cambio estas tecnologias desde aquel 2006 hasta la actualidad (¡pasaron 6 años!).

Ahora hablando un poco sobre el título de este post, creo si bien ambos lenguajes a simple vista parecen bastante distintos, tienen varias cosas en comun en cuanto a la caraterísticas que soportan. Sin duda la diferencia más distintiva es el hecho de que C# es de tipado estático y Ruby de tipado dinámico. Esto implica que en el caso de C# es necesario realizar una compilación explícita antes de pedirle a la maquina virtual que ejecute nuestro programa. Por otro lado, Ruby incorpora varias cosas de Smalltalk (metaclases, bloques, etc) lo cual me resulta muy feliz.

Más allá de las bondades del lenguaje, debo admitir que me he sorprendido a mi mismo, pues nunca crei que pudiera programar con un editor de texto (gedit) luego de haber trabajado por tanto tiempo con Visual Studio y Eclipse. Cuando trabajo en ruby codeo con gedit y tengo dos terminales abiertas, una para hacer el build y otra con irb (el interprete interactivo de ruby) para probar cosas del lenguje, pues aun no estoy suficientemente familiarizado. Cuando esporáricamente tengo que levantar Visual Studio o Eclipse, me deprimo mal, ambos entornos tardan una eternidad en levantar (a pesar de que tengo 4 GB de memoria). Y ni hablar cuando quiero compilar una solucion y correr las pruebas con visual studio.

Más allá de mi opinion (totalmente subjetivas) y de los gustos particulares de cada uno, creo que es importante que todo estudiante/profesional de sistemas haga una experiencia en ambos mundos: el corporativo (C#/Java) y el open source (ruby/python/smalltalk).

Por lo dicho en el post anterior, esa calificación no me aplica pues mi cambio de opinion

hace algunos años habiaal encarar un proyecto había tenido que elegir entre .Net y Ruby y en aquel momento habia elegido C# practicamente sin dudarlo (pero ojo, había investigado Ruby)

Cambiar de opinion no siempre es «panquequearse»

Una conocida frase dice «Se dió vuelta como un panqueque» y de ahí el término «panquequearse».  Esta frase suele utilizarse para hacer referencia a personas que cambian radicalmente de posición respecto a un tema. La analogia con el panqueque me parece bien, pero creo que no siempre se la interpreta correctamente. Paso a explicar.

La particularidad de la «dada vuelta» del panqueque es que ocurre reiteradas veces y en un breve lapso de tiempo. Entonces para que una persona sea etiquetada con la frase en cuestión deberia ocurrir que que dicha persona cambie de opinion varias veces en un breve lapso. Siguiendo esta línea de pensamiento, creo que uno de los mejores ejemplo de panquequeda en la actualidad lo constituyen (algunos) periodistas deportivos: Si Boca gana Riquelmente es un el mejor, si Boca no gana (lo cual ocurre la semana siguiente), Riquelme es un desastre. Como diria EL Diego, esos periodistas son los mismo que le toman la leche al gato y le roban la limosna al ciego. (ups! me fuí de tema)

Por otro lado, cambiar de opinión es algo sano en un punto, pues siginifica en muchos casos un aprendizaje, ¿acaso uno no cambia de opinion muchas veces luego de  aprender una lección?.

Este post ya se hizo demasiado largo para mi gusto, asi que corto aqui y en el siguiente post les cuento  que fue lo que me llevó a escribir esto.

Continuará…

El solo hecho de que una persona cambie de opinión (por más drástico que sea el cambio) no la «convierte en un panqueque»,

Acceso a ACM para gente Fiuba

ACM (Association for Computing Machinery) es una organización que nuclea profesionales y científicos de la computación y «colabora»* en la difusión de conocimiento en este área. En este sentido la ACM tiene una seria de publicaciones periódicas entre las que se destaca la revista Communications of ACM, que ha sido portadora de famosos artículos como GoTo Statement Considered Harmful de Dijkstra.

La buena noticia es que ahora los alumnos de fiuba pueden acceder a los recursos de ACM en forma totalmente gratuita. Para ello simplemente tienen que configurar sus exploradores para usar el proxy de revistas de fiuba**. Para conectar a este proxy es necesario contar con una cuenta de correo de fiuba (@fi.uba.ar).

¡Que lo disfruten!

* Colabora es una forma de decir, pues si bien ACM concentra muchas publicaciones en la denominada ACM Digital Library, el acceso a la misma es restringido.

** No publico la dirección del proxy por cuestiones de seguridad, los interesados pueden contactarme en privado o bien contactar directamente a soporte Fiuba.