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.

A medida que el software crece en alcance y número de usuarios sin ningún tipo de mantenimiento o refactorización , con el tiempo se convierte en un sistema heredado , frágil e imposible de mantener fácilmente sin fracturar 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.
• More subtle forms of brittleness commonly occur in artificial intelligence systems. These systems often rely on significant assumptions about their input data and then algorithms and heuristics , believed to correctly process this data, are created. However, when these assumptions aren't met or later found to be even flawed, then these systems containing incomplete algorithms will eventually respond (break) in unpredictable ways when confronted with untested inputs.
• Systems can also be brittle if the component dependencies are too rigid. One example of this is seen in the difficulties transitioning to new versions of dependencies. When one component expects another to output only a given range of values, and that range changes, then it can cause errors to ripple through the system, either during building (compiling) or at runtime.
• Fewer technical resources are available to support changes when a system is in maintenance, rather than during development (in terms of the Systems Development Life Cycle (SDLC)).

• Brittle system
• Software entropy
• Software rot
• Robustness (computer science)
• Technical debt

• Robert E. Filman; Tzilla Elrad; Siobhán Clarke; Mehmet Aksit (2004). Aspect-Oriented Dependency Management. Addison Wesley Professional. ISBN 0-321-21976-7.{{cite book}}: CS1 maint: deprecated archival service (link)
• Virginia Postrel (1999). "Power fantasies: the strange appeal of the Y2K bug – Year 2000 transition problem". Reason. Archived from the original on 2005-09-10. Retrieved 2008-07-25.