Weitzenfeld: Captulo 1

Parte I Introduccin En esta era tecnolgica en la cual vivimos, nuestras vidas estn regidas de gran manera por las computadoras y por el software que las controlan. Las consecuencias del uso del software son muy importantes, a favor y en contra. Cuando todo funciona bien las computadoras son de gran ayuda pero cuando no, el resultado puede ser nefasto, algo que se ha visto a lo largo de los aos en mltiples ocasiones. En esta primera parte del libro se da la motivacin al rea de ingeniera de software orientada a objetos donde se discuten los siguientes temas: (1) el costo del software para la sociedad, (2) la razn para utilizar tecnologa orientada a objetos y (3) el proceso de software necesario para desarrollar y mantener tales desarrollos. 1 El Costo del Software para la Sociedad Se comienza haciendo una pregunta muy sencilla: Cunto le cuesta a la sociedad utilizar sistemas de software? De manera bsica el costo del software puede calcularse en base al gasto mundial en comprar productos y servicios relacionado al software. Por ejemplo, en 1995 se calcul que el mercado mundial de software fue de alrededor de $400 billones de dlares y para el 2000 se estim que sera mayor a $1 trilln de dlares. Segn estadsticas del departamento de comercio americano, el mercado mundial de software empacado en 1994 fue de $77 billones de dlares (se calcula que en 1993 se perdieron $13 billones por piratera). Se calcula que para el ao 2000 sera de $153 billones de dlares. Este software empacado incluye herramientas de aplicacin, soluciones de aplicacin, software de sistemas, y utileras. El mercado de servicios de informacin mundial en 1995 en $324.7 billones de dlares con un incremento de 13% anualmente, lo que significara un mercado de $600 billones de dlares para el ao 2000. Sin embargo, estos costos no representan la realidad completa dada la dependencia que tenemos en el software. En este captulo profundizar un poco ms en este tema para entender cuales son los gastos "ocultos" del software y que consecuencias pueden tener para la sociedad, desde costos econmicos adicionales hasta, incluso, vidas humanas. 1.1 Costos Ocultos y Consecuencias del Software Quizs el costo oculto (externalidades) ms importante del software (el costo no oculto es el que se paga para adquirir o desarrollar ms servicios adicionales) tiene que ver con su funcionamiento incorrecto. La pregunta que nos hacemos es, dada la dependencia sobre el software en el mundo, cules son las consecuencias de su funcionamiento incorrecto? Estas consecuencias se pueden agrupar de la siguiente forma: ? ? Consecuencias inmediatas y efectos directos. Pueden significar horas de cada de los sistemas involucrados y horas de transacciones perdidas. A su vez, esto puede significar que la organizacin tenga que arreglrselas mientras tanto sin sus sistemas; y si los sistemas son centrales a los propsitos de la organizacin, una falla puede representar un costo inmenso. Estos costos corresponden a aplicaciones "criticas de negocios" o "crticas a la misin". Sin embargo, el costo total de una falla de computadora es ms que las consecuencias inmediatas y/o efectos directos. ? ? Consecuencias a mediano y largo plazo y efectos indirectos. Pueden significar productividad perdida, ventas perdidas, costos de servicios de emergencia, costos de restaurar datos, costos por propaganda negativa, costos por accidentes causados, incluyendo posibles juicios en su contra. Estos costos adicionales pueden volver insignificantes el costo bsico del software inicial. Estos puntos anteriores son indicativos de que es difcil predecir el costo real del software para la sociedad a mediano y largo plazo si consideramos los problemas que pudieran ocasionar por su utilizacin. Por otro lado el no utilizar software no sera una alternativa aceptable hoy en da ya que los efectos seran mucho mayores. A lo largo de estos ltimos aos se han podido presenciar casos de fallas de software con consecuencias nefastas. Existen muchos casos donde errores en el software o su mala utilizacin han costado vidas humanas o perdidas econmicas multimillonarias. Peter G. Neumann, moderador del foro de la ACM sobre riesgos al pblico en el uso de computadoras y sistemas relacionados, ha mantenido una lista comprensiva de desastres ocasionados por fallas del software o su mala utilizacin. Otros grupos, como los Profesionales de la Computacin para la Responsabilidad Social (CPSR por sus siglas en ingles) reportan sobre las implicaciones sociales de todo tipo de fallas en las computadoras. Lamentablemente se aprende ms de los errores que de la correcta ejecucin de los sistemas. Las siguientes secciones ilustran algunos de estos casos que sirven para motivar y concientizar al lector en que el software no es algo que pueda o deba tomarse a la ligera en especial si se conoce poco del tema. Ms adelante analizaremos qu se puede hacer para manejar su complejidad y evitar desastres.

Weitzenfeld: Captulo 1

