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

He insistido en diferentes artículos que gran parte de la suerte del proyecto se juega antes de que comience. Una mala negociación, una mala venta condiciona todo lo demás (pudiéndose partir de una situación de Death March Project) y solo produciéndose determinadas circunstancias ideales: un equipo de proyecto motivado y de calidad y un cliente y unos usuarios que facilitan las tareas, pueden paliar las pérdidas del proyecto, tangibles (en dinero), como intangibles (de pérdida de imagen con el cliente ante un proyecto de ejecución deficiente).

Sin embargo, la venta inicial del producto es solo una de las variables que condicionan el posterior desarrollo del proyecto, la elección de una mala metodología ya sea por parte del proveedor o impuesta por el cliente puede hacer estragos en el trabajo realizado, en el coste y en los resultados.

Lo mismo si no se delimita de manera adecuada el alcance (ya sea antes de la venta o antes incluso de empezar a recoger requisitos).

Y después toca el análisis. Si la metodología condiciona un desarrollo en cascada la realización de un análisis excelente es esencial, si bien, todo se puede ir al traste en el momento en que cambia algunas de las variables del proyecto (interlocutores, procesos, etc…) y es que los modelos predictivos tienen ese problema.

Si la metodología es ágil o al menos iterativa incremental (como RUP), las tareas de análisis también son de gran importancia, aunque desarrollos iterativos y evolutivos dan un mayor margen para la corrección de deficiencias en la captura e interpretación de los requisitos y en el modelado de la solución.

Por tanto, independientemente de que en función de la metodología aplicada la realización de un buen análisis tenga una mayor importancia, en todas condiciona el resto del proyecto y muchísimo.

Un mal análisis, si se detecta en etapas tardías (en muchos casos, cuando el producto ha llegado a producción), provocará un más que probable fracaso de la puesta en marcha del sistema y un más que probable esfuerzo económico importante para resolver esta circunstancia, mediante mantenimientos correctivos y evolutivos, que podrían ser incluso no asumibles si la deuda técnica del desarrollo es elevada.

Pero es que un mal diseño también tiene consecuencias y muy importantes en el resultado final del software.

Por eso destaco siempre que, además de contar con buenos programadores, disponer de buenos analistas funcionales y orgánicos permite que el trabajo de los que codifican brille más y sobre todo, sea útil.

De ahí la importancia de realizar testing desde el principio, fundamento este que dió lugar, por ejemplo a las metodologías de testing en V o en W.

En resumen, aunque muchos piensen que el partido se juega en la construcción del software, si no se han realizado de manera adecuada las etapas anteriores, el partido se habrá perdido antes de que el árbitro de el pitido inicial.

Quien esté libre de pecado que tire la primera piedra.

¿Nadie ha copiado y pegado código de Internet en su aplicación y ha hecho adaptaciones del mismo hasta que lo ha hecho funcionar?, ¿lo mismo solo que en lugar de Internet el código procede de otra aplicación de tu organización o en la que has participado previamente?.

Soy de la opinión de que en lo posible hay que intentar entender lo que se está haciendo porque si no es así, no tendremos completa seguridad, salvo que realicemos una buena batería de pruebas, de que realmente el código funciona. Además, si no lo entendemos y toca hacer una mantenimiento evolutivo del mismo, nos encontraremos con la misma situación de partida solo que ahora probablemente no tendremos código que copiar y adaptar.

A veces los plazos se nos echan encima, queremos quitarnos una tarea de cierta complejidad que realmente no tiene mucha importancia dentro del proyecto o hay algo que no nos termina de funcionar. Esto provoca que en ocasiones se busquen soluciones donde sea y se da lugar a esta práctica que todos sabemos que aunque pueda ser efectiva en ocasiones, no es nada positiva en el proceso de desarrollo de software.

Hay quien entiende esto como reutilización de código. Si se quiere reutilizar código, yo entiendo que lo mejor es utilizar la fórmula de las librerías, de las API (cuando se delega funcionalidades en terceros), ya que se tiene más controlado el software que se utiliza. También podría entender esto como reutilización de código si se comprende lo que se está haciendo, es decir, lo que se hace es ahorrar un trabajo que no va a aportar nada, que es pesado, que sabemos como hacerlo y que ya está hecho en otro proyecto.

Sobre copiar y pegar código de otras fuentes (en este caso Internet), el desarrollador Mike Johnson realiza la siguiente reflexión: “Copiar y pegar código de Internet en el código del programa es como masticar chicle que has encontrado en la calle”.

La respuesta la he obtenido en una cita anónima que dice que: “Cualquier programa que funciona correctamente está obsoleto”.

Es decir, la evolución del producto se puede extender a lo largo de todo su ciclo de vida porque en cualquier momento pueden aparecer nuevas funcionalidades que incorporar al sistema o la modificación de las ya existentes.

El desarrollo de software es así, evolutivo, cambiante y es importante que tengamos en cuenta ese aspecto a la hora de enfocar un proyecto, sobre todo si es complejo y/o de gran tamaño. También resulta fundamental la actitud pedagógica con la dirección de la organización y con otros departamentos para que tengan en cuenta este aspecto a la hora de designar los presupuestos para el Departamento TIC.