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.

Mantenimiento de Software

Primero que nada, debemos saber que es el mantenimiento de software:

• "El proceso de modificar un sistema de software o sus componentes, para prevenir fallos,  mejorar el desempeño u otros atributos, así como adaptarse a los cambios en su ambiente"

Por lo tanto, podemos decir que el mantenimiento de software concierne a:

• Corregir errores descubiertos posteriormente a la entrega del software.
• Adaptar al software a un cambio en los requerimientos,  un cambio en su ambiente.

El éxito en el mantenimiento depende en el desarrollo, por las siguientes razones:

1. Mayor calidad = menor mantenimiento (correctivo).
2. Anticipar cambios = menor mantenimiento (adaptativo y perfectivo).
3. Mejor ajuste a las necesidades del usuario = menos mantenimiento (perfectivo).
4. Menos código = menos mantenimiento.

Contamos con 4 tipos de mantenimiento:

• Correctivo: como el nombre lo dice, corrige los errores.
• Adaptativo: adaptarse al cambio del ambiente (tanto hardware como software).
• Perfectivo: adaptación al cambio en las necesidades del usuario.
• Preventivo: incrementar la mantenibilidad del sistema.

Después de todo lo dicho, podemos determinar que simplemente por haber entregado un software 100% funcional al cliente no implica que no se le debe dar seguimiento, sino todo lo contrario, se le debe mejorar, corregir e incluso perfeccionar, esto eventualmente nos dará un sistema cercano a la perfección requerida previamente por los usuarios.

Bibliografía

Amsterdan, U. (s.f.). Faculty Sciences. Obtenido de Department of Computer Sciences: https://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCoQFjAA&url=http%3A%2F%2Fwww.cs.vu.nl%2F~hans%2FSEslides%2Fmaint.ppt&ei=hGMBU47RGISiyAGGkoDYAw&usg=AFQjCNEu6TpvFtE_U0RANCqMtJ_GY1zi8w&sig2=LJulSW5jT1ECAMgzXQr6AQ&bvm=bv.61535280,d.aWc