1.1.1 Fallas en Sistemas de Software El orden en la presentacin de los siguientes ejemplos de desastres ocasionados directa o indirectamente por software y por las computadoras que lo operan, es exclusivamente cronolgico sin relacin al rea de aplicacin o las consecuencias que ocasionaron. Por supuesto que slo algunos ejemplos son mencionados, de lo contrario todo el libro pudiera haber sido dedicado al tema! ? ? Fracaso del Mariner 1 (1962). Podemos remontarnos bastante tiempo atrs para descubrir errores ya causados por computadoras. La primera misin del programa Mariner (con costo total de la misin Mariner 1 hasta Mariner 10 de 554 millones de dlares) fracas por culpa de un caracter incorrecto ('? ') en la especificacin del programa de control para el cohete de propulsin Atlas lo cual caus finalmente que el vehculo se saliera de curso. Ambos, el cohete y el vehculo espacial tuvieron que ser destruidos poco despus del lanzamiento. Adicionalmente, se cree que un error de computadora tambin fue la causa del fracaso del Mariner 8 en 1971. ? ? Sobregiro del Banco de New York (1985). En Noviembre de 1985, el Banco de New York (BoNY) tuvo accidentalmente un sobregiro de $32 billones de dlares (una buena suma si consideramos que esto fue hace 15 aos!) por culpa de un contador de 16 bits (la mayora de los dems contadores eran de 32 bits) que se activ ocasionando un "overflow" del contador que nunca fue verificado. BoNY no pudo procesar nuevos crditos de transferencias de "securities", mientras que la Reserva Federal de New York automticamente hizo un traspaso de $24 billones de dlares al BoNY para cubrir sus gastos por un da, por lo cual el banco tuvo que pagar $5 millones de dlares por los intereses diarios, hasta que el software fue arreglado. ? ? Accidente de un F-18 (1986). En Abril 1986 un avin de combate F-18 se estrell por culpa de un giro descontrolado ("unrecoverable spin") atribuido a una expresin "IF-THEN" para la cual no haba una instruccin "ELSE" porque se pens que era innecesaria, resultando en una transferencia fuera de control del programa. ? ? Muertes por el Therac-25 (1985-1987). El acelerador lineal mdico, Therac-25, producido por AECL (Atomic Energy of Canada Limited), fue diseado para tratamiento a pacientes por medio de radiacin de Rayos X de dos tipos: (i) tratamiento de rayo directo de bajo poder, y (ii) tratamiento de rayo indirecto reflejado de alto poder. Entre 1985 y 1987 este sistema ocasion la muerte de varios pacientes en diferentes hospitales de USA y Canad por culpa de radiaciones de alto poder aplicadas de manera incontrolada. La probable causa de los accidentes consista en que para ciertas secuencias de comandos del operador de la mquina, los controles de la computadora llevaban la mquina a un estado interno errneo y muy peligroso, generando una sobredosis masiva de radiacin al paciente. Despus de amplia publicidad de estos accidentes se descubri que la FDA (Federal Drug Agency) no especificaba requisitos, y no haca revisiones sobre prcticas de desarrollo de software o control de calidad de software en dispositivos mdicos. El FDA inform en Septiembre de 1987 que comenzara a requerir controles de software integrados a ciertas clases de dispositivos mdicos. ? ? Avin derribado por el USS Vincennes (1988). En julio de 1988 la fragata USS Vincennes estaba asignada al golfo prsico. Despus de repetidos intentos de comunicacin por radio, el USS Vincennes dispar un misil (por error) derribando un avin Airbus comercial Iran matando a todos los 290 pasajeros y tripulantes. Esto ocurri mientras el Airbus ganaba altura, bajo la suposicin incorrecta de que era un avin de combate F-14 que descendera sobre el barco de manera hostil. Aunque la orden de disparo fue dada por el comandante del navo, se culpa como causa contribuyente del incidente al sistema de radar AEGIS, el cual con su sistema de interface de usuario mostraba nicamente un punto junto a un dato textual representando al avin, en lugar del eco real del radar sobre el avin. Posteriormente se supuso que en algn momento la aerolnea Iran estuvo en la proximidad de un F-14, probablemente durante el despegue del aeropuerto, confundiendo al sistema AEGIS y asociando de manera incorrecta la informacin transmitida por los "transponders" aire-tierra del F-14 a la aerolnea. Cuando el avin despeg, ste qued asociado con los datos del F-14 sobre la pantalla. Un despliegue inconveniente y posiblemente confuso de la informacin de altitud del avin posiblemente confundi an ms a los oficiales del barco, los cuales supusieron que el F-14 estaba descendiendo, aunque en realidad estaba ganando altura. La inclusin de un eco real del radar sobre la pantalla hubiera hecho posible determinar que el eco del radar del avin era del tamao incorrecto para un avin de combate. ? ? Falla del software de AT&T (1990). El 15 de enero de 1990, AT&T (American Telegraph and Telephone) la compaa que controla las redes del mayor sistema de comunicacin en el mundo, experiment una falla masiva que dej fuera de servicio su sistema de comunicaciones de larga distancia. La falla dur alrededor de nueve horas e interrumpi millones de llamadas de larga distancia. Un error en el software de manejo de excepciones de un tipo particular de sistema de switching telefnico result en una falla de switching, que a su vez caus otras fallas de switching en un efecto cascada. Segn Neuman, se report que la ltima causa del problema tuvo

Weitzenfeld: Captulo 1

??

??

??

??

??

