nica del Software La Crisis Cro

Resumen Traducci on del art culo Softwares Chronic Crisis escrito por W. Wayt Gibbs, publicado por Scientic America en Septiembre de 1994

El nuevo aeropuerto internacional de Denver iba a ser el orgullo de las Rocallosas, una maravilla de la ingenier a moderna. Dos veces el tama no de Manhattan, 10 veces el ancho de Heathrow, el aeropuerto es lo sucientemente grande como para que aterricen tres Jets simult aneamente con mal clima. Mas impresionante a un que su circunferencia es el sistema de manejo subterr aneo de equipaje. Como si fuese una mina de carbon inteligente, 4000 telecars viajan y entregan el equipaje en las distintas puertas para 20 l neas a ereas diferentes. Un sistema nervioso central de unas 100 computadoras conectadas entre si y con 5000 ojos el ectricos, 400 receptores de radio y 56 escaners de c odigos de barra orquesta la seguridad y arribo en t ermino de cada maleta. Al menos ese es el plan. Por nueve meses, este Gulliver ha sido mantenido cautivo por los Liliputianos - errores en el software que controla en sistema automatizado de equipaje. Planeado para su lanzamiento el Halloween pasado, la gran apertura del aeropuerto fue pospuesta para diciembre para darle tiempo a Sistemas Automatizados BAE desechar los bugs de su sistema de 193 millones. Diciembre se alargo a Marzo. Marzo se estir o hasta Mayo. En Junio los planeadores de aeropuerto con su presupuesto desangrando tinta roja a un valor de 1.1 millones por d a en intereses y costos operativos ya que no pod an predecir cuando el sistema se iba a estabilizar lo suciente para que abrir el aeropuerto. Para los desarrolladores veteranos de software es notable solo por su visibilidad. Los estudios han demostrado que por cada 6 nuevos sistemas de software a gran escala que son puestos en operaci on, 2 son cancelados. El promedio de un proyecto de desarrollo de software sobrepasan su planicaci on por una mitad, los proyectos m as grandes generalmente empeoran y tres cuartos de todos los sistemas grandes son fallas operativas que o no funcionan como se previo o directamente no se usan. El arte de la programaci on ha tomado 50 a nos de continuo renamiento para llegar a este estado. Para cuando llego a los 25 a nos las dicultades para construir un gran sistema de software eran tan grandes que en el oto no de 1968 el comit e de ciencia de la OTAN contrat o algo as como 50 programadores, cient cos de las computadoras y capitales industriales para idear una salida a lo que se hab a conocido como la crisis del software. Aunque los expertos no pod an concebir un mapa para guiar a la industria a un terreno m as rme lo que si hicieron fue introducir un nombre para esa meta lejana: ingenier a del software, ahora denida formalmente como la aplicaci on de un aproximamiento sistem atico, disciplinado y cuanticable al desarrollo, operaci on y mantenimiento del software.

Un cuarto de siglo despu es la ingenier a del software permanece como una aspiraci on. La basta mayor a del c odigo de computadoras es todav a hecha a mano desde sistema de programaci on b asicos por artesanos que usan t ecnicas propias que ni miden y que no capaces de repetir consistentemente. Era como la fabricaci on del mosquete antes de Eli Whitney, dice Brad Cox, un profesor de la universidad George Mason. Antes de la revoluci on industrial hubo un aproximamiento no especializado a la manufactura de bienes que inclu a muy poca intercambiabilidad y un m aximo de artesan a. Si alguna vez vamos a destruir a la crisis de software tendremos que detener este aproximamiento preindustrial en el que cada programador construye todo desde la nada. El panorama no es enteramente negro. La intuici on esta cediendo lentamente al an alisis al tiempo en el que los programadores comiencen a usar medidas cuantitativas de la calidad del software que producen para mejorar la forma en que lo producen. Los fundamentos matem aticos de la programaci on solidican al tiempo que los investigadores trabajan en formas de expresar los dise nos de programas en formas algebraicas que hagan m as f acil el evitar los errores graves. Los cient cos acad emicos de computaci on est an comenzando a direccionar su falla a la producci on de un cuerpo s olido de profesionales del software. Tal vez m as importante, muchos en la industria est an focalizando su atenci on a la invenci on de la tecnolog a y las estructuras de mercadeo necesarias para sostener las partes del software que sean intercambiables y reusables. Desafortunadamente, la industria no aplica uniformemente a eso que es mejor conocido como la mejor pr actica, se lamenta Larry Druel, director del instituto de ingenier a en software de la universidad Carnegie Mellon. De hecho, una innovaci on t picamente requiere 18 a nos para hacerce camino en el repertorio de las t ecnicas de programaci on est andar. Combinando sus esfuerzos lo acad emico, lo industrial y lo gubernamental pueden ser capaces de llevar el desarrollo de software al nivel de una disciplina de ingenier a industrial en una d ecada. Si lo hacen m as r apido, la llegada sociedad a la era inform atica sera como lo mejor impredecible.

Arenas movedizas
Veremos cambios masivos (en el uso de la computadoras) dentro de los a nos venideros, causando que la revoluci on de la computadora personal palidezca en comparaci on, concluyeron 22 l deres en el desarrollo de software de los laboratorios de investigaci on, lo acad emico y lo industrial el pasado abril. Los expertos se congregaron en el Hetsor Park una corporaci on cercana a Londres, para conmemorar la conferencia de la OTAN y analizar el futuro direccionamiento del software. En 1968 sab amos lo que quer amos construir y no pudimos, reexiona Cli Jones, profesor de la universidad de Manchester. Hoy estamos parados en arenas movedizas. Los fundamentos de las pr acticas de programaci on tradicionales est an erosion andose lentamente, al mismo tiempo que los ingenieros de hardware desarrollan m aquinas m as baratas, r apidas y peque nas. Muchas suposici on fundamentales que los programadores hacen por ejemplo, su aceptaci on de que todo lo que produzcan tendr a defectos debe cambiar en respuesta. Ten es que comprender el software de una porque despu es no tendr as la posibilidad de actualizarlo, dice Mary Shaw, profesora de la Carnegie Melon. La cantidad de c odigo en muchos productos se esta doblando cada dos a nos, apunta 2

