Leyes de Lehman

Cuando hablamos de la Ingeniería de Software, las Leyes de Evolución de Software se refieren a los términos que Lehman y Belady formularon a partir de 1974 con respecto a la Evolución del Software. 

Estas leyes describen el balance que deberá existir entre el desarrollo de nuevo software y el evitar un desgasto al momento de hacerlo.

Al analizar los problemas experimentados, los autores de estas leyes, determinaron que los siguientes software podrían y/o deberían regirse por ciertos métodos, por lo que en 1980 Lehman publicó un artículo en el que afirmo que había que definir 3 categorías de software:

• S-Program: creado en base a la especificación (Specification) de lo que el programa debe hacer.
• P-Program: creado en base a la implementación de los procesos (Procedures) que el programa puede cumplir.
• E-Program: creado para actividades reales correspondientes al mundo y por lo tanto, la forma en que se diseñan esta bastante relacionado con su relación con el entorno (Environment), y en consecuencia este debe adaptarse a las condiciones y requerimientos necesarios para un buen funcionamiento.

En el periodo de 1974 a 1996 se formularon las siguientes 8 reglas, las cuales solo son aplicables a la categoría E:

1. Cambio continuo (1974): un sistema de tipo E deberá ser modificado continuamente o sera cada vez menos usable.
2. Complejidad Incrementable (1974): mientras un sistema E evolucione, su complejidad deberá incrementar a menos que haya sido previsto para mantenerse o reducirse.
3. Auto-Regulación (1974): el crecimiento es auto-regulado, y por tanto, sus atributos como lo son el tiempo de entregas, tamaño, y errores encontrados son invariantes a cada entrega.
4. Estabilidad Organizacional (1978): durante el tiempo de uso funcional de un programa, su tiempo de desarrollo evolutivo debe ser invariante.
5. Conservación de la familiaridad (1978): a medida que un sistema evoluciona, todo el personal relacionado con este, debe mantener un dominio y comportamiento para lograr el éxito evolutivo del mismo; el crecimiento desmedido, puede dar como resultado la perdida de domino, sin embargo, el crecimiento incremental lo puede mantener constante.
6. Crecimiento continuo (1991): el contenido usable de un sistema E deberá ser actualizado constantemente para mantener la satisfacción del usuario a lo largo del tiempo de vida del sistema.
7. Decremento de calidad (1996): la calidad correspondiente a un sistema de tipo E empezara a reducirse a menos que sea rigurosamente adaptada a cambios en el entorno operacional.
8. Retroalimentación del Sistema (1996, aunque fue dicha primeramente en 1974, fue formalizada como ley en 1996): el proceso de evolución de un sistema E, consta de retroalimentación por medio de multi-niveles y multi-iteraciones que deben ser tratados como base para terminar un producto totalmente funcional.

Al haber analizado las leyes anteriores y los tipos de sistema que se pueden desarrollar, podemos concluir que para realizar un buen sistema, es necesario delimitar de una manera adecuada el tipo de sistema, a quien se dirigirá éste mismo, y que funcionalidad deberá tener; en caso de realizar un sistema de tipo "E" debemos cumplir con las 8 reglas, si queremos un producto funcional y completo en el cual podamos confiar para realizar otras actividades relacionadas con un entorno real y variante.

Bibliografía

Lehman, M. M. (1980). On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle. NA: NA.

Lehman, M. M. (1980). Programs, Life Cycles, and Laws of Software Evolution. NA: NA.

Lehman, M. M., & J. F. Ramil, P. D. (1997). Metrics and Laws of Software Evolution-ninentees view. NA: NA.