RE: Academia e Ingeniería de Software

  • strict warning: Non-static method view::load() should not be called statically in /home/codecomp/public_html/codecompiling.net/mai.www/sites/all/modules/views/views.module on line 906.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /home/codecomp/public_html/codecompiling.net/mai.www/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /home/codecomp/public_html/codecompiling.net/mai.www/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_handler_filter_boolean_operator::value_validate() should be compatible with views_handler_filter::value_validate($form, &$form_state) in /home/codecomp/public_html/codecompiling.net/mai.www/sites/all/modules/views/handlers/views_handler_filter_boolean_operator.inc on line 159.
  • strict warning: Declaration of views_plugin_style_default::options() should be compatible with views_object::options() in /home/codecomp/public_html/codecompiling.net/mai.www/sites/all/modules/views/plugins/views_plugin_style_default.inc on line 24.
  • strict warning: Declaration of views_plugin_row::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/codecomp/public_html/codecompiling.net/mai.www/sites/all/modules/views/plugins/views_plugin_row.inc on line 134.
  • strict warning: Declaration of views_plugin_row::options_submit() should be compatible with views_plugin::options_submit(&$form, &$form_state) in /home/codecomp/public_html/codecompiling.net/mai.www/sites/all/modules/views/plugins/views_plugin_row.inc on line 134.

DONE

Nicolas Paez ha escrito un breve post sobre su percepción respecto a la forma en que se enseña Ingeniería de Software en distintas universidades en Latinoamérica. En lo personal, no he realizado investigación alguna al respecto en otras universidades (al menos no formalmente), y cualquier cosa que pueda decir se suscribe por lo pronto, únicamente a mi experiencia y a la forma en que enseñamos Ingeniería de Software en la Universidad de los Andes (ULA), en Venezuela.

En nuestro caso, estamos en el extremo de dictar una sola materia de Ingeniería de Software para toda la carrera. El programa de la asignatura se resume de forma muy general en la siguiente figura:

El curso tiene una carga horaria de 6 horas de clase a la semana, de las cuales 4 son “teóricas” y 2 son “prácticas” y se dicta en un total de 16 semanas. Como ven, son 16 semanas en las que si nos remitimos al programa hay que cubrir bastante contenido (debo decir que es un curso bastante agotador, sobre todo si se quiere dictar bien).

Personalmente estoy un poco inconforme con el hecho de que haya una sola asignatura de Ingeniería de Software, y sinceramente creo que la carrera podría beneficiarse mucho si se separase la asignatura al menos en otras dos: Arquitectura de Software por un lado e Ingeniería de Software por el otro. Esto liberaría un poco la presión y el exceso de contenido que tiene la materia actualmente y permitiría profundizar un poco más en algunos temas, y en especial, en algunos aspectos prácticos.

Como se puede apreciar, desde el punto de vista del post de Nicolas, en la ULA estamos mucho más cerca del grupo de “una materia por carrera” (como en la UNQ) que del grupo de “varias materias por carrera” (como es en el caso de la UBA).

Sin embargo, es importante decir que en la ULA ofrecemos una carrera de de Ingeniería en Sistemas, y no una carrera de Ingeniería Informática como sucede en la UBA. La Ingeniería en Sistemas es... bueno, una definición de qué es la Ingeniería en Sistemas (y más importante aún, qué no es) merece otro post completo, pero hay que decir que no sólo nos dedicamos a desarrollar software, sino que también hacemos otras cosas. Somos una escuela formada por tres departamentos (Control, Computación e Investigación de Operaciones) en la que se dicta un extraño híbrido entre varios de los perfiles en computación de la IEEE-ACM, mezclado con Control de Procesos, un poco de Automatización, etc.

Mi visión concreta respecto a lo que plantea Nicolas es muy simple: En la primera clase siempre le muestro a mis estudiantes esta transparencia:

Y posiblemente el punto debería ser aún más pequeño de lo que en actualmente es. La pregunta ¿qué representa el rectángulo verde y el punto negro? usualmente flota en el aire por un rato, y hasta ahora, nunca he conseguido que alguien, más que responder, adivine la intención oculta detrás de la interrogante (aunque muchos estudiantes lo han intentado).

La respuesta es simple: El rectángulo representa todo lo que se puede saber sobre Ingeniería/Desarrollo de Software, el punto negro, lo que podemos cubrir en este curso. La idea fundamental detrás de esta pregunta es mostrar lo verdaderamente abismal de todo lo que en efecto NO se puede cubrir durante el curso.

