Este artículo tiene varios problemas. Ayude a mejorarlo o discuta estos problemas en la página de discusión . ( Obtenga información sobre cómo y cuándo eliminar estos mensajes de plantilla )
|
La descomposición del software , también conocida como descomposición de bits , descomposición del código , erosión del software , descomposición del software o entropía del software, es un deterioro lento de la calidad del software con el tiempo o su capacidad de respuesta decreciente que eventualmente conducirá a que el software se vuelva defectuoso, inutilizable o en necesidad de actualizar . Este no es un fenómeno físico: el software en realidad no se deteriora, sino que adolece de una falta de capacidad de respuesta y actualización con respecto al entorno cambiante en el que reside.
El Jargon File , un compendio de la tradición de los piratas informáticos, 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 desintegración radiactiva. [1]
Varios factores son responsables de la descomposición del software, incluidos los cambios en el entorno en el que opera el software, la degradación de la compatibilidad entre las partes del propio software y la aparición de errores en el código no utilizado o que se utiliza raramente.
Cuando se producen cambios en el entorno del programa, en particular cambios que el diseñador del programa no anticipó, es posible que el software ya no funcione como se pretendía originalmente. Por ejemplo, muchos de los primeros diseñadores de juegos de computadora usaban la velocidad del reloj de la CPU como temporizador en sus juegos. [2] Sin embargo, los relojes de CPU más nuevos eran más rápidos, por lo que la velocidad de juego aumentó en consecuencia, lo que hizo que los juegos fueran menos utilizables con el tiempo.
Hay cambios en el entorno no relacionados con el diseñador del programa, sino con sus usuarios. Inicialmente, un usuario podía poner el sistema en funcionamiento y hacerlo funcionar sin problemas durante un cierto período de tiempo. 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 la información no disponible (contraseña perdida, instrucciones faltantes o simplemente un usuario difícil de administrar). interfaz que se configuró por primera vez mediante prueba y error). El arquitecto de información Jonas Söderström ha denominado a este concepto Onceability , [3] y lo define como "la calidad en un sistema técnico que evita que un usuario restaure el sistema, una vez que ha fallado".
Las partes del código que se utilizan con poca frecuencia, como los filtros de documentos o las interfaces diseñadas para ser utilizadas por otros programas, pueden contener errores que pasan desapercibidos. Con cambios en los requisitos del usuario y otros factores externos, este código puede ejecutarse más tarde, exponiendo así los errores y haciendo que el software parezca menos funcional.
El mantenimiento normal del software y los sistemas también puede provocar que el software se pudra. En particular, cuando un programa contiene varias partes que funcionan a distancia unas de otras, no tener en cuenta cómo los cambios en una parte afectan a las otras puede introducir errores.
En algunos casos, esto puede tomar la forma de bibliotecas que utiliza el software que se modifican de una manera que afecta negativamente al software. Si la versión anterior de una biblioteca que anteriormente funcionaba con el software ya no se puede usar debido a conflictos con otro software o fallas de seguridad que se encontraron en la versión anterior, es posible que ya no exista una versión viable de una biblioteca necesaria para el programa. usar.
La pudrición del software generalmente se clasifica como podredumbre latente o podredumbre activa .
El software que no se utiliza actualmente se vuelve inutilizable gradualmente a medida que cambia el resto de la aplicación. Los cambios en los requisitos del usuario y el entorno del software también contribuyen al deterioro.
El software que se modifica continuamente puede perder su integridad con el tiempo si los procesos de mitigación adecuados no se aplican de manera consistente. 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 aparte del diseño de ingeniería original. Como consecuencia de esto y de un entorno cambiante, las suposiciones hechas por los diseñadores originales pueden invalidarse, introduciendo errores.
En la práctica, la adición de nuevas funciones puede tener prioridad sobre la actualización de la documentación ; sin embargo, sin documentación, es posible que se pierdan conocimientos específicos relacionados con partes del programa. Hasta cierto punto, esto se puede mitigar siguiendo las mejores prácticas actuales para las convenciones de codificación .
El software activo se pudre una vez que una aplicación está cerca del final de su vida comercial y cesa el desarrollo posterior. Los usuarios a menudo aprenden a solucionar cualquier error de software restante , y el comportamiento del software se vuelve consistente ya que nada cambia.
Muchos programas seminales de los primeros días de la investigación de la IA han sufrido un deterioro irreparable del software. Por ejemplo, el programa SHRDLU original (un programa temprano de comprensión del lenguaje natural) no se puede ejecutar en ninguna computadora o simulador de computadora de hoy en día, ya que se desarrolló durante los días en que LISP y PLANNER todavía estaban en la etapa de desarrollo y, por lo tanto, utiliza macros y bibliotecas de software que ya no existen.
Suponga que un administrador crea un foro utilizando software de foro de código abierto y luego lo modifica en gran medida agregando nuevas funciones y opciones. Este proceso requiere amplias modificaciones al código existente y desviaciones de la funcionalidad original de ese software.
A partir de aquí, hay varias formas en que la descomposición del software puede afectar el sistema:
La refactorización es un medio para abordar el problema de la pudrición del software. Se describe como el proceso de reescribir código existente para mejorar su estructura sin afectar su comportamiento externo. [4] Esto incluye eliminar el código muerto y reescribir las secciones que se han modificado mucho y que 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.