34. Mantenimiento, evolución y soporte del software

34.1 Introducción

La vida de un sistema de software no termina cuando se entrega la primera versión. En la práctica, muchos productos pasan la mayor parte de su existencia siendo corregidos, adaptados, mejorados, monitoreados y soportados.

El mantenimiento, la evolución y el soporte son actividades fundamentales para que el software siga siendo útil, confiable y alineado con las necesidades de usuarios y organizaciones a lo largo del tiempo.

34.2 ¿Qué es el mantenimiento de software?

El mantenimiento de software es el conjunto de actividades realizadas después de la entrega inicial para corregir defectos, mejorar características, adaptar el sistema a nuevos contextos o prevenir problemas futuros.

Mantener software no significa simplemente "arreglar errores". También implica comprender cambios en el negocio, en la tecnología, en la legislación, en los usuarios y en el entorno donde el sistema funciona.

Idea central: un sistema de software se mantiene vivo mientras continúa cambiando para responder a nuevas necesidades y condiciones.

34.3 ¿Qué es la evolución del software?

La evolución del software es el proceso mediante el cual un producto cambia a lo largo del tiempo. Puede incorporar nuevas funcionalidades, modificar reglas existentes, mejorar su arquitectura, actualizar tecnologías o adaptarse a nuevos dispositivos, usuarios o integraciones.

La evolución es una consecuencia natural del uso real del sistema. Cuando el software resuelve un problema importante, normalmente aparecen nuevas necesidades, expectativas y oportunidades de mejora.

34.4 ¿Qué es el soporte de software?

El soporte de software ayuda a usuarios, clientes y equipos internos a resolver dudas, incidentes, problemas de operación o solicitudes relacionadas con el sistema.

Puede incluir atención de consultas, análisis de errores, recuperación ante fallas, comunicación de cambios, seguimiento de incidentes, coordinación con desarrollo y documentación de soluciones.

34.5 Diferencias entre mantenimiento, evolución y soporte

Concepto Propósito Ejemplo
Mantenimiento Modificar el software para corregir, adaptar o mejorar. Corregir un defecto en el cálculo de descuentos.
Evolución Transformar el producto para responder a nuevas necesidades. Agregar una aplicación móvil a un sistema existente.
Soporte Ayudar a operar el sistema y resolver incidentes o consultas. Atender un reporte de usuario que no puede acceder a su cuenta.

34.6 Tipos de mantenimiento

El mantenimiento puede clasificarse según la razón que motiva el cambio. Esta clasificación ayuda a entender que no todos los cambios tienen el mismo objetivo ni el mismo impacto.

Tipo Descripción Ejemplo
Correctivo Corrige defectos encontrados en el sistema. Arreglar un error que impide guardar una operación.
Adaptativo Ajusta el software a cambios del entorno. Modificar una integración porque cambió la API de un proveedor.
Perfectivo Mejora funcionalidad, rendimiento, usabilidad o calidad. Optimizar una búsqueda que demora demasiado.
Preventivo Reduce la probabilidad de problemas futuros. Refactorizar un módulo complejo antes de agregar nuevas funciones.

34.7 Mantenimiento correctivo

El mantenimiento correctivo se realiza cuando se detecta un defecto que debe solucionarse. Puede originarse en reportes de usuarios, pruebas, monitoreo, auditorías o revisión interna.

Corregir un defecto no debería limitarse a cambiar una línea de código. También conviene analizar la causa, agregar pruebas si corresponde y verificar que la corrección no produzca efectos secundarios.

34.8 Mantenimiento adaptativo

El mantenimiento adaptativo responde a cambios externos al sistema. Por ejemplo, nuevas leyes, cambios en navegadores, actualizaciones de sistemas operativos, modificaciones en servicios de terceros o nuevas políticas de seguridad.

Aunque el software no tenga errores, puede dejar de ser adecuado si el entorno cambia.

34.9 Mantenimiento perfectivo

El mantenimiento perfectivo busca mejorar el sistema. Puede aumentar la eficiencia, simplificar una tarea, mejorar la interfaz, agregar funciones solicitadas o resolver necesidades que aparecieron con el uso real.

Muchas mejoras surgen porque los usuarios aprenden a trabajar con el producto y descubren nuevas formas de obtener valor.

34.10 Mantenimiento preventivo

El mantenimiento preventivo intenta reducir problemas futuros. Incluye limpieza de código, refactorización, actualización de dependencias, mejora de pruebas, eliminación de duplicación, revisión de configuraciones y simplificación de componentes complejos.

Este tipo de mantenimiento suele ser difícil de justificar si solo se mira el corto plazo, pero es importante para sostener la velocidad y la calidad del desarrollo.