Remi Bourgonjon, director en tecnolog a en software del laboratorio de investigaci on Philips en Eindhoven. Reporta que los televisores pueden tener 500 KB de software; una afeitadora el ectrica 2KB. Los poderosos trenes en los nuevos autos General Motors ejecutan 30.000 l neas de c odigo de computadora. Entender el software desde la primera vez es dif cil hasta para aquellos que lo in1 tentan. El DoD lleva un riguroso y caro est andares de testeo para asegurar que el software en el cual la misi on depende. Esos est andares fueron usados para certicar a Clementina, un sat elite que la DoD y que la NASA dirigieron a la orbita lunar la pasada primavera. Una gran parte de la misi on Clementina fue probar el software de objetivos que podr a ser usado en un sistema de defensa con misiles espaciales. Pero cuando el sat elite fue puesto en orbita e instruido para jar la luna un bug en el programa causo que la nave espacial disparar a su turbina de maniobraje durante 11 minutos. Sin combustible y girando alocadamente, el sat elite no pudo encontrarse con el asteroide Geographos. Los errores en los sistemas de tiempo real tales como el Clementina son muy dif ciles de descubrir porque, como ese ruido sospechoso en el motor de tu auto, ocurren u nicamente cuando se dan las condiciones (ver Los riesgos del software por Bevs Littlewood y Lorenzo Strigini; cient co americano, noviembre 1992). No est a claro que los m etodos que son generalmente usados para producir software de seguridad, como el de los reactores nucleares o el de los autos evolucionen adecuadamente para equipararse a nuestras futuras expectativas, advirti o Gilles Kahn, cient co director del laboratorio de investigaci on INRIA de Francia, en el encuentro en el Hetsor Park. Por el contrario, con respecto a los sistemas de tiempo real creo que estamos en un punto de quiebre. El software est a entrando tambi en bajo acentos tect onicos impuestos por las inexorablemente crecientes demandas para los sistemas distribuidos: programas que ejecutan cooperativamente en varias computadoras en red. El mercado est a volcando capital en los sistemas de informaci on distribuidos que se espera se transformen en armas estrat egicas. La inconstancia del desarrollo de software puede transformar estos proyectos en una ruleta rusa. Muchas compa n as pretenden llegar a metas que parecen lo sucientemente simples. Algunas tratan de re-encarnar el obsoleto software basado en mainframes en forma distribuida. Otras quieren enchufar sus sistemas existentes unos o otros, o entre nuevos sistemas con los cuales puedan compartir datos y una interface de usuario m as amigable. En el lingo t ecnico, el conectar los programas en est a forma es usualmente llamado integraci on de sistemas. Pero Brian Randell, cient co de la computaci on de la universidad de Newcastle, sugiere que hay una mejor palabra que integraci on, del viejo lunfardo R.A.F.: graunch que signica, hacer caber algo mediante el uso de la fuerza excesiva. Es un negocio arriesgado, ya que aunque el software parezca una cosa maleable, muchos programas son en realidad intrincados plexuses de l ogica a trav es de los cuales los datos del tipo correcto pueden pasar. Como los mosquetes hechos a mano, muchos programas pueden desempe nar funciones similares y hasta ser u nicos en dise no. Eso hace que el software sea dif cil de modicar y reparar. Tambi en signica que los intentos de apachurrar los sistemas regularmente terminan mal. En 1987, por ejemplo, el departamento de veh culos a motor de California decidi o hacer la vida de sus usuarios m as f acil al incluir los sistemas de conductores y registros vehiculares del estado una tarea aparentemente f acil. Habr a esperado inaugurar pues1

Departamento de defensa

tos de renovaci on el a no pasado. En vez la D.M.V. vio que el costo proyectado explotaba a 6.5 veces el precio esperado y la fecha de entrega se movi o a 1998. En diciembre la agencia tir o la toalla y abandon o la inversi on de 44.3 millones. A veces nada falla como el exito. En los 70 American Airlines construy o SABRE, un sistema virtual de reservaci on de vuelos valuado 2 billones que se convirti o en parte de la infraestructura de la industria de viajes. SABRE fue un brillante ejemplo de un sistema de informaci on estrat egico porque llevo a America Airlines a ser la aerolinea m as grande del mundo, recuerda Bill Curtis, consultor del instituto de ingenier a en software. El intento de esgrimir el software tan efectivamente en esta d ecada, American Airlines trato de apachurrar su tecnolog a de reserva de vuelos con los sistemas de reserva de hoteles y autos de Marriott, Hilton y Budget. En 1992 el proyecto colapso en una litigaci on. Fue un error abismal, dice Curtis. American despilfarro 165 millones en ese sistema. La aerolinea no est a sufriendo sola. En junio el grupo de consultoras de IBM lanz o los resultados de una encuesta a 24 compa n as l deres que hab an desarrollado grandes sistemas distribuidos. 55 % de los proyectos costaron m as de lo esperado, 68 % sobrepasaron el tiempo estimado y 88 % tuvo que ser sustancialmente redise nado. La encuesta no reporto una estad stica cr tica, cuan conablemente ejecutaron los programas completos. Usualmente los sistemas se caen porque fallan al esperar lo inesperado. Las redes amplican este problema. Los sistemas distribuidos pueden consistir de un gran conjunto de puntos de falla interconectados, muchos de los cuales no han sido identicados de antemano, explica Randell. La complejidad y la fragilidad de estos sistemas imponen un desaf o mayor. El desaf o de la complejidad no solo es grande sino que tambi en est a creciendo. El golpe que las computadoras entregan por d olar se esta meses o algo as . Un resultado es una orden de magnitud crece en el tama no del sistema por cada d ecada, para algunas industrias, cada media d ecada, dice Curtis. Para equipararse con tal demanda los programadores tendr an que cambiar la forma en que trabajan. No podes construir rascacielos usando carpinteros, dice Curtis.

