El Problema del Año 2000 y su Gravedad

por Juan C. Vázquez
jvazquez@bbs.frc.utn.edu.ar


 
 
INTRODUCCIÓN 
 

Las computadoras electrónicas comenzaron recién en la década del sesenta a ser utilizadas por las grandes corporaciones multinacionales y las administraciones gubernamentales, únicos clientes con el potencial económico suficiente como para acceder a estas novedosas y muy costosas herramientas, para apoyar sus sistemas de información.

La tecnología de aquella época, ofrecía una capacidad de almacenamiento de información muy limitada; debemos recordar que eran comunes como soporte de datos, las tarjetas y cintas de papel perforadas en sus inicios y, sólo posteriormente, las cintas magnéticas y los discos rígidos; pero aún para utilizar estos últimos, se requería equipamiento del orden del millón de dólares para acceder a capacidades de tan sólo cien megabytes (esto es aproximadamente cien millones de símbolos). Hablamos de un costo promedio de ¡10.000 dólares por megabyte de almacenamiento!, en el mejor de los casos.

Los registros en que se informaban los movimientos de datos, por ejemplo de transacciones bancarias o las altas de cuenta, debían ser codificados usualmente en los escasos ochenta símbolos que ofrecían las tarjetas perforadas. Esto trajo como consecuencia que los programadores utilizaran todo tipo de artilugios lógicos para comprimir lo más posible la información, utilizando códigos compactos para la representación de datos reales, definiendo abreviaturas estándares, y ..., naturalmente, no colocando las innecesarias barras y el "19" que identifica al siglo veinte, en el formato de las fechas perforadas en las tarjetas y almacenadas en los discos.

A principios de la década el setenta, se desarrollan los primeros microprocesadores pero debe esperarse hasta el inicio de los ochenta para que esta tecnología se vuelva masiva con el lanzamiento de la primera computadora personal (PC) estándar. En sus primeros modelos, estos equipos incluían discos duros de cinco y diez megabytes y debía pagarse por ellos aproximadamente diez mil dólares, a razón de ¡1.000 dólares el megabyte!. Esto representó un furor sin precedentes en la industria electrónica; aún las pequeñas y medianas empresas podían ahora hacer uso de la tecnología de la computación. Sin embargo el almacenamiento seguía siendo un problema, por lo cual los sistemas siguieron utilizando técnicas sofisticadas de codificación e inclusive se idearon herramientas de compactación más poderosas.

La transmisión de datos inició, también en los ochenta, su crecimiento sostenido con los primeros equipos de comunicación de bajo costo (los modems o conversores analógico/digitales de señales), que permitieron utilizar las líneas telefónicas usuales para enviar y recibir transacciones y archivos completos entre las sucursales de una empresa, entre clientes y proveedores, entre reparticiones públicas, etc., ubicados a cualquier distancia. El costo de las comunicaciones telefónicas fue, sin lugar a dudas, otro factor que reforzó la necesidad de mantener los datos y las fechas codificadas y comprimidas lo más posible.

Recién a fines del siglo veinte, la tecnología ha logrado bajar el costo del almacenamiento de datos a ¡menos de cinco centavos de dólar el megabyte!. Se ha producido un salto cuantitativo y cualitativo de impresionantes proporciones en la tecnología de almacenamiento, bajando en casi cinco órdenes de magnitud el costo del mismo en sólo cuarenta años, aumentando su confiabilidad y durabilidad en similar magnitud. Las comunicaciones también han experimentado este progreso; la fibra óptica, las nuevas técnicas de compresión, los satélites, la digitalización de las comunicaciones telefónicas, la consolidación de ciertas normativas internacionales, etc., dan clara cuenta de ello. Incluso se ha llegado a comparar el impacto que la actual Internet está produciendo sobre la humanidad, con la invención de la imprenta.

 
 
EL PROBLEMA!
Sin embargo, este impresionante avance de la tecnología informática en lo referente al hardware, ha sido acompañado tímidamente por el software de aplicación, esto es, los programas que hacen utilizable y práctico al nuevo y poderoso equipamiento electrónico.

