Gestión del Ciclo de Vida del Software: Mantenimiento y Evolución de Sistemas Heredados

Introducción a la Evolución y Mantenimiento de Software

0. Ubicación en el Ciclo de Vida del Software

• Ciclo de desarrollo: Abarca desde los requisitos hasta la entrega, incluyendo fases como requisitos, diseño, implementación y pruebas.
• Ciclo de vida: Comprende desde la concepción hasta la retirada del software, incluyendo adquisición, suministros, desarrollo, explotación y mantenimiento.

1. Definiciones Clave

• Definición de mantenimiento (ANS/IEE): Las modificaciones de los productos de software después de su entrega para corregir fallos, mejorar el rendimiento u otros atributos, o adaptar el producto a un cambio de entorno.
• Evolución del software: La dinámica de crecimiento del software.
• Lehman: La evolución del software son todas las actividades de programación orientadas a generar una nueva versión del software a partir de versiones anteriores operativas.
• Chapin: La aplicación de las actividades y procesos de mantenimiento de software que generan una nueva versión operativa de un software con una funcionalidad de usuario o propiedades cambiadas, a partir de una versión anterior, junto con los procesos y actividades de garantía de calidad y la gestión de esos procesos.
• Complejidad del dominio del problema:
• Mantenimiento: Proceso de mejora y optimización del software después de su entrega al usuario final, así como la corrección y prevención de defectos.
• Evolución: Todas las actividades de generación de software orientadas a generar una nueva versión de un software a partir de una versión anterior operativa. Incluye cambios en los requisitos.
• Conservación: Uso continuo de medios extraordinarios para mantener operativo un sistema antiguo.

2. Importancia del Mantenimiento de Software

Aunque el hardware es más costoso que el software, es crucial realizar cambios en el software para corregir errores en los requisitos iniciales del sistema original y para implementar nuevos requisitos que surgen constantemente.

Cuestiones asociadas al coste del mantenimiento:

• Analizar los cambios desde la perspectiva técnica y de negocio: Los cambios deben contribuir a los objetivos del sistema.
• Los subsistemas no son nunca completamente independientes: Los cambios en uno pueden afectar de forma adversa al funcionamiento o comportamiento de otros.
• No se registran las decisiones de diseño original: Los responsables de la evolución tienen que resolver por qué se tomaron esas decisiones particulares de diseño.
• La estructura original se va corrompiendo por el cambio: De tal forma que se incrementan los costes de cambios adicionales.

Predicción de Mantenimiento

La aceptación o no de un cambio en un software/sistema depende de la mantenibilidad de los componentes afectados por dicho cambio. La implementación de los cambios del sistema tiende a degradar la estructura de dicho sistema y reduce su mantenibilidad. Los costes de mantenimiento dependen del número de cambios, y los costes de la implementación de los cambios dependen de la mantenibilidad de los componentes del sistema.

La predicción del número de peticiones de cambios para un sistema requiere entender la relación entre el sistema y su entorno:

• El número y la complejidad de las interfaces del sistema. Cuanto mayor sea el número de interfaces y más complejas sean estas, es probable que se hagan más peticiones de cambio.
• Los requisitos que reflejan políticas y procedimientos organizacionales son probablemente más volátiles que los requisitos basados en características del dominio.
• Los procesos de negocio en los que se utiliza el sistema. Puesto que los procesos de negocio evolucionan, generan peticiones de cambio en el sistema.

La predicción de la mantenibilidad de un sistema tiene que ver con el número y los tipos de relaciones entre los componentes del mismo. Reducir los costes de mantenimiento pasa por reemplazar los componentes complejos.

3. Procesos Diferenciados vs. Proceso Único

La diferencia entre desarrollo y mantenimiento tiende a ser irrelevante, puesto que gran parte de lo que se desarrolla es para adaptar el software ya existente o para que un sistema evolucione.

El coste del mantenimiento es a veces mayor que el del desarrollo, pero el desarrollo desde el principio suele generar más problemas que el mantenimiento.

4. Proceso Evolutivo del Software

La tendencia actual es ver el desarrollo y el mantenimiento dentro de un proceso único, continuo y evolutivo, que integra tanto actividades de desarrollo como de mantenimiento.

5. Objetivos Docentes en la Evolución del Software

• Comprender que los cambios y modificaciones del software son inevitables para que los sistemas sigan siendo útiles, y que el desarrollo y la evolución pueden integrarse en un único modelo (modelo en espiral).
• Conocer los diferentes tipos de mantenimiento del software y los factores que influyen en su coste.
• Ser consciente de los procesos implicados en la evolución del software.
• Comprender cómo los sistemas heredados pueden ser evaluados para decidir si desecharlos, mantenerlos, redesarrollarlos o reemplazarlos.

6. Procesos de Evolución del Software

Los procesos de evolución dependen de cada organización, pudiendo ser formales o informales.

Las peticiones de cambio son los conductores de los procesos de evolución del software en todas las organizaciones.

Tipos de propuestas de cambio:

• Requisitos ya existentes no integrados aún.
• Peticiones de nuevos requisitos.
• Reparaciones de errores.
• Ideas nuevas y mejoras indicadas por el equipo de desarrollo.

Los procesos de identificación de cambios y evolución del sistema son cíclicos y continúan durante toda la vida del sistema.

Cambio del software → entregas sucesivas del sistema.

