En ingeniería de software , las leyes de la evolución del software hacen referencia a una serie de leyes que Lehman y Belady formularon a partir de 1974 con respecto a la evolución del software . [1] [2]
Las leyes describen un equilibrio entre las fuerzas que impulsan nuevos desarrollos, por un lado, y las fuerzas que frenan el progreso, por el otro. Durante las últimas décadas, las leyes han sido revisadas y ampliadas varias veces. [3]
Contexto
Al observar que la mayor parte 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 de acuerdo con una especificación exacta de lo que ese programa puede hacer. Por ejemplo, un programa para encontrar soluciones al rompecabezas de las ocho reinas sería un programa S. Estos programas son en su mayoría estáticos y no deberían evolucionar mucho.
- Un programa P está escrito para implementar ciertos procedimientos que determinan completamente lo que el programa puede hacer (el ejemplo mencionado es un programa para jugar al ajedrez)
- Un programa E está escrito para realizar alguna actividad del mundo real; cómo debe comportarse está fuertemente vinculado al entorno en el que se ejecuta, y dicho programa debe adaptarse a los diferentes requisitos y circunstancias de ese entorno.
Se dice que las leyes se aplican sólo a la última categoría de sistemas.
Las leyes
En total, se formularon ocho leyes:
- (1974) "Cambio continuo": un sistema tipo E debe adaptarse continuamente o se vuelve progresivamente menos satisfactorio. [4]
- (1974) "Complejidad creciente": a medida que evoluciona un sistema de tipo E, su complejidad aumenta a menos que se trabaje para mantenerla o reducirla. [4]
- (1974) "Autorregulación": los procesos de evolución del sistema tipo E se autorregulan con la distribución de medidas de productos y procesos cercanas a lo normal. [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. [4]
- (1978) "Conservación de la familiaridad": a medida que evoluciona un sistema de tipo E, todos los asociados con él, los desarrolladores, el personal de ventas y los usuarios, por ejemplo, deben mantener el dominio de su contenido y comportamiento para lograr una evolución satisfactoria. El crecimiento excesivo disminuye ese dominio. Por tanto, el crecimiento incremental promedio permanece invariante a medida que evoluciona el sistema. [4]
- (1991) "Crecimiento continuo": el contenido funcional de un sistema tipo E debe incrementarse continuamente para mantener la satisfacción del usuario durante su vida útil.
- (1996) "Calidad en descenso": la calidad de un sistema tipo E parecerá estar disminuyendo a menos que se mantenga rigurosamente y se adapte a los cambios del entorno operativo. [5]
- (1996) "Sistema de retroalimentación" (establecido por primera vez en 1974, formalizado como ley en 1996): los procesos de evolución de tipo E constituyen sistemas de retroalimentación de múltiples niveles, múltiples bucles y múltiples agentes y deben tratarse como tales para lograr una mejora significativa sobre cualquier sistema de retroalimentación razonable. base.
Relevancia de las leyes de la evolución del software en la ingeniería de software moderna
En el dinámico mundo de la ingeniería de software moderna , las Leyes de la Evolución del Software siguen teniendo una profunda relevancia. Estas leyes, formuladas originalmente por Lehman y Belady en la década de 1970, proporcionan conocimientos duraderos sobre la naturaleza de los sistemas de software y su evolución. En el panorama actual del desarrollo de software , donde la agilidad y la adaptabilidad son primordiales, estas leyes sirven como principios rectores.
El "cambio continuo" es un concepto fundamental que enfatiza que el software debe evolucionar continuamente para seguir siendo satisfactorio. [4] Esto se alinea perfectamente con las metodologías de desarrollo ágiles, donde las actualizaciones iterativas y las mejoras de funciones son la norma.
La "complejidad creciente" es otra ley clave que subraya la necesidad de una gestión activa de la complejidad, particularmente en proyectos de software grandes y de larga duración. [4] A medida que los sistemas de software crecen, las prácticas de ingeniería modernas, como el diseño modular , los microservicios y DevOps, ayudan a controlar y reducir la complejidad, garantizando que el software siga siendo mantenible y escalable .
Las Leyes de la Evolución del Software también encuentran relevancia en el contexto de DevOps y la integración / implementación continua (CI/CD). En un entorno impulsado por DevOps , la ley de "crecimiento continuo" [4] se ejemplifica ya que las funciones del software deben ampliarse continuamente para satisfacer las demandas cambiantes de los usuarios y mantener su satisfacción.
La ley de "Calidad en descenso" es un claro recordatorio de que la calidad del software puede deteriorarse con el tiempo sin un mantenimiento riguroso, [4] destacando la importancia de las pruebas automatizadas y el control de calidad en el desarrollo de software moderno. Además, la ley del "Sistema de retroalimentación" [4] refuerza la idea de que la evolución del software es un proceso impulsado por la retroalimentación, con múltiples bucles y agentes involucrados.
Esto resuena con el énfasis en la colaboración y la retroalimentación dentro de las prácticas de DevOps , asegurando que el software se desarrolle, pruebe e implemente con un enfoque en la mejora continua . En resumen, las Leyes de la Evolución del Software continúan guiando a los ingenieros de software a navegar por las complejidades del desarrollo moderno, desde metodologías ágiles hasta DevOps , ayudándolos a ofrecer sistemas de software robustos y en evolución .
Referencias
- ^ abc Lehman, Meir M. (1980). "Programas, ciclos de vida y leyes de evolución del software". Proc. IEEE . 68 (9): 1060-1076. doi :10.1109/proc.1980.11805.
- ^ Lehman, MM; JF Ramil; PD Wernick; DE Perry; WM Turski (1997). "Métricas y leyes de la evolución del software: la visión de los noventa" (PDF) . Proc. 4to Simposio Internacional de Métricas de Software (METRICS '97) . págs. 20–32. doi :10.1109/METRIC.1997.637156.
- ^ Herráiz, Israel; Rodríguez, Daniel; Robles, Gregorio; González-Barahona, Jesús M. (2013). "La evolución de las leyes de la evolución del software". Encuestas de Computación ACM . 46 (2): 1–28. doi :10.1145/2543581.2543595. ISSN 0360-0300.
- ^ abcdefghij Lehman, MM (1980). "Sobre la comprensión de las leyes, la evolución y la conservación en el ciclo de vida de los programas grandes". Revista de Sistemas y Software . 1 : 213–221. doi :10.1016/0164-1212(79)90022-0.
- ^ Liguo Yu y Alok Mishra (2013) Un estudio empírico de la ley de Lehman sobre la evolución de la calidad del software en International Journal of Software and Informatics, 11/2013; 7(3):469-481.
