Las leyes de la evolución del software

A principios de los 80 Lehman formuló las que se conocen como leyes de la evolución del software, que escribió desde su observación de la evolución del OS/360 (desde el que curiosamente Brooks también desarrollo sus trabajos sobre gestión de proyectos) y 370. Lehman dividió los sistemas software en tres tipos: los S (que pueden especificarse formalmente, son estáticos), los P (que no pueden ser especificados y es necesario un proceso iterativo para ello) y los E (sistemas que ya funcionan en el mundo real). Y sobre estos últimos observo que están siempre en continuo cambio y que los cambios introducen complejidad de manera creciente, lo que más específicamente dividió en 8 leyes:
– I Cambio Continuo. Un programa tipo E que se usa debe ser continuamente adaptado, si no, progresivamente, será menos satisfactorio.

– II Complejidad incremental.
Cuando un programa evoluciona su complejidad se incrementa, a menos que se trabaje en mantenerla o en reducirla.
– III Autorregulación. El proceso de evolución del programa se autorregula según una distribución normal de atributos de proceso y producto.
– IV Conservación de la estabilidad organizacional. A lo largo del ciclo de vida del producto, la velocidad media de actividad global efectiva del sistema en evolución es invariante. El esfuerzo en la evolución lo determinan decisiones de dirección… pero su influencia queda restringida por factores externos, como los recursos disponibles, el personal competente, etc. Por ello, la actividad dedicada a la estabilización del software es aproximadamente constante.
– V Conservación de la familiaridad. Durante la vida de un programa en evolución, el tamaño de las sucesivas versiones es estadísticamente invariante. Uno de los factores que determina la evolución software es la familiaridad de los implicados con la versión, cuantos más cambios se hacen a una versión más difícil es que todos los implicados los conozcan, una evolución “grande” dificultaría esa familiaridad, por lo que los cambios tienden a ser de un tamaño parecido.
– VI Crecimiento continuo. La funcionalidad del programa debe incrementarse continuamente para mantener la satisfacción del usuario. Los sistemas nacen con limitaciones de funcionalidad, por motivos de tiempo o recursos, lo que produce que con el tiempo requisitos que se descartaron al principio vuelvan a aparecer.
– VII Calidad decreciente. Se percibirá que un programa de tipo E pierde calidad a menos que se mantenga de manera rigurosa y se adapte al entorno operacional.
– VIII Sistema de realimentación. El proceso de programación de un programa tipo E constituye un sistema de realimentación multinivel (no es estático) y debe ser tratado como tal para tener éxito en su modificación o mejora.
Y de las que de manera resumida podríamos extraer que: el software evoluciona o muere, cuando el software crece se hace más complejo, esa complejidad limita la evolución y el esfuerzo dedicado a la evolución es constante.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *