El mantenimiento del software es la modificación del software después de la entrega.
El mantenimiento de software a menudo se considera menos calificado y menos gratificante que el nuevo desarrollo. Como tal, es un objetivo común para la subcontratación o la deslocalización . Por lo general, el equipo que desarrolla el software es diferente de aquellos que lo mantendrán. Los desarrolladores carecen de incentivos para escribir el código para que sea fácil de mantener. El software suele entregarse incompleto y casi siempre contiene algunos errores que el equipo de mantenimiento debe corregir. El mantenimiento del software a menudo incluye inicialmente el desarrollo de nuevas funciones, pero a medida que el producto se acerca al final de su vida útil, el mantenimiento se reduce al mínimo y luego se interrumpe por completo antes de retirar el producto.
Cada ciclo de mantenimiento comienza con una solicitud de cambio que normalmente proviene de un usuario final. Esa solicitud se evalúa y si se decide implementarla, el programador estudia el código existente para entender cómo funciona antes de implementar el cambio. Las pruebas para garantizar que se conserva la funcionalidad existente y se agrega la nueva funcionalidad deseada a menudo comprenden la mayor parte del costo de mantenimiento.
El mantenimiento del software no está tan bien estudiado como otras fases del ciclo de vida del software, a pesar de representar la mayor parte de los costes. La comprensión no ha cambiado significativamente desde la década de 1980. El mantenimiento de software se puede clasificar en varios tipos dependiendo de si es preventivo o reactivo y si busca agregar funcionalidad o preservar la funcionalidad existente, esto último generalmente ante un entorno modificado.
A principios de la década de 1970, las empresas comenzaron a separar el mantenimiento de software con su propio equipo de ingenieros para liberar a los equipos de desarrollo de software de las tareas de soporte. [1] En 1972, RG Canning publicó "The Maintenance 'Iceberg ' ", en el que sostenía que el mantenimiento del software era una extensión del desarrollo de software con una aportación adicional: el sistema existente. [1] La disciplina del mantenimiento de software ha cambiado poco desde entonces. [2] Una innovación del siglo XXI ha sido que las empresas lanzan deliberadamente software incompleto y planean terminarlo después de su lanzamiento. Este tipo de cambio, y otros que amplían la funcionalidad, a menudo se denomina evolución del software en lugar de mantenimiento. [2]
A pesar de las pruebas y el control de calidad , prácticamente todo el software contiene errores en los que el sistema no funciona según lo previsto. El mantenimiento posterior al lanzamiento es necesario para corregir estos errores cuando se encuentran. [3] La mayor parte del software es una combinación de componentes de software comerciales preexistentes (COTS) y de código abierto con código escrito a medida. Los COTS y el software de código abierto generalmente se actualizan con el tiempo, lo que puede reducir la carga de mantenimiento, pero las modificaciones a estos componentes de software deberán ajustarse en el producto final. [4] A diferencia del desarrollo de software , que se centra en cumplir requisitos específicos, el mantenimiento del software está impulsado por eventos, como solicitudes de usuarios o la detección de un error. [5] Su objetivo principal es preservar la utilidad del software, generalmente frente a requisitos cambiantes. [6]
Si se concibe como parte del ciclo de vida del desarrollo de software , el mantenimiento es la última y normalmente la fase más larga del ciclo, [7] [8] y comprende entre el 80 y el 90 por ciento del costo del ciclo de vida. [9] Otros modelos consideran el mantenimiento separado del desarrollo de software, en lugar de ello, como parte del ciclo de vida de mantenimiento del software (SMLC). [8] Los modelos SMLC generalmente incluyen comprender el código, modificarlo y revalidarlo. [8]
Con frecuencia, el software se entrega en un estado incompleto. Los desarrolladores probarán un producto hasta que se les acabe el tiempo o la financiación, porque enfrentan menos consecuencias por un producto imperfecto que por excederse en el tiempo o el presupuesto. [10] La transición del equipo de desarrollo al de mantenimiento suele ser ineficiente, sin listas de problemas conocidos o pruebas de validación, que el equipo de mantenimiento probablemente recreará. [11] Después del lanzamiento, es probable que los miembros del equipo de desarrollo sean reasignados o dejen de estar disponibles. El equipo de mantenimiento necesitará recursos adicionales durante el primer año después del lanzamiento, tanto para soporte técnico como para corregir defectos que quedaron del desarrollo. [10]
Inicialmente, el software puede pasar por un período de mejoras después del lanzamiento. Se agregan nuevas funciones según los comentarios de los usuarios. En algún momento, la empresa puede decidir que ya no es rentable realizar mejoras funcionales y restringir el soporte a la corrección de errores y las actualizaciones de emergencia. Los cambios se vuelven cada vez más difíciles y costosos debido a la falta de experiencia o al deterioro de la arquitectura debido al envejecimiento del software . Una vez que un producto ya no recibe mantenimiento y no recibe ni siquiera este nivel limitado de actualización, algunos proveedores buscarán extraer ingresos del software durante el mayor tiempo posible, aunque es probable que el producto sea cada vez más evitado. Eventualmente, el software será retirado del mercado, aunque podrá seguir utilizándose. Durante este proceso, el software se convierte en un sistema heredado . [12]
El primer paso en el ciclo de cambio es recibir una solicitud de cambio de un cliente y analizarla para confirmar el problema y decidir si implementar el cambio. [13] Esto puede requerir aportaciones de varios departamentos; por ejemplo, el equipo de marketing puede ayudar a evaluar si se espera que el cambio genere más negocios. [14] La estimación del esfuerzo de desarrollo de software es un problema difícil, incluso para las solicitudes de cambio de mantenimiento, [15] pero es probable que la solicitud sea rechazada si es demasiado costosa o inviable. [16] Si se decide implementar la solicitud, se puede asignar a una publicación programada e implementarla. [16] Aunque la metodología ágil no tiene una fase de mantenimiento, [17] el ciclo de cambio puede representarse como un scrum sprint . [18]
Comprender el código existente es un paso esencial antes de modificarlo. [2] La tasa de comprensión depende tanto de la base del código como de la habilidad del programador. [19] Seguir convenciones de codificación, como el uso de nombres claros de funciones y variables que correspondan a su propósito, facilita la comprensión. [20] El uso de declaraciones de bucle condicional solo si el código se puede ejecutar más de una vez, y la eliminación del código que nunca se ejecutará también puede aumentar la comprensibilidad. [21] A los programadores experimentados les resulta más fácil comprender lo que hace el código en un alto nivel. [22] A veces se utiliza la visualización de software para acelerar este proceso. [23]
La modificación del código podrá realizarse de cualquier forma. Por un lado, es común aplicar una solución rápida al azar sin tener tiempo suficiente para actualizar la documentación del código . [24] Por otro lado, la mejora iterativa estructurada rígidamente puede comenzar cambiando el documento de requisitos de nivel superior y propagando el cambio hacia niveles inferiores del sistema. [25] La modificación a menudo incluye la refactorización del código (mejorar la estructura sin cambiar la funcionalidad) y la reestructuración (mejorar la estructura y la funcionalidad al mismo tiempo). [26] A diferencia del software comercial, los ciclos de cambio del software libre y de código abierto se limitan en gran medida a la codificación y las pruebas, con una documentación mínima. En cambio, los proyectos de software de código abierto se basan en listas de correo y una gran cantidad de contribuyentes para comprender la base del código y corregir errores de manera eficiente. [27]
Un problema adicional con el mantenimiento es que casi todos los cambios en el código introducirán nuevos errores o efectos dominó inesperados , que requieren otra ronda de correcciones. [2] Las pruebas pueden consumir la mayor parte de los recursos de mantenimiento del código crítico para la seguridad, debido a la necesidad de revalidar todo el software si se realiza algún cambio. [28] La revalidación puede incluir revisión de código , pruebas de regresión con un subconjunto de pruebas unitarias , pruebas de integración y pruebas del sistema . [26] El objetivo de la prueba es verificar que se conserva la funcionalidad anterior y que se ha agregado la nueva funcionalidad. [29]
El objetivo clave del mantenimiento del software es garantizar que el producto siga cumpliendo con los requisitos de usabilidad. En ocasiones, esto puede significar ampliar las capacidades del producto más allá de lo previsto inicialmente. [30]
Según la especificación ISO / IEC 14764, el mantenimiento de software se puede clasificar en cuatro tipos: [31]
Según algunas estimaciones, la mejora (las dos últimas categorías) comprende alrededor del 80 por ciento del mantenimiento del software. [35]
La mantenibilidad es la calidad del software que permite modificarlo fácilmente sin alterar la funcionalidad existente. [31] Según la especificación ISO/IEC 14764, la actividad para garantizar la mantenibilidad del software antes de su lanzamiento cuenta como parte del mantenimiento del software. [5] Muchas organizaciones de desarrollo de software descuidan la mantenibilidad, aunque hacerlo aumentará los costos a largo plazo. [36] La deuda técnica se incurre cuando los programadores, a menudo por pereza o urgencia por cumplir con una fecha límite, eligen soluciones rápidas y sucias en lugar de incorporar la mantenibilidad en su código. [37] Una causa común son las subestimaciones en la estimación del esfuerzo de desarrollo de software , lo que lleva a que se asignen recursos insuficientes al desarrollo. [38] Un aspecto importante es tener una gran cantidad de pruebas de software automatizadas que puedan detectar si la funcionalidad existente se ve comprometida por un cambio. [31]
Un desafío con la mantenibilidad es que muchos cursos de ingeniería de software no la enfatizan y entregan tareas únicas que tienen especificaciones claras y sin cambios. [39] Los cursos de ingeniería de software no cubren sistemas tan complejos como los que ocurren en el mundo real. [40] Los ingenieros de desarrollo que saben que no serán responsables del mantenimiento del software no tienen un incentivo para incorporar la mantenibilidad. [2]
El mantenimiento a menudo se considera un trabajo poco gratificante para los ingenieros de software , quienes, si se les asignaba mantenimiento, tenían más probabilidades de renunciar. [41] [42] A menudo paga menos que un trabajo comparable en el desarrollo de software. [42] La tarea a menudo se asigna a trabajadores temporales o personal menos calificado, [2] [43] aunque los ingenieros de mantenimiento también suelen ser mayores que los desarrolladores, en parte porque deben estar familiarizados con tecnologías obsoletas. [43] En 2008, alrededor de 900.000 de los 1,3 millones de ingenieros y programadores de software que trabajaban en los Estados Unidos estaban realizando tareas de mantenimiento. [44]
Las empresas crearon equipos separados para el mantenimiento, lo que llevó a subcontratar este trabajo a una empresa diferente y, a principios del siglo XXI, a veces a deslocalizar el trabajo a otro país, ya sea como parte de la empresa original o como una entidad separada. [45] [9] Las fuentes típicas de subcontratación son países desarrollados como Estados Unidos, Reino Unido, Japón y Australia, mientras que los destinos suelen ser países de menor costo como China, India, Rusia e Irlanda. [46] Las razones para la deslocalización incluyen aprovechar los menores costos laborales, permitir soporte las 24 horas, reducir la presión de tiempo sobre los desarrolladores y acercar el soporte al mercado para el producto. [47] Las desventajas de la deslocalización incluyen barreras de comunicación en forma de factores como la zona horaria y la disyunción organizacional y las diferencias culturales. [9] A pesar de que muchos empleadores consideran que el mantenimiento es un trabajo menos calificado y la fase de desarrollo de software más adecuada para la deslocalización, [9] [48] requiere una comunicación estrecha con el cliente y una respuesta rápida, las cuales se ven obstaculizadas por estas dificultades de comunicación. [9]
En ingeniería de software, el término sistema heredado no tiene un significado fijo, sino que a menudo se refiere a sistemas más antiguos que son grandes, difíciles de modificar y también necesarios para las necesidades comerciales actuales. A menudo, los sistemas heredados están escritos en lenguajes de programación obsoletos , carecen de documentación, tienen una estructura que se deteriora después de años de cambios y dependen de expertos para mantenerlos operativos. [49] Cuando se trata de estos sistemas, en algún momento se acumula tanta deuda técnica que el mantenimiento no es práctico ni económico. [12] Otras opciones incluyen:
A pesar de ocupar la mayor parte de los recursos de desarrollo de software, el mantenimiento es la fase menos estudiada del desarrollo de software. [56] [57] Gran parte de la literatura se ha centrado en cómo desarrollar código mantenible desde el principio, con menos atención en motivar a los ingenieros para que hagan de la mantenibilidad una prioridad. [58] A partir de 2020 [update], las soluciones automatizadas para la refactorización de código para reducir el esfuerzo de mantenimiento son un área activa de investigación, [59] al igual que la evaluación de la mantenibilidad mejorada con aprendizaje automático . [60]