archivo

Archivo de la etiqueta: mantenimiento correctivo

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.

No debería ser así porque realmente no hay nada que justifique que el software se tenga que ir deteriorando conforme se van realizando tareas de mantenimiento con el mismo. Sin embargo todos estamos hartos de ver gráficas con el número de errores de un software que llegado a un punto empiezan a crecer de nuevo de manera lenta, pero continua.

Algunos de los motivos pueden ser los siguientes:

– El software desarrollado tiene una importante deuda técnica lo que complica las tareas de mantenimiento.

– Se dispone de poco tiempo para poder realizar mantenimientos correctivos o evolutivos por lo que la consecuencia es eliminar el problema cuanto antes, lo que da lugar a parches que solucionan el problema pero incrementan la deuda técnica del producto.

– El software no para de crecer en funcionalidades incrementándose su complejidad.

Sobre el deterioro del software, Weinberg tiene la siguiente reflexión: “No hay un código tan grande, retorcido o complejo que el mantenimiento no puede empeorar”.

En los proyectos de desarrollo de software muchos usuarios (y directores usuarios) cargan sobre las espaldas de los responsables técnicos del proyecto mucho más que la gestión técnica del proyecto, desentendiéndose de muchas decisiones en el proceso de análisis y de casi todas las que proceden del día a día de un mantenimiento evolutivo.

Los que nos dedicamos a esto tenemos la costumbre de asumir ese trabajo por el bien del proyecto. Son tantos meses los que nos hemos llevado en el desarrollo que ya lo sentimos como nuestro y como además hemos aprendido buena parte del negocio pues además de la vertiente técnica nos vemos capaces de decidir sobre lo funcional.

El inconveniente de afrontar un desarrollo y un mantenimiento de esa manera es que por un lado, los responsables funcionales no valorarán de manera adecuada el trabajo que haces ya que si bien mantienes el proyecto funcionando no saben el esfuerzo que requiere y no aportarán al mismo los medios económicos que requieren. Por otro lado, al no ser ellos quienes deciden, dan manga ancha al conjunto de usuarios para que pidan continuamente cambios, en muchos casos de manera contradictoria y centrándose en aspectos dudosamente prioritarios.

Cuando en un proyecto se entra en la dinámica de que los responsables técnicos lleven el peso del mismo es muy complicado salir de ella, ya se sabe que las costumbres son complicadas de romper, por eso es importante dejar las cosas claras desde el principio, desde el mismo proceso de desarrollo y si se nota que los usuarios empiezan a desatender sus obligaciones, exponerlo.

Lo más importante en el proyecto de desarrollo de software son las personas (así lo establece el movimiento ágil y lo demuestra nuestra experiencia en este negocio), todos los que participamos en los proyectos independientemente del rol que juguemos en ellos. Todos aportamos y si alguna de las partes falla, los resultados se resienten.

En muchas ocasiones no se entra en esa dinámica de manera voluntaria, son los propios superiores en la organización los que toman la decisión de que se funcione de esa manera. Ante esto es complicado encontrar una solución. Lo importante es que si esto se produce nosotros hayamos advertido hasta el máximo nivel organizativo al que podamos llegar que esta situación va a perjudicar al proyecto y después que en lo posible, utilicemos nuestra propia habilidad para intentar conseguir toda la colaboración que sea posible de los usuarios.

Si en un sistema de información hay muchos fuegos que apagar en forma de mantenimientos correctivos y evolutivos (siendo estos por cambios en las especificaciones iniciales del usuario) y recursos muy limitados para hacerles frente, lo mejor es olvidarse de evolucionar el sistema en una línea distinta a donde se encuentran los problemas.

De no hacerse así, no solo no se solucionarán los problemas, sino que el fuego terminará consumiendo los nuevos desarrollos.

Una vez estabilizado el sistema de información (lo cual no quiere decir que se hayan eliminado todos los inconvenientes, ya que estos son como cuando un cristal se rompe, pasan meses y todavía te encuentras fragmentos por el suelo) y teniéndolo bajo control (cosa que es complicada de conseguir cuando llegan más tareas que las que se pueden afrontar, hay mucho ruido de fondo y todas son urgentes), ya se podría empezar a pensar en una evolución del mismo, sin perder de vista que la misma debe ser acorde a los recursos presentes y futuros.

Puede parecer que todo vale por ganar contratos en tiempos de crisis (y en tiempos de no crisis). Se tiran los precios, se ofrece lo posible y lo imposible y nada parece lo suficientemente difícil.

¿Qué pasa después? Desgaste y más desgaste, tijeretazos al alcance, la calidad por los suelos y cuando no un montón de código que no se comporta como quiere el usuario.

Los proyectos de desarrollo de software valen lo que valen, todo es optimizable, lo mismo el alcance de los trabajos se adapta a otros desarrollos previos y basta con hacer adaptaciones, todo eso es analizable, ahora bien, cuando lo que se ofrece es a todas luces imposible, lo más probable es que realmente lo sea.

Si no hay dinero para hacer un desarrollo, busca si existe un producto que se ajusta a tus posibilidades, si no hay ni una cosa ni la otra, lo mejor es que se espere a disponer de presupuesto suficiente, siempre será mejor eso que tirar el dinero o invertir una cantidad que se te multiplicará después en tareas de mantenimiento correctivo y evolutivo con una deuda técnica importante.

Se entrega una iteración de un sistema, se realiza una evolución del mismo mediante tareas de mantenimiento evolutivo o se corrigen incidencias y no paran de producirse efectos colaterales, una vez, otra vez y otra vez.

Además de dar muestras de que no se realizan pruebas de regresión de manera adecuada (o directamente no se llevan a cabo), el sistema de información da muestras de tener un diseño y/o una codificación deficiente, ya que cuando se toca un componente empiezan a salir grietas por todos lados.

Cuando esto pasa, la sensación de desconfianza entre los usuarios o los responsables tećnicos del cliente es tal que cualquier cambio en el sistema da sensación de pánico y lo peor de todo es que esas sensaciones se terminan convirtiendo en un hecho.

Cuando nos encontramos con estos problemas, hay que estudiar cuanto antes su origen. A veces serán aspectos concretos que se podrán más o menos controlar y otras veces serán tantas las minas en el código que cualquier cambio presenta un riesgo de efectos colaterales.

Una vez detectadas las causas toca tomar decisiones que dependerán de la envergadura del problema, de la disponibilidad presupuestaria y de la frecuencia con que se esperen tareas de mantenimiento sea del tipo que sea.

Una continuación de este artículo se puede leer en Testing Baires.