La podredumbre del software ( podredumbre de bits , podredumbre de código , erosión del software , decadencia del software o entropía del software ) es la degradación, el deterioro o la pérdida del uso o el rendimiento del software a lo largo del tiempo.
Desde la perspectiva de la experiencia del usuario del software, se trata de una evolución del entorno operativo que incluye el hardware. La primera causa de la pérdida objetiva del uso práctico del software es la pérdida del sistema host como entorno operativo práctico.
The Jargon File , un compendio de conocimientos sobre hackers, define "bit rot" como una explicación jocosa de la degradación de un programa de software a lo largo del tiempo incluso si "nada ha cambiado"; la idea detrás de esto es casi como si los bits que componen el programa estuvieran sujetos a la desintegración radiactiva. [1]
Varios factores son responsables de la degradación del software, incluidos los cambios en el entorno en el que opera el software, la degradación de la compatibilidad entre partes del propio software y la aparición de errores en código no utilizado o raramente utilizado.
Cuando se producen cambios en el entorno del programa, en particular cambios que el diseñador del programa no anticipó, el software puede dejar de funcionar como se pretendía originalmente. Por ejemplo, muchos de los primeros diseñadores de juegos de ordenador utilizaban la velocidad del reloj de la CPU como temporizador en sus juegos. [2] Sin embargo, los relojes de las CPU más recientes eran más rápidos, por lo que la velocidad de juego aumentaba en consecuencia, lo que hacía que los juegos fueran menos utilizables con el tiempo.
Existen cambios en el entorno que no están relacionados con el diseñador del programa, sino con sus usuarios. Inicialmente, un usuario podría poner el sistema en funcionamiento y hacerlo funcionar sin problemas durante un tiempo determinado. Pero, cuando el sistema deja de funcionar correctamente, o los usuarios quieren acceder a los controles de configuración, no pueden repetir ese paso inicial debido al contexto diferente y a la información no disponible (contraseña perdida, instrucciones faltantes o simplemente una interfaz de usuario difícil de manejar que se configuró primero por ensayo y error). El arquitecto de información Jonas Söderström ha denominado a este concepto Onceability [3] y lo define como "la cualidad en un sistema técnico que impide que un usuario restaure el sistema, una vez que ha fallado".
Las partes de código que se usan con poca frecuencia, como los filtros de documentos o las interfaces diseñadas para que las usen otros programas, pueden contener errores que pasan desapercibidos. Con los cambios en los requisitos del usuario y otros factores externos, este código puede ejecutarse más tarde, lo que expone los errores y hace que el software parezca menos funcional.
El mantenimiento normal de los programas y sistemas también puede provocar la degradación del software. En particular, cuando un programa contiene múltiples partes que funcionan de forma independiente entre sí, no tener en cuenta cómo los cambios en una parte que afectan a las demás pueden introducir errores.
En algunos casos, esto puede tomar la forma de bibliotecas que el software utiliza y que se modifican de una manera que afecta negativamente al software. Si la versión anterior de una biblioteca que funcionaba anteriormente con el software ya no se puede utilizar debido a conflictos con otro software o a fallas de seguridad que se encontraron en la versión anterior, es posible que ya no haya una versión viable de una biblioteca necesaria para que el programa la utilice.
El software comercial moderno suele conectarse a un servidor en línea para verificar la licencia y acceder a la información. Si se cierra el servicio en línea que alimenta el software, este puede dejar de funcionar. [4] [5]
Desde finales de la década de 2010, la mayoría de los sitios web utilizan conexiones seguras HTTPS . Sin embargo, esto requiere claves de cifrado llamadas certificados raíz que tienen fechas de vencimiento. Una vez que los certificados caducan, el dispositivo pierde la conectividad con la mayoría de los sitios web a menos que las claves se actualicen continuamente. [6]
Otro problema es que en marzo de 2021 los antiguos estándares de cifrado TLS 1.0 y TLS 1.1 quedaron obsoletos . [7] Esto significa que los sistemas operativos, navegadores y otro software en línea que no son compatibles al menos con TLS 1.2 no pueden conectarse a la mayoría de los sitios web, ni siquiera para descargar parches o actualizar el navegador, si están disponibles. A esto se le llama ocasionalmente el "apocalipsis TLS".
Entre los productos que no pueden conectarse a la mayoría de los sitios web se incluyen los PowerMac, los sistemas Unix antiguos y las versiones de Microsoft Windows anteriores a Server 2008/Windows 7 (al menos sin el uso de un navegador de terceros). El navegador Internet Explorer 8 en Server 2008/Windows 7 admite TLS 1.2, pero está deshabilitado de forma predeterminada. [8]
La descomposición del software generalmente se clasifica como "descomposición latente" o "descomposición activa".
El software que no se utiliza en ese momento se vuelve poco a poco inservible a medida que el resto de la aplicación cambia. Los cambios en los requisitos de los usuarios y el entorno del software también contribuyen al deterioro.
El software que se modifica continuamente puede perder su integridad con el tiempo si no se aplican de manera consistente los procesos de mitigación adecuados. Sin embargo, gran parte del software requiere cambios continuos para cumplir con los nuevos requisitos y corregir errores, y la reingeniería del software cada vez que se realiza un cambio rara vez es práctica. Esto crea lo que es esencialmente un proceso de evolución para el programa, lo que hace que se desvíe del diseño original. Como consecuencia de esto y de un entorno cambiante, las suposiciones hechas por los diseñadores originales pueden quedar invalidadas, lo que introduce errores.
En la práctica, se puede dar prioridad a la incorporación de nuevas funciones por sobre la actualización de la documentación ; sin embargo, sin documentación, es posible que se pierdan conocimientos específicos sobre partes del programa. Hasta cierto punto, esto se puede mitigar siguiendo las mejores prácticas actuales para las convenciones de codificación .
El deterioro activo del software se ralentiza cuando una aplicación se acerca al final de su vida comercial y se detiene el desarrollo posterior. Los usuarios suelen aprender a solucionar los errores de software restantes y el comportamiento del software se vuelve uniforme, ya que nada cambia.
Muchos programas fundamentales de los primeros tiempos de la investigación en IA han sufrido una descomposición irreparable. Por ejemplo, el programa original SHRDLU (un programa de comprensión del lenguaje natural primitivo) no se puede ejecutar en ningún ordenador o simulador informático moderno, ya que se desarrolló cuando LISP y PLANNER todavía estaban en fase de desarrollo y, por lo tanto, utiliza macros no estándar y bibliotecas de software que ya no existen.
Supongamos que un administrador crea un foro utilizando un software de código abierto y luego lo modifica en gran medida agregando nuevas funciones y opciones. Este proceso requiere modificaciones importantes del código existente y desviaciones de la funcionalidad original de ese software.
Desde aquí, hay varias formas en las que el deterioro del software puede afectar al sistema:
Supongamos que un webmaster instala la última versión de MediaWiki , el software que impulsa wikis como Wikipedia, y luego nunca aplica ninguna actualización. Con el tiempo, es probable que el servidor web actualice sus versiones del lenguaje de programación (como PHP ) y la base de datos (como MariaDB ) sin consultar al webmaster. Después de un tiempo suficientemente largo, esto eventualmente dañará sitios web complejos que no se han actualizado, porque las últimas versiones de PHP y MariaDB tendrán cambios importantes ya que desactualizan por completo ciertas funciones integradas , rompiendo la compatibilidad con versiones anteriores y causando errores fatales . Otros problemas que pueden surgir con el software de un sitio web no actualizado incluyen vulnerabilidades de seguridad y spam .
La refactorización es un medio para abordar el problema de la descomposición del software. Se describe como el proceso de reescribir el código existente para mejorar su estructura sin afectar su comportamiento externo. [9] Esto incluye eliminar el código inactivo y reescribir las secciones que se han modificado ampliamente y ya no funcionan de manera eficiente. Se debe tener cuidado de no cambiar el comportamiento externo del software, ya que esto podría introducir incompatibilidades y, por lo tanto, contribuir a la descomposición del software. Algunos principios de diseño a tener en cuenta cuando se trata de refactorizar son mantener la estructura jerárquica del código e implementar la abstracción para simplificar y generalizar las estructuras del código. [10]