Fragilidad del software

En programación informática e ingeniería de software , la fragilidad del software es la mayor probabilidad de que un software que antes parecía fiable ahora falle (se rompa) al recibir datos nuevos e inusuales que se alteran de alguna manera, generando un error lógico o semántico no detectado durante las pruebas iniciales del software . La frase se deriva de analogías con la fragilidad en la metalurgia . ^{[ 1 ] [ 2 ] [ 3 ]} Debido a la variedad de sistemas complejos como la electrónica analógica , la electrónica digital , la instrumentación , la robótica , el diseño de software , la heurística , la IA y más, la definición general es que cualquier sistema complejo que no pueda mantener el control debido a un pequeño cambio dentro del rango de operación esperado se consideraría frágil, rompible y, por lo tanto, "quebradizo". Cualquier sistema complejo que se lleve más allá de sus límites de control de diseño probablemente no se considerará quebradizo.

Cuando un software es nuevo, es muy maleable; puede adaptarse a cualquier necesidad de sus desarrolladores. Sin embargo, a medida que el software de un proyecto crece y desarrolla una base de usuarios más amplia con experiencia, se vuelve menos maleable. Como un metal endurecido por el uso, el software se convierte en un sistema obsoleto , frágil e imposible de mantener sin dañar todo el sistema.

La fragilidad del software puede deberse a algoritmos poco desarrollados que, si bien funcionaron correctamente con todos los datos de entrada en el momento de su creación, fallan rápidamente al enfrentarse a nuevos datos que se esperaba que el algoritmo pudiera procesar correctamente. A continuación, se presentan algunos ejemplos:

• Un buen ejemplo es un algoritmo con una gestión de errores inadecuada que permite una división por cero , o una ecuación de ajuste de curvas que se utiliza para extrapolar más allá de los datos a los que se ajustó. Otra causa de fragilidad es el uso de estructuras de datos que restringen los valores. Esto se observó comúnmente a finales de la década de 1990, cuando la gente se dio cuenta de que su software solo tenía espacio para una entrada de año de dos dígitos ; esto llevó a la actualización repentina de enormes cantidades de software frágil antes del año 2000. ^{[ 4 ]}
• Otra forma más común de fragilidad se presenta en las interfaces gráficas de usuario que parten de suposiciones erróneas. Por ejemplo, un usuario que utiliza una pantalla de baja resolución puede ver cómo el software abre una ventana demasiado grande para la pantalla . También puede ocurrir lo contrario: una ventana demasiado pequeña para la pantalla, sin posibilidad de redimensionarla, o una ventana cuyos elementos no se ajustan correctamente porque la suposición de los desarrolladores sobre la resolución ya no es cierta. Otro problema común se manifiesta cuando un usuario utiliza una combinación de colores distinta a la predeterminada , lo que provoca que el texto se muestre del mismo color que el fondo, o cuando utiliza una fuente distinta a la predeterminada, que no cabe en el espacio permitido y recorta las instrucciones y etiquetas.

A menudo, un código fuente antiguo, que puede basarse en suposiciones erróneas o tecnologías obsoletas, simplemente se abandona en favor de un código fuente nuevo creado desde cero ( es decir, reescrito ), que puede estar libre de muchas de las cargas del sistema heredado, pero esta solución puede ser un proceso costoso y que consume mucho tiempo.

Algunos ejemplos y razones de la fragilidad del software:

• Los usuarios esperan una interfaz de usuario relativamente constante . Una vez que una función se ha implementado y se ha puesto a disposición de los usuarios, es muy difícil convencerlos de que acepten cambios importantes en dicha función, incluso si esta no estaba bien diseñada o si su existencia obstaculiza el progreso.
• Existe mucha documentación que describe el comportamiento actual, y su modificación resultaría costosa. Además, es prácticamente imposible recuperar todas las copias de la documentación existente, por lo que es probable que los usuarios sigan consultando manuales obsoletos.
• Los desarrolladores originales, que conocían todos los detalles del software, se han marchado y han dejado documentación insuficiente sobre dichos detalles. Muchos de ellos se transmitieron oralmente entre los miembros del equipo de diseño, y gran parte de esa información se ha perdido irremediablemente, aunque algunos pueden redescubrirse mediante la laboriosa (y costosa) aplicación de la arqueología del software .
• Es probable que a lo largo de los años se hayan publicado parches que han modificado sutilmente el comportamiento del software. En muchos casos, estos parches, si bien corrigen el fallo evidente para el que fueron publicados, introducen otros fallos más sutiles en el sistema. Si no se detectan mediante pruebas de regresión , estos fallos sutiles dificultan las modificaciones posteriores del sistema.
• Las formas más sutiles de fragilidad son comunes en los sistemas de inteligencia artificial . Estos sistemas suelen basarse en suposiciones importantes sobre sus datos de entrada, y luego se crean algoritmos y heurísticas que, supuestamente, procesan correctamente dichos datos. Sin embargo, cuando estas suposiciones no se cumplen o se descubre que son erróneas, estos sistemas, que contienen algoritmos incompletos, terminarán respondiendo (fallando) de forma impredecible al enfrentarse a datos de entrada no probados.
• Los sistemas también pueden ser frágiles si las dependencias entre componentes son demasiado rígidas . Un ejemplo de esto se observa en las dificultades para migrar a nuevas versiones de las dependencias . Cuando un componente espera que otro genere solo un rango determinado de valores, y ese rango cambia, puede provocar que los errores se propaguen por todo el sistema, ya sea durante la compilación o en tiempo de ejecución .
• Se dispone de menos recursos técnicos para dar soporte a los cambios cuando un sistema está en mantenimiento, en comparación con la fase de desarrollo (en términos del ciclo de vida del desarrollo de sistemas (SDLC) ).

• Sistema frágil
• entropía del software
• Podredumbre del software
• Robustez (informática)
• deuda técnica

• Robert E. Filman; Tzilla Elrad; Siobhán Clarke ; Mehmet Aksit (2004). Gestión de dependencias orientada a aspectos . Addison Wesley Professional. ISBN 0-321-21976-7.{{cite book}}: CS1 maint: servicio de archivado obsoleto ( enlace )
• Virginia Postrel (1999). "Fantasías de poder: el extraño atractivo del  problema de transición del error Y2K al año 2000" . Reason . Archivado del original el 10 de septiembre de 2005. Consultado el 25 de julio de 2008 .