Una aplicación puede funcionar hoy y necesitar cambios mañana. Aparece un fallo que solo afecta a ciertos registros, un proveedor modifica su conexión o el equipo empieza a utilizar una función de otra manera. El mantenimiento de software organiza cómo se atienden esas situaciones después de la entrega.
El mantenimiento de software reúne las actuaciones necesarias para corregir, adaptar y mejorar una aplicación durante su vida útil. No se limita a resolver averías. También incluye preparar cambios para que el sistema siga siendo utilizable y mantenible.
Para una empresa, la pregunta es qué aplicación necesita soporte, quién asume cada responsabilidad y cómo se valida una modificación. Un plan claro evita descubrir esas condiciones cuando el sistema ya está dando problemas.
Los cuatro tipos de mantenimiento de software
La clasificación habitual distingue mantenimiento correctivo, adaptativo, perfectivo y preventivo. El capítulo de mantenimiento de la guía SWEBOK recoge estas categorías dentro de la ingeniería del software.
Correctivo: resolver un fallo existente
Se ocupa de errores detectados en el funcionamiento. Por ejemplo, una aplicación calcula mal un total cuando se combina una determinada condición. El trabajo debe incluir entender el fallo, corregirlo y comprobar que no reaparece en los escenarios conocidos.
Adaptativo: seguir funcionando cuando cambia el entorno
La aplicación puede necesitar ajustes porque cambia una dependencia, un sistema operativo o un servicio externo. Que el código propio no se haya modificado no significa que su entorno permanezca igual.
Perfectivo: mejorar el uso o el funcionamiento
Incluye mejoras sobre un sistema existente, como facilitar una búsqueda, ajustar una función o mejorar su rendimiento. Conviene distinguir las mejoras incluidas en el mantenimiento de los desarrollos que requieren un alcance adicional.
Preventivo: reducir problemas futuros
Busca corregir debilidades antes de que provoquen fallos en operación. Puede incluir reorganizar una parte difícil de modificar o reforzar comprobaciones. La prioridad debería relacionarse con un riesgo o una necesidad concreta, no con cambiar código sin un objetivo definido.
Mantenimiento, soporte e infraestructura: qué cubre cada uno
Una incidencia puede estar en la aplicación, en los datos, en una integración o en el entorno donde se ejecuta. Por eso conviene separar responsabilidades aunque un mismo equipo preste varias de ellas.
El soporte atiende consultas e incidencias de los usuarios. El mantenimiento modifica y evoluciona el software. La operación de infraestructura se ocupa del entorno que lo sostiene. La frontera exacta depende de lo contratado y debería quedar escrita.
Por ejemplo, si una aplicación deja de enviar correos, habrá que averiguar si falla el código, la configuración o el servicio de envío. No conviene que cada proveedor dé por hecho que la comprobación inicial corresponde a otro.
La coordinación entre desarrollo de aplicaciones a medida y arquitectura e infraestructura ayuda a definir ese recorrido. No implica que todas las tareas estén incluidas automáticamente en cualquier proyecto.
Qué debería incluir un plan de mantenimiento
Proponemos empezar con un inventario del sistema: aplicaciones cubiertas, repositorios, entornos, dependencias, conexiones externas y responsables. Después, concreta cómo se solicita, prioriza, ejecuta y acepta el trabajo.
Alcance y exclusiones
Describe qué versiones y componentes se mantienen, qué tareas están incluidas y cuáles necesitan presupuesto separado. Aclara también si existe un periodo de garantía y cómo se diferencia del mantenimiento posterior. No des por hecho que cualquier cambio solicitado es una corrección.
Accesos y documentación
Define quién administra los accesos, dónde se conserva la documentación y cómo se actualiza. El equipo encargado debe poder comprender cómo se despliega la aplicación y qué procesos de negocio dependen de ella.
Tratamiento de incidencias
Acuerda un canal de entrada y los datos necesarios: qué ocurre, desde cuándo, a quién afecta y qué evidencia permite reproducirlo. Evita enviar credenciales o información sensible en una solicitud sin un canal adecuado.
Validación y entrega
Cada modificación necesita una forma de comprobarse. Deja claro quién valida, en qué entorno se prueba y cómo se informa del resultado. Guarda un registro de cambios que permita relacionar una versión con los problemas o mejoras atendidos.
Cómo acordar prioridades y tiempos sin confusiones
«Urgente» no significa lo mismo para todo el mundo. Es más útil clasificar una incidencia según el impacto, el número de personas afectadas y la existencia de una alternativa temporal.
Como criterio de trabajo, puedes distinguir una interrupción que impide una operación principal de un fallo con alternativa y de una mejora que se puede planificar. La clasificación final debe acordarse según la actividad y las aplicaciones de la empresa.
Tiempo de respuesta no es tiempo de resolución
Una respuesta confirma que la solicitud se ha recibido y se está evaluando. Resolver exige encontrar la causa, preparar el cambio y comprobarlo. Si la solución depende de otro proveedor, el plan debería explicar cómo se gestiona esa dependencia.
Revisa horarios de atención, canal para incidencias críticas y condiciones fuera del horario habitual. No presupongas cobertura continua ni plazos garantizados si no aparecen expresamente acordados.
Cómo actualizar sin convertir cada cambio en una apuesta
Antes de una actualización, revisa qué componentes afecta y cómo se comprobará el recorrido de negocio. Proponemos usar un entorno de pruebas cuando el sistema y el alcance lo permitan, conservar una versión identificable y preparar qué hacer si el cambio no funciona.
Una copia de seguridad no sustituye ese plan. Hay que saber qué se puede restaurar, quién lo hará y qué datos podrían quedar afectados entre la actualización y la vuelta atrás. Esas condiciones cambian según la aplicación y su infraestructura.
Después de desplegar, comprueba las funciones afectadas y observa errores o comportamientos inesperados. Si el cambio modifica la forma de trabajar, informa también a las personas que utilizan la aplicación.
Qué hacer si el software lo desarrolló otro proveedor
Primero hace falta evaluar el sistema y confirmar qué materiales y permisos existen. Una revisión inicial puede comprobar el acceso al código, la posibilidad de reproducir el entorno, las dependencias y la documentación disponible.
No conviene comprometer una modificación sin entender cómo se prueba y se entrega. Si falta información, el primer encargo puede consistir en recuperarla y preparar un diagnóstico. Eso permite presupuestar el mantenimiento con una base más clara.
Pide que el traspaso deje un inventario y una lista de limitaciones conocidas. Tener acceso a un repositorio no garantiza, por sí solo, que otra persona pueda desplegar la aplicación o mantener todas sus conexiones.
Cómo valorar el coste del mantenimiento
La inversión depende de la criticidad del sistema, su estado técnico, la documentación y la cobertura que se necesite. También influyen las integraciones, la frecuencia de cambios y las condiciones de atención.
Al comparar propuestas, comprueba qué trabajo incluye la cuota o la bolsa de horas, cómo se autorizan extras y qué ocurre con lo no utilizado. Pide entregables visibles: incidencias resueltas, cambios realizados, pruebas y riesgos pendientes.
No existe un porcentaje del desarrollo que determine por sí solo el coste adecuado. Una aplicación pequeña con una conexión frágil puede necesitar más atención que otra mayor y estable. Cada sistema requiere una valoración independiente.
Preguntas frecuentes sobre mantenimiento de software
¿Hace falta mantenimiento si la aplicación funciona bien?
Conviene definir al menos quién revisa cambios de entorno, atiende incidencias y mantiene la documentación. La intensidad del trabajo dependerá del sistema y de sus necesidades reales.
¿Todas las funciones nuevas entran en mantenimiento?
Depende del alcance acordado. Una mejora pequeña puede estar incluida, mientras que una nueva área funcional puede requerir un proyecto separado. Esa diferencia debería aclararse antes de empezar.
¿El mantenimiento garantiza que nunca habrá fallos?
No. Organiza la prevención, la atención y la evolución del software. Los objetivos y las condiciones deben ser comprobables, sin prometer ausencia total de incidencias.
Revisa qué ocurrirá después de la entrega
Antes de contratar o renovar el mantenimiento, reúne las aplicaciones, sus responsables y las incidencias que más afectan al trabajo. Podemos revisar el punto de partida de tu software y ayudarte a definir qué necesita atención, con qué alcance y cómo comprobar cada entrega.
