archivo

Archivo de la etiqueta: Lehman

Su enunciado es el siguiente: “Los sistemas deben ser continuamente adaptados o se convierten progresivamente en menos satisfactorios”.

No todos los sistemas requieren el mismo nivel de evolución pero sí que es cierto que el contexto cambia y que tarde o temprano (en algunos casos más pronto que tarde) será necesaria una adaptación al cambio.

Es importante tener en cuenta que la adaptación no implica necesariamente un crecimiento del sistema (si bien en la mayoría de los casos pueden estar ligados), ya que un proceso de adaptación puede estar basado en una nueva forma de enfocar las funcionalidades ya implementadas en el sistema o en una reingeniería del proceso que se ha informatizado.

Es cierto que hay sistemas que no se han tocado en años pero, ¿es realmente porque no es necesario o por el coste que tendría asociado?. El motivo principal de que estas aplicaciones no se toquen es económico a lo que hay que sumar el factor de incertidumbre (o miedo) de retocar un sistema que está funcionando (con más o menos satisfacción para la organización y para los usuarios) y que por dentro se sospecha que está todo cogido con alfileres.

Lo que viene a decir esta ley es que no podemos pensar es que nuestra inversión no termina con la adquisición del producto software o con su desarrollo a medida, sino que tendremos que seguir realizando nuevas inversiones para adaptar el mismo a los cambios en las necesidades de la organización, del mercado, etc…

O lo que es lo mismo, el mantenimiento es inevitable.

Otro aporte de Lehman consistió en el hecho de que conforme se evoluciona un producto crece su complejidad y su tamaño, lo que hace que cada vez sean más costosas esas actividades.

Por tanto, el mantenimiento de un producto es inevitable y su coste (como consecuencia de una mayor complejidad) irá creciendo a lo largo del tiempo. De ahí que se considere que el software no se desgasta, pero sí que se deteriora.

Recordemos una conocida cita de Fred Brooks: “La complejidad del software es una propiedad esencial, no accidental”.

¿Es posible poner medios? Claro que sí, tanto en las actividades ordinarias de desarrollo (aplicando buenas prácticas y considerando la refactorización como parte del propio proceso de desarrollo) como con actividades extraordinarias (planes de acción para simplificar la arquitectura del sistema, reducir la deuda técnica, etc…). No obstante, debemos tener en cuenta que con independencia de estas actividades sí que es cierto que la complejidad del sistema crece conforme el mismo evoluciona.

Más controvertidas resultan otras afirmaciones de Lehman, en las cuales considera que determinados atributos relacionados con el desarrollo de software (tamaño, número de defectos, tasa de crecimiento), etc…, se mantienen más o menos constantes o siguen una tendencia (una proporcionalidad) a lo largo del proceso de evolución del software.

Estas afirmaciones, personalmente me parecen más discutibles (no quiero decir que no esté de acuerdo en todas), si bien, pese a que me base en mi propia experiencia, no he analizado datos empíricos para verificar si efectivamente se cumplen o no.

En los próximos días se van a publicar una serie de artículos sobre las 8 leyes de Lehman de evolución de los sistemas.

Lo más significativo de ellas es que trata de establecer una serie de pautas relacionadas con la evolución de los sistemas, tratando de generalizar ese comportamiento al conjunto de los mismos.

No es necesario estar de acuerdo con las mismas, de hecho, hay alguna que os parecerá más que discutible o que aplicando el enfoque adecuado se puede resolver o atenuar el problema que describe.

Me parece especialmente interesante el hecho de que Lehman considere la evolución de los sistemas (su mantenimiento) como algo inevitable, por mucho que te esfuerces en desarrollar una versión del producto que trate de ser definitiva.

