Pudrición del software , la enciclopedia libre

La pudrición del software, también conocida como la Pudrición del código o erosión de software o decaimiento de software o entropía del software describe la percibida "podredumbre" que es un deterioro lento del desempeño del software con el tiempo o su decreciente capacidad de respuesta que conducirá eventualmente a convertirse en defectuoso, inusable, o de otra manera llamado "obsoleto" (legacy) y en necesidad de actualizar (mantenimiento). No se trata de un fenómeno físico: el software realmente no se pudre, sino más bien adolece de una falta de responsabilidad y actualización con respecto al entorno cambiante en el que reside.

El software puede deteriorarse en "rendimiento" con el tiempo y se convierte en lo que comúnmente se llama "obsoleto" a medida que corre y acumula errores; Esto generalmente no es considerado putrefacción de software, aunque puede tener algunas de las mismas consecuencias. Usualmente, tal estado degradado puede ser remediado reinicializando completamente su estado (como por una reinstalación completa de todos los componentes relevantes de software, posiblemente incluyendo el software de sistema operativo); Esto también puede remediar algunas clases de pudrición de software, mientras que otras putrefacción de software son irreversibles, a medida que el entorno operativo del software o componentes del software en sí mismo se vuelven incompatibles y por lo tanto haciéndose obsoleto.

Hay varios factores responsables de la putrefacción del software. Estos incluyen cambios en el entorno en que opera el software, degradación de la compatibilidad entre partes del software en sí mismo, y la aparición de errores en el código no usado o raramente usado.

Cuando se producen cambios en el entorno del programa, particularmente cambios que no anticipó el diseñador del programa, el software no puede operar como previó originalmente. Por ejemplo, muchos de los primeros diseñadores de juegos de computadora hicieron suposiciones sobre la velocidad de procesamiento del CPU para los que los juegos fueron diseñados. Una consecuencia de esto fue que cuando la frecuencia del reloj del CPU fue utilizada como un contador de tiempo en el juego, la velocidad del juego aumentaría con la del CPU, haciendo el software menos usable con el tiempo.

Hay cambios en el ambiente no relacionadas con el diseñador del programa, sino con sus usuarios. Un usuario puede configurar el sistema de trabajo una vez y tenerlo funcionando perfectamente durante un tiempo. Pero cuando el sistema deja de funcionar correctamente, o los usuarios quieren acceder a los controles de configuración, no son capaces de repetir ese paso inicial debido al diferente contexto y la información no disponible (pérdida de contraseña, instrucciones faltantes, o simplemente una interfaz de usuario difícil de administrar que en un principio fue configurada por ensayo y error). El arquitecto de información Jonas Söderström ha nombrado este concepto como Onceability (una sola vez),^[1]​ y lo define como "la cualidad en un sistema técnico que impide a un usuario restaurar el sistema, una vez que ha fallado".

Porciones de código que normalmente no son ejecutadas, como filtros de documentos o interfaces diseñados para ser usados por otros programas, pueden contener errores que pasan desapercibidos. Con cambios en los requerimientos de los usuarios y otros factores externos, este código puede ejecutarse posteriormente, entonces exponiendo los errores y haciendo el software aparecer menos funcional.

El mantenimiento normal de software y sistemas también puede causar putrefacción de software. En particular, cuando un programa contiene múltiples partes que funcionan relacionadas una a la otra, fallando en considerar cómo los cambios en una parte afectan a las demás puede introducir errores.

En algunos casos, esto puede tomar la forma de bibliotecas que el software utiliza, siendo cambiadas de una manera que afecta negativamente al software. Si la versión antigua de una biblioteca que fue utilizada anteriormente con el software no puede usarse más debido a conflictos con otro software (como en el caso de archivos DLL — ver el infierno de las DLL), o fallos de seguridad que fueron encontrados en la versión anterior, puede no haber una versión viable de esa biblioteca necesaria para el programa.

Putrefacción de software generalmente se clasifica como putrefacción inactiva o putrefacción activa.

