3.7 Mantenimiento del software

Panorama y motivación

La gran mayoría de la vida de un programa no se dedica a su construcción, sino a su mantenimiento. En el instante en que un sistema sale a producción, ingresa en una fase (que con frecuencia se prolonga durante años o décadas) de reparación de defectos, adaptación a un entorno cambiante, mejora de lo que ya funciona y prevención de problemas futuros. En grandes organizaciones, y sobre todo en el sector público, esta fase domina el ciclo. Los motores de cálculo fiscal, los sistemas de prestaciones, las plataformas de defensa y los contables financieros centrales se mantienen durante mucho más tiempo del que sus encargantes previeron. El mantenimiento del software es la disciplina de mantener el software entregado correcto, actual y valioso a lo largo de toda su vida operativa.

El mantenimiento se subestima y se infravalora de forma crónica, y ese error tiene un coste elevado. Estudio tras estudio, a lo largo de decenios, sitúa el mantenimiento por encima de la mitad del coste total del ciclo de vida del software, con cifras habitualmente citadas entre el 60 y el 90 por ciento para los sistemas de larga duración. Y sin embargo, las organizaciones planifican, presupuestan, dotan de personal y celebran la construcción inicial como si fuera el proyecto completo. Luego tratan todo lo que viene después como un postscript, financiado desde una partida cada vez más reducida y asignado a quien esté disponible. El resultado es predecible: sistemas frágiles, mantenedores desmoralizados, un coste de cambio en ascenso y, al final, una crisis que se presenta como un «problema de sistemas heredados» (capítulo 3.6) cuando en realidad fue un problema de mantenimiento no gestionado desde el principio.

Este capítulo sigue el área de conocimiento de Mantenimiento del Software del SWEBOK (Cuerpo de Conocimiento de Ingeniería de Software) y la norma ISO/IEC 14764. Aborda los fundamentos del mantenimiento y sus cuatro categorías reconocidas; los principales obstáculos que lo hacen difícil, entre ellos el coste, la dotación de personal y el ánimo; el proceso de mantenimiento; las técnicas fundamentales de compresión del programa, reingeniería y refactorización; cómo estimar el coste del mantenimiento y (la idea de mayor alcance del capítulo) cómo diseñar para la mantenibilidad desde el inicio. La convicción central es que el mantenimiento no es una actividad menor que sigue a la ingeniería. Es la mayor parte de la ingeniería de software, y debe planificarse, dotarse de recursos y respetarse como tal.

Principios clave

El mantenimiento es la mayor parte del ciclo de vida, no un epílogo. Plánificalo y presupuéstalo desde el primer día; costará más que la construcción.
Las cuatro categorías son trabajos distintos. El mantenimiento correctivo, adaptativo, perfectivo y preventivo tienen distintos impulsores y ritmos; la mayor parte del esfuerzo no es la reparación de defectos.
No se puede modificar lo que no se comprende. La compresión del programa es la actividad individual más extensa del mantenimiento; haz que el código y su historia sean legibles.
La mantenibilidad es una propiedad de diseño. El coste del cambio futuro se fija en gran medida por las decisiones tomadas durante la construcción; diseñe para ello de forma deliberada.
El cambio continuo, pequeño y seguro supera al cambio diferido y de gran envergadura. Refactorice y modernice de forma incremental bajo una red de seguridad de pruebas, en lugar de acumular una deuda de cambio.
El software envejece aunque permanezca inerte. El entorno se mueve (dependencias, plataformas, regulaciones), así que un sistema estático se pudre en silencio; el mantenimiento preventivo es un trabajo real.
Los mantenedores merecen un estatus de primer orden. El ánimo, la retención de conocimiento y la dotación de personal de los equipos de mantenimiento determinan directamente el coste y el riesgo a largo plazo.

Recomendaciones

Distinga las cuatro categorías de mantenimiento y dote de personal para todas