Mayday, Mayday
Cuando un sistema se vuelve tan complejo que ni los gerentes pueden comprenderlo completamente, los procesos de desarrollo tradicional colapsan. La Administraci on Federal de Aviaci on (AFA) ha enfrentado este problema a trav es de el intento de reemplazar el obsoleto sistema de control de tr aco a ereo (ver Again Airways, por Gary Stix; Scientic American, Mayo). El reemplazo, llamado Sistema de Automatizaci on Avanzada (SAA), combina todos los desaf os de la computaci on en los 90. Un programa con un tama no de m as de un millon de l neas es distribuido a trav es de cientos de computadoras y embebido en hardware nuevo y sosticado, en donde muchas de las cuales deben responder a impredecibles eventos de tiempo real a contrareloj. Hasta una peque na falla es una potencial amenaza a la seguridad p ublica. Para realizar su sue no tecnol ogico la AFA eligi o a la Compa n a de Sistemas Federales de IBM, un bien ponderado l der en el desarrollo de software que ha sido adquirido por Loral. Los gerentes de la AFA esperaban (pero no demandaban) que IBM usara las t ecnicas del estado de arte para estimar el costo y la duraci on del proyecto. Asum an 4

que IBM iba a colmar las expectativas y a desarrollar un sistema que detectar a los errores en forma temprana, cuando pueden ser arreglados en hora en vez de d as. Y la AFA esperaba pagar $500 por l nea de c odigo, 5 veces el promedio del costo de los procesos de desarrollo bien gerenciados. De acuerdo a un reporte basado en el proyecto SAA lanzado en mayo por el centro de an alisis naval, el costo de estimaci on y el proceso de desarrollo de IBM us o datos no apropiados, fue llevado a cabo inconsistentemente e ignorado por los gerentes de proyecto. Como resultado la AFA ha estado pagando entre $700 y $900 por l nea por el software SAA. Una raz on para este precio exorbitante es que en promedio, cada l nea de c odigo desarrollado necesita ser re-escrita una vez, revela un reporte un reporte interno de la AFA. Alarmada por los costos que se van a las nubes y las pruebas que muestran un sistema semi-completo no conable, el administrador de la AFA David A. Hinson decidi o en junio cancelar dos de las cuatro parte mayoritarias de la SAA y aminorar un tercero. Los 144 millones gastados en estos programas fallidos no es sino una ca da cercana a los 1.4 billones invertidos en la cuarta pieza central: el nuevo software de estaci on de trabajo para controladores de tr aco a ereo. Ese proyecto tambi en est a decayendo. Ejecut andose 5 a nos m as tarde y con m as de 1 bill on por sobre el presupuesto, el programa infectado con bichos (bugs) esta siendo tratado expertos de software del Carnegie Melon y del MIT para determinar si puede ser salvado o debe ser ya cancelado. Los revedores tienen planeado hacer su reporte en septiembre. El desastre se volver a una parte com un y disruptiva del desarrollo del software a menos que la programaci on tome m as de las caracter sticas de una disciplina en ingenier a arraigado rmemente a las ciencias y a las matem aticas. Afortunadamente esa tendencia ha comenzado. Desde la d ecada pasada, los l deres de la industria han hecho un progreso signicativo al entendimiento de como medir, consistentemente y cuantitativamente, la densidad de errores en sus productos y la productividad de sus programadores. Los investigadores ya est an dando el paso siguiente: encontrar soluciones pr acticas y repetibles para esos problemas.

Procedimientos del proceso