El software que no está actualmente siendo usado, poco a poco se torna inservible a medida que el resto de la aplicación cambia. Cambios en los requerimientos de los usuarios y del entorno del software también contribuyen al deterioro.

El software que está siendo modificando continuamente puede perder su integridad con el tiempo si no son aplicados los apropiados procesos de mitigación en forma consistente. Sin embargo, mucho software requiere continuos cambios para satisfacer las nuevas exigencias y corregir errores, y la reingeniería de software cada vez que se realiza un cambio es raramente práctica. Esto crea lo que es esencialmente un proceso de evolución para el programa, causando que se aparten del diseño original de ingeniería. Como una consecuencia de esto y un entorno cambiante, asunciones hechas por los diseñadores originales pueden ser invalidadas, introduciendo errores.

Los desarrolladores a menudo son alentados a entender completamente un problema antes de programar una solución,^{[cita requerida]} y a mantener precisa y completa la documentación del software. En la práctica, sin embargo, añadiendo nuevas características puede ser priorizado sobre la actualización de la documentación. Sin documentación, sin embargo, es posible que se pierdan los conocimientos específicos relativos a las partes del programa. Hasta cierto punto, esto puede ser mitigado por las siguientes mejores prácticas actuales en cuanto a la documentación interna y nombres de variables.

La putrefacción de software activa disminuye una vez que una aplicación está casi al final de su vida comercial y el desarrollo futuro cesa. Con frecuencia los usuarios aprenden a solucionar (work around) cualquier resto de errores de software, y el comportamiento del software se vuelve consistente cuando nada está cambiando.

Muchos programas seminales de los primeros días de la investigación de la AI han sufrido pudrición de software irreparable. Por ejemplo, el programa SHRDLU original (un temprano programa de comprensión del lenguaje natural) no puede ser ejecutado en cualquier computador moderno de hoy o simulador de computadora, ya que se desarrolló durante los días cuando LISP y PLANNER todavía estaban en fase de desarrollo y por lo tanto usaba macros no estándar y bibliotecas de software que ya no existen.

Supongamos que un administrador crea un foro utilizando algún software de foro en línea. Entonces él o ella lo modifica fuertemente, añadiendo nuevas características y opciones. Este proceso requiere modificaciones extensas al código existente y la desviación de la funcionalidad original de ese software.

A partir de aquí, hay varias maneras de putrefacción del software que puede afectar el sistema:

• El administrador puede hacer accidentalmente cambios que tengan conflictos mutuamente o con el software original, causando que el foro se comporte de una manera no esperada o se venga abajo. Esto lo deja en muy mala posición: puesto que se ha desviado tanto del código original, serán difíciles de obtener el soporte técnico y la asistencia para resucitar el foro.
• Puede descubrirse un agujero de seguridad en el código fuente original del foro, que requiere una actualización de seguridad. Sin embargo, debido a que el administrador ha modificado el código tan extensivamente, el parche puede no ser directamente aplicable a su código, requiriendo que el administrador efectivamente reescriba la actualización.
• El administrador que hizo las modificaciones podría abandonar su posición, dejando al nuevo administrador con un foro complicado y muy modificado que carece de documentación completa. Sin comprender plenamente las modificaciones, es difícil para el nuevo administrador hacer cambios sin la introducción de conflictos y errores. (Además, la documentación del sistema original podría no estar disponible, podría haber sido abandonada, o, con el paso del tiempo, se ha perdido).

La refactorización es un medio de resolver el problema de la pudrición de software. Se describe como el proceso de reescritura de código existente para mejorar su estructura sin afectar su comportamiento externo.^[2]​ Esto incluye la eliminación de código muerto y la reescritura de secciones que han sido modificadas extensivamente y no trabajan eficientemente. Debe tenerse cuidado de no cambiar el comportamiento externo del software, ya que esto podría introducir incompatibilidades y por lo tanto contribuye en sí mismo a la pudrición de software.

• Crisis del software
• Entropía del software
• Hediondez del código
• Fragilidad del código
• Principio de Peter del software