fbpx

Ya a finales de la década de 1960, en los albores de la naciente industria del software, se reunieron en Garmisch Alemania personalidades de la industria y la academia de distintas partes del mundo para describir lo que llamaban “crisis del software” (Por cierto, precisamente en esa reunión se acuñó el término “Ingeniería de Software”).

Desde entonces, se ha podido observar una problemática en la industria del software que incluye lo siguiente:

  • Un incremento en la demanda, originada no solamente por la necesidad de desarrollo de software “convencional” para una cantidad creciente de áreas de aplicación, sino también para los legacy systems y el embedded software.
  • Un incremento en la complejidad, debido a que los sistemas son cada vez más grandes y complejos, llegando a involucrar cada vez más la integración de software, firmware y hardware.
  • Una mayor exigencia por la calidad, acentuada en buena medida por la globalización y el incremento en la “cultura informática” de los consumidores de software, pero también por la necesidad creciente de lo que denominamos software crítico (aquel que, si falla, literalmente alguien se muere).

Esta problemática origina que, por ejemplo, tan solo en los Estados Unidos en 2003, las pérdidas en su industria originadas por productos de software que funcionaron inadecuadamente ascendieron a casi $60,000 millones de dólares, que equivalieron aproximadamente al 1% de su Producto Interno Bruto de ese año.

Esas pérdidas consideran no solamente las del sector de tecnologías de información, sino de muchos otros sectores que utilizan el software en sus operaciones. Se trata de pérdidas que no son sólo cuantiosas, sino que permean gran parte de su sector productivo.

Más recientemente, en abril del 2014, fue detectado un bug, el Heartbleed, en el OpenSLL (versiones OpenSLL 1.1.1 hasta 1.0.1f), una de las librerías de criptografía más utilizadas en la World Wide Web. Dada la seriedad de la falla, incluso se lanzó una página dedicada a este bug (Heartbleed.com), en la que se describe en qué consistió el fallo y se responden algunas de las preguntas más frecuentes. Lo delicado del asunto radicó en que volvía vulnerables aplicaciones tales como el correo electrónico, la mensajería instantánea, algunas redes virtuales privadas (VPN) y la propia web, ya que permitía acceder a claves, contraseñas, nombres y contenidos.

Por otra parte, en el mes de julio de 2015, hubo tres incidentes sin precedente en los Estados Unidos: Primero, los aviones de United Airlines no pudieron despegar por un fallo informático que paralizó unos 3,500 de sus vuelos, por aproximadamente tres horas y media, provocando retrasos en vuelos tanto domésticos como internacionales. Poco tiempo después, otro fallo dejaba al NYSE –la Bolsa de Nueva York– sin cotizar durante casi cuatro horas, y Wall Street tomó la decisión de detener la actividad y cancelar todas las órdenes de compra y venta. Por último, pero casi a la misma hora, el sistema del Wall Street Journal –el periódico económico de referencia en la Unión Americana–  se caía.

Es poco probable que tres fallos de esta envergadura coincidan, pero resulta que los fallos en los sistemas no son poco comunes: De acuerdo con lo señalado por el diario español El País en ese mismo año (2015), según un estudio realizado por la EMC Corporation (ahora DELL EMC), cada año se acumulan pérdidas por 1.7 billones de dólares por fallos que dejan a las empresas fuera de servicio y se pierde una media de 25 horas de trabajo por los paros de actividad derivado de los fallos informáticos. El diario señala, además, que otros estudios aportan incluso el impacto económico por sectores de estos fallos. Por ejemplo, Network Computing, The Meta Group y Contingency Planning Research apuntan que las empresas de servicios financieros son las que más riesgo corren, pudiendo perder hasta 6.4 millones de dólares por hora. Le siguen las de energía con 2.8 millones, las empresas de telecomunicaciones, 2 millones; las manufactureras, 1.6 millones, el retail (ventas al por menor) 1.1 millones, el sector salud 636,000 dólares y el sector media, 90,000.

En México no tenemos estadísticas como las anteriores, pero es posible pensar en un comportamiento parecido. Sin embargo, en nuestro país el efecto es mucho más nocivo, ya que mientras que la industria del software estadounidense es mucho más grande y madura, la nuestra se encuentra más bien en desarrollo, lo que hace difícil ganar una inercia positiva en muchos sentidos: el crecimiento de la industria se vuelve más lento, se dificulta generar confianza en las tecnologías de información y comunicación, lo que hace más difícil la atracción de inversiones en empresas tecnológicas, lo que a su vez dificulta el crecimiento… un indeseable circulo vicioso.

Sin pretender ser exhaustivos, listamos los siguientes como algunos de los enfoques más relevantes que a lo largo de décadas han sido planteados por distintos actores para abatir la problemática descrita:

  • Incremento en la demanda:
    • Ofrecer herramientas y capacitación para desarrolladores y no desarrolladores.
    • Facilitar el reúso de componentes, que permita construir software a partir de elementos maduros.
  • Incremento en la complejidad:
    • Ofrecer ambientes de desarrollo que brinden mayor nivel de abstracción.
    • Desarrollar metodologías que faciliten la descomposición de problemas.
  • Exigencia en la calidad: ofrecer marcos como…
    • el Total Quality Management (TQM) con fuerte énfasis en el incremento de la calidad (satisfacción de requerimientos) a través de los empleados, una buena planeación estratégica, y el control estadístico de procesos;
    • las normas ISO 20000 y 25000 (Gestión de Servicios de TI, y Requisitos y Evaluación de Calidad de Productos de Software, respectivamente);
    • los modelos de calidad para software (CMMI, MoProSoft, etc.), centrados en la definición y mejora de procesos en áreas clave del desarrollo de software;
    • metodologías ágiles para el desarrollo de software como DevOps y Scrum;
    • los métodos formales (usados principalmente para desarrollar software crítico), que por construcción, permitan desarrollar software libre de defectos;
    • la prueba de software, que permita detectar anomalías en un producto de software (la mayor cantidad posible, lo más nocivas posible, lo antes posible).
                                                                 

Síguenos en :

Facebook
Facebook
YouTube
LinkedIn