Fragilidad del software

En programación informática e ingeniería de software , la fragilidad del software es la mayor dificultad para reparar software antiguo que puede parecer confiable, pero que, en cambio, falla cuando se le presentan datos inusuales o datos que se modifican de una manera aparentemente menor. La frase se deriva de analogías con la fragilidad en la metalurgia . ^[1]

Causas

Cuando un software es nuevo, es muy maleable; se lo puede moldear para que sea lo que los implementadores deseen. Pero a medida que el software de un proyecto determinado crece cada vez más y desarrolla una base más grande de usuarios con una larga experiencia con el software, se vuelve cada vez menos maleable. Como un metal que se ha endurecido con el trabajo, el software se convierte en un sistema heredado , frágil e incapaz de ser mantenido fácilmente sin fracturar todo el sistema. ^{[ cita requerida ]}

La fragilidad del software puede deberse a algoritmos que no funcionan bien con toda la gama de datos de entrada. A continuación, se ofrecen algunos ejemplos:

Un buen ejemplo es un algoritmo que permite que se produzca 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 vio con frecuencia a fines 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 2 dígitos ; esto llevó a la actualización repentina de enormes cantidades de software frágil antes del año 2000. ^[2]
Otra forma de fragilidad que se encuentra con más frecuencia se da en las interfaces gráficas de usuario que hacen suposiciones no válidas. Por ejemplo, un usuario puede estar trabajando en una pantalla de baja resolución y puede observar que el software abre una ventana demasiado grande para caber en la pantalla . También podría darse el caso opuesto; por ejemplo, una ventana demasiado pequeña para la pantalla, sin la capacidad de cambiar de tamaño, o una ventana en la que los elementos no encajan correctamente, porque la suposición de los desarrolladores sobre la resolución ya no era cierta. Otro problema común se expresa cuando un usuario utiliza un esquema de color distinto al predeterminado , lo que hace que el texto se represente en el mismo color que el fondo, o un usuario utiliza una fuente distinta a la predeterminada, que no cabe en el espacio permitido y corta las instrucciones y las etiquetas.

Muy a menudo, una base de código antigua simplemente se abandona en favor de una completamente nueva (que pretende estar libre de muchas de las cargas del sistema heredado; también conocida como reescritura ) creada desde cero, pero este puede ser un proceso costoso y que requiere mucho tiempo.

Algunos ejemplos y razones detrás de la fragilidad del software:

Los usuarios esperan una interfaz de usuario relativamente constante . Una vez que se ha implementado una función y se ha expuesto a los usuarios, es muy difícil convencerlos de que acepten cambios importantes en esa función, incluso si la función no está bien diseñada o su existencia impide un mayor progreso.
Es posible que exista una gran cantidad de documentación que describa el comportamiento actual y que sea costoso modificarla. 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 implementadores originales, que conocían todos los detalles intrincados del software, se fueron y dejaron una documentación insuficiente de dichos detalles intrincados. Muchos de esos detalles solo se transmitieron a otros a través de tradiciones orales del equipo de diseño, muchas de las cuales finalmente se perdieron irremediablemente, aunque algunas se pueden redescubrir mediante la aplicación diligente (y costosa) de la arqueología del software .
Probablemente se han publicado parches a lo largo de los años que modifican sutilmente el comportamiento del software. En muchos casos, estos parches, si bien corrigen el error evidente para el que se publicaron, introducen otros errores más sutiles en el sistema. Si no se detectan mediante pruebas de regresión , estos errores sutiles dificultan la realización de cambios posteriores en el sistema.
En los sistemas de inteligencia artificial , se dan con frecuencia formas más sutiles de fragilidad . Estos sistemas suelen basarse en suposiciones importantes sobre los datos de entrada. Cuando estas suposiciones no se cumplen, tal vez porque no se enunciaron (como suele suceder), el sistema responderá de maneras completamente impredecibles.
Los sistemas también pueden volverse frágiles si las dependencias de los componentes son demasiado rígidas . Un ejemplo de esto se ve en las dificultades para realizar la transición a nuevas versiones de las dependencias . Cuando un componente espera que otro muestre solo un rango determinado de valores, y ese rango cambia, puede provocar que los errores se propaguen por el sistema, ya sea durante la construcción ( compilación ) o en tiempo de ejecución . ^{[ cita requerida ]}
Hay menos recursos técnicos disponibles para respaldar los cambios cuando un sistema está en mantenimiento, en lugar de durante el desarrollo (en términos del Ciclo de vida del desarrollo de sistemas (SDLC) ^{[ cita requerida ]} ).

Véase también

Referencias

^ "Definición de fragilidad del software". PCMAG . Consultado el 19 de mayo de 2023 .
^ "Error del año 2000". education.nationalgeographic.org . Consultado el 19 de mayo de 2023 .

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. Archivado desde el original el 30 de enero de 2013.
Virginia Postrel (1999). «Fantasías de poder: el extraño atractivo del problema del efecto 2000: el problema de la transición al año 2000». Reason . Archivado desde el original el 10 de septiembre de 2005. Consultado el 25 de julio de 2008 .