La ISO/IEC 14764 y el SWEBOK reconocen cuatro categorías, y confundirlas es un error habitual en la planificación. El mantenimiento correctivo repara defectos detectados en operación. El mantenimiento adaptativo mantiene el software operativo ante los cambios de su entorno: nuevos sistemas operativos, navegadores, dependencias, hardware, regulaciones o sistemas de interconexión. El mantenimiento perfectivo mejora el software para usuarios y mantenedores, a través de nuevas funciones, mejor rendimiento, mayor usabilidad y mayor mantenibilidad. El mantenimiento preventivo corrige fallos latentes y reduce el riesgo futuro antes de que se manifiesten, mediante el refuerzo, la limpieza y la modernización de áreas frágiles. Una subdivisión útil agrupa el correctivo y el preventivo como corrección (atención a los defectos) y el adaptativo y el perfectivo como mejora (atención a nuevos requisitos). Lo crucial es que los estudios empíricos constatan de forma constante que la mayor parte del mantenimiento no es correctivo; la mejora y la adaptación dominan. Presupuesto y dotación de personal en consecuencia, y registre en qué categoría cae realmente su esfuerzo para poder gestionarlo.

Invierta en la compresión del programa

La actividad individual más extensa del mantenimiento es comprender el sistema existente lo suficientemente bien para modificarlo con seguridad. Los mantenedores dedican habitualmente más tiempo a leer y razonar sobre el código que a modificarlo. Haga que esto sea más barato de forma deliberada. Mantienga la documentación cerca del código y actualizada (capítulo 2.7). Preserve la historia de las decisiones mediante registros de decisiones de arquitectura (capítulo 1.6) y un historial de commits limpio (capítulo 2.6). Utilice análisis estático, gráficos de dependencias y herramientas de navegación de código para cartografiar territorio desconocido. Las pruebas de caracterización (pruebas que fijan el comportamiento actual, incluidas las particularidades) convierten el conocimiento tácito en conocimiento ejecutable y duradero. Cuando comprender es caro, cada cambio es lento y arriesgado. Cuando es barato, el mantenimiento se vuelve rutinario.

Refactorice de forma continua bajo una red de seguridad de pruebas

La refactorización es la reestructuración disciplinada de código que mejora su calidad interna sin alterar su comportamiento externo. Realizada de forma continua y en pequeños pasos, contrarresta el derrape natural hacia la complejidad y mantiene el coste del cambio estable en lugar de ascendente. La condición innegociable es una suite de pruebas automatizadas fiable (capítulo 2.4). Sin ella, «refactorizar» es simplemente reescribir con riesgo. Integre la refactorización en el trabajo cotidiano: deje cada módulo un poco más limpio de como lo encontró, en lugar de reservarla para limpiezas raras, grandes y peligrosas. Esto es mantenimiento preventivo en la práctica, y es el mantenimiento más barato que existe.

Reingeníere cuando el cambio incremental ya no es suficiente

Cuando un componente ha degradado hasta el punto en que el cambio rutinario resulta demasiado costoso o arriesgado, la reingeniería (examinar y alterar un sistema para reconstruirlo en una nueva forma) es la herramienta más pesada. La reingeniería combina habitualmente la ingeniería inversa (recuperar el diseño y la intención a partir de la implementación) con la reingeniería directa (construir sobre una mejor estructura preservando el comportamiento). Prefiera reingenierar en fragmentos acotados e incrementales, usando patrones como el de la figuera estranguladora (strangler fig) y la rama mediante abstracción (branch-by-abstraction) (capítulo 3.6), en lugar de una reescritura global. La reingeniería se sitúa en el continuo entre mantenimiento y modernización: refactorización para lo pequeño y local, reingeniería para lo estructural y modernización para lo a nivel de plataforma.

Ejecute un proceso de mantenimiento definido

El mantenimiento se beneficia de un proceso explícito y repetible, tal como describe la ISO/IEC 14764: implementación del proceso (establecimiento de planes y procedimientos), análisis de problemas y modificaciones (clasificación, reproducción, evaluación de impacto y coste), implementación de la modificación, revisión y aceptación del mantenimiento, migración y retirada. Envuélvalo en una gestión del cambio disciplinada: toda solicitud de mantenimiento, sea un informe de defecto o una mejora, debe registrarse, clasificarse por categoría, evaluarse en su impacto, priorizarse, implementarse bajo control de versiones con pruebas, revisarse y publicarse a través del flujo de trabajo habitual (capítulo 11.2). El análisis de impacto (comprender todo lo que un cambio propuesto pueda tocar) es central y merece un esfuerzo real. La retirada también forma parte del proceso: la desactivación segura de un sistema, la migración de sus datos y usuarios y la preservación de registros son trabajo de mantenimiento que debe planificarse, no improvisarse.