34.11 Incidentes, problemas y solicitudes

En soporte conviene diferenciar distintos tipos de situaciones para responder adecuadamente.

Tipo Descripción Ejemplo
Incidente Interrupción o degradación de un servicio esperado. Los usuarios no pueden iniciar sesión.
Problema Causa raíz de uno o varios incidentes. Una configuración incorrecta provoca cierres de sesión inesperados.
Solicitud Pedido de información, asistencia o cambio. Un usuario solicita recuperar acceso o cambiar un dato.

34.12 Priorización de cambios

No todos los cambios pueden realizarse al mismo tiempo. La priorización ayuda a decidir qué se atiende primero según impacto, urgencia, valor de negocio, riesgo, costo y dependencias.

Un error que impide facturar o acceder a información crítica suele tener mayor prioridad que una mejora visual menor, aunque ambas solicitudes sean válidas.

34.13 Impacto del cambio

Antes de modificar un sistema existente, es importante analizar el impacto. Un cambio aparentemente pequeño puede afectar reglas de negocio, integraciones, reportes, permisos, datos históricos o procesos de otros usuarios.

  • Qué módulos o componentes se verán afectados.
  • Qué usuarios o procesos dependen de esa funcionalidad.
  • Qué pruebas deben repetirse.
  • Qué documentación debe actualizarse.
  • Qué riesgos aparecen si el cambio falla.
  • Cómo se puede revertir o corregir rápidamente.

34.14 Regresión

Una regresión ocurre cuando un cambio rompe algo que antes funcionaba. Es uno de los riesgos más comunes durante el mantenimiento, especialmente en sistemas grandes o poco documentados.

Las pruebas automatizadas, la revisión de código, la integración continua y el conocimiento del dominio ayudan a reducir este riesgo.

34.15 Soporte y comunicación con usuarios

El soporte no solo resuelve problemas técnicos. También comunica el estado de incidentes, explica cambios, recopila información útil, traduce necesidades del usuario y ayuda a mejorar el producto.

Una comunicación clara reduce frustración. Cuando ocurre un problema, los usuarios necesitan saber qué sucede, qué impacto tiene, si existe una alternativa y cuándo se espera una solución.

34.16 Métricas de mantenimiento y soporte

  • Cantidad de incidentes por período.
  • Tiempo promedio de respuesta.
  • Tiempo promedio de resolución.
  • Cantidad de defectos recurrentes.
  • Porcentaje de cambios urgentes.
  • Defectos introducidos por nuevas versiones.
  • Solicitudes pendientes por prioridad.

34.17 Ejemplo práctico

Supongamos un sistema de turnos médicos ya en producción. Después de algunas semanas, los usuarios reportan que algunos recordatorios llegan duplicados. El equipo registra el incidente, analiza los datos, identifica que una tarea programada se ejecuta dos veces y corrige la configuración.

Además de corregir el error, el equipo agrega una prueba, actualiza la documentación operativa y mejora el monitoreo para detectar rápidamente si vuelve a ocurrir.

34.18 Errores comunes

  • Creer que el trabajo termina con la primera entrega.
  • Corregir defectos sin investigar la causa real.
  • No priorizar solicitudes y atender todo como urgente.
  • Modificar código sin pruebas de regresión.
  • No actualizar documentación después de los cambios.
  • Ignorar señales de deterioro en la arquitectura o el código.
  • No comunicar adecuadamente el estado de incidentes importantes.

34.19 Buenas prácticas

  • Registrar incidentes, solicitudes y cambios de manera ordenada.
  • Priorizar según impacto, urgencia, riesgo y valor.
  • Analizar la causa raíz de defectos importantes.
  • Agregar o actualizar pruebas al corregir errores.
  • Evaluar impacto antes de modificar funcionalidades existentes.
  • Comunicar cambios e incidentes con claridad.
  • Reservar tiempo para mantenimiento preventivo y mejora interna.

34.20 Qué debes recordar

  • El software continúa cambiando después de su primera entrega.
  • El mantenimiento puede ser correctivo, adaptativo, perfectivo o preventivo.
  • El soporte conecta problemas reales de usuarios con acciones técnicas y organizativas.
  • Cada cambio debe analizarse por su impacto y riesgo de regresión.
  • Un producto sostenible necesita mantenimiento planificado, no solo atención de urgencias.

34.21 Conclusión

El mantenimiento, la evolución y el soporte son parte natural de la vida del software. Un sistema valioso cambia porque los usuarios lo utilizan, el negocio evoluciona y el entorno técnico se transforma.

En el próximo tema veremos deuda técnica, refactorización y sostenibilidad, conceptos directamente relacionados con la capacidad de mantener y evolucionar un producto sin perder calidad.

Volver al índice