Mantenimiento de software

El mantenimiento del software consiste en la modificación del software después de su entrega.

El mantenimiento de software suele considerarse una tarea menos cualificada y menos gratificante que el desarrollo de nuevas funcionalidades. Por ello, es un objetivo frecuente de la subcontratación o la deslocalización . Generalmente, el equipo que desarrolla el software es diferente del que se encarga de su mantenimiento. Los desarrolladores carecen de incentivos para escribir código de fácil mantenimiento. El software suele entregarse incompleto y casi siempre contiene errores que el equipo de mantenimiento debe corregir. Inicialmente, el mantenimiento de software suele incluir el desarrollo de nuevas funcionalidades, pero a medida que el producto se acerca al final de su ciclo de vida, el mantenimiento se reduce al mínimo indispensable y, finalmente, se elimina por completo antes de que el producto se retire del mercado.

Cada ciclo de mantenimiento comienza con una solicitud de cambio, generalmente proveniente de un usuario final. Dicha solicitud se evalúa y, si se decide implementarla, el programador estudia el código existente para comprender su funcionamiento antes de realizar el cambio. Las pruebas para asegurar 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 representar la mayor parte del costo. La comprensión del tema no ha cambiado significativamente desde la década de 1980. El mantenimiento de software se puede clasificar en varios tipos según sea preventivo o reactivo y según busque agregar funcionalidades o preservar las existentes, esto último generalmente ante un entorno cambiante.

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ó "El iceberg del mantenimiento " , en el que sostenía que el mantenimiento de software era una extensión del desarrollo de software con un aporte 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 publiquen deliberadamente software incompleto y planeen 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. ^{[ 2 ]}

A pesar de las pruebas y el control de calidad , prácticamente todo el software contiene errores que impiden que el sistema funcione como se espera. El mantenimiento posterior al lanzamiento es necesario para corregir estos errores cuando se detectan. ^{[ 3 ]} La mayoría del software es una combinación de componentes de software comerciales preexistentes ( COTS) y de código abierto con código personalizado. El software COTS y de código abierto se actualiza normalmente 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 con los requisitos especificados, el mantenimiento de software se basa en eventos, como las solicitudes de los usuarios o la detección de un error. ^{[ 5 ]} Su propósito principal es preservar la utilidad del software, generalmente ante cambios en los requisitos. ^{[ 6 ]}

Si se 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, ^{[ 7 ] [ 8 ]} que 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 cambio, como parte del ciclo de vida del mantenimiento de software (SMLC). ^{[ 8 ]} Los modelos SMLC suelen incluir la comprensión del código, su modificación y su revalidación. ^{[ 8 ]}

Transición desde el lanzamiento al mantenimiento hasta el final de su vida útil.

Con frecuencia, el software se entrega incompleto. Los desarrolladores prueban un producto hasta que se les acaba el tiempo o el presupuesto, ya que las consecuencias de un producto imperfecto son menores que las de exceder el plazo o el presupuesto. ^{[ 10 ]} La transición del equipo de desarrollo al de mantenimiento suele ser ineficiente, sin listas de problemas conocidos ni pruebas de validación, que el equipo de mantenimiento probablemente recreará. ^{[ 11 ]} Tras el lanzamiento, es probable que los miembros del equipo de desarrollo sean reasignados o dejen de estar disponibles. El equipo de mantenimiento requerirá recursos adicionales durante el primer año posterior al lanzamiento, tanto para soporte técnico como para corregir los defectos remanentes del desarrollo. ^{[ 10 ]}

Inicialmente, el software puede pasar por un período de mejoras después de su 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 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 por el envejecimiento del software . Una vez que un producto deja de recibir mantenimiento y ni siquiera recibe este nivel limitado de actualizaciones, algunos proveedores intentarán obtener ingresos del software el mayor tiempo posible, aunque es probable que el producto sea cada vez más evitado. Finalmente, el software se retirará del mercado, aunque puede que siga en uso. Durante este proceso, el software se convierte en un sistema heredado . ^{[ 12 ]}