En particular, muchos de los sistemas desarrollados en los últimos cuarenta años han sido transportados casi sin cambios de equipo en equipo, aprovechando las nuevas capacidades y velocidades de los mismos, pero manteniendo básicamente el diseño inalterado; en particular, el formato de fechas establecido como un número de seis dígitos DDMMAA (o cualquiera de sus variantes, según el país de que se trate), con dos dígitos para representar el día, dos para el mes y dos para el año, ha llegado como un estándar de facto hasta nuestros días.

La decisión de utilizar dos dígitos para el año como característica de diseño, fue transmitida de generación en generación de programadores, los que recibían como herencia las enseñanzas y los sistemas en funcionamiento de sus predecesores. Hoy en día hay, BILLONES de dólares invertidos en todo el mundo en investigación y desarrollo de sistemas que están funcionando correctamente, ... pero que quizás dejen de hacerlo el primero de enero del año 2000.

La antigüedad de un empleado en su cargo, los intereses a pagar en plazos fijos y a cobrar en créditos otorgados, el vencimiento de las especialidades medicinales, la obsolescencia del equipamiento en un sistema de mantenimiento de fábrica, la validez de un archivo en cinta, las catalogaciones de propiedades por antigüedad y muchos otros tópicos comerciales y administrativos, son controlados por sus fechas.

Pero el problema no se circunscribe estrictamente a los sistemas comerciales y de administración. Infinidad de sistemas específicos (como los de control de vuelo en aeropuertos, de tele control de estaciones reductoras de gas, de válvulas en oleoductos, de tendidos de la red eléctrica, de equipos de conmutación de paquetes en redes de telefonía pública, etc., por nombrar sólo algunos) requieren para su funcionamiento algún cálculo de tiempo y, dependiendo de cómo éste esté implementado, podrían fallar si se presenta un año cero en algún momento.

Por otro lado y a un nivel más cotidiano, la lógica embebida en la electrónica de una lavadora de ropa, en el sistema de inyección de combustible de un moderno automóvil, en el control de presurización de un avión de línea, en su reloj pulsera o en el de su computadora hogareña, en el aparato de Rayos X o en la Cámara Gama de su centro de salud, etc., podría contener rutinas de manejo de fechas para su funcionamiento que en el año 2000 producirán resultados impredecibles.

No hace falta ser muy imaginativo para ver que el problema del año 2000 nos afectará a todos. Revise la fecha de vencimiento de su tarjeta de crédito o de su licencia de conducir, las fechas relevantes de su recibo de haberes, de su cédula de identificación o de su resumen bancario; en muchos de ellos encontrará el año expresado en dos dígitos y es muy posible, que no sea sólo un error de impresión.

Pero en lo referido estrictamente al ámbito informático, si el problema es sólo la costumbre de colocar dos dígitos para el año, ¿porqué no colocar en todos los archivos y programas el año con cuatro dígitos y ya?. El problema es que, ¡ese no es el problema!.

Los técnicos informáticos sabemos cómo modificar la lógica de nuestras rutinas para soportar el cambio de milenio, e inclusive, existen algunas metodologías bien estipuladas y probadas al respecto. Los problemas reales que existen al enfrentar la reparación de un sistema que está en funcionamiento desde hace tiempo son, por ejemplo:

 y muchos otros por el estilo. Aquí reside el real problema !!!

Por otro lado, el tiempo en que debe hacerse toda la reparación, no admite aplazamientos. Al 31/12/1999 deben estar todos los sistemas modificados y probados (en muchas aplicaciones, aún antes de esta fecha ya que cualquier transacción real a plazo – plazos fijos, pagos en cuotas, previsiones de fondos, créditos hipotecarios, etc. – involucran fechas a futuro que actualmente pueden estar sobrepasando el 1999). Es más, para algunos analistas financieros e impositivos, la fecha límite la constituye el primero de Junio de 1999, fecha de inicio del año fiscal.

 
 
GRAVEDAD
El problema puede ser subestimado por el público en general, pero de ninguna forma por los entes decisores, tanto de las empresas privadas como de las administraciones públicas. Ellos son en última instancia, los responsables de los problemas que puedan generar los sistemas que funcionan en las dependencias a su cargo.

