Las causas de la degradación del software y sus tipos

0 411

La degradación del software es un problema real cuyos efectos los podemos observar a simple vista en nuestros dispositivos móviles, computadoras, etc. Una de las cuestiones más curiosas del asunto es que muchas veces es ignorada por los programadores. Es verdad que en ciertos casos no se la conoce con un nombre específico. Por esto es importante tenerla en cuenta. Por esto hoy en Code Time explicamos las causas de la degradación del software y los tipos de degradación.

Nota: Antes de continuar te recomendamos que leas la nota anterior donde damos una introducción al tema. Gracias a ella podrás tener un mejor contexto y entenderás mejor. A lo largo de este artículo se darán por sabidos esos conceptos. Si estás interesado en leerlo aquí tienes un enlace directo.

Las causas de la degradación del software

Existen diversos factores que pueden contribuir a la aparición de la degradación del software. A continuación listamos las más importantes.

Cambios en el entorno en el que opera el software

Este es uno de los factores más fáciles de entender. Consisten en cambios en el entorno del programa. Generalmente son cambios que el diseñador del programa no anticipó. Las consecuencias pueden ir desde una pequeña malfunción hasta la inutilidad misma del programa.

Un ejemplo de esto se dio durante muchos en los que los juegos utilizaban el reloj del procesador como timer. Con los años las frecuencias de los procesadores incrementó exponencialmente haciendo que los contadores se volvieran literalmente locos y hoy en día ese programa fuese algo inutil. Como se puede observar, en los equipos originales no había ningún problema pero al instalar el mismo programa en otro equipo más potente la situación era catastrófica para el usuario.

degradación del software

Onceability

Antes que nada he de pedir disculpas pero este término lo vi dificil de traducir por lo que decidí preservar su nombre original. A diferencia del caso anterior, este no está relacionado con problemas de diseño sino con los usuarios de un programa.

Inicialmente un usuario podría instalar y utilizar un software sin problemas durante cierto período de tiempo. Pero por algún problema el sistema deja de funcionar correctamente o realizan un ajuste que hace algo irreversible que afecta al programa. La clave de este punto es la imposibilidad de volver a un estado anterior en el que las cosas funcionaban bien.

Entre las posibles causas tenemos corrupción de archivos de configuración, realización de tareas de forma no atómica cuando era necesario, contraseñas perdidas.

El código no utilizado

Las partes de código utilizadas con poca frecuencia pueden ser causantes de grandes problemas. Se que suena contradictorio pero es una triste realidad pero es algo que se ve todo el tiempo. Un ejemplo clásico podríamos verlo en wordpress cuando se desactiva un plugin. Al hacerlo este no se actualiza y puede contener vulnerabilidades que gracias a un mal diseño pueden convertirse en un agujero de seguridad en la página.

Pero wordpress no es el único caso. Estamos llenos de esto. Suelen ser piezas raramente usadas como filtros de documentos, librerías, interfaces, entre otras, que pueden contener errores que pasan desapercibidos.

Con los cambios en los requisitos del usuario y otros factores externos, este código se puede ejecutar más tarde, exponiendo los errores y haciendo que el software parezca menos funcional.

Códigos raramente actualizados

Esta causa suena similar a la anterior, y ciertamente comparten ciertas características pero no son lo mismo. El código raramente utilizado se centra principalmente en el trabajo con las librerías.

Los problemas surgen cuando parte de un programa emplea una librería para hacer parte del trabajo y el resto del software se actualiza. Esto lleva a ciertas incompatibilidades. Más aun las cosas empeoran al no emplearse buenas prácticas de documentación.

Además se pueden dar casos en los que una librería depende de otra y el cambio a otro sistema genere problemas de dependencias. De esto no se salva nadie. Existen formas de mitigarlo pero en general cuanto más se actualice un software sin las precauciones correspondientes el problema puede crecer peligrosamente.

Tipos de degradación de software

La degradación del software puede clasificarse en degradación latente y degradación activa.

Degradación latente

Esta se centra en componentes que raramente son utilizados de un programa. A medida que el resto de la utilidad se ve actualizada es muy probable que las otras partes comiencen a volverse inútiles o deficientes. En esto se ve mucho la mano del usuario quien cambia ciertos requisitos sobre un desarrollo olvidando parte de las premisas originales o por ejemplo al cambiar el entorno mediante una actualización del sistema operativo, librerías o incluso el hardware.

degradación del software

Degradación activa

El software que se modifica continuamente puede perder su integridad con el tiempo si los procesos de mitigación adecuados no se aplican de forma coherente.

Es aquí donde el equilibrio es la clave. Toda aplicación requiere mantenimiento y actualizaciones para incorporar nuevas funcionalidades, es decir necesita evolucionar. El problema se produce cuando se produce un desvío del diseño original. De esta forma el programa cambia, empiezan a haber conflictos con otros componentes y así aparecen errores e incluso las cosas pueden degenerar en inutilidad.

La documentación no es la excepción. Es muy común ver la incorporación de nuevas funciones y re implementaciones pero la documentación suele quedar desactualizada lo que lleva a los nuevos desarrolladores e incluso a los originales a plantear soluciones erroneas tomando ese material com fuente.

Así pués podemos concluir que cuanto más se actualiza un progrma es más probable que se de este tipo de degradación.

Y la solución es…

No existe una respuesta sencilla a esta pregunta y de hecho abre un debate bastante interesante. La idea es diseñar las cosas bien desde un principio anticipando la escalabilidad y posibles futuras actualizaciones. Obviamente todo esto tiene un límite y muchas veces la solución es hacer refactoring (reescribir parte del programa), que si no se hace correctamente puede resultar más costoso y peor que el problema original.

Esperamos que esta nota haya sido de tu agrado. Si fue así no dudes en dejarnos un comentario. Tu opinión es importante para nosotros. Y nos sería de mucha ayuda que difundieras el material para hacer llegar el conocimiento a muchas más personas.

Aprende a desarrollar aplicaciones para iOS 11
Aprende a Curso completo de Swift 4 desde cero
Mis medios de contacto

Twitter    Gmail

Contenido

Spreaker    iTunes    Ivoox    Canal de Telegram  Youtube

Comentarios
Loading...

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. AcceptRead More

Privacy & Cookies Policy