origen en un programa en el lenguaje C que contena una instruccin "BREAK" dentro de una clusula "IF" dentro de una clusula "SWITCH". Aberracin esfrica en el telescopio espacial Hubble (1990). El 25 de Abril de 1990 se puso en rbita el famoso telescopio espacial Hubble desde el vehculo espacial Discovery. Al poco tiempo, NASA descubri que el componente ms crtico del telescopio de $4 billones de dlares, su espejo principal, tena una gran falla, imposibilitando producir imgenes altamente enfocadas. El problema en su lente es tcnicamente conocido como una "aberracin esfrica". Una investigacin de la NASA revel que el espejo se haba construido con la forma incorrecta siendo 2 micrones (1 micrn = 10-6 metros) ms plano a los lados de lo estipulado en el diseo original, un error bastante grande segn los estndares de precisin de la ptica moderna. Este fue el error principal encontrado en el telescopio, considerando que hubo otros problemas adicionales, como en sus paneles solares, sus giroscopios, y contactos elctricos. El problema del lente radic en que nunca fue realmente probado antes de ser enviado al espacio. En su lugar, una simulacin de computadora se us como mtodo de menor costo para validar el rendimiento del espejo. Por desgracia, malos datos de entrada se utilizaron en la simulacin, significando resultados despreciables. Para corregir el error final en el espacio, se agreg al telescopio ptica correctiva a un costo muchas veces mayor que una prueba en tierra del espejo, significando adems que el espejo nunca funcionara tan bien como se plane. Por lo pronto, la NASA no planea otro telescopio de la magnitud del Hubble, por lo cual los astrnomos tendrn que limitarse a las restricciones actuales del Hubble, con el cual slo se pueden ver objetos aproximadamente 20 veces ms grandes de lo original. Duplicacin de solicitudes de transferencias bancarias (1990). En 1990 un error de software ocasion que un banco en el Reino Unido duplicara cada solicitud de transferencia de pago por un periodo de media hora, acumulando 2 billones de libras esterlinas adicionales. Aunque el banco expres haber recuperado todos los fondos, se especul que los posibles intereses perdidos pudieran haber llegado a medio milln de libras por da. Falla del software de los misiles Patriot (1991). En las primeras etapas de la guerra del golfo prsico de 1991, el sistema Patriot fue descrito como altamente exitoso. En anlisis posteriores, los estimados de su efectividad fueron disminuidos seriamente de 95% a 13% o incluso menos. El sistema fue diseado para trabajar en un ambiente mucho ms limitado y menos hostil que el que haba en Arabia Saudita. Segn report posteriormente el New York Times, una falla en la computadora de tierra del misil Patriot fue responsable de evitar la peor baja americana durante la guerra. Esto result en su inoperabilidad, permitiendo que un misil "scud" destruyera unas barracas militares americanas en Dhahran, Arabia Saudita, causando 29 muertos y 97 heridos. Aparentemente el sistema de radar del Patriot nunca vio al misil Scud. Segn oficiales del ejrcito "una combinacin imprevista de docenas de variables - incluyendo la velocidad, altura y trayectoria del Scud - causaron la falla del sistema del radar [este caso fue] una anomala que nunca apareci durante las horas de pruebas." El error se atribuye a una acumulacin de inexactitudes en el manejo interno del tiempo de la computadora del sistema. Aunque el sistema ejecutaba segn las especificaciones, ste deba ser apagado y prendido con la suficiente frecuencia para que el error acumulado nunca fuera peligroso. Como el sistema se us de manera no planeada, una pequea inexactitud signific un serio error. Despus de 8 horas de uso se detect el problema del reloj acumulado. La correccin slo se logr al da siguiente de la catstrofe (Mellor, 1994; Schach 1997). Error en el procesador Pentium de Intel (1994). En 1994 un error de punto flotante en el procesador Pentium le cost US $475 millones a Intel. El error no fue reconocido pblicamente por varios meses por Intel diciendo que el procesador era "suficientemente bueno" adems de que sera muy difcil que el error ocurriera. Actualmente, Intel est sufriendo otros problemas similares con sus procesadores, como la unidad MTH (Memory Translator Hub) usado para transferir seales de la memoria a otra unidad de la computadora (Intel 820) que podra significarle un costo similar. Recientemente ha tenido problemas con la ltima generacin del Pentium III de 1 Ghz, donde se ha visto obligada a retirarlo del mercado. Al menos la compaa ya ha aprendido a reconocer sus errores! Error en sistema de autentificacin de tarjeta de crdito (1995). Segn un artculo del 4 de Noviembre 4 de 1995 del peridico Guardian en UK se relata que los dos sistemas ms grandes en UK para la autorizacin de crdito (Barclay's PDQ y NatWest's Streamline) fallaron el sbado 28 de octubre de 1995 dejando a los negocios sin poder verificar las tarjetas de crdito de sus clientes. En el caso de Barclay, ms del 40% de las transacciones fallaron por un "error en el sistema de software". Para NatWest, el problema fue una gran cola de llamadas, por razones desconocidas, las cuales retrasaron la autentificacin de tarjetas. Aunque ambos tenan sistemas de contingencia permitiendo a los negocios telefonear para autenticar solicitudes, por el volumen de ventas las lneas se saturaron rpidamente.

Weitzenfeld: Captulo 1

??

??

??

??

??

??

