archivo

Archivo de la etiqueta: mantenimiento evolutivo

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

La realidad del desarrollo de software es que el parque de aplicaciones a mantener es muy superior al de nuevas aplicaciones a desarrollar y más en un contexto económico como el actual donde las limitaciones presupuestarias y la necesaria cautela en un entorno con tanta incertidumbre aconsejan medir muy bien las inversiones que se realizan y el software en particular y las TIC en general no son ajenos a esa circunstancia.

Por tanto buena parte del trabajo de los desarrolladores será mantener y gestionar sistemas de información que han sido desarrollados probablemente por otros (de tu organización o de otra). Eso es una realidad. Lo bonito es afrontar desarrollos desde cero, retos tecnológicamente interesantes, sin embargo, salvo que te dediques a hacer productos, lo más probable es que tengas que trabajar en mantenimientos. Es un trabajo y alguien tiene que hacerlo.

Los mantenimientos son poco agradecidos. Tenemos que gestionar o realizar tareas sobre sistemas de información con problemas (el mantenimiento evolutivo en la mayoría de los casos es consecuencia de la insatisfacción de los usuarios y/o de los responsables usuarios respecto a la situación actual de la aplicación), en los que tendremos severas limitaciones para mantenerlo (el presupuesto de mantenimiento por regla general será inferior a las necesidades reales que tiene el sistema a lo que hay que sumar las presión existente que lejos de ayudar a la consecución de los objetivos suponen una resistencia) y en donde todas las miradas van dirigidas a ti, con independencia o no de que hayas participado en el desarrollo inicial del sistema y en sus evoluciones posteriores.

Jim Horning lleva más de cuarenta años en este negocio dedicándose principalmente al campo de la investigación. Doctorado en Stanford, desarrolló los primeros años de su carrera laboral en la Universidad de Toronto, pasando después siete años en el Xerox Parc (entre 1977 y 1984), tras esa etapa siguió desarrollando su labor investigadora en otras entidades y centros.

Hay una cita de Horning, que refleja en gran medida la complejidad del trabajo que realizamos, ya sea cuando realizamos el mantenimiento evolutivo o adaptativo de un sistema o realizamos un desarrollo siguiendo un enfoque iterativo e incremental donde en cada iteración se pasan a producción partes funcionales del software: “La ciencia informática es la única disciplina en la que nosotros consideramos la construcción de una nueva ala a un edificio como si fuera un mantenimiento”.

Y es así, podemos cometer errores de gran impacto cuando se realizan modificaciones sobre un sistema en producción: funcionalidad mal implementada o mal especificada que puede afectar a una función de negocio importante, efectos colaterales, etc… y que después pueden obligar a tener que actuar con urgencia lo que a la vez puede traer consigo nuevos problemas.

El desarrollo de software es así, tal vez por eso nos gusta tanto a la par de que nos trae muchísimos (demasiados) problemas.

Nos encontramos con este antipatrón cuando ante un sistema de información de complejidad y tamaño medio/alto, con una deuda técnica alta, se solicita la realización de tareas de mantenimiento, generalmente evolutivo, de cierta envergadura, las cuáles deberían ejecutarse en un plazo de tiempo muy ajustado y se centran los esfuerzos en intentar conseguir ese objetivo, independientemente de que el producto vea incrementada su deuda técnica y complejidad.

El primer problema que nos encontramos es la existencia de una restricción temporal que condiciona los trabajos, lo que hace que se enfoquen los esfuerzos en “apagar el incendio”, dejando de lado la aplicación de determinadas buenas prácticas y controles de calidad del software si estos pudieran frenar el avance de la ejecución de las tareas.

Esto hace que el plan de proyecto se centre en dar una respuesta a la situación, dejando para el final la realización de tareas que mitiguen la deuda técnica y la simplificación de funcionalidades eliminando funcionalidades o código que no ya no tienen utilidad (ver antipatrones lava seca y ancla de barco). ¿Qué es lo que suele pasar? Pues que al final no haya tiempo para realizar esos ajustes, ya sea porque nos hemos quedado sin presupuesto y/o aparecen nuevos fuegos que ir mitigando.

Esa restricción temporal puede estar justificada ante la necesidad de adaptar un sistema de información a una normativa o para adaptar el sistema a un cambio en procesos o a un nuevo proceso que resultan esenciales para el funcionamiento de la organización y que de no estar en los plazos fijados podría suponer un importante perjuicio económico que podría incluso afectar seriamente no solo a los balances, sino incluso a la propia viabilidad de la compañía.

Otras veces la restricción temporal, pese a que pueda estar sustentada por ciertos criterios objetivos, no deja de ser un capricho de cierto personal directivo a los que un día en un “alarde de creatividad” deciden que es necesario realizar ajustes en un sistema o incluirle nuevos módulos.