Uno de los problemas que nos encontramos los desarrolladores de software es que el área usuaria no entiende que un producto requiera de un mantenimiento posterior, pese a que sean ellos mismos los que sugieran o provoquen esos cambios (pese a que entiendan que deberían haber sido tenidos en cuenta en el proceso de desarrollo). Y eso que tienen todos los ejemplos que quieran en el mundo real, más allá del desarrollo de software, para entender la necesidad de una evolución, una adaptación o un mantenimiento del software.

Es cierto que el software es un elemento lógico y que como tal no se desgasta (de ahí la diferencia con el mantenimiento de un elemento físico) pero también lo es que las necesidades de los usuarios, de la organización o del negocio varían, así como su capacidad de inversión (lo mismo hay funcionalidades que no se abordaron por su coste que ahora sí que interesa llevar a cabo) y no se puede pretender, por irreal, que una primera versión finalista del software tenga en cuenta no solo las necesidades presentes sino las futuras (algo que por otra parte sería temerario salvo que se tuviera muy claro cuál es la línea de evolución del producto, algo que en muchos casos depende de muchos factores y variables externas).

La evolución del sistema no solo va a ser motivada por cambios originados por los usuarios y/o por el contexto (puede ser necesario modificar la aplicación para poder dar una respuesta a un determinado movimiento de un competidor en el mercado o para adelantarse a él), sino por la propia infraestructura que lo sustenta o incluso por los propios componentes, librerías, artefactos o backends que utiliza.

Esos elementos que pueden ser físicos o lógicos también evolucionan y la organización responde a esos cambios actualizando las diferentes versiones que utilizan de los mismos o sustituyéndolos por otros, ya que generalmente resuelven problemas de seguridad, robustez, rendimiento y eficiencia. Además estos cambios de versiones llevan aparejados una pérdida de soporte por parte del fabricante, por lo que por un motivo o por otro no tenemos más remedio que terminar evolucionándolos.

Este cambio, a su vez provoca una evolución de los propios sistemas (tareas en este caso de mantenimiento adaptativo), con el objeto de que puedan seguir funcionando en ese nuevo contexto tecnológico.

Lo mismo sucedería, por ejemplo, con las propias librerías que utiliza la aplicación, ¿no cambiaríamos de versión de determinadas librerías (siempre y cuando tengamos la oportunidad de hacerlo) si las nuevas versiones mejoran, por ejemplo, el rendimiento del sistema?.

Manny Lehman se hizo muy conocido por haber formulado las 8 leyes de evolución del software, las cuales se fundamentaron en el estudio que realizó en IBM junto a Laszlo Belady basado en la evolución de los sistemas operativos OS/360 y OS/370.

Dentro de ese estudio, realizado en 1974, me parece muy interesante la clasificación que realizaron de los sistemas de información:

– S-type (Static type): Son aquellos que pueden especificarse formalmente. Por ejemplo, sistemas que devuelven resultados en base a fórmulas ya definidas (una calculadora).

– P-type (Practical type): Son aquellos que pese a que pueden especificarse formalmente, su solución no es ni aparente, ni inmediata, lo que provoca que sea necesario un proceso iterativo para encontrar una solución válida. Se sabe, por tanto, el resultado que se necesita (o el esperado), pero no se sabe describir cómo llegar a él.

La característica principal de esos dos tipos de sistemas es la estabilidad de sus requisitos o especificaciones (una vez encontrada la solución adecuada en el P-type).

– E-type (Embedded type): Son aquellos que tratan de modelar procesos del mundo real y como consecuencia de su uso forman parte del mundo que tratan de modelar, dando lugar a una situación en la que el sistema y su entorno evolucionan de manera conjunta. Este tipo de sistemas son los más comunes hoy día.

Las leyes de evolución del software están basadas en los sistemas de tipo E, en el sentido de que al ser dependientes del contexto, están siempre en continua evolución.

En 1974, Lehman, considera ya el cambio como algo inherente a determinados tipos de sistemas de información y como algo que resulta necesario para mantener el equilibrio con su contexto (su entorno).