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. En las últimas décadas, las leyes han sido revisadas y ampliadas varias veces. [3]
Contexto
Al observar que la mayoría del software está sujeto a cambios a lo largo de su existencia, los autores se propusieron determinar leyes que estos cambios normalmente obedecerán o deberán obedecer para que el software sobreviva. [1]
En su artículo de 1980, [1] Lehman calificó la aplicación de dichas leyes distinguiendo entre tres categorías de software:
- Un programa S se escribe de acuerdo con una especificación exacta de lo que puede hacer ese programa. 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 ajedrez).
- Un programa E se escribe para realizar alguna actividad del mundo real; su comportamiento está fuertemente vinculado al entorno en el que se ejecuta, y dicho programa debe adaptarse a los distintos 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 un sistema de tipo E evoluciona, su complejidad aumenta a menos que se realice trabajo para mantenerla o reducirla. [4]
- (1974) "Autorregulación" — Los procesos de evolución de sistemas de tipo E se autorregulan con una distribución de medidas de productos y procesos cercana 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 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 (desarrolladores, personal de ventas y 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 lo tanto, el crecimiento incremental promedio permanece invariable 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 declive”: la calidad de un sistema tipo E parecerá estar en declive a menos que se lo mantenga rigurosamente y se lo 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 base razonable.
Relevancia de las leyes de evolución del software en la ingeniería de software moderna
[ ¿Investigación original? ]
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 concepto de “cambio continuo” es fundamental y pone énfasis en que el software debe evolucionar continuamente para seguir siendo satisfactorio. [4] Esto se alinea perfectamente con las metodologías de desarrollo ágil, donde las actualizaciones iterativas y las mejoras de funciones son la norma.
"La creciente complejidad" es otra ley clave que subraya la necesidad de una gestión activa de la complejidad, en particular en proyectos de software grandes y de larga duración. [4] A medida que crecen los sistemas de software, las prácticas de ingeniería modernas como el diseño modular , los microservicios y DevOps ayudan a controlar y reducir la complejidad, lo que garantiza que el software siga siendo mantenible y escalable .
Las leyes de la evolución del software también son relevantes en el contexto de DevOps y la integración continua / implementación continua (CI/CD). En un entorno impulsado por DevOps , la ley del "crecimiento continuo" [4] se ejemplifica como las características del software que deben expandirse continuamente para satisfacer las demandas cambiantes de los usuarios y mantener su satisfacción.
La ley de la "calidad en declive" es un duro recordatorio de que la calidad del software puede deteriorarse con el tiempo sin un mantenimiento riguroso [4] , lo que pone de relieve 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 coincide con el énfasis en la colaboración y la retroalimentación dentro de las prácticas de DevOps , lo que garantiza 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 en la navegación por las complejidades del desarrollo moderno, desde las metodologías ágiles hasta DevOps , ayudándolos a entregar sistemas de software robustos y en evolución .
Referencias
- ^ abc Lehman, Meir M. (1980). "Programas, ciclos de vida y leyes de la 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 perspectiva de los años noventa" (PDF) . Proc. 4th International Software Metrics Symposium (METRICS '97) . págs. 20–32. doi :10.1109/METRIC.1997.637156.
- ^ Herraiz, Israel; Rodriguez, Daniel; Robles, Gregorio; Gonzalez-Barahona, Jesus M. (2013). "La evolución de las leyes de la evolución del software". ACM Computing Surveys . 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 de gran tamaño". 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.