El siguiente problema es la realización de cambios de cierta magnitud en un sistema con una deuda técnica elevada, que implican que cualquier tarea de desarrollo sobre el mismo (sobre todo aquellas que supongan modificaciones en módulos ya implementados) cueste muchísimo más esfuerzo (como correr con un vendaval de viento en contra, con carga en una mochila y con pegamento en la suela de las zapatillas), además de incrementarse la probabilidad de errores, tanto por posibles efectos colaterales como por la presión de ejecutar trabajo rápidamente, dejando de lado la realización de determinadas prácticas de aseguramiento de la calidad del software.

Al final, en el caso de que cumplamos el hito temporal (algo que en aquellos casos donde los plazos sean muy ajustados solo será posible priorizando tareas, teniendo a todos los stakeholders muy implicados y acertando mucho), tendremos un producto más complejo, más costoso de mantener (si cabe) y bastante más inestable.

Este antipatrón se produce cuando conociendo la existencia de un error en el sistema no se le presta atención o no se considera prioritaria su corrección al asumirse que la ocurrencia del mismo no ocasiona perjuicio al sistema, los usuarios, el servicio que se ofrece y/o la continuidad del negocio, sin haber realizado previamente un análisis del riesgo objetivo del mismo.

Los desarrolladores podemos considerar una incidencia como intrascendente y sin embargo para los usuarios y/o el negocio ser muy negativa. Hay que tener en cuenta que el producto no es para nosotros sino para un tercero y para unos propósitos concretos, por lo que nuestra opinión no es la única que vale a la hora de analizar el impacto e importancia de un error.

Si para el usuario todas las incidencias son urgentes y además también lo son los evolutivos a realizar, toca hacerlo bajar a la realidad de los recursos disponibles y de la metodología utilizada, no será fácil que lo entienda, pero no tendrá más remedio que priorizar.

Sistema desarrollado. En producción. Usuarios que no les gusta el resultado final o que no les parece adecuado el resultado que se obtiene como consecuencia de las directrices funcionales que dieron otros antes. Sistema de gran tamaño. Capacidad muy limitada a nivel presupuestario para poder ejecutar varias líneas de trabajo en paralelo. Usuarios que no quieren utilizar el sistema.

¿Os suena? Es el resultado típico de un proyecto desarrollado en cascada. Admito, ya lo he hecho en otros artículos, que estoy generalizando y que cada cual cuenta la historia tal como la ha vivido y/o puede observar en su entorno. Esta es mi visión sobre este tipo de desarrollo y no es teoría, os lo puedo asegurar.

Ante la situación descrita anteriormente hay dos alternativas posibles: renunciar al sistema de información (tirarlo a la basura) o que todas las partes (área usuaria, dirección usuaria y área informática) asuman lo desarrollado como propio y que tiren hacia adelante, teniendo en cuenta y muy presente, que lo que viene a continuación es una larga travesía en el desierto, donde habrá personas bastante descontentas y donde el uso del sistema será incómodo.

Asumir eso no es fácil, pero es lo que queda si se quiere salvar el sistema de información, ya que no se tendrá el mismo dinero para mantener que para desarrollar y el mantenimiento es sobre el conjunto del sistema (salvo que haya módulos que se prioricen sobre otros).

Llegado un punto el sistema de información empieza a deteriorarse. Existen funcionalidades que dejan de usarse o su utilización residual y que no se eliminan, hay errores que persisten versión tras versión y que afectan a la calidad del dato y a la adecuada realización del proceso a través del sistema, en lugar de mantenerlo lo más simple y funcional posible se añaden funcionalidades cada vez más complejas y que no proporcionan el valor esperado y/o dificultan el mantenimiento, etc…

El sistema crece y llegado un punto resulta complicado de controlar, sobre todo en proyectos grandes. Es complicado en estos casos tener una visión global de todo y no caer en errores que contribuyan a ese deterioro.

Por otro lado tenemos también tanto la corrección de incidencias y la adición de funcionalidades que conllevan en muchos casos la introducción de nuevos errores en el sistema ya sea en el propio código que se corrige o en el módulo que se añade o provocado por efectos colaterales en otras secciones del código y funcionalidades de la aplicación.

Frederick Brooks que dirigió el desarrollo del sistema operativo OS/360 sabe muy bien a que se refiere cuando habla de los inconvenientes del mantenimiento, sobre todo en proyectos complejos, de tamaño moderado y con grandes equipos de trabajo y su posible repercusión en el deterioro de la aplicación y lo podemos apreciar en su siguiente reflexión: “El problema fundamental del mantenimiento de un programa es que la corrección de un defecto tiene una probabilidad importante de introducir otro”.