Entrega → versiones de los componentes del sistema → seguimiento de versiones para el aseguramiento de la corrección de versiones en cada entrega: gestión de configuraciones.

7. Mantenimiento y su Clasificación

Actuaciones comunes para mantener la operatividad del software:

• Corrección de defectos en el software.
• Creación de nuevas funcionalidades en el software por nuevos requisitos de usuario.
• Mejora de la funcionalidad y del rendimiento.

Tipos de Mantenimiento:

• Mantenimiento perfectivo: Conjunto de actividades para mejorar o añadir nuevas funcionalidades requeridas por el usuario.
• Mantenimiento adaptativo: Conjunto de actividades para adaptar el sistema a los cambios en su entorno tecnológico.
• Mantenimiento correctivo: Conjunto de actividades dedicadas a corregir defectos en el hardware o en el software detectados por los usuarios durante la explotación del sistema.
• Mantenimiento preventivo: Conjunto de actividades para facilitar el mantenimiento futuro del sistema.

Métricas de Predicción del Mantenimiento:

• El número de peticiones de mantenimiento correctivo: El crecimiento en el número de informes de fallos de ejecución puede indicar que se han introducido más errores en el programa de los que se han corregido durante el proceso de mantenimiento.
• Tiempo medio requerido para el análisis de impacto: Este tiempo refleja el número de componentes del sistema que se ven implicados en una petición de cambio.
• Tiempo medio empleado en implementar una petición de cambio: Se trata de la cantidad de tiempo que se necesita realmente para modificar el sistema y su documentación.
• El número de peticiones de cambio pendientes: Un incremento en este número a lo largo del tiempo puede implicar una disminución en la mantenibilidad.

8. Sistemas Heredados (Legacy Systems)

Sistemas socio-técnicos: Un sistema es una colección de componentes interrelacionados que trabajan conjuntamente para cumplir un objetivo.

Los sistemas que incluyen software son de dos tipos:

• Sistemas técnico-informáticos: Son sistemas que incluyen hardware y software, pero no procesos ni procedimientos.
• Sistemas socio-técnicos: Son sistemas que comprenden uno o más sistemas técnicos, pero que además incluyen conocimiento de cómo debe usarse el sistema para alcanzar algún objetivo más amplio.

Características de los sistemas socio-técnicos:

• Propiedades emergentes: Surgen de la interacción de los componentes individuales más las relaciones entre ellos. No pueden probarse hasta que no esté el sistema completo.
• No determinista: Cuando se presenta una entrada determinada al sistema, no siempre se obtiene la misma salida.
• Grado de apoyo a los objetivos organizacionales: El grado de apoyo a los objetivos no solo depende del sistema, sino de la propia estabilidad de los objetivos, de las relaciones y conflictos, y de cómo las personas interpretan esos objetivos.

Evolución en los Sistemas Heredados:

Un sistema heredado es un sistema socio-técnico que es útil o fundamental para una organización, pero que ha sido desarrollado utilizando una tecnología o métodos obsoletos.

Un sistema heredado es un sistema informático que ha quedado anticuado pero que se sigue utilizando, y no se quiere o no se puede reemplazar o actualizar de forma sencilla.

Es necesario que se realicen evaluaciones realistas de sus sistemas heredados y decidir cuál es la estrategia de evolución más adecuada para estos sistemas.

Estrategias de Evolución para Sistemas Heredados:

• Desechar completamente el sistema: Esta opción debería elegirse cuando el sistema no constituye una contribución efectiva para los procesos de negocio. Esto ocurre cuando los procesos de negocio han cambiado desde que se instaló el sistema y ya no son completamente dependientes de este.
• Dejar el sistema sin cambios y continuar con un mantenimiento regular: Se deberá optar por esto cuando el sistema aún es necesario y muy estable, y los usuarios solicitan un número relativamente pequeño de cambios.
• Reemplazar todo o parte del sistema con un nuevo sistema: Esta opción deberá elegirse cuando otros factores hacen que el sistema antiguo no pueda continuar.
• Hacer reingeniería del sistema para mejorar su mantenibilidad: Cuando un sistema se ha ido modificando continuamente, puede suceder que la calidad del sistema se ha degradado y los cambios son aún necesarios.

9. Evaluación de los Sistemas Heredados

Perspectiva Técnica y de Negocio:

• Baja calidad y bajo valor de negocio: Mantenimiento caro, beneficios pequeños → desechar.
• Baja calidad y alto valor de negocio: Mantenimiento caro y grandes beneficios, no puede desecharse → mejorar o reemplazar.
• Alta calidad y bajo valor de negocio: Mantenimiento barato y beneficios pequeños → si los cambios son caros, desecharlo.
• Alta calidad y alto valor de negocio: Mantenimiento barato y grandes beneficios → continuar mantenimiento.

Evaluar el Valor de Negocio:

• Uso del sistema.
• Procesos de negocio soportados.
• Confiabilidad del sistema.
• Salidas del sistema.

Evaluar la Perspectiva Técnica:

Factores utilizados en la evaluación de la APLICACIÓN:

• Comprensión del código fuente.
• Documentación.
• Datos.
• Rendimiento.
• Lenguajes de programación.
• Gestión de configuraciones.
• Datos de prueba.
• Habilidades del personal.

Factores utilizados en la evaluación del ENTORNO:

• Estabilidad del proveedor.
• Tasas de fallos de ejecución.
• Edad.
• Rendimiento del sistema.
• Costes de mantenimiento.
• Interoperabilidad.