En 1991, por ejemplo, el instituto de ingenier a en software fundado por la milicia revel o su Modelo de Capacidad Madurativa (MCM). Provee un visi on de excelencia de la ingenier a del software y el gerenciamiento, acota David Zubrow, que conduce un proyecto de m etodos emp ricos en el instituto. El MCM por n ha persuadido a muchos programadores de concentrarse en el proceso por el cual producen el software, un pre-requisito para cualquier disciplina de ingenier a industrial. Usando entrevistas, cuestionarios y el MCM como benchmark los evaluadores pueden graduar la habilidad de un equipo de programaci on para crear un software predeciblemente que se adecue a las necesidades de los usuarios. El MCM usa una escala nivel 5, variando desde el caos en el nivel 1 hasta el dechado del buen gerenciamiento en el nivel 5. Hasta la fecha 261 organizaciones han sido testeadas. La vasta mayor a cerca del 75 % est an todav a en el nivel, reporta Curtis. No tiene un proceso formal, mediciones de lo que hacen ni un forma de saber cuando est an el camino equivocado o fuera del camino directamente (el centro para el an alisis naval 5

concluy o que el proyecto ASA en Sistemas Federales IBM parece estar por debajo del 1 en el ranking). El 24 % de los proyectos restantes est an en el nivel 2 o 3. Solo 2 grupos de elite han llegado a lo m as alto del ranking MCM, el nivel 5. El equipo de programaci on indio de Motorola en Bangalor se lleva un t tulo. El proyecto de enlace espacial de Loral (anteriormente IBM) se lleva el otro. El equipo de Loral ha aprendido a controlar los bugs tan bien que puede predecir conablemente cuantos habr an en el nuevo software. Esa es una haza na destacable, considerando que el 90 % de los programadores americanos ni siquiera llevan una cuenta de los errores que encuentran, de acuerdo a Capers Jones, vocero de la investigaci on de la productividad del software, de esos que si (que llevan la cuenta) unos pocos identican m as de un tercio de los defectos que hay. Tom Peterson, cabeza de proyecto de Loral le atribuye su exito a una cultura que trata de arreglar no solo el bug sino tambi en la falla en el proceso de testeo que permiti o que este se metiera. A un as , alguno bugs escapan a la detecci on. El primer lanzamiento del enlace espacial en 1961 fue abortado y retrasado por dos d as porque una falla impidi o que las 5 computadoras a bordo se sincronizar an apropiadamente. Otra falla, esta en el programa de aproximaci on del enlace, puso en peligro la misi on de rescate del sat elite Intelsat 6 en 1992. Aunque el MCM nos es panacea, su salida del instituto de ingenier a en software ha persuadido a un n umero de compa n as l deres de software que el control de calidad cuantitativa puede traer sus benecios a la larga. la divisi on de equipamiento Raytheon, por ejemplo, form o una iniciativa en ingenier a del software en 1988, despu es de reprobar el examen MCM. La divisi on comenz o a invertir 1 millon por a no para renar la inspecci on rigurosa y la l nea de testeo y entrenar a sus 400 programadores para que la sigan. En 3 a nos la divisi on hab a saltado 2 niveles. Para el pasado junio, muchos proyectos incluyendo los sistemas de radar complejos y los de control de tr aco a ereo estaban terminando antes de lo previsto y por debajo del presupuesto. La productividad se ha m as que doblado. Un an alisis de los costos de trabajo que fueron evitados revel o un ahorro de $7.80 por cada d olar invertido en la iniciativa. Impresionada por tal exito, la fuerza a erea americana ha mandado que todos sus desarrolladores de software deban alcanzar el nivel 3 del MCM para 1998. La NASA est a considerando un pol tica similar.

Recreaciones matem aticas

Hasta los mejores dise nos pueden salir mal, y habr an errores en tanto los humanos creen los programas. Los bugs que son descubiertos en forma temprana raramente amenazan el presupuesto y la fecha de entrega de un proyecto. Los errores devastadores son aquellos del dise no inicial que pasan desapercibidos hasta el producto nal. Los productores de software para el mercado masivo, porque no tienen un solo usuario para complacer, pueden aproximarse de una forma tard a y bruta al remoci on de bugs: lanzan el producto fallado como una versi on beta y dejan que las hordas de usuarios descubran las fallas. De acuerdo a Charles Simonui, arquitecto en jefe de Microsoft la nueva versi on del sistema operativo Windows ser a betatesteado por 20.000 voluntarios. Eso es remarcablemente efectivo, caro y usualmente no pr actico. Los investigadores est an formulando varias estrategias para atacar a los bugs en forma temprana o para directamente evitar introducirlos. Una idea es reconocer que un 6

problema que se supone que un sistema resuelva siempre cambia al mismo tiempo que el sistema est a siendo construido. Los planeadores del aeropuerto de Denver cargaron BAE con 20 millones en cambios al dise no de su sistema de equipaje mucho tiempo despu es que la construcci on hubiese empezado. IBM ha sido similarmente confundida por la decisi on de los gerentes de AFA. Ambas compa n as ingenuamente asumieron que una vez que su dise no fuese aprobado, tendr an rienda libre para construirlo. Alguno desarrolladores est an al n desprendi endose de esa ilusi on y repensando el software como algo que debe ser desarrollado en vez de construido. Como primer paso los programadores est an juntando prototipos r apidos salidos de componentes est an de interfase gr aca. Como el modelo a escala de un arquitecto, el prototipo de un sistema puede ayudar a aclarar los malos entendidos entre el usuario y el desarrollador antes que el fundamento l ogico sea llevado a cabo. Ya que hacen m mica solo del comportamiento de los sistemas, los prototipos son de poca ayuda para identicar las inconsistencias l ogicas en el dise no de un sistema. La basta mayor a de un software a gran escala son los errores de omisi on, nota Baszlo Belady, director de los laboratorios de investigaci on el ectrica de Mitsubishi. Aparte los modelos no hacen m as f acil el detectar bugs una vez que el sistema es codicado. Cuando positivamente debe ser correcto, los ingenieros conf an en el an alisis matem atico para predecir como sus dise nos se comportar an en el mundo real. Desafortunadamente, la matem atica que describe los sistemas f sicos no se aplica dentro del universo binario de un programa computaci on; la matem atica discreta, un campo mucho menos maduro, manda aqu . Pero usar las todav a limitadas herramientas de la teor a de conjuntos y c alculo de predicado, los cient cos de las ciencias de la computaci on han ideado formas de traducir las especicaciones y los programas al lenguaje de las matem aticas, donde pueden ser analizados con herramientas te oricas conocidas como m etodos formales. Praxis recientemente us o m etodos formales en un proyecto de control de tr aco a ereo de la autoridad de aviaci on civil de Gran Breta na. Aunque el programa de Praxis fue mucho m as peque no que el de la AFA, los dos compart an un problema de dise no similar: necesitan mantener los sistemas redundantes sicronizados de modo que si uno falla, el otro pueda hacerse cargo instant aneamente. La parte dif cil fue garantizar que los mensajes sean entregados en una orden apropiada en las redes gemelas, recuerda Anthony Hall, consultor principal de Praxis. Aqu tratamos de llevar a cabo pruebas de nuestro dise no y fallaron, porque el dise no era err oneo. El benecio de encontrar los errores en forma temprana es enorme. El sistema fue terminado a tiempo y puesto en operaci on el pasado octubre. Praxis uso anotaciones formales solo en las partes m as cr ticas de su software, pero otra rmas de software han empleado el rigor matem atico a trav es del desarrollo entero de un sistema. Gek Alsthom de Paris est a usando un m etodo formal llamado B y gasta 350 millones para actualizar el software de cambio y control de velocidad que gu a los 6.000 trenes el ectricos del sistema ferroviario nacional de Francia. Aumentando la velocidad de los trenes y disminuyendo la distancia entre ellos, el sistema puede ahorrar millones de d olares que de otra forma la compa n a necesitar a gastar en nuevas l neas. La seguridad era una preocupaci on obvia: as que los desarrolladores de Gek escribieron un dise no entero y un programa nal en anotaci on formal y luego usaron las matem aticas para probar su consistencia. Las pruebas funcionales son todav a necesarias sin embargo, por dos razones, dice Fernando Mejia, gerente de la secci on de