El objetivo principal del mantenimiento de software es garantizar que el producto siga cumpliendo con los requisitos de usabilidad. En ocasiones, esto puede implicar ampliar las capacidades del producto más allá de lo previsto inicialmente. ^{[ 30 ]}

Según la especificación ISO / IEC 14764, el mantenimiento del software se puede clasificar en cuatro tipos: ^{[ 31 ]}

• Mantenimiento correctivo : modificación del software para corregir un error u otro fallo que impida cumplir con los requisitos, generalmente reportado por un usuario final. ^{[ 31 ] [ 32 ]}
• Mantenimiento preventivo : modificación prospectiva del software después de su entrega para asegurar que siga cumpliendo los requisitos o solucionar problemas que aún no se han manifestado. ^{[ 33 ] [ 31 ]} Este tipo de mantenimiento se realiza especialmente en sistemas que requieren alta seguridad o disponibilidad. ^{[ 33 ]} La renovación del software es una forma de mantenimiento preventivo para limpiar el estado y prevenir problemas futuros. ^{[ 33 ]}
• Mantenimiento adaptativo: modificación del software realizada después de la entrega para asegurar su continua usabilidad en un entorno cambiado o en constante cambio. ^{[ 31 ] [ 33 ]}
• Mantenimiento perfectivo: mejora del software después de su entrega para optimizar cualidades como la experiencia del usuario , la eficiencia del procesamiento y la mantenibilidad . ^{[ 33 ] [ 34 ]} El mantenimiento perfectivo es necesario si se realizan otros tipos de mantenimiento, ya que la modificación de una base de código existente, de lo contrario, aumentaría la complejidad y provocaría el deterioro de la estructura existente. ^{[ 34 ]} El mantenimiento perfectivo puede incluir la reescritura de la documentación , la refactorización del código y la optimización del rendimiento. ^{[ 33 ]}

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 cualidad del software que permite modificarlo fácilmente sin afectar la funcionalidad existente. ^{[ 31 ]} Según la especificación ISO/IEC 14764, la actividad para garantizar la mantenibilidad del software antes de su lanzamiento se considera 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 para cumplir con un plazo, eligen soluciones rápidas y poco elegantes en lugar de incorporar la mantenibilidad en su código. ^{[ 37 ]} Una causa común es la subestimación en la estimación del esfuerzo de desarrollo de software , lo que lleva a la asignación insuficiente de recursos al desarrollo. ^{[ 38 ]} Un aspecto importante es contar con una gran cantidad de pruebas de software automatizadas que puedan detectar si la funcionalidad existente se ve comprometida por un cambio. ^{[ 31 ]}

Se puede calcular un índice de mantenibilidad con ciertas fórmulas a partir de medidas de líneas de código , medidas de McCabe y medidas de complejidad de Halstead .

La medición y el seguimiento de la mantenibilidad tienen como objetivo ayudar a reducir o revertir la tendencia de un sistema hacia la "entropía del código" o la degradación de su integridad, e indicar cuándo resulta más económico y/o menos arriesgado reescribir el código que modificarlo.

Un desafío con la mantenibilidad es que muchos cursos de ingeniería de software no la enfatizan y asignan tareas únicas con especificaciones claras e inmutables. ^{[ 39 ]} Los cursos de ingeniería de software no cubren sistemas tan complejos como los que se presentan en el mundo real. ^{[ 40 ]} Los ingenieros de desarrollo que saben que no serán responsables del mantenimiento del software no tienen incentivos para incorporar la mantenibilidad. ^{[ 2 ]}