Estime el coste del mantenimiento de forma explícita y fináncielo

No trate el mantenimiento como algo gratuito ni como ruido en el presupuesto de construcción. Estímelo. Los enfoques habituales incluyen las proporciones de esfuerzo de mantenimiento (la regla práctica ampliamente utilizada de que el mantenimiento anual ronda el 15 al 25 por ciento del coste de desarrollo original, aunque los sistemas críticos de larga duración acumulan mucho más a lo largo de su vida), modelos paramétricos como el COCOMO II (Modelo Constructivo de Coste) con sus extensiones de mantenimiento y reutilización, y la predicción basada en métricas a partir de sus propios datos históricos de tasas de defectos, volumen de cambios y coste del cambio. Alimente estas estimaciones en el análisis del coste total de propiedad y en la economía tratada en el capítulo 10.10. El precio de compra o el coste de construcción de un sistema es la entrada. La hipoteca es el mantenimiento, y debe figurar en cada caso de negocio.

Diseñe para la mantenibilidad desde el inicio

La mayor palanca sobre el coste del mantenimiento se ejerce antes de que comience. La mantenibilidad (analizabilidad, modificabilidad, probabilidad y modularidad, en la terminología de la ISO/IEC 25010) es una calidad de diseño que debe ser un requisito explícito, no una feliz casualidad. Prefiera diseños modulares, de acoplamiento débil y alta cohesión (capítulo 2.2); interfaces claras y separación de responsabilidades; pruebas automatizadas sólidas; código legible y documentación actual; y una rica observabilidad para que operadores y mantenedores puedan ver lo que el sistema hace (Parte 9). Cada una de estas decisiones intercambia un poco más de esfuerzo ahora por grandes ahorros, con efecto compuesto, a lo largo de las décadas que el sistema vivirá realmente. Construir para la mantenibilidad es la inversión de mayor rentabilidad en todo el ciclo de vida.

Compensaciones: ventajas e inconvenientes

Enfoque	Ventajas	Inconvenientes
Refactorización continua / mantenimiento preventivo	Mantiene el coste del cambio estable, reduce el riesgo, alta rentabilidad	Esfuerzo continuo sin funciones nuevas visibles; exige pruebas sólidas
Diferir el mantenimiento («mantener las luces encendidas»)	Lo más barato este trimestre; libera capacidad para funciones	La deuda de cambio se compón; crisis eventual y acción forzada y costosa
Reingeniería de un componente degradado	Restaura la mantenibilidad y prolonga la vida útil	Esfuerzo y riesgo significativos; el comportamiento debe preservarse con cuidado
Diseñar para la mantenibilidad desde el inicio	Ahorros a lo largo de la vida con efecto compuesto; cada cambio futuro más fácil	Coste inicial mayor y disciplina; los beneficios se diferían y son menos visibles

La compensación recurrente en el mantenimiento es el coste presente frente al coste futuro, y la tentación siempre tira hacia el diferimiento. Omitir la refactorización, dejar que las dependencias envejecen y privar al equipo de mantenimiento de recursos parecen gratuitos este trimestre, porque la factura llega después: como un sistema más lento, más arriesgado y más caro, y eventualmente como una «crisis de sistemas heredados». La disciplina del buen mantenimiento consiste en pagar costes pequeños, continuos y visibles ahora para evitar costes grandes, súbitos y que definen carreras profesionales más tarde. Como los ahorros son diferidos e invisibles, esta compensación exige una dirección que entienda la economía del ciclo de vida, no solo las fechas de lanzamiento.

Preguntas para discutir con su equipo