Explosin del cohete Ariane 5 (1996). El 6 de Junio de 1996 una computadora fue culpada por la explosin del primer vuelo, el 501, del cohete Ariane 5 con un costo de US$500 millones de dlares. El cohete, que parece que no estaba asegurado, llevaba cuatro satlites, ocasionando prdidas totales de $1.8 billones de dlares. El Ariane-5 estaba funcionando perfectamente hasta los 40 segundos iniciales cuando de repente empez a salirse de su curso y fue destruido remotamente por una explosin solo fracciones de segundo despus, ocasionadas por una seal enviada por un controlador de tierra del Ariane. Segn ESA (Agencia Espacial Eurpea), la desviacin fuera de curso fue ocasionada por instrucciones de la computadora controlando los escapes de los dos poderosos impulsadores del cohete. Incluso se especul que la instruccin fue generada por la computadora porque crey que el cohete se estaba saliendo de su curso y de esta manera estara corrigiendo el curso de vuelo. Segn el reporte final, la causa de la falla fue una excepcin de software ocurrida durante la conversin de un nmero flotante de 64-bits a un nmero entero de 16 bits. El nmero flotante siendo convertido tena un valor mayor del que poda ser representado por un nmero entero de 16 bits (con signo). Esto result en un "error de operando". Las instrucciones de conversin de datos (cdigo en Ada) no estaban protegidos de causar tal error de operando, aunque otras conversiones de variables similares en el mismo lugar, s estaban protegidas. El origen del problema parece haber sido en que el Ariane 5 poda llevar un mayor nmero de satlites que el Arianne-4, incrementando as su peso. Sin embargo el Ariane-5 utilizaba una gran cantidad de software diseado para el Ariane-4. Las conclusiones finales no oficiales fueron que ningn mtodo formal hubiera detectado el problema, ya que la raz de tal era a nivel de comunicacin entre humanos, en relacin a informacin fsica aparentemente no relacionada y no un problema de programacin. Error del sistema de cobranza lleva a una compaa a la quiebra (1996). Un artculo en la edicin de Abril de 1996 de "TVRO Dealer" (una publicacin del rea de televisin por satlite) describe cmo el intento de un servicio de programacin de una gran compaa de televisin por satlite de cambiar a un nuevo sistema de software de cobranza el 28 de Marzo anterior finalmente caus la quiebra de la compaa. Error del sistema de cobranza en MCI (1996). En la edicin del 29 de marzo de 1996 del Washington Post, MCI report que devolveran aproximadamente 40 millones de dlares a sus clientes por causa de un error de cmputo. El error de cobranza fue descubierto por un reportero investigador de una estacin local de televisin en Richmond, VA. Los reporteros encontraron que fueron facturados por 4 minutos despus de hacer una llamada de tan solo 2.5 minutos, dando lugar a una profunda investigacin. Mayor falla de una computadora en la historia de bancos en USA (1996). El 18 de mayo de 1996 la revista US & World Report, y al siguiente da el diario The Boston Globe, reportaron que aproximadamente 800 clientes del First National Bank of Chicago fueron sorprendidos al ver que sus saldos eran $924 millones de dlares ms de lo que tenan la semana pasada. La causa fue el tradicional "cambio en el programa de la computadora". De acuerdo a la Asociacin de Banqueros Americanos, el total de $763.9 billones fue la cantidad ms grande para tal error en la historia bancaria de los Estados Unidos, ms de seis veces el total de fondos ("assets") del First Chicago NBD Corp. El problema fue atribuido a un "error de la computadora". Falla de la computadora del centro de control de trfico areo de NY (1996). El 20 de Mayo 1996 fall la computadora del Centro de Control Areo de Nueva York (ARTCC - NY Air Route Traffic Control Center) que controla el trfico areo sobre los estados de New York, Connecticut, New Jersey, Pennsylvania y parte del ocano Atlntico. La computadora de 7 aos de vigencia perdi capacidad de servicio efectivo ("fall") dos veces la tarde del lunes 20 de mayo; la primera vez por 23 minutos y la segunda por alrededor de una hora, una hora ms tarde. Parece que 4 das antes se haba instalado un nuevo software en el sistema. Se volvi al sistema anterior, con procedimientos de control de trfico areo ms ineficientes, ocasionando un lmite ms bajo de saturacin de trfico y retrasos en los despegues de alrededor de una hora en los aeropuertos principales en el rea; junto con un incremento en la carga de trabajo de los controladores y menor seguridad, incluyendo la desactivacin de la "alerta automtica de conflictos". Mala planificacin del nuevo sistema de una administradora de servicios de salud (1997). Segn report el Wall Street Journal el 11 de diciembre de 1997, Oxford Health Plans Inc., administradora de servicios de salud en USA, de gran crecimiento en los ltimos tiempos, anunci que registrara una prdida de US$120 millones o ms durante ese trimestre, adems de una prdida adicional de US$78,2 millones, su primera prdida desde que sali a la bolsa en 1991. La razn principal fue la larga lista de problemas ocurridos con un sistema informtico que se puso en lnea en 1996; desde el diseo del sistema y su instalacin hasta cmo fue administrado por los ejecutivos del grupo Oxford. Los problemas ocasionaron que Oxford no pudiera enviar facturas mensuales a miles de cuentas de clientes adems de incapacitarla para rastrear los pagos a cientos de mdicos y hospitales. En menos de un ao, los pagos no cobrados de sus clientes se triplicaron a ms de US$400 millones, mientras que el monto que Oxford deba a los proveedores de servicios mdicos aument en ms del 50%, a una suma

Weitzenfeld: Captulo 1

??

??

??

