LONE STAR RUBY CONFERENCE 2010 REAL SOFTWARE

ENGINEERING BY GLENN VANDERBURG

Buenos das, soy Glenn Vanderburg, trabajo para InfoEther con Rich Killmer, Chad Fauler
y Bruce Williams; imagino, muchos de ustedes lo conocen.
Estoy aqu para hablar sobre la Ingeniera de Software Real, he estado en las cuatro Lone
Star Ruby Conference anteriores, y lo pas genial.

Entonces, para empezar, la Ingeniera de Software no funciona, al menos, no de la forma

en la que actualmente es enseada en las universidades y en programas de
entrenamiento en compaas, en caso trabajes para una de las pocas compaas que se
encargan de ensear. Las tcnicas que son enseadas y que son llamadas Ingeniera de
Software simplemente no funcionan: no son fiables para el control de costos, no se
producen software de calidad fiables, algunas veces, incluso tras haber practicado
rigurosamente por personas que han sido entrenadas para ensear, para nada producen
un software que funcione. Y eso no debera sorprendernos, porque esto parece ser parte
del conocimiento comn entra programadores en todas partes, a menos de este pas.
Bueno, no es sorpresa, pero s es extrao, porque en cualquier otra especialidad, que
aspira al ttulo de ser una disciplina de la ingeniera, el trmino ingeniera est reservado
para prcticas que funcionan. De hecho, esa es una muy buena definicin corta de
Ingeniera de forma independiente a cualquiera disciplina en particular, la cual es un
conjunto de prcticas y tcnicas que han sido determinadas para trabajar fiablemente
ante una experiencia; en cambio en software tenemos ese conjunto de prcticas que no
funcionan. Y llamamos a eso Ingeniera.

Ahora, esto ha causado mucha discusin, especialmente el ao pasado, sobre si Software

es o no una disciplina de la Ingeniera, y si el desarrollo de software realmente no encaja
en esa metfora no es ingeniera, es ms un arte, o algo ms, como jardinera, o hacer
pelculas, u otras analogas que he escuchado ; y quizs Ingeniera es un trmino
inapropiado para la tarea de construir un software; y no creo que eso sea cierto. S creo
que la ingeniera de software sea una artesana, un arte, y tambin ciencia; pero eso no
significa que tambin pueda ser ingeniera.

Yo digo que el problema es que las personas que definieron el conjunto de disciplinas que
llamamos Ingeniera de Software han malentendido dos cosas muy importantes: la
ingeniera, y el software. Y eso ha resultado en que la Ingeniera de Software sea
realmente una caricatura de una disciplina de ingeniera. Voy a explicar a qu me refiero,
y para ello necesito empezar explicando por qu es una caricatura y cmo es que lleg a
eso. Luego necesito explicar cmo luce una ingeniera real.

Cuntas personas ac se entrenaron como ingenieros y no como desarrolladores de

software? Estoy especialmente interesado en la apreciacin de personas que tienen un
pasado de una clsica ingeniera porque yo no. He tenido que aprender todo esto por mi
cuenta, y pienso te tengo un buen entendimiento de dnde hizo mal la ingeniera de
software. Y luego vamos a ver cmo luce el real desarrollo de software y durante el camino
entenderemos lo que ingeniera de software realmente es.

Entonces, la primera vez que el trmino Ingeniera de Software estaba siendo usado fue
en 1968, en una conferencia en Garmisch, Alemania, organizada por NATO. La primera
conferencia de Ingeniera de Software fue auspiciada por el comit de ciencia de NATO, y
en este tiempo las personas estaban lidiando con lo que llamaban la crisis del software, y
a la vista que proyectos no eran fiables, y podan cometer errores y tenan altos costos de
corrido, y no se saba realmente como manejar esto. As que dijeron sabes? Necesitamos
crecer como una disciplina, como un cambo y empezar a ser una disciplina de la
ingeniera. He sabido sobre esta conferencia por muchos aos. Nunca supe ningn
detalle sobre este tema, y me interes en eso y me puse a ver los documentos y esperaba
encontrar con la locura que comenz ah; y en realidad, no encontr nada as.

