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.
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.
