Ingenería de Sotware

No hay balas de plata. Esencia y accidentes de la ingenier´ıa de software

Anthony Hall*

University of North Chapel Hill

Manejar constructos complejos es la esencia; tareas accidentales aparecen al representar estos constructos en alg´un lenguaje. El progreso en el pasado ha reducido las tareas accidentales de manera tal

que el progreso ahora depende de resolver la esencia.

De todos los monstruos que llenan las pesadillas de nuestro folklore, ninguno aterroriza m´as que los hombreslobo, porque se transforman de manera inesperada de algo familial a algo horroroso. Para ellos se buscan balas

de plata que puedan destruirlos de forma m´agica.

Los proyectos de software habituales, al menos tal como los ve un administrador no t´ecnico, tiene algunas de

estas caracter´ısticas; generalmente se ve inocente y directo, pero puede transformarse en un monstruo de plazos

no alcanzados, presupuestos sobrepasados, y productos con errores. Entonces se escuchan gritos desesperados

pidiendo una bala de plata–algo que haga disminuir los costos del software tan r´apidamente como bajan los

costos del hardware.

Pero, si miramos con un horizonte de diez a˜nos, no vemos ninguna bala de plata. No existe ni un solo desarrollo,,

ni en tecnolog´ıa ni en administraci´on, que por s´ı mismo prometa ni siquiera un orden de magnitud de mejoras en

la productividad, confiabilidad, o simplicidad. En este art´ıculo, tratar´e de mostrar por qu´e, examinando tanto

la naturaleza de los problemas del software como las propiedades de las balas que han sido propuestas.

Sin embargo, escepticismo no es lo mismo que pesimismo. A pesar de que no vislumbramos grandes saltos

cualitativos–y por cierto creo que esto es consistente con la naturaleza del software–existen en desarrollo muchas

innovaciones promisorias. Un esfuerzo disciplinado y consistente para desarrollar, propagar y explotar estas

innovaciones deber´ıa por cierto traer un orden de magnitud de mejora. No existe un camino real, pero este es el

camino.

El primer paso hacia la cura de las enfermedades fue reemplazar las teor´ıas de los demonios por la teor´ıa de los

g´ermenes. S´olo ese cambio en s´ı, el comienzo de la esperanza, quita toda esperanza de soluciones m´agicas. Esto

ense˜n´o a los trabajadores que el progreso se har´ıa paso a paso, con gran esfuerzo, y que se deber´ıa tener una

disciplina persistente con la limpieza. De la misma forma se encuentra hoy la ingenier´ıa de software.

Es necesario que sea dif´ıcil? – Dificultades esenciales

No s´olo no existe ninguna bala de plata a la vista, sino que la naturaleza del software en s´ı hace improbable

que exista ninguna–ning´un invento har´a a la productividad, confiabilidad, y simplicidad lo que la electr´onica, los

transistores, y la integraci´on a gran escala hicieron por el hardware de los computadores. No podremos entonces

esperar mejorar las ganancias al doble cada dos a˜nos.

*Originalmente publicado en Information Processing 1986, ISBN No. 0444-7077-3, H. J. Kugler, Ed., Elsevia Science Publishers

B.V. (North-holland) IFIP 1986. Traducido por Mar´ıa Cecilia Bastarrica en agosto de 2006.

1

Primeramente, debemos observar que la anomal´ıa no es que el progreso del software es muy lento, sino que

el progreso en hardware es muy r´apido. Ninguna otra tecnolog´ıa desde el inicio de la civilizaci´on ha tenido seis

´ordenes de magnitud de aumentos en sus ganancias en la relaci´on precio-performance en 30 a˜nos. En ninguna otra

tecnolog´ıa se puede escoger tomar las ganancias o bien en mejoras en la performance o en reducir los costos. Estas

ganancias provienen de la transformaci´on de la industria de los computadores de una industria de ensamblaja a

una industria de procesos.

En segundo t´ermino, para apreciar la tasa de progreso que se puede esperar en tecnolog´ıas de software, examinemos sus dificultades. De acuerdo con Arist´oteles, las dividimos en esencia, o dificultades inherentes a la

naturaleza del software, y accidentes, o sea esas dificultades que hoy enfrentamos pero que no son inherentes a

la producci´on de software.

La esencia de una entidad de software es un constructo de conceptos interrelacionados: conjuntos de datos,

relaciones entre estos datos, algoritmos, e invocaciones a funciones. Esta esencia es abstracta considerando que

es la misma independientemente de su representaci´on. Sin embargo, es muy precisa y ricamente detallada.

Creo que la parte m´as dif´ıcil de construir software es su especificaci´on, dise˜no y prueba de estos constructos

conceptuales, no la labor de representarlos y probar la fidelidad de dicha representaci´on. A´un cometemos errores

de sintaxis, con seguridad, pero son detalles comparados con los errores conceptuales en la mayor parte de los

sistemas. Si esto es cierto, construir software siempre ser´a dif´ıcil. Inherentemente no existe ninguna bala de plata.

Consideremos las propiedades inherentes de esta esencia irreductible de los sistemas de software modernos:

complejidad, conformidad, modificabilidad, e invisibilidad.

Complejidad. Las entidades de software son m´as complejas para su tama˜no quiz´as que ning´un otro constructo

humano porque no existen dos partes iguales (al menos sobre el nivel de sentencias). Si existen, hacemos que

las partes similares sean una ´unica rutina, cerrada o abierta. De esta forma, los sistemas de software difieren

profundamente de los computadores, edificios o autom´oviles, donde existen abundantes elementos repetidos.

Los computadores digitales son en s´ı m´as complejos que la mayor parte de las cosas que las personas construyen:

tienen un enorme n´umero de posibles estados. Esto hace que concebir, describir y probarlas sea tan dif´ıcil. Los

sistemas de software tienen ´ordenes de magnitud m´as estados que los computadores.

De forma similar, el escalamiento de un software no es meramente la repetici´on de los mismos elementos en

tama˜nos m´as grandes; es tambi´en necesariamente un escalamiento en el n´umero de elementos diferentes. En la

mayor parte de los casos, los elementos interactuan entre s´ı de una forma no lineal, y la complejidad del todo

aumenta m´as que linealmente.

La complejidad del software es una propiedad esencial, no accidental. Por lo tanto, las descripciones de un

software que abstraen su complejidad, tambi´en suelen quitar su esencia. Durante tres siglos, las matem´aticas y

la f´ısica han hecho

...