¿Quién es responsable del presupuesto de mantenimiento en su organización, y es una partida de primer orden o un residuo raspado de lo que la construcción no gastó? El mantenimiento es la mayor parte del coste del ciclo de vida, habitualmente entre el 60 y el 90 por ciento para sistemas de larga duración, y sin embargo se financia de forma sistemática como un olvido y se dotó con quien esté libre. Cuando el presupuesto es residual, el trabajo preventivo es lo primero que se recorta, la deuda de cambio se compón y comienza un deslizamiento predecible hacia una «crisis de sistemas heredados». Aporte una estimación real (una proporción de esfuerzo de mantenimiento, un modelo paramétrico o sus propios datos históricos de coste de cambio) y nombre a la persona responsable de financiarlo a lo largo de la vida del sistema. La solución es presupuestar el mantenimiento de forma explícita en cada caso de negocio, del mismo modo que una hipoteca se sitúa junto al precio de compra. Una dirección que solo celebra lanzamientos seguirá infravalorando la fase donde reside la mayor parte del dinero y del riesgo.
¿Reservan capacidad para el mantenimiento preventivo, o siempre pierde ante la siguiente función? El trabajo preventivo (refactorización bajo una red de pruebas, actualización de dependencias, refuerzo de áreas frágiles) es el mantenimiento más barato que existe, porque mantiene la curva de coste del cambio estable en lugar de dejarla subir. Es también el más fácil de diferir, ya que omitirlo parece gratuito este trimestre y la factura llega después como un sistema más lento y arriesgado. Un mecanismo concreto ayuda: una asignación permanente (muchos equipos sólidos protegen aproximadamente una quinta parte de su capacidad) que se resguarda en lugar de negociarse cada iteración. Aporte su tendencia del coste del cambio como evidencia; si está ascendiendo, ya están invirtiendo insuficientemente. La disciplina consiste en pagar costes pequeños, visibles ahora para evitar costes grandes, súbitos y que definen carreras más tarde, y eso exige una dirección que lea la economía del ciclo de vida en lugar de las fechas de lanzamiento.
¿Cuál es su plan para retirar un sistema, y cuándo desactivó realmente uno por última vez? La retirada es una parte explícita del proceso de mantenimiento (migración de datos, conmutación de usuarios, preservación de registros, apagado seguro), y sin embargo las organizaciones arrastran sistemas muertos y redundantes durante años porque desactivarlos es un trabajo ingrato y sin presupuesto. Cada sistema zombi sigue consumiendo licencias, parches de seguridad, superficie de integración y la atención de personas que podrían estar en otro sitio. Aporte un inventario y marque los sistemas sin usuarios activos o con un reemplazo ya operativo, y planee su desactivación como cualquier otro trabajo: migrar los datos, preservar lo que la normativa exige y confirmar que nada depende todavía de ellos. En el sector público sobre todo, la legislación de retención de documentos condiciona cómo se retira, así que involucre a cumplimiento desde el principio. Una señal de madurez que merece seguimiento: ¿cuándo desactivó su organización deliberadamente algo?
¿Qué proporción de cada cambio se dedica a comprender el sistema antes de tocarlo, y cuál es el factor bus de los sistemas que más importan? La compresión del programa es la actividad individual más extensa del mantenimiento, y su coste lo fija lo legible que se ha mantenido el código, su historia y su comportamiento. Cuando el conocimiento vive solo en la cabeza de unos pocos profesionales con larga antigüedad, cada salida o jubilación encarece cada cambio futuro, y una sola ausencia puede paralizar una corrección crítica. Aporte evidencia: la proporción entre tiempo de lectura y razonamiento frente a tiempo de edición en los cambios recientes, el número de personas que pueden modificar con seguridad cada módulo central, y si las reglas de negocio y las decisiones están documentadas junto al código o se reconstruyen de memoria cada vez. La consideración contraria es real: la documentación y las pruebas de caracterización cuestan esfuerzo ahora por ahorros que solo se manifiestan más tarde, por lo que son fáciles de saltarse. En entornos empresariales y de sector público, donde los sistemas superan con creces a sus autores originales por décadas y las reglas normativas están sepultadas en un motor de cálculo que nadie recuerda del todo, trate la compresión capturada (registros de decisiones de arquitectura, pruebas de caracterización, documentación actualizada) como un activo que se financia de forma deliberada, no como una cortesía que se hace cuando alguien tiene tiempo libre.
¿Quién cubre realmente el trabajo de mantenimiento, y su estatus y ánimo reflejan su importancia? El mantenimiento es la mayor parte del coste del ciclo de vida y la ingeniería más difícil que existe: modificar con seguridad sistemas que no se construyeron y quizá no se comprenden del todo. Sin embargo, se asigna de forma sistemática a las personas con menos experiencia y se enmarca como un trabajo de bajo estatus, «mantener las luces encendidas». Esa señal es corrosiva: los mejores ingenieros evitan el trabajo, el conocimiento se concentra y luego se marcha por la puerta, y el coste del cambio sube mientras nadie lo vigila. Aporte el perfil de senioridad de quienes mantienen los sistemas de mayor antigüedad, sus datos de rotación y retención de conocimiento, y una valoración honesta de si el mantenimiento es un callejón sin salida profesional o una especialidad respetada en su organización. La tensión es real: los ingenieros ambiciosos quieren construir cosas nuevas y la dirección quiere celebrar lanzamientos, así que respetar el mantenimiento exige estructura deliberada. Para una gran empresa o un organismo público que gestiona sistemas que soportan riesgo regulatorio y financiero durante décadas, dotar el mantenimiento con ingenieros seniors respetados es una decisión de gestión del riesgo, y permitir que el mantenimiento se convierta en un destino punitivo es cómo se fabrica la próxima crisis de sistemas heredados.
¿Registran en cuál de las cuatro categorías cae realmente su esfuerzo, y miden el coste del cambio como indicador anticipatorio? Los equipos planifican el mantenimiento como si fuera sobre todo reparación de defectos, cuando los estudios empíricos muestran que la mejora y la adaptación dominan, de modo que un portafolio financiado solo para trabajo correctivo tiene un alcance equivocado desde el inicio. Sin el registro por categoría no se puede ver que un sistema está siendo remodeledo por un flujo constante de adaptaciones normativas, y sin una métrica de coste del cambio (tiempo de ciclo del cambio, tasa de fallo del cambio, tendencias de complejidad) no se puede saber si la curva es estable o asciende en silencio hacia una crisis. Aporte su desglose real por categorías del último año, su tendencia del coste del cambio si la tienen, y una nota honesta sobre si el análisis de impacto es un paso real o una formalidad que se omite bajo presión de plazo. El tirón contrario es que la medición en sí cuesta esfuerzo y puede parecer sobrecarga mientras el sistema sigue funcionando. En portafolios empresariales y de sector público, donde muchos equipos mantienen muchos sistemas y una curva ascendente en cualquiera de ellos es una señal de alerta temprana que merece acción, el registro compartido por categorías y los indicadores de coste del cambio son lo que permite a la dirección reingenierar un módulo antes de que se degrade, no después de que falle en público.

