Capítulo X.
Evolución y Mantenimiento de Software • Conforme el software se modifica, su estructura tiende a degradarse y los cambios se vuelven más y más
Objetivos del capítulo
• Explicar por qué la evolución del software forma parte importante de la ingeniería de software, así como
describir los procesos de evolución del software. • Comprender que el cambio es inevitable si los sistemas de
software deben mantener su utilidad. • Conocer diferentes tipos de mantenimiento de software y los factores
que afectan los costos de mantenimiento.
Definiciones
Estándar IEEE 1219
• La modificación de un producto software después de su entrega al cliente o usuario para corregir defectos,
para mejorar el rendimiento u otras propiedades deseables, o para adaptarlo a un cambio de entorno. Estándar
ISO/IEC 14764
• Conjunto de actividades destinadas a proporcionar soporte económicamente rentable para un determinado
producto software. Estas actividades se realizan tanto antes de la entrega del producto como después de la
entrega del mismo. • Las actividades previas a la entrega incluyen las actividades destinadas a planificar,
anticipar y preparar actividades de mantenimiento posteriores. Las actividades posteriores a la entrega
incluyen modificaciones del producto software, formación y asistencia al usuario.
Mantenibilidad (Maintainability)
• Capacidad de un producto software de ser modificado. Estas modificaciones incluyen correcciones,
mejoras, o adaptaciones a cambios en el entorno, los requisitos o las especificaciones funcionales.
Efecto dominó (ripple effect)
• Un determinado cambio en un producto software se dice que genera un efecto dominó cuando a
consecuencia del cambio debemos realizar cambios adicionales en el sistema.
Estabilidad de un diseño de software.
• Capacidad de resistencia al efecto dominó que tendría un sistema software derivado de dicho diseño cuando
es modificado.
Sistema Heredado (Legacy Systems)
• Un sistema heredado es un método, tecnología, computador o aplicación antiguo que continúa en uso porque
aún satisface las necesidades de los usuarios, aun existiendo nuevas tecnologías o métodos más eficientes
disponibles (ej. aplicaciones COBOL en banca, Amadeus).
Evolución y Mantenimiento del SW
Introducción
• Es una actividad continua a lo largo de la vida del producto de SW (cambios empresariales, tecnológicos,
legales, otros)
• Los sistemas se consideran activos empresariales críticos
– Se requiere inversión para mantener el valor de esos activos
– las compañías más grandes gastan más en conservar los sistemas existentes que en el desarrollo de sistemas
nuevos.
– los costos del cambio del software representan una gran parte del presupuesto
• Puesto que el costo del software es elevado, una compañía debe usar un sistema de software durante muchos
años para recuperar su inversión (sistemas empresariales con frecuencia superan los 10 años). •
Evidentemente, los requerimientos de los sistemas instalados cambian conforme lo hace el negocio y su
entorno. Por consiguiente, se crean a intervalos regulares nuevas versiones de los sistemas, las cuales
incorporan cambios y actualizaciones. • Por ende, la ingeniería de software se debe considerar como un
proceso en espiral, con requerimientos, diseño, implementación y pruebas continuas, a lo largo de la vida del
sistema.
• Otro modelo hace una distinción entre evolución y servicio. La evolución es la fase donde es posible hacer
cambios significativos a la arquitectura y la funcionalidad del software. Durante el servicio, los únicos
cambios que se realizan son relativamente pequeños. • Durante la evolución, el software se usa con éxito y
hay un flujo constante de propuestas de cambios a los requerimientos.
costosos.
• En la fase final, de retiro gradual (Phase-out), el software todavía puede usarse, aunque no se implementan
más cambios. Los usuarios tienen que sobrellevar cualquier problema que descubran.
Proceso de evolución
• Las propuestas de cambio al sistema son el motor para la evolución del sistema en todas las organizaciones.
Provienen de:
– Requerimientos existentes que no se han implementado – Peticiones de nuevos requerimientos – Reportes
de bugs – Nuevas ideas de mejora
• La primera implementación del cambio puede involucrar la comprensión del programa, sobre todo si los
desarrolladores del sistema original no son los responsables de implementar el cambio. • Durante esta fase
de comprensión del programa, hay que entender cómo está.
• En ocasiones, las peticiones de cambio se relacionan con problemas del sistema que tienen que
enfrentarse de manera urgente. Estos cambios urgentes surgen básicamente por tres razones:
1. Si ocurre una falla seria del sistema que deba repararse para permitir que continúe la operación
normal.
2. Si los cambios a los sistemas que operan el entorno tienen efectos inesperados que perturban la
operación normal.
3. Si hay cambios no anticipados a la empresa que opera el sistema, como el surgimiento de
competidores nuevos o la introducción de una nueva legislación que afecte al sistema.
Proceso de reparación de emergencia
Mantenimiento del software
Características:
• El mantenimiento del software es el proceso general de cambiar un sistema después de que éste se entregó.
• Los cambios realizados al software van desde los simples para corregir errores de codificación, los más
extensos para corregir errores de diseño, hasta mejorías significativas para corregir errores de especificación
o incorporar nuevos requerimientos. • Los cambios se implementan modificando los componentes del sistema
existentes y agregándole nuevos componentes donde sea necesario.
Tipos de Mantenimiento de SW
Reparación de Fallas:
Los errores de codificación por lo general son relativamente baratos de corregir; los errores de diseño son
más costosos, ya que quizás impliquen la reescritura de muchos componentes del programa. Los errores de
requerimientos son los más costosos de reparar debido a que podría ser necesario un extenso rediseño del
sistema. Adaptación Ambiental:
• Se requiere cuando algún aspecto del entorno del sistema, como el hardware, la plataforma operativa del
sistema u otro soporte, cambia el software. • El sistema de aplicación tiene que modificarse para lidiar con
dichos cambios ambientales.
Adición de Funcionalidad:
• Este tipo de mantenimiento es necesario cuando varían los requerimientos del sistema, en respuesta a un
cambio organizacional o empresarial. • La escala de los cambios requeridos en el software suele ser mucho
mayor que en los otros tipos de mantenimiento • Se usan algunos términos genéricos para estos tipos de
mantenimiento tales como “correctivo”, “adaptativo” y “perfectivo”.
Distribución del esfuerzo de mantenimiento 3. Los procesos empresariales donde se usa el sistema.
• Los costos relativos de mantenimiento y del nuevo desarrollo varían
de un dominio de aplicación a otro.
• Por lo general, resulta efectivo en costo invertir esfuerzo en el diseño
y la implementación de un sistema, con la finalidad de reducir los costos
de cambios futuros.
• Por lo tanto, es posible que el trabajo realizado durante el desarrollo
para hacer que el software sea más fácil de entender y cambiar reduzca los
costos de evolución.
Costos de mantenimiento de SW
• Los estudios concuerdan ampliamente en que el mantenimiento del software toma una proporción más alta
de presupuestos de TI que el nuevo desarrollo (casi dos tercios en mantenimiento y un tercio en desarrollo).
• También coinciden en que una mayor parte del presupuesto de mantenimiento se destina a la
implementación de nuevos requerimientos, y no a la reparación de bugs. • Evolucionar el sistema para
enfrentar nuevos entornos y requerimientos nuevos o cambiantes consume más esfuerzo de mantenimiento. Complejidad y mantenibilidad.
• Los costos relativos de mantenimiento y del nuevo desarrollo varían de un dominio de aplicación a otro. La complejidad de un programa y la mantenibilidad del mismo tienen una relación directa.
Guimaraes (1983) descubrió que los costos de mantenimiento para sistemas de aplicación empresarial son – Mientras más complejo el componente, más costoso mantenerlo.
ampliamente comparables con los costos de desarrollo del sistema. – Los estudios indican que el esfuerzo de mantenimiento tendía a enfocarse en un pequeño número de
• Agregar nueva funcionalidad después de la entrega es costoso porque toma tiempo aprender cómo funciona componentes complejos.
el sistema y analizar el impacto de los cambios propuestos. • Por lo tanto, es posible que el trabajo realizado Ejemplos de métricas de proceso para valorar la mantenibilidad.
durante el desarrollo para hacer que el software sea más fácil de entender, y de cambiar, reduzca los costos 1. Número de peticiones para mantenimiento correctivo.
de evolución. • Las buenas técnicas de ingeniería de software, como la especificación precisa, el uso de 2. Tiempo promedio requerido para análisis del impacto.
desarrollo orientado a objetos y la administración de la configuración, contribuyen a reducir los costos de 3. Tiempo promedio tomado para implementar una petición de cambio.
mantenimiento. • La realidad es que la inversión adicional en el mejoramiento del código rara vez se hace 4. Número de peticiones de cambio pendientes
durante el desarrollo. Esto se debe principalmente a aplicaciones presupuestarias de la organización. Invertir La información predicha sobre las peticiones de cambio y las predicciones acerca de la mantenibilidad del
en la mantenibilidad conduce a aumentos de costo a corto plazo, los cuales son mensurables. En cambio, las sistema se usan para predecir los costos de mantenimiento.
ganancias a largo plazo no pueden medirse al mismo tiempo, de modo que las compañías son renuentes a
gastar dinero en un rendimiento futuro incierto.
Esquemas para mantenimiento de SW
• Establecer procedimientos claramente definidos y estandarizados para el mantenimiento de software, que
• En general, resulta más costoso agregar funcionalidad después de que un sistema está en operación, que
se basen en técnicas y herramientas para el mantenimiento bien definidas y validadas. • Asignarle los recursos
implementar la misma funcionalidad durante el desarrollo. Las razones son:
adecuados, tanto físicos y económicos como humanos. • Usar técnicas para control de calidad, tanto sobre el
1. Estabilidad del Equipo
producto como sobre el proceso.
Después de que un sistema se entrega, es normal que el equipo de desarrollo se integre a nuevos
Organigrama del equipo humano
proyectos. Los responsables del mantenimiento del sistema no entienden el sistema o los antecedentes
de las decisiones de diseño del mismo. Necesitan emplear tiempo para comprender el sistema existente,
antes de implementar cambios en él.
2. Práctica de desarrollo deficiente
El contrato para mantener un sistema por lo general está separado del contrato de desarrollo del sistema
(y no estar a cargo del desarrollador original). Este factor, junto con la falta de estabilidad del equipo,
indica que no hay incentivo para que un equipo de desarrollo escriba software mantenible.
3. Habilidades del personal Soluciones técnicas para el mantenimiento de SW
• El personal de mantenimiento no siempre está familiarizado con el dominio de la aplicación. • Se
suele asignar personal más novato a esta actividad. • Los sistemas antiguos pueden estar escrito en
lenguajes de programación obsoletos.
4. Antigüedad y estructura del programa:
• Conforme se realizan cambios al programa, su estructura tiende a degradarse. En consecuencia, a
medida que los programas envejecen, se vuelven más difíciles de entender y cambiar. • La
documentación del sistema puede estar perdida o ser inconsistente.
Predicción de mantenimiento
Para evitar costos inesperadamente altos, es importante predecir qué cambios deben proponerse al sistema y
qué partes del sistema es probable que sean las más difíciles de mantener. Proceso de Reingeniería
Predecir el número de peticiones de cambio para un sistema requiere un entendimiento de la relación entre el • Muchos sistemas, especialmente los sistemas heredados más antiguos, son difíciles de entender y de
sistema y su ambiente externo, por lo que se debe valorar: cambiar. • Es posible que los programas se hayan optimizado para rendimiento o utilización de espacio a
1. El número y la complejidad de las interfaces del sistema. expensas de la claridad o, con el tiempo, la estructura inicial del programa quizá se corrompió debido a una
2. El número de requerimientos de sistema inherentemente inestables.
serie de cambios. • Para hacer que los sistemas de software heredados sean más sencillos de mantener, se
pueden someter a reingeniería para mejorar su estructura y entendimiento.
• La reingeniería puede implicar volver a documentar el sistema, refactorizar su arquitectura, traducir los
programas a un lenguaje de programación moderno, y modificar y actualizar la estructura y los valores de
los datos del sistema. • La funcionalidad del software no cambia y, normalmente, conviene tratar de evitar
grandes cambios a la arquitectura de sistema.
• Hay dos beneficios importantes de la reingeniería respecto de la sustitución:
1. Reducción de Riesgos:
– Hay un alto riesgo en el desarrollo de software empresarial crítico. – Las demoras en la
introducción del nuevo software podrían significar que la empresa está perdida y que se incurrirá en
costos adicionales.
2. Reducción de Costos:
– El costo de la reingeniería puede ser significativamente menor que el costo de desarrollar
software nuevo
• La entrada al proceso es un sistema heredado, en tanto que la salida es una versión mejorada y
reestructurada del mismo programa.
Las actividades en este proceso de reingeniería son las siguientes:
1. Traducción del código fuente: Con una herramienta de traducción, el programa se convierte de un
lenguaje de programación antiguo a una versión más moderna del mismo lenguaje o a un lenguaje
diferente.
2. Ingeniería inversa: El programa se analiza y se extrae información de él.
3. Mejoramiento de la estructura del programa: La estructura de control del programa se analiza y
modifica para facilitar su lectura y comprensión
4. Modularización del programa: Las partes relacionadas del programa se agrupan y donde es adecuado
se elimina la redundancia.
5. Reingeniería de datos: Los datos procesados por el programa cambian para reflejar cambios al
programa.
Mantenimiento preventivo mediante refactorización
• Proceso de cambio de un sistema software de forma que su comportamiento externo no se vea afectado pero
que mejora su estructura interna (conocido como limpieza de código). • La refactorización es el proceso de
hacer mejoras a un programa para frenar la degradación mediante el cambio. • Significa modificar un
programa para mejorar su estructura, reducir su complejidad o hacerlo más fácil de entender. • Mientras se
refactorice un programa, no se debe agregar funcionalidad, sino que hay que concentrarse en la mejora del
mismo. Por ende, se puede considerar la refactorización como el “mantenimiento preventivo” que reduce los
problemas de cambios futuros. • Aunque la reingeniería y la refactorización tienen la intención de hacer el
software más fácil de entender y cambiar, no son lo mismo.
Reingeniería
• La reingeniería se lleva a cabo después de haber mantenido un sistema durante cierto tiempo y, por
consiguiente, los costos de mantenimiento aumentan. • Se usan herramientas automatizadas para procesar y
someter a reingeniería un sistema heredado y así crear un nuevo sistema que sea más mantenible.
Refactorización
• La refactorización es un proceso continuo de mejoramiento debido al proceso de desarrollo y evolución. •
Tiene la intención de evitar la degradación de la estructura y el código que aumentan los costos y las
dificultades por mantener un sistema.
Mantenimiento preventivo mediante refactorización (..)
• La refactorización es una parte inherente de los métodos ágiles, como lo es la programación extrema, porque
dichos métodos se basan en el cambio. • El énfasis en las pruebas de regresión en los métodos ágiles reduce
el riesgo de introducir nuevos errores a través de la refactorización. Cualquier error que se introduzca debe
ser detectable, ya que las pruebas anteriormente exitosas podrían fracasar.
----
Hay algunos estereotipos (bad smell) en los cuales el código puede ser susceptible de mejorarse por
refactorización:
1. Código Duplicado. El mismo código muy similar puede incluirse en diferentes lugares de un programa.
Éste se descarta o se implementa como un solo método o función que se llame cuando se requiera.
2. Métodos largos. Si un método es demasiado largo, debe rediseñarse en varios métodos más cortos.
3. Enunciados de switch (case). Con frecuencia éstos implican duplicación, donde el cambio (switch)
depende del tipo de algún valor. Los enunciados switch pueden dispersarse alrededor de un programa. En los
lenguajes orientados a objetos, normalmente es posible usar un polimorfismo para lograr lo mismo.
4. Aglomeración de datos. Ocurren cuando el mismo grupo de objetos de datos (campos en clases,
parámetros en métodos) vuelven a ocurrir en muchos lugares en un programa. Generalmente pueden
sustituirse con un objeto que encapsule todos los datos.
5. Generalidad especulativa. Esto ocurre cuando los desarrolladores incluyen generalidad en un programa,
en caso de que se requiera en el futuro. Por lo general, esto simplemente puede eliminarse.
¿Qué síntomas indican que debería refactorizar?
El código es más difícil de entender (y por tanto de cambiar) cuando:
• Usa identificadores mal escogidos • Incluye fragmentos de código duplicado • Incluye lógica condicional
compleja • Los métodos usan número elevado de parámetros • Incluye fragmentos de código secuencial muy
extensos • Está dividido en módulos enormes (estructura monolítica) • Los módulos en los que se divide no
resultan razonables desde el punto de vista lógico (cohesión baja) • Los distintos módulos de un sistema están
relacionados con otros módulos de un sistema (acoplamiento fuerte) • Un método accede continuamente a
los datos de un objeto de una clase diferente a la clase en la que está definida (posiblemente, el método
debería pertenecer a la otra clase) • Una clase incluye variables de instancia que deberían ser variables locales
de algunos(s) de sus métodos • Métodos que realizan funciones análogas se usan de forma diferente (tienen
nombres distintos y/o reciben los parámetros en distinto orden) • Un comentario se hace imprescindible para
poder entender un fragmento de código (deberíamos re-escribir el código de forma que podamos entender su
significado)
Refactorizaciones más populares
1. Pull Up Method: Existen métodos cuasi-idénticos en las subclases
2. Move Method: Un método de una clase A es más usado en una clase B que en la clase donde está definido Ingeniería Inversa
• El objetivo de la ingeniería inversa es obtener información
o un diseño a partir de un producto accesible al público, con
el fin de determinar de qué está hecho, qué lo hace
funcionar y cómo fue fabricado.
• Hoy en día (principios del siglo XXI), los productos más
comúnmente sometidos a ingeniería inversa son los
programas de computadoras y los componentes
electrónicos, pero, en realidad, cualquier producto puede
3. Add Parameter: • Un método necesita más información de quien lo llama ser objeto de un análisis de Ingeniería Inversa.
• El método se denomina así porque avanza en dirección
opuesta a las tareas habituales de ingeniería, que
consisten en utilizar datos técnicos para elaborar un
producto determinado. En general, si el producto u otro
material que fue sometido a la ingeniería inversa fue
obtenido en forma apropiada, entonces el proceso es
¡OJO! Puede crear listas interminables de argumentos
legítimo y legal. De la misma forma, pueden fabricarse y
3.5. Introduce Parameter Object: Existen grupos de parámetros que están naturalmente relacionados
distribuirse, legalmente, los productos genéricos creados a
partir de la información obtenida de la ingeniería inversa,
como es el caso de algunos proyectos de software libre
ampliamente conocidos.
• El programa Samba es un claro ejemplo de ingeniería inversa, dado que permite a sistemas operativos UNIX
compartir archivos con sistemas Microsoft Windows.
• El proyecto Samba tuvo que investigar información confidencial (no liberada al público en general por
Microsoft) sobre los aspectos técnicos relacionados con el sistema de archivos Windows
4. Move Field: Un atributo de una clase A es más usado en una clase B que en la clase donde está definido. Ingeniería Inversa de código Java a UML

5. Rename Method/Field: El nombre de un atributo o método no es significativo

Ingeniería Inversa de BD relacionales

Replace Magic Number with Symbolic Constant

Tenemos una constante numérica con un significado bien definido

1. Por cada tabla sin referencias a otras tablas, creamos una entidad.
2. Para las entidades creadas, copiamos atributos y marcamos claves primarias. Marcamos las tablas como
procesadas.
3. Por cada tabla con referencias externas, creamos una entidad.
4. Para las entidades creadas, copiamos atributos y marcamos claves primarias.
5. Por cada clave externa, creamos una relación entre la entidad creada y la referenciada.
6. Para dicha relación, el extremo de tabla referenciada tendrá cardinalidad 1, salvo restricción expresa.
7. Para dicha relación, el extremo de la entidad creada, tendrá cardinalidad0..*, salvo restricción expresa.
8. Si una entidad tiene: (1) su clave primaria formada por la unión de las claves primarias de tablas con las
cuales se relaciona; y (2) los extremos de las relaciones con las otras entidades tienen como cardinalidad
superior 1, convertir dicha entidad en una relación n a m entre entidades.
9. Copiar los atributos de la entidad a atributos de la relación.