La lámina anterior resume lo que pienso sobre la enseñanza de la Ingeniería de Software hoy en día: Simplemente no podemos enseñar/transmitir a los estudiantes todos los conocimientos teóricos que necesitan para afrontar todos los problemas que se van a encontrar en sus carreras profesionales. Lo que si podemos (y debemos) es formar criterio, suficiente para que nuestros estudiantes puedan aprender luego por sí mismos y enfrentar nuevas situaciones según sea el caso. Esto es particularmente cierto en una ingeniería tan dinámica como la nuestra, y también tan subjetiva, en la que muchas cosas y conceptos dependen de la dirección desde la que se las vea, o tal como lo dice Martin Fowler, refiriéndose en este caso puntual al término “arquitecto” y luego generalizándolo casi a cualquier cosa:


“In software, the term architect means many things. (In software any term means many things)”

...o peor aún, como me gusta decir a mis estudiantes, en Ingeniería de Software, dados dos puntos de vista diametralmente opuestos, simplemente "escojan un bando, pero eso si, argumenten bien el porqué de la elección".

Finalmente, me gustaría también aportar un poco más que sólo el feedback que solicitó Nicolas en su post. Me gustaría hablar sobre las distintas formas en que hasta los momentos he dictado la asignatura.

No se hasta que punto mis estudiantes se dan cuenta de esto, pero he hecho unos cuantos experimentos durante las distintas instancias del curso a lo largo de los últimos cuatro años. Algunos han salido bien, otros muy bien, y otros casi se convierten en desastres totales (bueno, quizá no tanto). Simplificando un poco, he dictado la materia usando tres enfoques distintos: el teórico clásico (y aburrido) en el que se dicta un curso lleno de contenido, el práctico utilizando cascada y el práctico utilizando métodos ágiles. También he integrado el curso de Ingeniería de Software con el curso de Bases de Datos, y hasta hay un artículo que está por publicarse al respecto, pero eso ya es harina de otro costal.

Con el enfoque ágil, he usado distintos sabores de Scrum (ScrumBut dirán algunos, y probablemente tendrán razón), tratando más que nada de adaptar Scrum al contexto “muy a medio tiempo” de un curso de Ingeniería de Software, en el que los estudiantes son compartidos generalmente con otras cuatro materias, además de otros obstáculos que no vienen al caso. En este sentido he hecho algunos avances importantes y voy refinando la técnica semestre a semestre.

Sobre el punto de vista “teórico versus práctico”, para mi la respuesta es evidente: la visión práctica siempre gana. Tengo la firme creencia de que la Ingeniería de Software es algo que se debe enseñar/aprender de forma práctica, de modo que eso es exactamente lo que hago con mis estudiantes de pre-grado: Utilizar la estrategia RAIS para desarrollar productos. Además, de quedarme solamente con el enfoque teórico, es muy probable que me hubiese aburrido hace rato, después de todo, no hay nada mejor que hacer productos interesantes en el salón de clase.

El otro punto de contraste es ágil versus cascada. Aquí debo decir que me ha ido bien con ambos enfoques, pero me ha ido mucho mejor con el enfoque ágil, que es el que utilizo actualmente. Desde el punto de vista académico creo que las dos visiones tienen ventajas y desventajas. Ágil por un lado permite comenzar a desarrollar casi desde el día uno, cascada no. Por lo antes mencionado, ágil permite desarrollar productos más ambiciosos que con cascada, porque usualmente hay más tiempo dedicado a la programación, a aprender las nuevas tecnologías y técnicas necesarias para desarrollar el producto de turno, etc.

Ahora bien, dependiendo del punto de vista, una de las desventajas de ágil es que pareciera que permite ejercitar menos algunos aspectos más formales del contenido del curso, cosa que si es posible hacer con cascada... quizá ha sido una falla mía, pero por lo pronto esa es la impresión que tengo. Por otra parte, ágil permite hacer algo que considero bueno: ejercitar algunos valores y principios fundamentales para desarrollar software, y con los que particularmente me siento muy identificado, así como enseñar la importancia de generar productos funcionando en lugar de producir pilas de papeles (usualmente inútiles desde mi punto de vista).

En resumen, y por los momentos, hasta ahora me quedo con la visión ágil en mis cursos de Ingeniería de Software.

Excelente aporte Demian,


Excelente aporte Demian, muchas gracias. Me parece tan interesante que se lo pasado a mis alumnos para que lo lean.

Citas...

In software, the term architect means many things. (In software any term means many things)

Martin Fowler

Cursos