Perspectiva por sector

Startup. Con un puñado de ingenieros y poco margen, no se puede permitir un proceso de mantenimiento pesado, pero tampoco se puede permitirse una base de código a la que nadie quiera tocar. Reserve un pequeño espacio fijo en cada ciclo (aproximadamente un día cada cinco) para trabajo preventivo: parchear dependencias, resolver defectos menores antes de que se compon y refactorizar los rincones que ya se temen bajo las pruebas que se tengan. El objetivo es mantener el código barato de modificar mientras se pivotea, para no despertarse con veinte ingenieros confundiendo el mantenimiento diferido con un «problema de sistemas heredados».

Pequeña empresa. Sin un especialista en mantenimiento y con un presupuesto ajustado, inclínese hacia comprar y alojar en lugar de construir, de modo que el mantenimiento adaptativo (parches de seguridad, actualizaciones de plataforma y dependencias) sea en gran medida tarea de otro. Donde sí posea código, manténgalo pequeño, aburrido y bien documentado, y asegúrese de que al menos dos personas comprendan cualquier cosa en la que la empresa dependa. Registre el puñado de sistemas que no puede permitirse perder, y presupueste una línea modesta y explícita para mantenerlos al día, en lugar de fingir que el mantenimiento es gratuito.

Gran empresa. A escala, se mantienen muchos sistemas de larga duración a lo largo de muchos equipos, por lo que la prioridad es un proceso definido y repetible: una canalización de solicitudes registrada y clasificada, la clasificación en las cuatro categorías, el análisis de impacto rutinario y una asignación preventiva permanente que se resguarde en lugar de negociarse. Financie el mantenimiento como un programa de primer orden, mida los indicadores de coste del cambio a lo largo del portafolio y use una curva ascendente como disparador para reingenierar un módulo antes de que se convierta en un lastre. Las expectativas de gobernanza y auditoría significan que el registro por categorías y los registros de cambio no son sobrecarga, son la evidencia de que el parque está bajo control.

