Skip to content Skip to navigation

OpenStax_CNX

You are here: Home » Content » Leyes de la Evolución del Software

Navigation

Recently Viewed

This feature requires Javascript to be enabled.
 

Leyes de la Evolución del Software

Module by: Miguel-Angel Sicilia. E-mail the authorEdited By: Verónica De la Morena

Summary: Breve descripción de las Leyes de la Evolución del Software según Lehman.

Lehman1 (1974) formuló las primeras “leyes de la evolución del software” por primera vez a partir de un estudio del proceso de programación en IBM. Con el tiempo, se han llegado a formular ocho de estas leyes.

En el ámbito de ciencias de la ingeniería, una ley debe entenderse como una característica común a muchos fenómenos o que se presenta con regularidad.

A continuación se resume la formulación de las leyes del mantenimiento tal y como se describen en (Lehman2, 1997). Todas ellas hacen referencias a programas “de tipo E”, es decir, a aquellos programas destinados a solucionar un problema del mundo real determinado:

  • Ley I: CAMBIO CONTINUO.
  • Ley II: COMPLEJIDAD.
  • Ley III: AUTORREGULACIÓN.
  • Ley IV: CONSERVACIÓN DE LA ESTABILIDAD ORGANIZATIVA (VELOCIDAD DE TRABAJO INVARIANTE.
  • Ley V: CONSERVACIÓN DE LA FAMILIARIDAD.
  • Ley VI: CRECIMIENTO CONTINUO.
  • Ley VII: CALIDAD DECRECIENTE.

Estas leyes no son otra cosa que el resultado del estudio científico de experiencia acumulada en Ingeniería del Software. Como tales, nos pueden servir como base para la planificación de las actividades de mantenimiento y para la toma de decisiones al respecto.

Ley I: Cambio Continuo

Un programa de tipo-E que se utiliza debe adaptarse continuamente, en caso contrario, el programa se hace progresivamente menos satisfactorio. Estas adaptaciones son el resultado del cambio en la operación del entorno en el cual la aplicación cumple una función.

Ley II: Complejidad creciente

A medida que evoluciona un programa, su complejidad se incremente, a menos que se trabaje para mantenerla o reducirla.

Esta ley implica un tipo de “degradación” o “entropía” en la estructura del programa. Esto a su vez implica un aumento progresivo del esfuerzo de mantenimiento, a menos que se realice algún tipo de mantenimiento perfectivo a este respecto.

Ley III: Autorregulación

El proceso de evolución del programa se autorregula con una distribución de medidas de atributos de producto y procesos cercana a la normal.

La evolución de programas industriales tipo-E se lleva a cabo por un equipo que opera en una organización más grande. Las decisiones de gestión respecto a los cambios en el programa constituyen una dinámica que determina las características de crecimiento del producto.

Ley IV: Conservación de la estabilidad organizativa

La velocidad de actividad global efectiva media en un sistema en evolución es invariante a lo largo del ciclo de vida del producto.

Usualmente se considera que el esfuerzo gastado en la evolución del sistema se determina por decisiones de dirección. Esto es por supuesto así en un cierto grado, pero su influencia está limitada por factores externos respecto al empleo, la disponibilidad de personal competente, etc. NO obstante, también influyen los atributos del sistema, por ejemplo, la complejidad. Los datos empíricos sugieren que la actividad lleva a una estabilización de actividad aproximadamente constante.

Ley V: Conservación de la familiaridad

Durante la vida activa de un programa en evolución, el contenido de las versiones sucesivas es estadísticamente invariante.

Uno de los factores que determina el progreso de un desarrollo de software es la familiaridad de todos los implicados. Cuantos más cambios y adiciones se hacen a una versión, es más difícil que todos los implicados la conozcan. Debido a que el crecimiento está limitado por la capacidad de adquirir información de los participantes, una evolución “grande” dificultaría ese aprendizaje, por lo que los cambios tienden a ser de un tamaño parecido y limitado.

Ley VI: Crecimiento continuo

El contenido funciona de un programa debe incrementarse continuamente para mantener la satisfacción del usuario durante su ciclo de vida.

Esta ley refleja un aspecto del mismo fenómeno que refleja la primera. Habitualmente, los sistemas se crean con una limitación en cuanto a la funcionalidad del dominio cubierta, por motivos de tiempo o recursos. Esto hace que con el tiempo, los requisitos que se descartaron vuelvan a aparecer como necesidades.

Ley VII: Calidad decreciente

Los programas de tipo-E serán percibidos como de calidad decreciente a menos que se mantengan de manera rigurosa y se adapten al entorno operativo cambiante.

Esta percepción de la calidad decreciente tiene que ver con los cambios en los criterios de aceptabilidad de los usuarios.

Footnotes

  1. Lehman, M.M. (1974) Programs, Cities, Students, Limits to Growth?, Inaugural Lecture, May 1974. Publ. in Imp. Col of Sc. Tech. Inaug.l Lect. Ser., vol 9, 1970, 1974, pp. 211 - 229. Also in Programming Methodology, (D Gries ed.), Springer, Verlag, 1978, pp. 42 – 62
  2. Lehman, M.M. (1997) Laws of Software Evolution Revisited, pos. pap., EWSPT96, Oct. 1996, LNCS 1149, Springer Verlag, 1997, pp. 108-124

Content actions

Download module as:

PDF | EPUB (?)

What is an EPUB file?

EPUB is an electronic book format that can be read on a variety of mobile devices.

Downloading to a reading device

For detailed instructions on how to download this content's EPUB to your specific device, click the "(?)" link.

| More downloads ...

Add module to:

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need an account to use 'My Favorites'.

| A lens I own (?)

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks