Las Leyes de Lehman

Las Leyes de Lehman:

En ingeniería del software, las Leyes de evolución del software, o simplemente leyes de Lehman se refieren a una serie de leyes empíricas que Lehman y Belady formularon, basados en trabajos que comenzaron en 1974, con respecto a la evolución del software.

Ley 1. Cambio Continuo: Un programa que se emplea debe adaptarse continuamente, en caso contrario el programa se hace progresivamente menos útil. Estas adaptaciones son el resultado del cambio de la operación del entorno en el cual desempeña una función.

Ejemplo:

Cuando el navegador de Internet Explorer se volvió obsoleto debido a su casi nulo soporte por el formato CSS, además de la fama negativa de ser lento, tanto así que al no cambiar esas expectativas, su lentitud y su poca compatibilidad con CSS, los usuarios lo abandonaron, haciendo que sus creadores (Microsoft) tuvieran que reinventarlo, como otro software, bajo el nombre de EDGE.

Ley 2. Complejidad Creciente. A medida que evoluciona un programa, su complejidad aumenta, salvo que se trabaje para reducir su estructura. Esto conlleva un incremento progresivo del esfuerzo de mantenimiento, excepto que se realice algún tipo de, mantenimiento perfectivo a este respecto.

Ejemplo:

Podemos decir que el sistema operativo Android, con el tiempo y las actualizaciones, su estructura se fue haciendo más compleja, pues cada vez se le añadían cosas nuevas, tanto así que bajo el rendimiento de algunos Smartphone, por lo que a partir de su versión KitKat tuvo que homologarse para evitar que eso siguiera pasando en futuras versiones.

Ley 3. Evolución Prolongada del Programa (Autorregulación). El proceso de evolución del programa se autorregula con una distribución de medidas de atributos del producto y de procesos cercanos a lo normal. Los acuerdos de gestión en relación con los cambios en el programa instituyen una dinámica que determina las características de crecimiento del producto.

Ejemplo:

Por ejemplo, el sistema informático de un banco, al estar operando tanto tiempo, este necesita evolucionar, agregando funcionalidades, por ejemplo, para las transacciones vía internet, estas actualizaciones al sistema, así mismo aumentan su complejidad, haciendo que las actualizaciones futuras sean más complicadas y que puedan ser propensas a errores, sin embargo, sin estas actualizaciones, el sistema tendría principios de ser obsoleto.

Ley 4. Ley de Conservación de la Estabilidad Organizativa. La velocidad de actividad total efectiva media en un sistema en evolución es invariante a lo largo el ciclo de vida del producto. Habitualmente se piensa que el esfuerzo gastado en la evolución del sistema se establece por decisiones de dirección.

Ejemplo:

En esta ley se puede observar un desarrollo constante, para ejemplificar, tomaremos el desarrollo del SO “Windows” y el SO Mobile “Windows Phone”, donde Microsoft dedica más personal al desarrollo del primero, pues este llega a muchas más personas que WP, sin embargo, el hecho de que más personas se dediquen a este, no quiere decir que su desarrollo es más rápido, este es constante, pero diferente debido a su relevancia.

Ley 5. Conservación de la familiaridad. En el trascurso de la vida de un programa en evolución, el contenido de las versiones subsiguientes es estadísticamente invariante. Uno de los componentes que fija el progreso de un desarrollo de software es la familiaridad de todos los involucrados.

Ejemplo:

Un ejemplo adecuado para esta ley es WhatsApp, esta aplicación, era constantemente actualizada, agregando funcionalidades y reparando bugs del sistema, una actualización grande fue aquella donde se agregó el cifrado punto a punto de los mensajes, sin embargo recientemente se actualizo, la manera de visualizar los estados, el cambio fue tan radical que se perdió la propiedad de familiaridad por lo que probablemente WhatsApp tenga que recurrir a un downgrade.

Ley 6. Ley del Cremento Continuo. Un programa debe extenderse continuamente para mantener la satisfacción del usuario durante su ciclo de vida. Tradicionalmente los sistemas se crean con una limitación en cuanto a la funcionalidad del dominio protegida por motivos de tiempo o recursos. Con el tiempo, los requisitos regresan como necesidades.

Ejemplo:

Un ejemplo seria la aplicación de Facebook, en un comienzo, Facebook era exclusivo para ingresar desde un navegador, después el sistema evoluciono y se unifico entre distintas plataformas. Para referenciar, en un inicio solo se podía publicar estados y agregar amigos, luego se agregaron los mensajes privados, publicaciones de fotos y se cambió “el muro”, por “la biografía”. Actualmente, sigue en constante cambio.

Ley 7. Calidad Decreciente. Los programas se consideran de calidad decreciente si no se mantienen de manera tenaz y se adaptan al entorno operativo cambiante. Esto es, por los cambios en los criterios de aceptabilidad de los usuarios.

Ejemplo:

Pokemon GO, en un inicio fue un éxito entre los usuarios de smarthphones, sin embargo, esta aplicación no fue actualizada, decreciendo su calidad y haciendo que los usuarios perdieran el interés por esta aplicación.

Ley 8. Realimentación del sistema. Los procesos de evolución adicionan sistemas de realimentación multiagente y multiblucle, estos deben ser tratados como sistemas de realimentación para lograr una mejora significativa del producto

Ejemplo:

Un software como Google Chrome, se retroalimenta, según las búsquedas que efectúas, así, plataformas como YouTube o páginas de compra, pueden identificar los gustos de los usuarios, basados en las cosas que buscas usando esta aplicación, por lo que cada vez que las usas, sugieren cosas que concuerdan con tus gustos.