Sector público. Las normas de contratación, la transparencia y la rendición de cuentas pública condicionan el mantenimiento tanto como la ingeniería. El mantenimiento adaptativo impulsado por la legislación llega con plazos anuales ineludibles que no pueden deslizarse, así que presupueste el mantenimiento como un coste operativo indefinido y dote de un equipo experto y estable que retenga el conocimiento de reglas cuyos autores se jubilaron hace años. La retirada está condicionada por la legislación de retención documental, así que planee la desactivación con cumplimiento desde el principio, y prefiera contratos y arquitecturas que mantengan el sistema mantenible y portable en lugar de atraparlo con un único proveedor durante décadas.

Ejemplos

Startup. Una startup que acaba de lanzar su MVP tiene la tentación de dedicar cada hora a nuevas funciones, pero su ingeniero fundador reserva un espacio fijo en cada iteración (aproximadamente un día cada cinco) para mantenimiento desde el primer mes. Ese presupuesto mantiene las dependencias al día, resuelve defectos menores antes de que se compon y refactoriza los rincones que el equipo ya teme, de modo que la base de código se mantiene barata de modificar mientras el producto pivotea. Las startups que omiten esto llegan a veinte ingenieros con una base de código a la que nadie quiere tocar y la confunden con un «problema de sistemas heredados» cuando en realidad fue mantenimiento diferido desde el principio.

Gran empresa. Un banco global gestiona una plataforma de pagos que lleva quince años en producción. Financia el mantenimiento como un programa permanente de primer orden, no como una línea presupuestaria residual. El trabajo se clasifica en las cuatro categorías: un flujo constante de cambios adaptativos sigue nuevas regulaciones y actualizaciones de interfaz con bancos asociados, el trabajo perfectivo añade funciones y mejora el throughput, el correctivo resuelve defectos contra acuerdos de nivel de servicio estrictos, y una asignación preventiva permanente (aproximadamente una quinta parte de la capacidad del equipo) va abonando la complejidad mediante refactorización continua bajo una suite de pruebas exhaustiva. El equipo mide el tiempo de ciclo del cambio y la tasa de fallo del cambio, y trata una curva ascendente como una señal de alerta para reingenierar un módulo antes de que se convierta en un lastre. Los mantenedores son ingenieros seniors bien considerados, no personal junior aparcado en «mantener las luces encendidas».

Sector público. Una agencia fiscal nacional mantiene un sistema que lleva más de treinta años en funcionamiento y se modifica cada año con el cambio de la ley de impuestos. La categoría dominante aquí es el mantenimiento adaptativo impulsado por la legislación, con plazos anuales ineludibles. La autoridad invierte mucho en la compresión del programa: las reglas de negocio están documentadas junto al código, las pruebas de caracterización fijan el comportamiento de reglas cuyos autores originales se jubiló hace años, y el análisis de impacto es un paso formal antes de cualquier cambio en el motor de cálculo. Dado que el entorno (la ley) cambia de forma continua, el sistema nunca puede estar «terminado», por lo que la autoridad presupuesta el mantenimiento como un coste operativo indefinido, dota de un equipo experto y estable para retener el conocimiento y moderniza las prácticas de entrega circundantes (como el control de versiones, la integración continua y las pruebas automatizadas) aunque el núcleo perdure.

Caso de negocio: motivaciones, rentabilidad y coste total de propiedad

El hecho económico central del software es que el mantenimiento, no la construcción, es donde se va el dinero. A lo largo de la industria y de decenios de estudios, el mantenimiento representa la clara mayoría del coste del ciclo de vida, con cifras habitualmente citadas entre el 60 y el 90 por ciento para los sistemas de larga duración, que en el sector empresarial y público son la mayor parte. Cualquier análisis del coste total de propiedad que se detiene en la salida a producción está equivocado por un factor de varios. El caso de negocio primario para tomar el mantenimiento en serio es simplemente la precisión: presupueste toda la vida del sistema, o será sorprendido repetidamente por la factura.

La rentabilidad viene de doblar la curva de coste. En un sistema descuidado, el coste de cada cambio asciende con el tiempo a medida que la complejidad se acumula y la compresión decae, hasta que el cambio se vuelve prohibitivamente lento y arriesgado. En un sistema bien mantenido, el trabajo preventivo continuo (refactorización, actualización de dependencias, cobertura de pruebas, documentación) mantiene esa curva estable, de modo que el milésimo cambio cuesta aproximadamente lo que el décimo. Invertir en la mantenibilidad y el mantenimiento preventivo no es un gasto que se minimiza. Es la palanca que determina si un sistema se mantiene asequible de modificar o se desvía hacia el coste y el riesgo crecientes de un parque de sistemas heredados (capítulo 3.6) y los desafíos de sostenimiento del capítulo 10.4. Financie el mantenimiento de forma deliberada, mida el coste del cambio como indicador anticipatorio y trate una curva ascendente como una señal para actuar, no como un hecho de la naturaleza. La economía se desarrolla con mayor detalle en el capítulo 10.10.

Antipatrones y trampas

Tratar el mantenimiento como un olvido. Presupuestar y celebrar solo la construcción, y luego privar de recursos la fase mucho mayor y más larga del mantenimiento.
Dotar el mantenimiento con las personas de menor experiencia. Asignar el trabajo más difícil (modificar con seguridad sistemas que no se comprenden del todo) a quienes menos preparados están, y enviar la señal de que el mantenimiento es un trabajo de bajo estatus.
Confundir el mantenimiento con la reparación de defectos. Planificar solo para el trabajo correctivo cuando la adaptación y la mejora dominan realmente el esfuerzo.
Diferir el mantenimiento preventivo indefinidamente. Nunca refactorizar, nunca actualizar dependencias, hasta que la deuda de cambio force una crisis costosa.
Cambiar código sin análisis de impacto. Realizar una «pequeña corrección» que se propaga en fallos imprevistos en otros lugares.
Refactorizar sin red de seguridad de pruebas. Reestructurar código sin forma de demostrar que el comportamiento se preservó: eso es simplemente reescribir con riesgo.
Dejar que el conocimiento se marche por la puerta. No documentar las reglas de negocio ni las decisiones, de modo que cada jubilación o salida encarece cada cambio futuro.
No retirar nada. Arrastrar sistemas muertos y redundantes durante años porque desactivarlos es un trabajo ingrato y sin plan.

Modelo de madurez

Nivel 1: Iniciar. El mantenimiento no está planificado ni financiado; se gestiona de forma reactiva por quien esté libre. Se percibe como reparación de defectos y como un trabajo de bajo estatus. No hay registro por categorías, no hay estimación de coste y el conocimiento vive en unas cuantas cabezas. El coste del cambio asciende sin que nadie lo note, hasta que una corrección se estanca o una crisis fuerza la atención.
Nivel 2: Desarrollar. Algunos equipos han comenzado a registrar y clasificar las solicitudes de mantenimiento y a llevar una línea presupuestaria, pero la práctica es irregular a lo largo de la organización y el presupuesto suele ser residual. El trabajo correctivo se registra, mientras que el esfuerzo adaptativo y perfectivo no se distingue con claridad. Existen pruebas y documentación en focos, de modo que el cambio está parcialmente controlado, pero la compresión sigue siendo cara y desigual de un equipo a otro.
Nivel 3: Estandarizar. Un proceso de mantenimiento definido (según la ISO/IEC 14764) está documentado y se aplica en toda la organización: el trabajo se clasifica en las cuatro categorías, el análisis de impacto y la gestión del cambio son rutinarios, y el mantenimiento se estima y financia de forma explícita en cada caso de negocio. El mantenimiento preventivo y la refactorización son práctica habitual bajo una suite de pruebas sólida, y la mantenibilidad (analizabilidad, modificabilidad, probabilidad y modularidad) es un requisito de diseño explícito en lugar de un hábito local.
Nivel 4: Gestionar. El mantenimiento se mide y controla con datos frente a líneas base. Los indicadores de coste del cambio (tiempo de ciclo del cambio, tasa de fallo del cambio, tendencias de complejidad y defectos) se rastrean por sistema, la mezcla de esfuerzo por las cuatro categorías se cuantifica frente a las expectativas, y las proporciones de esfuerzo de mantenimiento y las estimaciones paramétricas se cotejan con el coste real de cambio histórico. Una curva ascendente se detecta como indicador anticipatorio y dispara una acción, y la asignación preventiva se dimensiona a partir de la evidencia en lugar de con conjeturas. Las decisiones de refactorizar, reingenierar o retirar se toman con umbrales medidos, no con intuición.
Nivel 5: Orquestar. El mantenimiento mejora de forma continua y se integra a lo largo de la organización y su economía de ciclo de vida. El coste total de propiedad a lo largo de la vida dirige la inversión del portafolio, la reingeniería se aplica de forma deliberada antes de que los componentes se degraden, el conocimiento se retiene activamente y la retirada se planifica y ejecuta de forma rutinaria. La organización reequilibra el esfuerzo de mantenimiento a medida que el entorno cambia (regulaciones, plataformas, dependencias), los mantenedores son ingenieros seniors respetados y todo el parque se adapta para que el coste del cambio se mantenga estable en sistemas que viven durante décadas.