Estas responsabilidades no sólo son operativas o morales. Los abogados están esperando ansiosos el inicio de los litigios que ya se vislumbran, por la negligencia de no abordar a tiempo el problema del año 2000. Inclusive se está sentando jurisprudencia en algunos países al respecto, ya que las empresas y gobiernos están requiriendo en sus contratos de adquisición de nuevos equipamientos y productos de software, certificación de compatibilidad con el año 2000.

Esta modalidad no se limita al ámbito informático; el equipamiento biomédico de alta complejidad, por ejemplo, es un caso testigo que está siendo desde hace ya algún tiempo controlado por la "Food and Drugs Administration" de los Estados Unidos de América, la cual ha publicado numerosos artículos al respecto efectuando recomendaciones diversas sobre los controles que se deben efectuar y sobre las modalidades de contratación que dejan a resguardo de futuros juicios a los facultativos y centros de salud. Sería catastrófico que un modelo de Bomba de Cobalto o de Cámara Gamma no detuviera a tiempo su funcionamiento por un cálculo que no contemplara el nuevo milenio. ¡Aquí hay vidas humanas en juego y no sólo dinero!. No puede dejarse su control y solución al azar.

Otro ejemplo de problemas en ámbitos no informáticos, lo constituyó una prueba que se llevó a cabo en una central eléctrica del Reino Unido; se simuló en la misma, estar ya en el año 2000 para ver cómo respondían todos los sistemas. El resultado fue que la central entró en estado de "protección automática" cuando el sensor de los gases de combustión no pudo calcular la temperatura media de los gases en el lapso de treinta segundos, porque no reconoció la fecha y hora post-milenio.

Por otro lado, no hace falta profundizar sobre las implicaciones que podrían tener los errores de software debido al año 2000, sobre el equipo de defensa de las Fuerzas Armadas de los distintos países. Un error en el sistema de mantenimiento de misiles intercontinentales, el bloqueo de los sensores planetarios y/o satelitales de ubicación de fuerzas enemigas, desperfectos en los sistemas de posicionamiento global, etc., podrían ser tomados por los sistemas automáticos de defensa como indicios de un ataque electrónico, ... y procederían en consecuencia.

Son innumerables los problemas que se pueden presentar en los más diversos ámbitos; pero volvamos a lo estrictamente informático y al ámbito empresarial y administrativo. Señalaré en lo que sigue, tres aspectos distintos referidos a la gravedad del problema que nos ocupa: el económico, el temporal y el de recursos humanos.
 

 

Gravedad Económica


Desde el punto de vista económico, las empresas tendrán que atender tres principales fuentes de posibles gastos, producidos por el problema del año 2000:

 

 

Gravedad Temporal


No todos los sistemas tendrán problemas con las fechas y, de los que los tengan, no todos serán procesos críticos; por esto, es importante evaluar el impacto que el nuevo milenio traerá sobre cada programa de cada sistema, delinear una solución potable y comenzar su desarrollo e implementación cuanto antes, comenzando por los sistemas críticos.

La gravedad del problema pensando en la faceta temporal del trabajo que se debe realizar, reside precisamente en que ya no hay casi tiempo para hacerlo.

Tomemos una empresa imaginaria como ejemplo. Si esta empresa cuenta con sistemas de, digamos, mil programas construidos en un determinado lenguaje de programación, deberá entre otras cosas:

Sólo teniendo en cuenta los mil programas a revisar (dejando de lado los problemas de coordinación del proyecto, el mantenimiento de los actuales sistemas en producción, el estudio del equipamiento, la búsqueda del personal adecuado, etc., cosa que puede demorar meses el inicio del proyecto), puede pensarse que un programador experimentado tardará no menos de un día de trabajo para revisar de uno a tres programas (según su complejidad), entender lo que hacen, determinar los campos y variables de probable conflicto, estudiar las estructuras de datos externas y cómo éstas son actualizadas por los programas, delinear las modificaciones según la metodología definida para el proyecto, codificarlas apropiadamente, probarlas, implementarlas y actualizar cierta documentación de control y gestión.

