DECAIMIENTO DE SOFTWARE

La pudricin del software, tambin conocida como la Pudricin del cdigo o erosin de software o decaimiento de software o entropa del software describe la percibida "podredumbre" que es un deterioro lento del desempeo 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 fenmeno fsico: el software realmente no se pudre, sino ms bien adolece de una falta de ser responsivo y actualizado con respecto al entorno cambiante en el que reside. El software puede deteriorarse en "rendimiento" con el tiempo y se convierte en lo que comnmente se llama "obsoleto" a medida que corre y acumula errores; Esto generalmente no es considerado putrefaccin de software, aunque puede tener algunas de las mismas consecuencias. Usualmente, tal estado degradado puede ser remediado reinicializando completamente su estado (como por una reinstalacin completa de todos los componentes relevantes de software, posiblemente incluyendo el software de sistema operativo); Esto tambin puede remediar algunas clases de pudricin de software, mientras que otras putrefaccin 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 hacindose obsoleto.

ndice

1 Causas o 1.1 Cambio del entorno o 1.2 Una sola vez o 1.3 Cdigo sin usar o 1.4 Cdigo raramente actualizado 2 Clasificacin o 2.1 Putrefaccin inactiva o 2.2 Putrefaccin activa 3 Ejemplo 4 Refactorizacin 5 Referencias 6 Vase tambin

Causas
Hay varios factores responsables de la putrefaccin del software. Estos incluyen cambios en el entorno en que opera el software, degradacin de la compatibilidad entre partes del software en s mismo, y la aparicin de errores en el cdigo no usado o raramente usado.

Cambio del entorno

Cuando se producen cambios en el entorno del programa, particularmente cambios que no anticip el diseador del programa, el software no puede operar como previ originalmente. Por ejemplo, muchos de los primeros diseadores de juegos de computadora hicieron suposiciones sobre la velocidad de procesamiento del CPU para los que los juegos fueron diseados. 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 aumentara con la del CPU, haciendo el software menos usable con el tiempo.
Una sola vez

Hay cambios en el ambiente no relacionadas con el diseador 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 configuracin, no son capaces de repetir ese paso inicial debido al diferente contexto y la informacin no disponible (prdida de contrasea, instrucciones fltantes, o simplemente una interfaz de usuario difcil de administrar que en un principio fue configurada por ensayo y error). El arquitecto de informacin Jonas Sderstrm ha nombrado este concepto como Onceability (una sola vez),1 y lo define como "la cualidad en un sistema tcnico que impide a un usuario restaurar el sistema, una vez que ha fallado".
Cdigo sin usar

Porciones de cdigo que normalmente no son ejecutadas, como filtros de documentos o interfaces diseados 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 cdigo puede ejecutarse posteriormente, entonces exponiendo los errores y haciendo el software aparecer menos funcional.
Cdigo raramente actualizado

El mantenimiento normal de software y sistemas tambin puede causar putrefaccin de software. En particular, cuando un programa contiene mltiples partes que funcionan relacionadas una a la otra, fallando en considerar cmo los cambios en una parte afectan a las dems 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 versin antigua de una biblioteca que fue utilizada anteriormente con el software no puede usarse ms 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 versin anterior, puede no haber una versin viable de esa biblioteca necesaria para el programa.

Clasificacin

Putrefaccin de software generalmente se clasifica como putrefaccin inactiva o putrefaccin activa.

Putrefaccin inactiva

El software que no est actualmente siendo usado, poco a poco se torna inservible a medida que el resto de la aplicacin cambia. Cambios en los requerimientos de los usuarios y del entorno del software tambin contribuyen al deterioro.
Putrefaccin activa

El software que est siendo modificando continuamente puede perder su integridad con el tiempo si no son aplicados los apropiados procesos de mitigacin en forma consistente. Sin embargo, mucho software requiere continuos cambios para satisfacer las nuevas exigencias y corregir errores, y la reingeniera de software cada vez que se realiza un cambio es raramente prctica. Esto crea lo que es esencialmente un proceso de evolucin para el programa, causando que se aparten del diseo original de ingeniera. Como una consecuencia de esto y un entorno cambiante, asunciones hechas por los diseadores originales pueden ser invalidadas, introduciendo errores. Los desarrolladores a menudo son alentados a entender completamente un problema antes de programar una solucin,[cita requerida] y a mantener precisa y completa la documentacin del software. En la prctica, sin embargo, aadiendo nuevas caractersticas puede ser priorizado sobre la actualizacin de la documentacin. Sin documentacin, sin embargo, es posible que se pierdan los conocimientos especficos relativos a las partes del programa. Hasta cierto punto, esto puede ser mitigado por las siguientes mejores prcticas actuales en cuanto a la documentacin interna y nombres de variables. La putrefaccin de software activa disminuye una vez que una aplicacin 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.

Ejemplo
Muchos programas seminales de los primeros das de la investigacin de la AI han sufrido pudricin de software irreparable. Por ejemplo, el programa SHRDLU original (un temprano programa de comprensin del lenguaje natural) no puede ser ejecutado en cualquier computador moderno de hoy o simulador de computadora, ya que se desarroll durante los das cuando LISP y PLANNER todava estaban en fase de desarrollo y por lo tanto usaba macros no estndar y bibliotecas de software que ya no existen. Supongamos que un administrador crea un foro utilizando algn software de foro en lnea. Entonces l o ella lo modifica fuertemente, aadiendo nuevas caractersticas y opciones. Este proceso requiere modificaciones extensas al cdigo existente y la desviacin de la funcionalidad original de ese software.

A partir de aqu, hay varias maneras de putrefaccin 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 posicin: puesto que se ha desviado tanto del cdigo original, sern difciles de obtener el soporte tcnico y la asistencia para resucitar el foro. Puede descubrirse un agujero de seguridad en el cdigo fuente original del foro, que requiere una actualizacin de seguridad. Sin embargo, debido a que el administrador ha modificado el cdigo tan extensivamente, el parche puede no ser directamente aplicable a su cdigo, requiriendo que el administrador efectivamente reescriba la actualizacin. El administrador que hizo las modificaciones podra abandonar su posicin, dejando al nuevo administrador con un foro complicado y muy modificado que carece de documentacin completa. Sin comprender plenamente las modificaciones, es difcil para el nuevo administrador hacer cambios sin la introduccin de conflictos y errores. (Adems, la documentacin del sistema original podra no estar disponible, podra haber sido abandonada, o, con el paso del tiempo, se ha perdido).