El mantenimiento de software en ingeniería de software es la modificación de un producto de software después de su entrega para corregir fallas, mejorar el rendimiento u otros atributos. [1] [2]
Una percepción común del mantenimiento es que implica simplemente reparar defectos . Sin embargo, un estudio indicó que más del 80% del esfuerzo de mantenimiento se utiliza para acciones no correctivas. [3] Esta percepción se perpetúa cuando los usuarios envían informes de problemas que en realidad son mejoras de funcionalidad del sistema. [ cita necesaria ] Estudios más recientes sitúan la proporción de corrección de errores más cerca del 21%. [4]
Meir M. Lehman abordó por primera vez el mantenimiento del software y la evolución de los sistemas en 1969. Durante un período de veinte años, su investigación condujo a la formulación de las Leyes de Lehman (Lehman 1997). Los hallazgos clave de su investigación concluyen que el mantenimiento es realmente un desarrollo evolutivo y que las decisiones de mantenimiento se ven favorecidas por la comprensión de lo que sucede con los sistemas (y el software) a lo largo del tiempo. Lehman demostró que los sistemas siguen evolucionando con el tiempo. A medida que evolucionan, se vuelven más complejos a menos que se tomen algunas medidas, como la refactorización del código, para reducir la complejidad. A finales de la década de 1970, un famoso y ampliamente citado estudio realizado por Lientz y Swanson expuso la muy alta fracción de los costos del ciclo de vida que se gastaban en mantenimiento.
La encuesta mostró que alrededor del 75% del esfuerzo de mantenimiento se realizó en los dos primeros tipos, y la corrección de errores consumió alrededor del 21%. Muchos estudios posteriores sugieren una magnitud del problema similar. Los estudios muestran que la contribución de los usuarios finales es crucial durante la recopilación y el análisis de datos de nuevos requisitos. Esta es la principal causa de cualquier problema durante la evolución y el mantenimiento del software. El mantenimiento del software es importante porque consume una gran parte de los costos generales del ciclo de vida y además la incapacidad de cambiar el software de manera rápida y confiable significa que se pierden oportunidades comerciales.[5] [6] [7]
Los aspectos clave del mantenimiento del software son administrativos y técnicos. Los problemas de gestión incluyen la alineación con las prioridades del cliente, la dotación de personal, la asignación de responsabilidades y la estimación de costos. Los problemas técnicos incluyen: comprensión limitada, análisis de impacto , pruebas y medición de la mantenibilidad.
El mantenimiento de software es una actividad amplia que incluye corrección de errores, mejoras de capacidades, eliminación de capacidades obsoletas y optimización. Debido a que el cambio es inevitable, se deben desarrollar mecanismos para evaluar, controlar y realizar modificaciones.
Cualquier trabajo realizado en el software después de su implementación se considera mantenimiento. El mantenimiento preserva el valor del software a lo largo del tiempo. El valor se puede mejorar ampliando la base de clientes, satisfaciendo requisitos nuevos y adicionales, volviéndose más fáciles de usar, más eficientes y empleando tecnología más nueva. El mantenimiento puede durar décadas, mientras que el desarrollo inicial suele durar menos de tres años.
Una parte integral del software es el mantenimiento, que requiere la elaboración de un plan de mantenimiento preciso durante el desarrollo del software. Debe especificar cómo los usuarios solicitarán modificaciones o informarán problemas. El presupuesto debe incluir estimaciones de recursos y costos, y se debe abordar una nueva decisión para el desarrollo de cada nueva característica del sistema y sus objetivos de calidad. El mantenimiento del software, que puede durar más de 5 años (o incluso décadas) después del proceso de desarrollo, requiere un plan eficaz que pueda abordar el alcance del mantenimiento del software, la adaptación del proceso posterior a la entrega/implementación, la designación de quién proporcionar mantenimiento y una estimación de los costos del ciclo de vida.
Esta sección describe los seis procesos de mantenimiento de software como:
Hay una serie de procesos, actividades y prácticas que son exclusivas de los mantenedores, por ejemplo:
EB Swanson identificó inicialmente tres categorías de mantenimiento: correctivo, adaptativo y perfectivo. [8] El estándar IEEE 1219 fue reemplazado en junio de 2010 por P14764 . [9] Desde entonces, estos se han actualizado e ISO/IEC 14764 presenta:
También existe la noción de mantenimiento previo a la entrega/prelanzamiento, que son todas las cosas buenas que se hacen para reducir el costo total de propiedad del software. Cosas como el cumplimiento de estándares de codificación que incluyen objetivos de mantenibilidad del software. La gestión del acoplamiento y cohesión del software. El logro de los objetivos de compatibilidad del software (SAE JA1004, JA1005 y JA1006, por ejemplo). Algunas instituciones académicas [ ¿quién? ] están llevando a cabo investigaciones para cuantificar el costo del mantenimiento continuo del software debido a la falta de recursos, como documentos de diseño y capacitación y recursos para la comprensión del sistema/software (multiplique los costos por aproximadamente 1,5-2,0 cuando no haya datos de diseño disponibles).
Impacto de los factores clave de ajuste en el mantenimiento (ordenados en orden de máximo impacto positivo)
Los módulos propensos a errores no sólo son problemáticos, sino que también pueden degradar el rendimiento. Por ejemplo, un código espagueti muy complejo es bastante difícil de mantener de forma segura. Una situación muy común que a menudo degrada el rendimiento es la falta de herramientas de mantenimiento adecuadas, como software de seguimiento de defectos, software de gestión de cambios y software de biblioteca de pruebas. A continuación se describen algunos de los factores y el alcance del impacto en el mantenimiento del software.
Impacto de los factores clave de ajuste en el mantenimiento (ordenados en orden de máximo impacto negativo)
[10]
En un artículo para la 27.ª Conferencia Internacional sobre Gestión de la Calidad del Software en 2019, [11] John Estdale introdujo el término "deuda de mantenimiento" para las necesidades de mantenimiento generadas por la dependencia de una implementación de factores externos de TI, como bibliotecas, plataformas y herramientas, que se han convertido en caído en desuso. [12] La aplicación continúa ejecutándose y el departamento de TI olvida esta responsabilidad teórica y se concentra en requisitos y problemas más urgentes en otros lugares. Esta deuda se acumula con el tiempo, devorando silenciosamente el valor del activo de software. Al final sucede algo que hace que el cambio de sistema sea inevitable.
El propietario puede entonces descubrir que el sistema ya no se puede modificar: es literalmente imposible de mantener. De manera menos dramática, el mantenimiento puede llevar demasiado tiempo o costar demasiado para resolver el problema comercial, y se debe encontrar una solución alternativa. El software se bloqueó repentinamente y alcanzó un valor de £0.
Estdale define "Deuda de mantenimiento" [12] como: la brecha entre el estado de implementación actual de una aplicación y el ideal, utilizando únicamente la funcionalidad de componentes externos que se mantiene y admite en su totalidad. Esta deuda muchas veces se oculta o no se reconoce. La mantenibilidad general de una aplicación depende de la continua disponibilidad de componentes de todo tipo de otros proveedores, incluidos:
y por supuesto
La desaparición completa de un componente podría hacer que la aplicación no se pueda reconstruir o que sea inminentemente imposible de mantener.
[13]