desarrollo formal de Gek. Primero, los programadores cometen errores en las pruebas en forma ocasional. Segundo, los m etodos formales pueden garantizar solo que el software se encuentre con su especicaci on, y no que pueda manejar las sorpresas del mundo real. Los m etodos formales tambi en tiene otro problema. Leer p aginas de formulas algebraicas es a un m as in util que revisar el c odigo de computadoras. Odissey es s olo una de muchas compa n as que est an tratando de automatizar los m etodos formales para hacerlos menos onerosos para los programadores. Gek est a colaborando con Digilog en Francia para comercializar las herramientas de programaci on para el m etodo B. La versi on beta est a siendo testeado por 7 compa n as e instituciones. Del otro lado del atl antico, los m etodos formales en si todav a no se pusieron de moda. Hay excepciones, entre el creciente c rculo de compa n as que experimentan con la enfoque del cuarto limpio. Este proceso de clean room intenta unir las anotaciones formales, las pruebas de correctitud y el control de calidad estad stico con un enfoque evolutivo del desarrollo del software. Como la t ecnica de manufactura del microchip de la cual toma su nombre, el desarrollo de clean room trata de usar t ecnicas de ingenier a rigurosas para fabricar productos consistentemente que se ejecuten perfectamente desde la primera vez. Los programadores desarrollan sistemas de una funci on por vez y certican la calidad de casa unidad antes de integrarlas a la arquitectura. El desarrollo de software requiere una nueva aproximaci on al testeo. Tradicionalmente, los desarrolladores prueban un programa al ejecutarlo en la forma que debe se usado, que usualmente tiene poca similitud a las condiciones del mundo real. En el proceso clean room los programadores tratan de asignar una probabilidad a cada camino de ejecuci on correcto e incorrecto que los usuarios puedan tomar. Despu es derivan los casos de prueba de datos estad sticos, de modo que los caminos m as comunes sean testeados m as exhaustivamente. Luego el programa se ejecuta a trav es de cada caso y cronometra cuanto tarda en fallar. Esos tiempos son entonces retroalimentados a un modelo que calcula cuan conable es un programa. Hay resultados alentadores. Ericson Telecom uso los procesos clean room en un proyecto de 70 programadores para fabricar un sistema operativo. Los errores fueron reducidos a 1 en 1.000 l neas de c odigo; el porcentaje de la industria es 25 veces m as alto aproximadamente. Tal vez lo m as importante, es que la compa n a encontr o que la productividad de desarrollo hab a aumentado en un 70 % y la probabilidad se hab a duplicado.

Sin bala de plata

Desde 1960 los desarrolladores han hecho docena de innovaciones tecnol ogicas para incrementar la productividad muchas han sido hasta proyectos de demostraci on para probar la veracidad de sus alardes. Los defensores de los an alisis y la programaci on orientado a objetos claman que su enfoque representa un cambio de paradigma que va a acarrear una mejora de 14 a 1 en la productividad, junto con una calidad m as alta y un mantenimiento m as f acil, todo a un costo reducido. Hay razones para ser esc epticos, en los 70 la programaci on estructurada fue vendida como un cambio de paradigma, recuerda Curtis. As tambi en fue la herramienta CASE (computer-assisted software engineering), y as lo fueron los lenguajes de cuarta y quinta 8