Ideas para la discusión

¿Qué fracción de su esfuerzo de ingeniería se dedica realmente al mantenimiento, y reflejan su presupuesto y su dotación de personal esa realidad?
¿Pueden desglosar su trabajo de mantenimiento en las cuatro categorías, y la mezcla coincide con sus suposiciones?
¿Qué proporción de un cambio típico se dedica a comprender el sistema frente a modificarlo, y qué haría la compresión más barata?
¿Está el coste del cambio ascendiendo, estable o descendiendo con el tiempo, y lo están midiendo?
¿Tienen sus equipos una red de seguridad de pruebas fiable que hace segura la refactorización continua, o la reestructuración es demasiado arriesgada como para intentarla?
¿Quién mantiene sus sistemas de mayor antigüedad, cómo se captura su conocimiento, y cuál es el estatus y el ánimo de ese trabajo?

Ideas clave

El mantenimiento es la mayor parte del coste del ciclo de vida del software (habitualmente entre el 60 y el 90 por ciento para sistemas de larga duración) y debe planificarse, presupuestarse y dotarse de personal como una actividad de primer orden.
Las cuatro categorías (correctivo, adaptativo, perfectivo y preventivo) son trabajos distintos, y la mejora y la adaptación, no la reparación de defectos, suelen dominar.
La compresión del programa es la actividad individual más extensa del mantenimiento; haga que el código, su historia y su comportamiento sean legibles para que cada cambio sea barato.
Refactorice de forma continua bajo una red de seguridad de pruebas y reingeníere los componentes degradados de forma incremental para mantener el coste del cambio estable.
Estime el coste del mantenimiento de forma explícita e incorpórelo en el análisis del coste total de propiedad y en las decisiones económicas.
Diseñe para la mantenibilidad desde el inicio (es la inversión de mayor rentabilidad en todo el ciclo de vida) y trate a los mantenedores como los profesionales seniors que necesitan ser.

Referencias y lecturas complementarias

Sociedad de Informática del IEEE, Guía SWEBOK (Cuerpo de Conocimiento de Ingeniería de Software), área de conocimiento de Mantenimiento del Software
ISO/IEC 14764 / IEEE 14764, Ingeniería de Software: Procesos del Ciclo de Vida del Software, Mantenimiento
ISO/IEC 25010, Requisitos de Calidad de Sistemas y Software y Evaluación (SQuaRE): características de calidad de mantenibilidad
Martin Fowler, Refactoring: Improving the Design of Existing Code
Michael Feathers, Working Effectively with Legacy Code
Thomas M. Pigoski, Practical Software Maintenance
Penny Grubb y Armstrong A. Takang, Software Maintenance: Concepts and Practice
Barry Boehm et al., Software Cost Estimation with COCOMO II (modelos de mantenimiento y reutilización)
Meir M. Lehman, «Laws of Software Evolution» (sobre por qué el software debe cambiar continuamente o perder utilidad)
Robert C. Seacord, Daniel Plakosh y Grace A. Lewis, Modernising Legacy Systems