superior a los US$650 millones. La administradora de servicios mdicos comenz a planear su nuevo sistema informtico en 1993, cuando slo tena 217,000 miembros. El sistema, desarrollado por Oracle, no comenz a utilizarse hasta Octubre de 1996, cuando el nmero de abonados a su seguro mdico haba llegado a 1,5 millones. En ese momento el sistema ya era obsoleto. En lugar de tomar 6 segundo inscribir a un nuevo miembro, tomaba 15 minutos. A pesar de esto y que la infraestructura administrativa de Oxford no daba abasto, los ejecutivos seguan inscribiendo nuevos clientes, en el ltimo ao se incorpor medio milln adicional. A finales de 1993, Oxford trat de ajustar el sistema, adems de convertir de una sola vez la mayora de su base de datos para facturacin: unas 43,000 cuentas cubriendo a 1,9 millones de miembros. Esto signific la catstrofe final, ya que la transformacin entre base de datos no funcion, y mientras tanto se suspendi por unos meses la facturacin ya que no se contaba con un sistema de seguridad, ni siquiera manual. A pesar de todo esto, Oxford sigui sus prcticas habituales de contabilidad, registrando aquellas facturas que no se haban cobrado como facturacin trimestral. Los problemas finales surgieron cuando Oxford comenz a poner al da las cuentas vencidas contactando a los clientes por primera vez en varios meses. Muchos se negaron a pagar y otros dijeron que haca mucho que haban cancelado su cuenta. Por consiguiente, Oxford tuvo que registrar US$111 millones como deudas incobrables y reconoci que tena 30,000 afiliados menos de lo que haba calculado. El presidente reconoci que deba haber contratado un ejrcito de trabajadores temporales para que escribieran a mquina las facturas. Por otro lado, lo primero que perdieron fueron los clientes pequeos, pero como luego no resolvieron ningn problema comenzaron a perder a los clientes grandes. Error de un controlador de discos de Toshiba (1999). En noviembre de 1999 Toshiba lleg a un arreglo fuera de corte que le costara a la compaa ms de $2 billones de dlares para cubrir errores que pudiesen haber significado la prdida de informacin por culpa de fallas en los controladores de discos "floppy" producidos en sus computadoras porttiles a partir de 1980. Aunque los controladores fueron diseados originalmente por NEC, Toshiba produca sus propios componentes y nunca incluy la modificacin hecha por NEC en 1987 lo cual hubiese evitado el problema. Lo mas interesante del caso es que realmente nunca se report falla alguna. Queda por ver que consecuencias traer este caso al resto de los fabricantes de computadoras para los cuales este precedente los tiene extremadamente preocupados. Actualizacin de software mal planificada paraliza Nasdaq (1999). El 17 de noviembre de 1999 los corredores de la bolsa de valores Nasdaq no pudieron comprar ni vender acciones durante 17 minutos cruciales, despus de que oficiales de Nasdaq intentaran actualizar sobre la marcha un sistema de software durante la ltima media hora de la sesin. Algo funcion mal y los inversionistas tuvieron que pagar el precio. Error del milenio (2000). Concluyo estos ejemplos con un pequeo pero nocivo error que se le conoce como el problema Y2K, error del milenio, o inclusive el problema de software del siglo 20. El problema se remonta a la dcada de los 60, y radica en que hace mucho tiempo los programadores adoptaron la convencin de representar el ao con dos dgitos en lugar de cuatro. Esta convencin ocasionara fallas en los sistemas al llegar al ao 2000, ya que se alambraba el "19" (no se permita utilizar un nmero que no fuera el 19), para generar la fecha lo cual al llegar al ao 2000 fallara por saturar el registro de almacenamiento ("overflow"). Para empeorar las cosas a menudo los dgitos "99" o "00" eran valores reservados (nmeros mgicos) significando "nunca borrar esto" o "esta es una cuenta de demostracin". Adems, esto resultaba en el uso de un algoritmo incorrecto para reconocer aos bisiestos. No est claro si hay una razn nica para haber hecho esto; porque la memoria de las computadoras en esa poca era extremadamente cara, o porque no se esperaba que estos sistemas duraran tanto tiempo, o incluso quizs porque no reconocieron el problema. Aunque el problema se activ en este nuevo milenio, se tiene precedentes. Muy pocos se dieron cuenta que la IBM 360 no poda manejar fechas mayores al 31 de Diciembre de 1969, hasta que estas mquinas empezaron a fallar a la medianoche hora local. IBM recomend a sus clientes en Amrica y Asia mentirles a las computadoras cambiando a una fecha anterior, mientras IBM empez a crear una solucin al problema. El problema es muy extenso, afecta hardware (BIOS, relojes de tiempo real, "embedded firmware", etc.), lenguajes y compiladores, sistemas operativos, generadores de nmeros aleatorios, servicios de seguridad, sistemas de manejo de bases de datos, sistemas de procesamiento de transacciones, sistemas financieros, hojas de clculo, conmutadores telefnicos, sistemas telefnicos y ms. No es solamente un problema de sistemas de informacin, todo aquel sistema que use fechas est expuesto: automviles, elevadores, etc. (Por ejemplo, en cierto momento Visa y MasterCard pidieron a sus bancos asociados que dejen de dar tarjetas que expiren en el 2000 o despus.) No solamente es un problema de aplicaciones antiguas: el ao pasado el paquete Quicken para manejo de finanzas personales fue corregido para ir ms all de 1999. En enero se report que el Instituto Nacional de Salud (NIH) en USA recibi nuevas PCs con tres versiones diferentes de BIOS, dos de las cuales fallaron a la transicin Y2K. Las soluciones fueron muchas, consistiendo de diferentes etapas para analizar el problema particular y decidiendo las medidas a tomar, incluyendo no hacer nada y dejar que el problema ocurriera para luego

Weitzenfeld: Captulo 1