generaci on. Hemos escuchado grandes promesas para la tecnolog a, muchas de las cuales no fueron cumplidas. Nuestros principales logros fueron importados de est a cultura extranjera de la ingenier a en hardware m aquinas m as r apidas y m as memoria, dice Cox. Fisher concuerda: ajustado por la inaci on el valor agregado por trabajador en la industria ha sido de 10.000 por dos d ecadas, acierta no estamos viendo ninguna mejora. Han habido mejoras, pero todos usan distintas deniciones para productividad, replica Richard Demilo. Un estudio reciente publicado por Capers Jones pero basado necesariamente en datos hist oricos dice que los programadores estadounidenses usaron dos veces la cantidad de c odigo hoy as como en 1970. El meollo del asunto es que nadie sabe cuan productivos son los desarrolladores de software, por tres razones. Primero, menos del 10 % de las compa n as americanos miden consistentemente la productividad de sus programadores. Segundo, la industria todav a tiene que asentar una unidad de medida est andar. Muchos reportes expresan la productividad en t erminos de l neas de c odigo por trabajador por mes. Pero los programas son escritos en una amplia variedad de lenguajes y var an enormemente en la complejidad de su operaci on. Comparar el n umero de l neas escritas por un programador japon es usando C con el n umero producido por un americano usando Ada, es como comparar sus salarios sin convertir los yenes a d olares. Tercero, Fisher dice podes caminar dentro de una t pica compa n a y encontrar a dos tipos compartiendo una ocina, ganando el mismo sueldo y teniendo esencialmente las mismas credenciales y a un as encontrar un factor de 100 diferencias en el n umero de instrucciones por d a que producen. Tales diferencias individuales tienden a empantanar los peque nos efectos de la tecnolog a o las mejoras de proceso. Despu es de 25 a nos de decepci on con las innovaciones aparentes que resultaron ser irreproducibles, muchos investigadores coinciden en que la ciencia de la computaci on necesita una rama experimental para separar los resultados generales de los accidentales. La gente est a desarrollando todo tipo de cosas y es realmente alarmante lo mala que algunas son, dice Victor Basili, profesor de la universidad de Maryland. Mary Shaw destaca que los campos de ingenier a maduros codican soluciones probadas el libros para que hasta los novatos puedan manejar los dise nos de rutina consistentemente, liberando a los practicantes m as talentosos para los proyectos de avanzada. Ning un libro de este tipo existe para el software, as que los errores se repiten proyecto tras proyecto y a no tras a no. Demilo sugiere que el gobierno deber a tener un rol m as activo la fundaci on nacional de ciencia deber a estar interesada en la investigaci on que apunte a vericar los resultados experimentales que han sido obtenidos por otras personas. Si la ingenier a de software va a ser una ciencia experimental, eso implica que necesita ciencia de laboratorio. D onde cuernos est an los laboratorios?, pregunta Basili. Ya que los intentos de llevar la tecnolog a prometedoras a proporciones industriales usualmente fallan, los peque nos laboratorios son de utilidad limitada. Necesitamos lugares donde podamos juntar datos y probar cosas. La u nica forma de hacerlo es tener una organizaci on de desarrollo de software como compa nera. Han habido pocos acompa namientos. Tal vez el m as exitoso es el laboratorio de ingenier a en software, un consorcio del centro de vuelo espacial Goddard de la NASA y la universidad de Maryland. Basili ayudo a fundar el laboratorio en 1976. Desde entonces los estudiantes graduados y no graduados han colaborado en casi 100 proyectos, muchos

de los cuales ten an que ver con la construcci on de software de apoyo terrestre para los sat elites.

S olo agregue agua

Los fabricantes de mosquetes no se volvieron m as productivos hasta que Eli Whitney descubri o como manufacturar partes intercambiable que pudieran ser ensambladas por cualquier obrero calicado. De la misma forma, las partes del software pueden ser estandarizadas apropiadamente, y reusadas a distintas escalas. Los programadores han usado por d ecadas librer as de subrutinas para evitar reescribir el mismo c odigo una y otra vez. Pero estos componentes dejan de funcionar cuando se los mueve a un lenguaje de programaci on distinto, a una plataforma distinta o a un entorno operativo distinto. Lo tr agico es que el hardware se vuelve obsoleto, una expresi on excelente de un algoritmo de ordenamiento escrito en los 60 tiene que ser reescrito observa Simonyi de Microsoft. Fisher ve la tragedia como de otro tipo. El precio real que pagamos es que, como especialista en cualquier tecnolog a de software, no podes capturar tu capacidad especial en un producto. Si no podes hacer eso, b asicamente no podes ser un especialista. No es algunos no hayan tratado. Antes de mudarse a NIST al a no pasado, Fisher fund oy sirvi o como CEO de Sistemas Incrementales. Eramos realmente los mejores del mundo en tres de las tecnolog as de componentes que van en los compiladores, pero no eramos tan bueno en otras siete m as o menos declara. Pero descubrimos que no hab a una forma pr actica de vender los componentes de los compiladores, ten amos que vender compiladores enteros. As que ahora el est a haciendo algo al respecto. En abril, NIST anunci o que estaba creando un programa de tecnolog a avanzada para ayudar a la creaci on de un mercado para software basado en componentes. Como cabeza del programa, Fisher estar a distribuyendo 150 millones de d olares en subsidios para investigaci on a las compa n as deseosas de atacar los obst aculos t ecnicos que com unmente hacen que las partes del software sean poco pr acticas. El desaf o m as grande es encontrar las formas de cortar inherentemente unen programas a computadoras espec cas y a otros programas. Se est an investigando distintos enfoques prometedores, incluyendo un lenguaje com un que se puede usar para describir las partes del software, programas que reforman componentes para que se compatibilicen en cualquier entorno, y componentes que tengan varios rasgos opcionales que se puedan activados o desactivados. Fisher favorece la idea de que los componentes sean sintetizados sobre la marcha. Los programadores b asicamente capturar an como hacerlo en vez de hacerlo, creando una receta que cualquier computadora pueda entender. Entonces, cuando quieras ensamblar dos componentes, tomar as esta receta y derivar as versiones compatibles al agregarle elementos adicionales a sus interfases. Entonces todo estar a automatizado explica. A un con un incentivo de 150 millones y las presiones del mercado forzando a las compa n as a encontrar formas m as baratas de producir software, una revoluci on industrial en el software no es inminente. S olo esperamos ver ejemplos aislados de estas tecnolog as dentro en cinco a siete a nos y tal vez ni siquiera tengamos exito t ecnicamente declara Fisher. A un cuando la tecnolog a est e lista, los componentes van a encontrar pocos compradores a menos que sean de costo efectivo. Los costos de las partes del soft10