Los participantes de esta conferencia fue un grupo de personas bastante inteligentes que
trabajaban en desarrollo de software, haban algunos acadmicos, que tenan muy buenas
cosas que decir. Y, de lejos, los descubrimientos en esta conferencia fueron bastante
razonables y reflejaron una gran sabidura sobre software y su estado en esa poca. De
hecho, lo que les sorprender ms es que si profundizas y lees los documentos, es cuan
conscientes eran para admitir que no saban nada. La conferencia est llena de: Somos
como bebs en el bosque en este nuevo campo, que es diferente a otros anteriores, hay
muchas cosas que no sabemos, pensamos que podra ser as, pero hay bastante
incertidumbre. Y Alan Perles dio una charla al final de la conferencia en la que resumi
las pocas cosas que el grupo lleg a estar de acuerdo, acerca de cmo deba lucir
Software como ingeniera, y la primera de las 3 cosas es que un sistema de software
puede ser mejor diseado si la prueba est entrelazada con el diseo en vez de ser usada
despus del diseo. Eso es razonable. Nmero 2, una simulacin que concuerda con los
requerimientos contiene el control que organiza el diseo del sistema. Ahora, la
terminologa ha evolucionado con el paso del tiempo, as que no parece tener mucho
sentido de manera inmediata, pero si combinamos con la tercera, est claro su
significado. A travs de repeticiones sucesivas de este proceso de prueba entrelazada al
diseo, el modelo se convierte en el software en s en efecto, la prueba y el reemplazo
de simulaciones con mdulos que son ms profundos y detallados van en el modelo de
simulacin controlando el lugar y orden en el cual estas cosas son hechas. Muy
razonable.

Hubo una segunda conferencia organizada por NATO, un ao despus. El tono de esos
documentos es completamente diferente- Durante ese ao, todo sali mal, y dentro de
ese ao, la Ingeniera de Software se convirti en lo que fue por muchos aos, que es un
campo de procesos diseados en la universidad por practicantes. Qu sali mal en un
ao? No lo s. Estaba vivo cuando sucedi, pero no era programador en ese tiempo, as
que no estuve envuelto en este proceso, pero tena una teora de qu sali mal, y puedo
ilustrar esa teora hablando de otro lugar donde varias ideas razonables se convirtieron en
conclusiones irrazonables : el nacimiento del procedimiento cascada. La cascada fue
introducida por Winston Royce en una publicacin de IEEE West Conn en 1970, y la
publicacin se llamaba Gestin del desarrollo de sistemas de software grandes . Royce
pas el resto de su carrera yendo por todos sitios aclarando que fue malinterpretado. Yo
tambin o esa historia, pero cuando fui y le la publicacin, me sorprend bastante al
encontrar que realmente deca la verdad: que l no recomienda el proceso cascada, pero
me di cuenta que la razn por la que las personas pensaron que l recomendaba cascada
es que esta publicacin es una maravilla de mal diseo de informacin. Si quisieras
estudiar cmo escribir una publicacin que conlleva a una impresin exactamente
opuesta a lo que ests intentando explicar, no podras hacer mejor cosa que leer este
paper.

Tomemos una mirada por un minuto y asumamos que eres un gerente de un grupo que
produce un software en 1970, y ests teniendo dificultades en cmo estimar y producir
cosas que funcionan. Y todos estos problemas han estado en la gerencia de software
desde el inicio, y un colega deja esta publicacin en tu escritorio, y ves el ttulo y te
interesas y ves que hay un diagrama en la primera pgina, as que empiezas como que
viendo el diagrama para ver de qu trata todo esto, pasas poco a poco y luego lees. Ese
diagrama dice que se tiene que comenzar con anlisis y luego se pasa a la codificacin.
Eso es un poco simplista, e incluso yo s que es simplista, as que antes de perder mi
tiempo leyendo este paper, voy a ver el resto de diagramas para ver si este tipo tiene un
ceebro en la cabeza o no. Entonces, en la parte superior de la segunda pgina veo esto.
Esta es la primera vez que el clsico diagrama de cascada apareci. Bueno, veamos, se ve
bien: requerimientos del sistema, luego requerimientos del software, para luego ser
movido al anlisis y diseo, codificacin y operaciones de prueba y miren el nombre de la
imagen: Pasos de implementacin para desarrollar un programa de computadora grande
a pedido de un cliente. Puedo entender ese proceso, tiene sentido para m, veo cmo
todas esas cosas trabajan, y tengo esta reunin a la que debo ir, en fin, saqu lo que
necesito de ella.

Miren la siguiente lnea: Creo en este concepto, pero la implementacin descrita

anteriormente es peligrosa e invita a errores. Lo gracioso es que esto explica la figura 3
que est en la siguiente pgina, para ver lo que Winston Royce tiene que decir sobre la
figura 2, tienes que volver a la primera pgina donde se menciona: cualquier plan de
implementacin asegurado solo a estos pasos, sin embargo, est maldito.