El mantenimiento suele considerarse un trabajo poco gratificante para los ingenieros de software , quienes, si se les asignaba a esta tarea, tenían más probabilidades de renunciar. ^{[ 41 ] [ 42 ]} A menudo se paga menos que un trabajo comparable en el desarrollo de software. ^{[ 42 ]} La tarea suele asignarse a trabajadores temporales o personal menos cualificado, ^{[ 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 Estados Unidos realizaban tareas de mantenimiento. ^{[ 44 ]}

Las empresas comenzaron a formar equipos separados para el mantenimiento, lo que llevó a la subcontratación de este trabajo a otra empresa y, a principios del siglo XXI, a veces a la deslocalización del 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 el soporte las 24 horas, reducir la presión de tiempo sobre los desarrolladores y acercar el soporte al mercado del producto. ^{[ 47 ]} Las desventajas de la deslocalización incluyen barreras de comunicación en forma de factores tales como la zona horaria y la disyunción organizacional y las diferencias culturales. ^{[ 9 ]} A pesar de que muchos empleadores consideran el mantenimiento como un trabajo de menor cualificación y la fase del 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, ambas obstaculizadas por estas dificultades de comunicación. ^{[ 9 ]}

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, además, necesarios para las necesidades empresariales actuales. Con frecuencia, los sistemas heredados están escritos en lenguajes de programación obsoletos , carecen de documentación, presentan una estructura que se deteriora tras años de cambios y dependen de expertos para su funcionamiento. ^{[ 49 ]} Al tratar con estos sistemas, en algún momento se acumula tanta deuda técnica que el mantenimiento deja de ser práctico o económico. ^{[ 12 ]} Otras opciones incluyen:

• Congelación: no se realiza más trabajo en el sistema heredado. ^{[ 50 ]} Esta opción puede elegirse si el proveedor desea seguir obteniendo ingresos el mayor tiempo posible evitando los costos de mantenimiento. ^{[ 12 ]}
• Externalizar la funcionalidad del sistema heredado a otra empresa, especialmente si no se considera una función empresarial central. ^{[ 50 ]}
• Descartar el sistema heredado existente y desarrollar una nueva aplicación desde cero para cumplir el mismo propósito que el sistema heredado. ^{[ 50 ]} Sin embargo, este enfoque es ineficiente debido a que se descarta un sistema que funciona, y con este enfoque existe el peligro de que el nuevo sistema no satisfaga los requisitos comerciales cambiantes. ^{[ 50 ]}
• Envolver la aplicación heredada en una capa de abstracción para simplificar las interfaces obsoletas. ^{[ 50 ]} El código fuente no se modifica, pero la nueva interfaz permite que un componente probado y comprobado sea accedido por aplicaciones más recientes. Este enfoque no soluciona ninguno de los problemas relacionados con el mantenimiento de un sistema heredado. ^{[ 51 ]} Bases de datos, funciones y aplicaciones completas pueden envolverse de esta manera. ^{[ 52 ]}
• Migrar el sistema heredado a una nueva plataforma puede reducir el costo del desarrollo de nuevo software al reutilizar la implementación, el diseño, las especificaciones y los requisitos del sistema heredado. ^{[ 53 ]} La migración puede tardar de 5 a 10 años, pero resulta en una mayor flexibilidad y ahorros a largo plazo en el mantenimiento del software. ^{[ 54 ]} Hasta el 80 por ciento del costo se destina a las pruebas; es decir, a garantizar que el nuevo sistema tenga el mismo resultado que el sistema antiguo. ^{[ 55 ]} Una vez finalizado el nuevo sistema, es necesario realizar una transición del sistema antiguo al nuevo con una mínima interrupción de las funciones empresariales. ^{[ 55 ]}

A pesar de consumir 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 énfasis en motivar a los ingenieros para que hagan de la mantenibilidad una prioridad. ^{[ 58 ]} A partir de 2020Las soluciones automatizadas para la refactorización de código con el fin de reducir el esfuerzo de mantenimiento son un área activa de investigación, ^{[ 59 ]} al igual que la evaluación de la mantenibilidad mejorada mediante aprendizaje automático . ^{[ 60 ]}

• Estimación de costos en ingeniería de software
• Costo total de propiedad , costo del producto, incluidos los costos de mantenimiento y otros costos indirectos.