archivo

Archivo de la etiqueta: mantenimiento

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

Cada persona tiene su propia percepción de la realidad. La comprensión de lo que se ve está modulada por una infinidad de variables que hace que incluso que una misma persona sobre un mismo hecho pueda tener percepciones distintas, aún existiendo un intervalo de tiempo pequeño entre ellas.

Ante esta situación, ¿qué podemos decir de las diferentes visiones que existen sobre la calidad del software? Pues lo mismo, existe una para cada persona, si bien, en muchos casos las diferencias son simples matices que hacen que entendamos que nuestra visión de la misma es igual que la de otros.

Es decir, a lo más que se podrá llegar es a agrupar a personas que tienen pensamientos similares sobre lo que debe ser, los cuales muy probablemente iran cambiando de grupo en función de su evolución profesional, conocimientos y experiencias.

Parece que es algo común asociar calidad con el software que funciona pero, ¿qué es el software que funciona?, ¿dónde está el umbral para determinar que un software funciona? No es adecuado establecer de antemano cuáles son esos límites porque no serán los mismos en una aplicación crítica que en otra que no lo es.

También parece que es común asociar calidad con software mantenible pero, volvemos a los mismo, ¿qué entendemos por software mantenible?, ¿software que sea fácilmente evolucionable?, ¿software con una deuda técnica acorde a sus características e inversión realizada?, ¿todo eso y más variables?.

En el fragor de la batalla, cuando los proyectos empiezan a tener problemas se prioriza que el “software funcione” sobre el “software mantenible” porque se entiende que lo segundo no sirve de nada si no se consigue lo primero.

Este error es muy común porque en el caso de que “no funcione” mejor que tengamos un software donde se pueda realizar con facilidad evoluciones y correcciones.

No se trata de priorizar la mantenibilidad porque si lo hacemos sin pensar en “que funcione” perderemos intención y se tirará, más adelante, mucho código que ha costado mucho esfuerzo poner en pie.

Para otro no se puede entender la calidad sin el cumplimiento de los plazos, sin la relación coste/beneficio, sin atender a los procesos de calidad y desarrollo de software de la organización, sin la existencia de documentación, etc…

Es difícil convencer a alguien de que cambie su visión sobre la calidad del software porque generalmente esos cambios de opinión vendrán dados por la propia experiencia personal, teniendo en cuenta que para poder cambiar y evolucionar hay que querer.

Es positivo intercambiar apreciones sobre este tema porque incluso en posiciones divergentes es posible encontrar nuevas variables a tener en cuenta o considerar diferentes puntos de vista sobre otras en las que ya creemos.

A veces nos encontramos con sistemas de información donde vemos de manera clara que hay que realizar modificaciones sensibles en su arquitectura y diseño porque de lo contrario no se van a poder resolver los problemas de base que tiene el producto.

Las estrategias utilizadas pueden ser variopintas, si bien todos los caminos no están abiertos, ya que hay una restricción muy importante a tener en cuenta que no es otra que el presupuesto con el que contamos.

Una posible estrategia puede ser la de desarrollar el producto de nuevo. Es la más limpia, pero para poder aplicarla es necesario que el sistema anterior realmente se haya desechado y no lo utilice nadie o bien que si se utiliza tengamos presupuesto suficiente para desarrollar el nuevo sistema manteniendo el actual (todo eso evaluando el tiempo que sería necesario para realizar la sustitución de uno por otro, al menos en aquellas funcionalidades que se consideren esenciales).

Si no se dan esas condiciones (puede que sea la que quisiéramos aplicar pero por mucho que hayamos solicitado fondos no se han conseguido), toca trabajar sobre lo que hay.

No se debe caer en la precipitación y querer cambiar de golpe partes importantes del sistema porque probablemente estaremos apostando todo a una sola carta. Lo mejor es que el cambio sea gradual, persiguiendo el objetivo que tenemos pensado (en consenso con los usuarios) porque será más fácil hacerlo dando saltos cortos, ya que de esta forma analizamos de manera más objetiva el siguiente paso que debemos dar y tendremos recursos económicos para atender otras necesidades que requiera el sistema.

¿Es el software que funciona el patrón a seguir? Para empezar deberíamos tener todos claro qué significa “software que funciona”, algo que resulta tan complicado como ponernos de acuerdo en dar una definición al término calidad del software.

Un software que funciona no es un software que corra sobre un sistema operativo o a través de un navegador, sino que sirva para el propósito para el que se ha desarrollado y eso se consigue si se satisfacen las expectativas que tenían los usuarios sobre él. Y las expectativas van más allá de valores funcionales, ya que hay otros aspectos como: usabilidad, rendimiento, disponibilidad y seguridad (entre otros), que también resultan de gran importancia.

Pero un software que funciona debe ser sostenible, es decir, debe estar preparado para podamos adaptarlo al cambio si resulta preciso, esto implica que se deban tener en cuenta otros factores como su mantenibilidad, algo que está directamente ligado a su deuda técnica.

Es posible que algunos esteis pensando que estoy tratando de dar mi propia definición de la calidad del software utilizando como excusa el término “software que funciona”. No lo niego, pero no es más que una visión personal en base a la visión actual que tengo del desarrollo de software, mañana puede que añada, quite o modifique matices y por supuesto, es probable, que varíe en función del proyecto.

¿Realmente se puede decir que el producto está terminado antes de que finalice su ciclo de vida? La realidad es que no es así, incluso en aquellos casos donde se encuentre sin evolucionar durante años.

Es más correcto decir que un proyecto se ha terminado que indicar que el producto está terminado porque lo contrario sería suponer que el producto no va a sufrir más modificaciones.

Precisamente el problema de los responsables técnicos de los sistemas de información (que también debería serlo por parte de los propietarios del producto) es que en cualquier momento pueden surgir necesidades de evolución y lo mismo no hay posibilidades en ese momento de dar respuesta a la misma en la medida y forma que se necesita. Es decir, si tienes una vinculación con el producto y no con el proyecto no vas a poder separarte de él, salvo que cambies de empresa, de departamento o tu jefe te indique otras prioridades (aunque, como sabes, seguirás realizando por mucho, mucho tiempo tareas relacionadas con ese sistema).