ware van a depender menos de la tecnolog a que del tipo de mercado que los produce y los consume. Brad Cox, como Fisher, una vez gerenci o una compa n a de componentes de software y le resulto muy dif cil continuar. El cree haber descubierto el problema y su soluci on. La rma de Cox trat o de vender partes de programas de bajo nivel an alogas a los chips de computadoras. Lo que es diferente entre los circuitos integrados de software y los circuitos de silicio es que los circuitos de silicio est an hechos de atomos, entonces obedecen a la conservaci on de masa, por lo tanto la gente sabe como comprarlos y venderlos dice. Pero este proceso de intercambio que est a en la ra z de todo comercio no funciona para cosas que pueden ser copiadas en nanosegundos. Cuando Cox trat o de vender las partes que sus programadores hab an creado, vi o que el precio que el mercado soportar a era mucho m as bajo de lo esperado, por lo que a el le costar a recuperar los costos de desarrollo. Eran dos las razones. Primero, reformar el componente a mano tomaba mucho tiempo; NIST espera derribar esta barrera con su programa de tecnolog a avanzada. El otro factor no era tan t ecnico sino m as cultural: los compradores quieren pagar por un componente una sola vez y hacer copias gratis. La industria de la m usica ha tenido este mismo problema por casi un siglo, observa Cox. Sol an vender bienes tangibles como rollos de piano y m usica en hojas, despu es vino la radio y la televisi on y lo mejor o. Las compa n as musicales se adaptaron a transmitir por medio de la creaci on de agencias que colectar an las regal as cada vez que una canci on fuera puesta al aire y reembolsarles el dinero a los artistas y productores. Cox sugiere, de forma similar cobrar a los usuarios cada vez que usen un componente de software. De hecho, ese modelo podr a funcionar mejor para el software que para la m usica, gracias a la ventaja de infraestructura que las computadoras y la comunicaciones nos dan. Los grabadores no tienen links a una red de alta velocidad para reportar el uso, pero nuestras computadoras s . O lo tendr an al menos. Adelant andose al tiempo en que las computadoras est en casi todas conectadas, Cox visiona la distribuci on de software de todo tipo v a redes que unan a los productores de componentes, a los usuarios nales y a las instituciones nancieras. Es an aloga a una operaci on con tarjeta de cr edito, pero con tent aculos que lleguen a las PCs. Aunque pueda sonar alarmante para algunos, Cox argumenta que la internet se parece m as a un basurero que a un mercado de granjeros. Necesitamos una infraestructura nacional que pueda soportar la distribuci on de todo, desde la receta de las galletitas de la abuela a la ventana de los gerentes de Apple, a los libros electr onicos de Addison-Wesley. Reconociendo la enormidad del cambio cultural que est a proponiendo, Cox espera presionar su causa en los a nos venideros a trav es de la coalici on por los mercados electr onicos, la cual el preside. La combinaci on del control de proceso industrial, las herramientas tecnol ogica avanzadas y las partes intercambiables promete transformar no s olo como se realiza la programaci on sino quien la realiza. Muchos de los expertos que convergieron en el Hedsor Park concordaron con Belady en que en el futuro, los profesionales en la mayor a de los campos usar an la programaci on como una herramienta, pero no se llamar an a s mismos programadores ni se ver an perdiendo tiempo programando. Pensar an que est an haciendo arquitectura, planeamiento de tr aco o lmaciones. Esa posibilidad destaca la cuesti on de quien est a calicado para construir sistemas importantes. Hoy cualquiera se puede vender como un ingeniero de software. Pero cuando ten es 100 millones

11

usuariosprogramadores, frecuentemente van a estar haciendo cosas que son cr ticas para la vida construir aplicaciones que llenan prescripciones, por ejemplo nota Barry W. Boehm, director del centro para la ingenier a de software de la Universidad del Sur de California. Boehm es uno de un n umero creciente que sugiere certicar a los ingenieros de software, como se hace otros campos de la ingenier a. Por supuesto que la certicaci on ayuda si los programadores est an adecuadamente entrenados. Actualmente s olo 28 Universidades ofrecen programas en ingenier a de software; cinco a nos atr as hab an s olo 10. Ninguna ofrece t tulo intermedio. A un acad emicos tales como Shaw, DeMillo y Basili concuerdan que los curr culums de ciencias de la computaci on proveen una preparaci on pobre para el desarrollo de software industrial. Cosas b asicas como el desarrollo de c odigos de inspecci on, la producci on de documentaci on de usuario y el mantenimiento de software no se cubren en las academias se lamenta Capers Johns. Los ingenieros, la infanter a de toda revoluci on industrial, no se generan espont aneamente. Se entrenan a trav es de los malos h abitos de los artesanos que los precedieron. Hasta que las clases de ciencias de la computaci on no inculquen no s olo un deseo de construir mejores cosas, sino de construir las cosas mejor, lo mejor que podemos esperar es que el desarrollo de software atraviese una lenta, y probablemente dolorosa, evoluci on industrial.

El progreso hacia profesionalismo

Paradigma de la evoluci on de la ingenier a
Producci on Virtuosos y talentosos amateurs. El dise no utiliza la intuici on y la fuerza bruta. Progreso desordenado. Conocimiento transmitido lenta y casualmente. Uso extravagante de material. La manufactura para uso m as que para la venta. enfoque como ocio Ciencia Artesanos h abiles. Procedimiento establecido. Renamiento pragm atico. Entrenamiento en mec anica. Preocupaci on econ omica por los costos y el abastecimiento de materiales. Manufactura para la venta. enfoque para comercializaci on Ingenier a profesional Profesionales educados. An alisis y teor a. El progreso se basa en la ciencia. El an alisis posibilita nuevas aplicaciones. Segmentaci on del mercado por variedad de productos. Las disciplinas de ingenier a comparten etapas en com un en su evoluci on, observa Mary Shaw de la universidad de Carnegie Melon. Divisa paralelos interesantes entre la ingenier a del software y la ingenier a qu mica, dos campos que aspiran a explotar en una escala industrial los procesos que son descubiertos a trav es de la investigaci on en peque na escala. Como los desarrolladores del software, los ingenieros qu micos tratan de dise nar procesos para crear productos seguros y puros lo m as barato y r apido posible. A diferencia de 12

