El mantenimiento del software es la modificación del software después de su entrega. [1]
Según el glosario estándar IEEE de terminología de ingeniería de software, el mantenimiento de software se refiere al proceso de modificación y actualización del software después de su desarrollo e implementación inicial, para corregir fallas, mejorar el rendimiento u otros atributos, agregar nuevas características para cumplir con los requisitos cambiantes de los usuarios o adaptarse a un entorno modificado. Es importante enfatizar que el mantenimiento de software implica muchas actividades que van más allá de la mera corrección de errores. El mantenimiento de software es un proceso continuo que es esencial para la longevidad de un sistema de software, para mantenerlo efectivo, adaptable y relevante en un panorama tecnológico en constante evolución.
El mantenimiento de software suele considerarse menos especializado y menos gratificante que el desarrollo de nuevos productos. Por ello, es un objetivo habitual de la subcontratación o deslocalización . Normalmente, el equipo que desarrolla el software es diferente del que lo va a mantener. Los desarrolladores carecen de incentivos para escribir el código de forma que sea fácil de mantener. El software suele entregarse incompleto y casi siempre contiene algunos errores que el equipo de mantenimiento debe solucionar. El mantenimiento de software suele incluir 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 elimina por completo antes de retirar el producto.
Cada ciclo de mantenimiento comienza con una solicitud de cambio que, por lo general, proviene de un usuario final. Se evalúa esa solicitud y, si se decide implementarla, el programador estudia el código existente para comprender cómo funciona antes de implementar el cambio. Las pruebas para asegurarse de que se conserve la funcionalidad existente y se agregue la nueva funcionalidad deseada suelen representar la mayor parte del costo de mantenimiento.
El mantenimiento de software no ha sido tan estudiado como otras fases del ciclo de vida del software, a pesar de que comprende la mayoría de los costos. La comprensión no ha cambiado significativamente desde la década de 1980. El mantenimiento de software se puede clasificar en varios tipos según si es preventivo o reactivo y si busca agregar funcionalidad o preservar la funcionalidad existente, esta última generalmente ante un entorno modificado.
A principios de los años 70, las empresas comenzaron a separar el mantenimiento del software con su propio equipo de ingenieros para liberar a los equipos de desarrollo de software de las tareas de soporte. [2] En 1972, RG Canning publicó "El 'Iceberg ' del mantenimiento ", en el que sostenía que el mantenimiento del software era una extensión del desarrollo de software con un insumo adicional: el sistema existente. [2] La disciplina del mantenimiento del software ha cambiado poco desde entonces. [3] Una innovación del siglo XXI ha sido que las empresas lanzan deliberadamente software incompleto y planean terminarlo después del lanzamiento. Este tipo de cambio, y otros que amplían la funcionalidad, a menudo se denomina evolución del software en lugar de mantenimiento. [3]
A pesar de las pruebas y el control de calidad , prácticamente todo el software contiene errores que hacen que el sistema no funcione como se esperaba. Es necesario un mantenimiento posterior al lanzamiento para remediar estos errores cuando se encuentran. [ 4] La mayoría del software es una combinación de componentes de software de código abierto y de software comercial listo para usar (COTS) preexistentes con código escrito a medida. El software COTS y de código abierto generalmente se actualiza 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. [5] A diferencia del desarrollo de software , que se centra en cumplir con los requisitos específicos, el mantenimiento del software está impulsado por eventos, como solicitudes de usuarios o detección de un error. [6] Su propósito principal es preservar la utilidad del software, generalmente frente a requisitos cambiantes. [7]
Si se lo concibe como parte del ciclo de vida del desarrollo de software , el mantenimiento es la última y, por lo general, la fase más larga del ciclo, [8] [9] que comprende entre el 80 y el 90 por ciento del costo del ciclo de vida. [10] Otros modelos consideran el mantenimiento separado del desarrollo de software, en cambio como parte del ciclo de vida de mantenimiento de software (SMLC). [9] Los modelos SMLC generalmente incluyen la comprensión del código, su modificación y su revalidación. [9]
Con frecuencia, el software se entrega en un estado incompleto. Los desarrolladores probarán un producto hasta que se queden sin tiempo o sin fondos, porque enfrentan menos consecuencias por un producto imperfecto que por excederse en el tiempo o el presupuesto. [11] 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á. [12] 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. [11]
Inicialmente, el software puede pasar por un período de mejoras después del lanzamiento. Se agregan nuevas características de acuerdo con 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 actualizaciones de emergencia. Los cambios se vuelven cada vez más difíciles y costosos debido a la falta de experiencia o la arquitectura en decadencia debido al envejecimiento del software . Después de que un producto ya no se mantiene y no recibe ni siquiera este nivel limitado de actualización, algunos proveedores buscarán extraer ingresos del software el mayor tiempo posible, aunque es probable que el producto se evite cada vez más. Finalmente, el software se retirará del mercado, aunque puede permanecer en uso. Durante este proceso, el software se convierte en un sistema heredado . [13]
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 se debe implementar el cambio. [14] Esto puede requerir la participación de varios departamentos; por ejemplo, el equipo de marketing puede ayudar a evaluar si se espera que el cambio genere más negocios. [15] La estimación del esfuerzo de desarrollo de software es un problema difícil, incluso para las solicitudes de cambio de mantenimiento, [16] pero es probable que la solicitud se rechace si es demasiado costosa o inviable. [17] Si se decide implementar la solicitud, se puede asignar a una versión programada e implementar. [17] Aunque la metodología ágil no tiene una fase de mantenimiento, [18] el ciclo de cambio se puede implementar como un sprint de scrum . [19]
Comprender el código existente es un paso esencial antes de modificarlo. [3] La velocidad de comprensión depende tanto de la base del código como de la habilidad del programador. [20] Seguir las convenciones de codificación, como usar nombres claros de funciones y variables que correspondan a su propósito, facilita la comprensión. [21] 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. [22] Los programadores experimentados tienen más facilidad para comprender lo que hace el código a un alto nivel. [23] La visualización de software se utiliza a veces para acelerar este proceso. [24]
La modificación del código puede tener lugar de cualquier forma. Por un lado, es común aplicar al azar una solución rápida sin tener tiempo suficiente para actualizar la documentación del código . [25] Por otro lado, la mejora iterativa estructurada dura puede comenzar modificando el documento de requisitos de nivel superior y propagando el cambio a niveles inferiores del sistema. [26] La modificación a menudo incluye la refactorización del código (mejora de la estructura sin cambiar la funcionalidad) y la reestructuración (mejora de la estructura y la funcionalidad al mismo tiempo). [27] 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. Los proyectos de software de código abierto, en cambio, 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. [28]
Un problema adicional con el mantenimiento es que casi cada cambio en el código introducirá nuevos errores o efectos dominó inesperados , que requieren otra ronda de correcciones. [3] Las pruebas pueden consumir la mayoría de los recursos de mantenimiento para el código crítico para la seguridad, debido a la necesidad de revalidar todo el software si se realizan cambios. [29] 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 . [27] El objetivo de las pruebas es verificar que se conserva la funcionalidad anterior y se ha agregado la nueva funcionalidad. [30]
El objetivo principal del mantenimiento de 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. [31]
Según la especificación ISO / IEC 14764, el mantenimiento de software se puede clasificar en cuatro tipos: [32]
Según algunas estimaciones, la mejora (las dos últimas categorías) comprende alrededor del 80 por ciento del mantenimiento del software. [36]
La mantenibilidad es la cualidad del software que permite modificarlo fácilmente sin romper la funcionalidad existente. [32] Según la especificación ISO/IEC 14764, la actividad para asegurar la mantenibilidad del software antes del lanzamiento cuenta como parte del mantenimiento del software. [6] Muchas organizaciones de desarrollo de software descuidan la mantenibilidad, aunque hacerlo aumentará los costos a largo plazo. [37] 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. [38] Una causa común son las subestimaciones en la estimación del esfuerzo de desarrollo de software , lo que lleva a recursos insuficientes asignados al desarrollo. [39] 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. [32]
Un desafío con la mantenibilidad es que muchos cursos de ingeniería de software no la enfatizan y asignan tareas únicas que tienen especificaciones claras e inmutables. [40] Los cursos de ingeniería de software no cubren sistemas tan complejos como los que existen en el mundo real. [41] Los ingenieros de desarrollo que saben que no serán responsables del mantenimiento del software no tienen un incentivo para incorporar la mantenibilidad. [3]
El mantenimiento se considera a menudo un trabajo poco gratificante para los ingenieros de software , quienes, si se les asigna el mantenimiento, tenían más probabilidades de renunciar. [42] [43] A menudo paga menos que un trabajo comparable en el desarrollo de software. [43] La tarea a menudo se asigna a trabajadores temporales o personal menos calificado, [3] [44] aunque los ingenieros de mantenimiento también suelen ser mayores que los desarrolladores, en parte porque deben estar familiarizados con tecnologías obsoletas. [44] En 2008, alrededor de 900.000 de los 1,3 millones de ingenieros de software y programadores que trabajaban en los Estados Unidos estaban haciendo mantenimiento. [45]
Las empresas crearon equipos separados para el mantenimiento, lo que llevó a externalizar 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 una entidad separada. [46] [10] Las fuentes típicas de externalizació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. [47] Las razones para la deslocalización incluyen aprovechar los menores costos laborales, permitir soporte las 24 horas, reducir la presión del tiempo en los desarrolladores y acercar el soporte al mercado del producto. [48] Las desventajas de la deslocalización incluyen barreras de comunicación en forma de factores como la zona horaria , la disyunción organizacional y las diferencias culturales. [10] A pesar de que muchos empleadores consideran que el mantenimiento es un trabajo que requiere menos cualificación y la fase del desarrollo de software más adecuada para la deslocalización, [10] [49] requiere una comunicación estrecha con el cliente y una respuesta rápida, ambas obstaculizadas por estas dificultades de comunicación. [10]
En ingeniería de software, el término sistema heredado no tiene un significado fijo, pero a menudo se refiere a sistemas 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 deteriorada después de años de cambios y dependen de expertos para mantenerlos operativos. [50] 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. [13] 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. [57] [58] Gran parte de la literatura se ha centrado en cómo desarrollar código mantenible desde el principio, con menos enfoque en motivar a los ingenieros para que hagan de la mantenibilidad una prioridad. [59] 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, [60] al igual que la evaluación de mantenibilidad mejorada con aprendizaje automático . [61]