Con estos supuestos, este programador experimentado tardará, sólo trabajando en este proyecto su jornada completa, en promedio, quinientos días hábiles (aproximadamente veinticinco meses) para efectuar la modificación completa de los sistemas, con lo cual si empieza hoy mismo, acabará aproximadamente en Mayo del 2001, fecha en la cual todos los perjuicios indicados ya habrían sido producidos. Se pensaría entonces en contratar otro programador para el proyecto con el fin de terminarlo en doce meses y medio, o mejor aún, ... contratar veinticinco programadores experimentados (si los hubiere) para terminar el proyecto en un mes !!!

Los profesionales informáticos saben que esto no es posible (y no sólo en informática; si un médico realiza un transplante de corazón en nueve horas no se cumple que nueve médicos lo harán en una hora; si un ingeniero y su equipo de trabajadores construyen una represa en seis meses, por más ingenieros y trabajadores que se asignen al proyecto, la represa no podrá construirse respetando las normas de calidad en una semana); el incremento de programadores en un proyecto de sistemas, intrínsecamente trae consigo mayor complejidad en la coordinación del mismo, mayores controles de compatibilidad y coherencia entre el trabajo de unos y otros, problemas de comunicación interpersonal, diferentes reglas mnemónicas que atender, etcétera, etcétera. Estos hechos incrementan en forma exponencial el tiempo de desarrollo cuando los programadores exceden un núcleo de tres o cuatro personas, por lo cual las estimaciones de tiempo lineales no son aplicables. Mientras más gente trabaje programando, mayor deberá ser el tiempo de análisis y especificación de tareas, previo a la etapa de codificación, y mayor será la tarea de coordinación.

En resumen, con un poco de suerte y viento en popa, asignando todos los recursos necesarios para el proyecto, si inicia ya las tareas pertinentes nuestra "empresa ejemplo de mil programas" terminará la reparación de sus sistemas muy cerca del 31/12/1999, pero ... muy cerca.

 

 


Gravedad Personal

El problema de los recursos humanos, ha sido de alguna manera tratado en los anteriores párrafos en cuanto a su costo y su capacidad de efectuar trabajos de revisión y adecuación en el tiempo. Resta aquí, hacer un análisis de las distintas modalidades de contratación que se han ensayado hasta la fecha.

Las empresas pueden optar por tres modalidades básicas de atacar el problema:

Hay mucho escrito en innumerables trabajos bibliográficos o publicados en la Internet sobre estas modalidades y sus respectivas mezclas, pero es de consenso general, que ninguna de las tres alternativas enunciadas anteriormente funciona bien en su forma pura.

En general, y a esta altura de los acontecimientos (Octubre de 1998), se prefiere combinar la primera con la tercera, esto es, contratar un grupo externo de desarrollo altamente calificado, que no genere relación de dependencia laboral con la empresa, que traiga consigo experiencia en la problemática del año 2000 y en los diversos lenguajes de programación, que destine el tiempo adecuado a sus tareas sin interferir de manera significativa con el normal desenvolvimiento del área informática de la empresa, pero que interactúe fuertemente con el personal informático interno a los fines de establecer sutilezas de diseño en los sistemas, confrontar con ellos la metodología planteada para la solución y su factibilidad, efectuar pruebas conjuntas y, por último, que el personal interno conozca los cambios que se efectuaron para poder luego seguir el normal mantenimiento de los sistemas en forma autónoma.

Cabe señalar, finalmente, que estos grupos de desarrollo son también escasos y caros, por lo cual debo insistir: no hay tiempo que perder para iniciar el desarrollo de la solución al problema, cuando antes se haga mayor será la probabilidad de llegar a tiempo con los sistemas corregidos y menor será el gasto total del proyecto.

 

U.T.N. - Facultad Córdoba - Dpto. de Ingeniería en Sistemas de Información
Argentina - Octubre de 1998 - Juan C. Vázquez
jvazquez@bbs.frc.utn.edu.ar