muchos programadores, los ingenieros qu micos conf an mayormente en la teor a cient ca, el modelado matem atico, las soluciones probadas de dise no y los m etodos de control de calidad riguroso y sus esfuerzos usualmente tiene exito. El software, apunta Shaw, es de alguna forma menos maduro, m as como una industria rural que una disciplina de ingenier a profesional. Aunque la demanda de software m as sosticado y conable ha elevado la programaci on a gran escala hasta la etapa comercial, la ciencia de la computaci on (que es m as joven que muchos de sus investigadores) todav a tiene que construir el fundamento experimental en el cual la ingenier a del software debe descansar.

Ingenier a qu mica
Producci on - Ocio 1775: La academia francesa ofrece una recompensa. por el m etodo para convertir la salmuera (sal) en cenizas de soda. 1300: Los alquimistas descubren el alcohol. 1700: La leg a es hervida para hacer jab on. Tinturas hechas de vegetales. Ciencia - Comercializaci on 1774: Jouseph Priestleu a sla el ox geno. 1808: John Dalton publica su teor a at omica. 1887: George Davis identica las operaciones funcionales. 1922: Hermann Stiudanjer explica la polimerizaci on. 1823: El proceso de alcali industrial de Nicolas Leblanc se pone en operaci on por primera vez. 1850: Poluci on en las tierras medias brit anicas por las plantas de a lcali. 1857: William Henry Perkin funda la industria del tinturas sint eticas.

Ingenier a profesional 1915: Irthur D. Little rena y demuestra la unidad operacional. 1994: Duppont opera megaplantas qu micas.

Ingenier a del software

Producci on - Ocio 1970: Los m etodos de programaci on estructurada ganan favor. 1980: Se lanzan los lenguajes de cuarta generaci on. 1990: Se fundan los repositorios de reuso. 1950: Los programas son peque nos e intuitivos. 1970: El sistema de reserva a erea SABRE es un exito a medias. 1990: Mucho del software para las PC es todav a hecho a mano.

13

Ciencia - Comercializaci on 1956: IBM inventa FORTRAN. 1968: Donald Eknuth publica su teor a de algoritmos y estructura de datos. 1972: Se lanza el lenguaje SMALLTALK orientado a objetos. 1980: Se renan los m etodos y anotaciones formales. 1980: Muchos sistemas de informaci on de gobierno y administraci on utilizan controles de producci on. Algunos sistemas de seguridad cr tica (como los de defensa y transporte) utilizan controles rigurosos.

Ingenier a Profesional 1994: Ejemplos aislados de algoritmos, estructuras de datos y construcci on compiladores.

Un mundo en desarrollo
Desde la invenci on de la computadora, los americanos han dominado el mercado de software. Microsoft sola produce en un a no m as c odigo de computadora que cualquiera de cien naciones, de acuerdo a Capers Johns de investigaci on para la productividad de software en Burlington, Mass: EE.UU, los proveedores tiene el 70 % del mercado alrededor del mundo. Pero como las redes internacionales crecen y las grandes corporaciones se desinan, India, Ungr a, Rusia, Las Filipinas y otras naciones m as pobres est an descubriendo en el software una industria lucrativa que requiere la u nica fuente en las cuales son ricas: una fuerza laboral desempleada y bien educada. Los gigantes americanos y europeos ahora est an compitiendo por contratos con compa n as de desarrollo asi aticas, y en respuesta, muchas est an formando subsidiarias cruzando los mares. Algunos gerentes predicen que el desarrollo de software se va a separar gradualmente entre los ingenieros de software del oeste que desarrollen sistemas y los programadores del este que los construyan. De hecho, ya est a pasando dice Laszlo A. Beladi, director del laboratorio de investigaci on el ectrica de Mitsubishi. AT&T, Hewlett-Packard, IBM, British Telecom, y Texas Instruments han comenzado equipos de programaci on en la India. El grupo Pact en Lyons, Francia mantiene una f abrica de software en Manila. Cadence, el proveedor americano de VLSI Herramientas de Dise no, ha tenido su desarrollo de software en las costas del pac co por muchos a nos reporta Martin Tomas. Hasta el momento, la estrella de la India ha subido al rmamento: el desarrollo o shore ha comenzado a despegar entre los pasados 18 y 24 meses dice Ragendra S. Pawar, cabeza del NIIT Nueva Deli. Las exportaciones de software de la India han visto un crecimiento anual del 38 % sobre los u ltimos 5 a nos; el a no pasado saltaron un 60 % cuatro veces la tasa de crecimiento promedio alrededor del mundo. Alrededor de 58 % de los 360 millones de d olares en software que salieron de la India el a no pasado terminaron en los EE.UU. Esa gotita apenas si salpica en un mercado de 92.8 billones de d olares. Pero muchas corrientes pueden empujar las exportaciones m as all a de la marca de 1 bill on cerca de 1997. 14

El factor m as importante seg un Pawar, es el apoyo del gobierno Indio que ha bajado tarifas y restricciones, subsidiado numerosos parques de tecnolog a de software y zonas de exportaci on, y ha exento de impuestos a los exportadores de software por 5 a nos. La apertura de la econom a India est a actuando como un gran catalizador dice Pawar. Ciertamente parece haber atra do la atenci on de grandes rmas multinacionales deseosas de reducir tanto el costo del software que necesitan como la cantidad que producen en casa. El costo primario del software es el trabajo. Los programadores indios son tan baratos u$s 125 por unidad de software contra u$s 925 de un desarrollador americano, de acuerdo a Johns que algunas compa n as llevan a un equipo completo a EE.UU. para trabajar en un proyecto. Otro factor observa Pawar, es una creciente conanza en la calidad de la administraci on de proyectos o-shore. En los u ltimos dos a nos, las compa n as americanas se han sentido m as c omodas con el concepto o-shore dice.

15