arreglarlo. Existe an toda una industria alrededor de este problema, con 1,800 compaas asociadas a la organizacin "year200" (year2000.com, year2000.org) y proporcionando certificaciones. Se dice que lleg a ser tanta la demanda por programadores del lenguaje Cobol (donde el problema fue ms significativo) y tan desesperada la situacin, que segn se report, se fue a buscar programadores de Cobol ya retirados en asilos para ancianos Actualmente se desconoce el costo final al problema de Y2K. Es difcil estimar cual fue el costo total del problema Y2K. Segn la compaa TMR (Technology Management Reports) de San Diego, los costos podran haber sido superior a $1 trilln de dlares. Esto incluye reescribir programas existentes, adquisicin e instalacin de sistemas que los reemplacen, y productividad perdida por culpa de la interrupcin de los sistemas para pruebas y las propias fallas por no ser funcionales en el ao 2000. Y esto no incluye demandas por daos ocasionados. Otras compaas predijeron rangos de costos similares, como el grupo Gartner, que predijo un costo de $600 billones de dlares a nivel mundial. Varias compaas asignaron presupuestos para este problema: Chase Manhattan dijo que gastara $250 millones de dlares, American Airlines y Hughes Electronics dijeron que gastaran $100 millones de dlares cada una. La oficina de administracin de presupuesto de la Casa Blanca (OMB - Office of Management and Budget) calcul sus costos de reparacin en 2.8 billones. Esto inclua 4,500 computadoras para defensa nacional, trfico areo, pagos de impuestos y seguridad social. El Grupo Gartner estim que los costos para el Departamento de Defensa de USA podran ser superior a los US$30 billones. 1.1.2 Sobrecostos, Retrasos y Cancelaciones en los Sistemas de Software Lamentablemente los costos de los sistemas de software no se restringen a fallas en el software o los sistemas de computadora. Segn una encuesta hecha por el Standish Consulting Group en 1995 compaas y agencias gubernamentales americanas perdieron $81 billones de dlares por proyectos de software cancelados. Segn Rob Thomsett, las causas de esto pueden ser de dos niveles principales: (i) factores que casi garantizan la cancelacin del proyecto, como la falta de un dueo del proyecto; y (ii) factores que no resultan en una cancelacin inminente del proyecto, pero seguramente ocasionarn reducciones substanciales en su calidad. En esta seccin se muestran algunos ejemplos clsicos en orden cronolgico. ? ? Sobrecosto y retraso en sistema de Allstate Insurance (1982). En 1982, Allstate Insurance comenz a construir un sistema para automatizar su negocio por $8 millones. El supuesto esfuerzo de 5 aos continu hasta al menos 1993 cuando termin costando cerca de $100 millones. ? ? Sobrecosto, retraso y cancelacin en sistema de London Stock Exchange (1983-1988). El proyecto Taurus de la Bolsa de Valores de Londres estaba originalmente cotizado en 6 millones de libras. Varios aos ms tarde y ms de 100 veces (13,200%) sobre presupuesto el proyecto fue cancelado, costando a la ciudad de Londres al momento de ser abandonado, 800 millones de libras. ? ? Sobrecosto y retraso en sistema del bombardero B-1 (1985). El bombardero B-1 en servicio desde 1985 requiri US $1 billn adicional para mejorar su software de defensa area que era inefectivo, aunque problemas de software imposibilitaron alcanzar los objetivos originales. ? ? Sobrecosto, retraso y cancelacin en sistema de Bank of America (1988). En 1988, Bank of America gast US $23 millones en una plan inicial de 5 aos para desarrollar MasterNet, un sistema computarizado para contabilidad y reportes de "trust". Luego de abandonar el sistema viejo, gastaron $60 millones adicionales para lograr que el nuevo sistema funcionara y finalmente terminaron desistiendo. Las cuentas de los clientes perdidos pudieron haber excedido los billones de dlares. ? ? Sobrecosto y retraso en sistema de control de rastreo por satlite (1989). El software para la modernizacin de la Facilidad de Control de Rastreo por Satlite tom 7 aos ms de lo previsto y cost $300 millones adicionales ofreciendo menor capacidad de la requerida. ? ? Sobrecosto y retraso en sistema Airborne Self-Protection Jammer (1989). El sistema ASJP (Airborne SelfProtection Jammer), un sistema electrnico de defensa area instalado en alrededor de 2,000 aviones de combate y ataque de la Marina Americana, cost US $1 billn adicional, tom 4 aos adicionales, y slo fue "efectivo operacionalmente marginalmente y apropiado operacionalmente marginalmente". ? ? Sobrecosto en sistema del avin de carga C-17 (1989). El avin de carga C-17 construido por Douglas Aircraft cost $500 millones adicionales por problemas del software aeronutico. Un reporte de GAO not que existieron 19 computadoras a bordo, 80 microprocesadores, y 6 lenguajes diferentes de programacin. 1.1.3 Razn de los Problemas del Software Cmo podemos justificar tantos problemas en el software y las computadoras? Una pequea ancdota refleja la situacin.

Weitzenfeld: Captulo 1