Bueno, seamos optimistas, y asumamos que el gerente vuelve de su reunin y recoge el

papel y trata de seguir adelante con l, y voltea ala tercera pgina y ve esto , y a nuestros
ojos se ven ms razonables, podemos ver retroalimentacin de pasos posteriores
influenciando los primeros pasos, y aprendes ms mientras ms te metes en los detalles.
Y Royce Morgan sale y dice que la retroalimentacin es siquiera tan localizada. Las cosas
que se aprenden haciendo pruebas va todo el camino hacia arriba y afectar los
requerimientos del software. Esto comienza a ser bastante desordenado, y difcil de
controlar

Oh no, no s ni qu significa esto Todas esas cajas blancas Solo se ponen peor y
peor, Y el diagrama final, que felizmente es llamado resumen. Creo que volver a este.

Y por unos pocos aos, cascada fue un estndar establecido en la industria y es fcil de
ver que cascada es como la mayora de personas diran que no es la forma correcta. La
mayora de personas se da cuenta que no es la manera de hacer las cosas. Pero hubieron
grupos que religiosamente siguieron con cascada vara ver qu cosas posiblemente
podan funcionar, hasta hace 3 o 4 aos. Y tan reciente como en el final de los 90's, donde
el Departamento de Defensa segua demandando cascada para todos los proyectos que
ellos financiaron.

Ha pasado bastante tiempo para que esta idea que fue presentada como una manera de
hacer las cosas fue obviamente equivocada, para finalmente salir de la conciencia de las
personas, porque a las personas les gusta las soluciones simples, y oyen trminos,
mapean esos trminos y los asocian con lo que creen que entienden, y trabajan con ello
sin pensar cuidadosamente, es simplemente la caracterstica de la gente, y pas con la
cascada y creo que tambin pas con el trmino Ingeniera de Software.

H. L. Mencken dijo Para todo problema complejo, hay una solucin que es simple,
ordenada, e incorrecta. Ciertamente se aplica ah. Ms tarde, la Ingeniera de software,
incluso cuando la gente se emez a entender de las debilidades del modelo cascada y
yendo ms all, la Ingeniera de software comparte una similitud con el modelo cascada,
el cual es el modelo de proceso definido. Esta una descripcin de ese modelo hecha por
el libro de Shwaber y Beedle sobre Scrum: El modelo de control de procesos definidos
requiere que cada pieza del trabajo sea completamente entendida. Un proceso definido
puede ser empezado y permitir que siga hasta completarse, con los mismos resultados
cada vez. La idea de modelo de procesos fue introducida por unos investigadores en
ingeniera qumica, y hay dos ideas sobre el modelo de proceso definido, y hablaremos de
la otra ms adelante. Pero casi toda la Ingeniera de software ha tenido tendencia hacia el

modelo de proceso definido, mientras que cuando los ingenieros qumicos aprendieron
esto, con frecuencia se entretenan al ver que Software haba escogido un modelo tan
salvajemente inapropiado para el tipo de cosas que hacemos. Pero esta inclinacin hacia
el modelo de proceso definido se ha permanecido en la literatura de la ingeniera de
software y dems. Aqu hay un ejemplo hecho por uno de los gigantes de la ingeniera de
software: David Parnas en una publicacin en 1986 describe lo que llama Un Proceso de
Diseo Racional: Estableces y documentas requisitos, diseas y documentas la estructura
del mdulo, diseas y documentas las interfaces del mdulo, diseas y documentas la
jerarqua de usos, diseas y documentas las estructuras internas del mdulo, escribes los
programas, y haces mantenimiento. Ahora, miren lo que dice ms adelante en la misma
publicacin. La figura del diseador de software derivando su diseo en una forma
racional de una declaracin de requerimiento es un poco irrealista. Jams se ha
desarrollado un sistema de esa forma, y probablemente nunca se haga. Y an ah sus
lazos con el modelo de procesos definidos persistieron, y persisten hasta este da
diciendo que la manera en que los sistemas son en realidad desarrollados son irracionales
, porque llama a esto el Proceso racional de diseo.

S, el nombre te lo dice, el nombre de la publicacin es Un proceso racional de diseo y

cmo y por qu aparentar otras cosas. Pero s, ests en lo correcto, el nombre de la
publicacin, su tono; es una verdadera vergenza que no podamos hacer las cosas de ese
modo que podra ser mucho mejores, y por aparentar sacas beneficios de esta forma
irracional indisciplinada en que tenemos que hacer las cosas