Leyes de Lehman sobre la evolución del software

En ingeniería de software , las leyes de la evolución del software se refieren a una serie de leyes que Lehman y Belady formularon a partir de 1974 con respecto a la evolución del software . ^{[ 1 ] [ 2 ]} Estas leyes describen un equilibrio entre las fuerzas que impulsan nuevos desarrollos, por un lado, y las que ralentizan el progreso, por otro. En las últimas décadas, estas leyes se han revisado y ampliado varias veces. ^{[ 3 ] [ 4 ] [ 5 ]}

Observando que la mayoría del software está sujeto a cambios en el curso de su existencia, los autores se propusieron determinar las leyes que estos cambios normalmente obedecerán, o deben obedecer para que el software sobreviva. ^{[ 1 ]}

En su artículo de 1980, ^{[ 1 ]} Lehman calificó la aplicación de tales leyes distinguiendo entre tres categorías de software:

• Un programa S se escribe siguiendo una especificación precisa de sus funciones. Por ejemplo, un programa para encontrar soluciones al rompecabezas de las ocho reinas sería un programa S. La validez de un programa S se deriva completamente de dicha especificación. Estos programas suelen ser estáticos y no deberían evolucionar mucho.
• Un programa P se escribe para modelar un problema del mundo real . Un ejemplo es la predicción meteorológica. Si bien un programa P se escribe siguiendo una especificación, su valor y validez final se determinan comparando su resultado no con la especificación, sino con el contexto del mundo real.
• Un programa electrónico se escribe para "mecanizar una actividad humana o social". ^{[ 1 ]} Como tal, los programas electrónicos están integrados en la parte del mundo real que modelan. El comportamiento de un programa electrónico está estrechamente ligado al entorno en el que se ejecuta, y dicho programa necesita adaptarse continuamente a los requisitos y circunstancias cambiantes de ese entorno.

En el mismo artículo, Lehman también definió los programas A como la unión de los tipos P y E. Los programas A se diferencian de los tipos S "en que representan una aplicación en el mundo real". ^{[ 1 ]} Sin embargo, en un artículo posterior de 1997, ^{[ 2 ]} pareció difuminar la distinción entre los tipos A y E al definir los programas de tipo E como "software que resuelve un problema o aborda una aplicación en el mundo real". Se dice que las leyes que se resumen a continuación se aplican a los programas de tipo E según esta última definición.

En total, se formularon ocho leyes:

1. (1974) "Cambio continuo": un sistema de tipo E debe adaptarse continuamente o se vuelve progresivamente menos satisfactorio. ^{[ 2 ]}
2. (1974) "Complejidad creciente": a medida que un sistema de tipo E evoluciona, su complejidad aumenta a menos que se realice un trabajo explícito para mantenerla o reducirla. ^{[ 2 ]}
3. (1974) "Autorregulación" — Los procesos de evolución del sistema de tipo E se autorregulan con una distribución de medidas de producto y proceso cercana a la normal. ^{[ 2 ]}
4. (1978) "Conservación de la estabilidad organizacional ( tasa de trabajo invariante )" — la tasa de actividad global efectiva promedio en un sistema de tipo E en evolución es invariante durante la vida útil del producto. ^{[ 2 ]}
5. (1978) "Conservación de la familiaridad": a medida que un sistema de tipo E evoluciona, todos los asociados a él (desarrolladores, personal de ventas y usuarios, por ejemplo) deben mantener el dominio de su contenido y comportamiento para lograr una evolución satisfactoria. Un crecimiento excesivo disminuye ese dominio. Por lo tanto, el crecimiento incremental promedio permanece invariable a medida que el sistema evoluciona. ^{[ 2 ]}
6. (1991) "Crecimiento continuo": el contenido funcional de un sistema tipo E debe incrementarse continuamente para mantener la satisfacción del usuario a lo largo de su vida útil. ^{[ 2 ]}
7. (1996) "Calidad en declive": la calidad de un sistema tipo E parecerá estar en declive a menos que se mantenga rigurosamente y se adapte a los cambios del entorno operativo. ^{[ 2 ]}
8. (1996) "Sistema de retroalimentación" (enunciado por primera vez en 1974, formalizado como ley en 1996): los procesos de evolución de tipo E constituyen sistemas de retroalimentación multinivel, multiloop y multiagente, y deben tratarse como tales para lograr una mejora significativa sobre cualquier base razonable. ^{[ 2 ]}