Se dice que hace unos aos se juntaron un mdico, un ingeniero civil y un ingeniero en computacin para discutir cual era la profesin ms antigua del universo. El mdico explic: Dios cre a Eva de la costilla de Adn; obviamente se requiri ciruga, por lo cual la medicina tiene que haber sido la profesin ms antigua. A esto dijo el ingeniero civil: antes de Adn y Eva, Dios cre todo el universo, del caos puso orden en el cielo y en la tierra, siendo sta la aplicacin ms espectacular de la ingeniera civil y tambin la ms antigua. Finalmente, exclam el ingeniero en computacin, quin creen que cre el caos en primer lugar. Una frase ms actual dice que para hacer las cosas mal es suficiente una persona, pero para hacerlas verdaderamente desastrosas se requiere una computadora. 1.2 Complejidad del Software El problema principal que hemos visto en la seccin anterior radica en que cuanto ms grandes son los sistemas de software mayor es su complejidad. Uno se pregunta, de dnde proviene toda esta complejidad? Se puede hablar de dos aspectos que causan esta complejidad, uno esttico y otro dinmico. El aspecto esttico del software tiene que ver con la funcionalidad que el software ofrece. Cuanto mayor es su funcionalidad mayor es el nmero de requisitos que debe satisfacer un sistema. Esto significa que los sistemas se vuelven ms grandes y ms difciles de comprender por la cantidad de informacin y funciones que manejan. El nivel de complejidad radica en estos aspectos intrnsicos a la aplicacin. Para reducir tal complejidad habra que simplificar la funcionalidad que el sistema ofrece. Obviamente, la complejidad puede fcilmente aumentar si la aplicacin no est desarrollada de manera adecuada. El aspecto dinmico del software tiene que ver con los cambios que pudieran hacerse en un sistema en el futuro. Segn una ley de desarrollo de software (Lehman, 1985), todo programa que se use se modificar; y cuando un programa se modifica, su complejidad aumenta, siempre y cuando uno no trabaje activamente contra esto. Esto es similar al problema de la entropa, una medida de termodinmica sobre desorden. Segn la segunda ley de termodinmica, la entropa de un sistema cerrado no puede ser reducida, solo puede aumentar o posiblemente mantenerse sin cambios. Una alternativa es aplicar reingeniera para reducir esta entropa, y as poder continuar con el mantenimiento del sistema. Por otro lado, cuando se llega a tal desorden, no es econmicamente justificable continuar con el sistema, ya que es demasiado caro modificarlo. Lamentablemente, como se vi antes, la historia nos muestra que los sistemas raramente se desarrollan a tiempo, dentro del presupuesto y segn las especificaciones originales. Ms an, los sistemas tienden a fallar. Sin embargo, segn veremos en el Captulo 3, no todo es negativo. Un aspecto importante para poder manejar la complejidad de los sistemas, es seguir un buen proceso de software. 1.2.1 Robustez del Software Tomemos el caso de los sistemas de control de trfico areo de Estados Unidos. El gobierno requiere que sus nuevos sistemas no dejen de funcionar por ms de 3 segundos al ao. Adems requiere que en los sistemas de las aerolneas civiles la probabilidad de ciertas fallas catastrficas no sean mayor a 10-9 por hora. La problemtica de esto es cmo comprobar que dichas fallas nunca ocurran dado que de por s ocurren muy raras veces. Por ejemplo, el requisito anterior significa que se tendra que ejecutar un programa varios mltiplos de 109 (100,000 aos) para asegurarse que el sistema funcione bien y que tales fallas no ocurran. Segn Edward Adams de IBM Thomas Watson Research Center, un tercio de todas los errores (bugs) son defectos de "5,000 aos" (MTBF - mean time between failures): cada una de ellas produce un error una vez cada 5,000 aos. Adems de la dificultad para encontrar la falla, remover una de ellas significara una mejora insignificante en la robustez del sistema. Segn Caper Jones (1995), se puede estimar el nmero de defectos "latentes" en un sistema tpico de acuerdo al tamao del sistema, medido en puntos de funciones, subido a la 1.2 potencia. Se calcul que cuando Microsoft Windows 3.1 se envi al mercado en 1992 contaba con 5,000 errores (bugs) conocidos. Considerando que Windows 95 consista aproximadamente de 80,000 puntos de funcin, esto sugiere que Windows 95 tena aproximadamente 765,000 errores latentes (o sea, errores que en el proceso de desarrollo deban componerse durante las etapas de pruebas). Si todas estas pruebas removieran el 99% de los errores, aun quedaran 7,650 para ser encontrados despus de haberse enviado el software al mercado. La primera versin de Word tuvo 27,000 lneas mientras que Word 6.0 tena 2 millones. Word 6.0 tena 10 veces ms funcionalidad que Word 5.1, y 3 veces la cantidad de cdigo, significando obviamente una gran lentitud en el sistema. Los nmeros para Office 2000 y Windows 2000 aterraran a cualquiera! Por supuesto que existen mtodos formales que son pruebas matemticas para garantizar si un programa funciona de acuerdo a sus especificaciones. Sin embargo, esto tampoco ofrece una solucin completa, aunque siempre ayuda. Entonces, que alternativa tenemos para mejorar la robustez del software? Analizaremos esto y otros temas ms adelante.

Weitzenfeld: Captulo 1

1.2.2 Software Suficientemente Bueno En general no existe una sola medida que nos diga que tan bueno es un sistema de software. Por un lado, un sistema de software se puede considerar exitoso cuando satisface y posiblemente excede las expectativas de los clientes y/o usuarios en el momento de utilizarse. A nivel de negocios, esto tambin implica que se desarrolle a tiempo, de manera econmica, y que se ajuste a modificaciones y extensiones posteriores. De manera general se pueden caracterizar aspectos externos e internos al sistema. Como factores externos, los usuarios esperan resultados rpidos, que el software sea fcil de aprender, sea confiable, etc. Como factores internos los administradores del software esperan que el sistema sea fcil de modificar y extender, al igual que sea fcil de comprender, verificar, migrar (a diferentes ambientes de cmputo), etc. Quizs de todos estos aspectos, lo que ms se puede medir cuantitativamente es la cantidad de errores o defectos que resultan. Aunque en la prctica no se puede garantizar el software perfecto, o sea cero defectos, la pregunta es cundo el software es suficientemente bueno, y cuanto esfuerzo amerita invertir para eliminar defectos adicionales. Segn Yourdon los tres elementos ms importantes del software "suficientemente bueno" son funcionalidad ("feature richness"), calidad y tiempo (schedule) como se muestra en la Figura 1.1. Cualquier cambio en uno de estos aspectos afecta a los otros.
Funcionalidad

Calidad

Tiempo

Figura 1.1 Diagrama de calidad versus funcionalidad versus horario del software. Actualmente la situacin es tan extrema que en el apogeo de la guerra de "browsers" entre Netscape y Microsoft se competa por quien liberaba ms rpido su siguiente browser, agregando cada vez mayor funcionalidad, con ciclos de desarrollos de slo unos pocos meses. Esto obviamente afect la calidad del producto significando muchos errores en los nuevos "browsers" que no fueron depurados de manera adecuada, volvindose el usuario el encargado de probar realmente el software y encontrar sus errores. En 1997 errores de seguridad en Netscape y Explorer 4.0 hicieron que las compaas revisaran sus programas y los quitaran temporalmente del mercado. Situaciones similares son comunes en la actualidad. Lo peor del caso es que ante la opcin de escoger entre un software perfecto, con cero defectos o una versin ms nueva con todo lo novedoso, pero que pudiera tener algunos errores, la gente siempre quiere la nueva. En cierta manera nosotros mismos impulsamos el deterioro en la calidad del software comercial. La famosa frase "ms rpido, ms barato, mejor" realmente significa en la actualidad "suficientemente rpido, suficientemente barato, suficientemente bueno". 1.2.3 La Bala de Plata ("Silver Bullet") En 1975 Fred Brooks, "el padre del Sistema 360 de IBM", escribi su famoso libro "The Mythical Man-Month" en el cual resaltaba la complejidad en el desarrollo de sistemas de software; un clsico an hoy en da vuelto a publicar en 1995 para su vigsimo aniversario. El sistema operativo OS/360 de IBM escrito en la dcada de los 60 tuvo en su apogeo 1000 personas trabajando al mismo tiempo en el proyecto, incluyendo programadores, documentadores, operadores, secretarias, administradores y dems. Entre 1963 y 1966 se calcul que se utilizaron para el diseo, construccin y documentacin del sistema 5000 aos-persona. Calculado a 100 lneas/persona/mes esto sera equivalente a 5,000x100x12 = 6 millones de lneas. Este sistema es el precursor de MVS/370 y MVS/390 an utilizado por los mainframes de IBM. Uno de sus ms conocidos legados es la famosa "Ley de Brooks" que resalta que cuanto ms gente se agregue a un proyecto de software ya retrasado ms se retrasa el proyecto, como se muestra en la grfica de la Figura 1.2.

Weitzenfeld: Captulo 1

Tiempo

Nmero de Programadores

Figura 1.2 Ley de Brooks: cuanto ms se aumente el nmero de trabajadores mayor el tiempo de desarrollo. La razn para esto se basa en que las necesidades de personal se calculan inicialmente segn una simple medida de lneas de cdigo producidas por una persona al mes (el estndar actual es aproximadamente de 100 a 1,000 lneas por personas al mes), lo cual significara que si un proyecto requiere 10 millones de lneas, simplemente se puede dividir por los meses y personas que se requieren para lograr esa cantidad y si llegase a haber un retraso, simplemente se pueden agregar ms personas en base a un clculo similar. Sin embargo, esto no funciona as en la realidad. La razn principal de esto es que a las nuevas personas hay que entrenarlas y explicarles el proyecto. Significa que se quita temporalmente personal ya involucrado en el proyecto para dedicarle a las nuevas contrataciones, causando que el proyecto se retrase an ms. Pero esta ley no es el legado ms importante de Fred Brooks para la computacin. Brooks ha contribuido con muchas ideas, incluso algunas controversiales. En 1987 (IEEE Computer, Abril 1987) public su ya clebre artculo "No Silver Bullet" en el cual menciona: "..segn miramos al horizonte de una dcada, no vemos ninguna bala de plata. No existe un solo desarrollo, en la tecnologa o tcnica de administracin, que por si slo prometa incluso una mejora de un orden de magnitud en productividad, seguridad (reliability), simplicidad, dentro de una dcada". En otras palabras, no hay nada que permita mejorar la calidad del software de manera radical. 1.2.4 Ciclo de Vida del Software Para apreciar esto es necesario comprender un poco ms en qu consiste desarrollar software. Un sistema de software tiene un ciclo de vida que comienza con la formulacin de un problema, seguido por la especificacin de requisitos, anlisis, diseo, implementacin, verificacin, validacin, integracin y pruebas del software, continuado de una fase operacional durante la cual se mantiene y extiende el sistema. Todo desarrollo de software incluye aspectos esenciales, como la creacin de las estructuras que resuelvan el problema, junto con aspectos secundarios ("accidentales"), como la codificacin y las pruebas. Segn Brooks, existe una regla emprica ("thumb rule") que dice que para el desarrollo de un proyecto de software se debe asignar, 1/3 del tiempo a la planeacin, 1/6 a codificacin, 1/4 a pruebas de componentes, y 1/4 a pruebas del sistema, como se muestra en la Figure 1.3. O sea, la mitad del esfuerzo (2/4) son dedicados a pruebas lo cual tambin incluye la depuracin y aspectos secundarios del software.

1/6 Codificacin

1/4 Pruebas Componentes

1/3 Planeacin

1/4 Pruebas Sistema

Figura 1.3 Estimado general del tiempo dedicado al desarrollo de un proyecto de software. La mayora de las mejoras en la productividad del sofware se han dado histricamente simplificando las tareas secundarias como las herramientas, ambientes y lenguajes de programacin. Segn la premisa de Brooks, a menos

Weitzenfeld: Captulo 1

10

que lo secundario fuese ms de 9/10 del esfuerzo total, reduciendo estas actividades a cero no resultara en un orden de magnitud de mejora. Ya que ste no es el caso, sera necesario tambin reducir el tiempo dedicado a lo esencial. Entonces, como hacer para mejorar tan radicalmente la productividad del software? El autor muestra cierto pesimismo, y lamentablemente bastante realismo. Todo esto es un reflejo de que los sistemas de software son muy complejos, pudiendo contar con muchos millones de lneas de cdigo. Esta complejidad requiere de un proceso de desarrollo de software eficiente y sistemtico, con base a buenas metodologas y herramientas de apoyo. Como no se puede eliminar la complejidad, por lo menos se podr reducirla a un nivel manejable. Otro famoso autor y tecnlogo, Ed Yourdon discute en su libro "Rise and Resurrection of the American Programmer" en 1996 (una revisin a su libro anterior titulado "Decline and Fall of the American Programmer, 1993), que aunque no hay un slo desarrollo que sea la "bala de plata", s se pueden ver varios aspectos que juntos pueden dar ese incremento en orden de magnitud. En particular, l da nfasis en la cuestin humana ("peopleware"), proceso de software, tecnologa de objetos, reuso y mtricas de software. Estos temas han sido tratados por mltiples autores, algunos ms optimistas que otros. Considerando que es inevitable seguir desarrollando software, veamos qu se puede hacer. Analicemos en el resto de la introduccin de este libro los aspectos ms relevantes en la actualidad, del software orientado a objetos (Captulo 2) y del proceso de software (Captulo 3).