Chapter 9 – Software Evolution

30/10/2014 Chapter 9 Software Evolution 1

Topics covered

 Procesos de evolución
 Sistemas heredados
 Mantenimiento del software

30/10/2014 Chapter 9 Software Evolution 62

Software change

 El cambio de software es inevitable

 Surgen nuevos requisitos cuando se utiliza el software;
 El entorno empresarial cambia;
 Hay que reparar errores;
 Se añaden nuevos ordenadores y equipos al sistema;
 Es posible que haya que mejorar el rendimiento o la fiabilidad
del sistema.
 Un problema clave para todas las organizaciones es
implantar y gestionar el cambio de sus sistemas de
software existentes.

30/10/2014 Chapter 9 Software Evolution 63

Importance of evolution

 Las organizaciones realizan grandes inversiones en sus

sistemas de software: son activos empresariales críticos.
 Para mantener el valor de estos activos para la
empresa, hay que cambiarlos y actualizarlos.
 La mayor parte del presupuesto de software de las
grandes empresas se dedica a cambiar y evolucionar el
software existente en lugar de desarrollar software
nuevo.

30/10/2014 Chapter 9 Software Evolution 64

A spiral model of development and evolution

30/10/2014 Chapter 9 Software Evolution 65

Evolution and servicing

Desarrollo de
Evolución del
software Mantenimiento
software
de software Software
Jubilación

30/10/2014 Chapter 9 Software Evolution 66

Evolution and servicing

 Evolución
 Etapa del ciclo de vida de un sistema informático en la que se
utiliza de forma operativa y evoluciona a medida que se
proponen e implementan nuevos requisitos en el sistema.
 Mantenimiento
 En esta etapa, el software sigue siendo útil, pero los únicos
cambios que se realizan son los necesarios para mantenerlo
operativo, es decir, correcciones de errores y cambios para
reflejar los cambios en el entorno del software. No se añaden
nuevas funcionalidades.
 Retirada
 El software puede seguir utilizándose, pero no se le hacen más
cambios.
30/10/2014 Chapter 9 Software Evolution 67
 Evolution processes

30/10/2014 Chapter 9 Software Evolution 68

Evolution processes

 Los procesos de evolución del software dependen de

 El tipo de software que se mantiene;
 Los procesos de desarrollo utilizados;
 Las competencias y experiencia de las personas implicadas.
 Las propuestas de cambio son el motor de la evolución
del sistema.
 Deben vincularse a los componentes afectados por el cambio, lo
que permite estimar el coste y el impacto del cambio.
 La identificación y evolución de los cambios continúa
durante toda la vida útil del sistema.

30/10/2014 Chapter 9 Software Evolution 69

Change identification and evolution processes

Proceso de identificación
de cambios

Nuevo sistema Propuestas de cambio

Proceso de evolución
del software

30/10/2014 Chapter 9 Software Evolution 70

 The software evolution process

Solicitudes de Análisis de Planificación de Aplicación del Liberación

cambio impacto la liberación cambio del sistema

Reparación Plataforma de mejora del

de averías adaptación sistema

30/10/2014 Chapter 9 Software Evolution 71

Change implementation

Cambios Análisis de Actualización Desarrollo de

propuestos requisitos de requisitos software

30/10/2014 Chapter 9 Software Evolution 72

Change implementation

 Iteración del proceso de desarrollo en la que se diseñan,

implementan y prueban las revisiones del sistema.
 Una diferencia fundamental es que la primera fase de la
aplicación del cambio puede implicar la comprensión del
programa, sobre todo si los desarrolladores originales
del sistema no son responsables de la aplicación del
cambio.
 Durante la fase de comprensión del programa, hay que
entender cómo está estructurado el programa, cómo
ofrece funcionalidad y cómo podría afectar al programa
el cambio propuesto.

30/10/2014 Chapter 9 Software Evolution 73

Urgent change requests

 Es posible que haya que aplicar cambios urgentes sin

pasar por todas las fases del proceso de ingeniería de
software.
 Si hay que reparar un fallo grave del sistema para permitir que
continúe el funcionamiento normal;
 Si los cambios en el entorno del sistema (por ejemplo, una
actualización del sistema operativo) tienen efectos inesperados;
 Si se producen cambios en la empresa que requieran una
respuesta muy rápida (por ejemplo, el lanzamiento de un
producto de la competencia).

30/10/2014 Chapter 9 Software Evolution 74

The emergency repair process

Solicitud Analizar el Modificar el Entregar sistema

de cambio código fuente código fuente modificado

30/10/2014 Chapter 9 Software Evolution 75

Agile methods and evolution

 Los métodos ágiles se basan en el desarrollo

incremental, por lo que la transición del desarrollo a la
evolución es fluida.
 La evolución no es más que una continuación del proceso de
desarrollo basado en frecuentes versiones del sistema.
 Las pruebas de regresión automatizadas son
especialmente valiosas cuando se realizan cambios en
un sistema.
 Los cambios pueden expresarse como historias de
usuario adicionales.

30/10/2014 Chapter 9 Software Evolution 76

Handover problems

 Cuando el equipo de desarrollo ha utilizado un enfoque ágil,

pero el equipo de evolución no está familiarizado con los
métodos ágiles y prefiere un enfoque basado en la
planificación.
 El equipo de evolución puede esperar documentación detallada para
apoyar la evolución y esto no se produce en los procesos ágiles.
 Cuando se ha utilizado un enfoque basado en la
planificación para el desarrollo, pero el equipo de evolución
prefiere utilizar métodos ágiles.
 Es posible que el equipo de evolución tenga que empezar desde
cero a desarrollar pruebas automatizadas y que el código del
sistema no se haya refactorizado y simplificado como se espera en
el desarrollo ágil.

30/10/2014 Chapter 9 Software Evolution 77

 Legacy systems

30/10/2014 Chapter 9 Software Evolution 78

Legacy systems

 Los sistemas heredados son sistemas antiguos que

dependen de lenguajes y tecnologías que ya no se
utilizan para el desarrollo de nuevos sistemas.
 El software heredado puede depender de hardware
antiguo, como ordenadores centrales, y puede tener
asociados procesos y procedimientos heredados.
 Los sistemas heredados no son sólo sistemas de
software, sino sistemas sociotécnicos más amplios que
incluyen hardware, software, bibliotecas y otros
programas y procesos empresariales de apoyo.

30/10/2014 Chapter 9 Software Evolution 79

The elements of a legacy system

Incorpora
conocimientos de
Software de Software de Políticas y normas
apoyo aplicación empresariales

Hardware del Datos de la Procesos

sistema aplicación empresariales

30/10/2014 Chapter 9 Software Evolution 80

Legacy system components

 Hardware del sistema Los sistemas heredados pueden

haber sido escritos para hardware que ya no está
disponible.
 Software de soporte El sistema heredado puede depender
de una serie de software de soporte, que puede estar
obsoleto o no tener soporte.
 Software de aplicación El sistema de aplicación que
proporciona los servicios empresariales suele estar formado
por una serie de programas de aplicación.
 Datos de aplicación Son los datos que procesa el sistema
de aplicación. Pueden ser incoherentes, estar duplicados o
almacenados en diferentes bases de datos.
30/10/2014 Chapter 9 Software Evolution 81
Legacy system components

 Procesos empresariales Son procesos que se utilizan en

la empresa para alcanzar algún objetivo empresarial.
 Los procesos empresariales pueden diseñarse en torno
a un sistema heredado y estar limitados por la
funcionalidad que ofrece.
 Políticas y normas empresariales Son definiciones de
cómo debe llevarse a cabo la actividad empresarial y de
las restricciones que pesan sobre ella. El uso del
sistema de aplicaciones heredado puede estar integrado
en estas políticas y normas.

30/10/2014 Chapter 9 Software Evolution 82

Legacy system layers

Sistema sociotécnico

Procesos empresariales

Software de aplicación

Software de plataforma e infraestructura

Hardware

30/10/2014 Chapter 9 Software Evolution 83

Legacy system replacement

 La sustitución de los sistemas heredados es arriesgada

y cara, por lo que las empresas siguen utilizándolos
 La sustitución de sistemas es arriesgada por varias
razones
 Falta de una especificación completa del sistema
 Estrecha integración del sistema y los procesos empresariales
 Reglas de negocio no documentadas integradas en el sistema
heredado.
 El desarrollo del nuevo software puede retrasarse o exceder el
presupuesto.

30/10/2014 Chapter 9 Software Evolution 84

Legacy system change

 Los sistemas heredados son caros de cambiar por

varias razones:
 No existe un estilo de programación coherente
 Uso de lenguajes de programación obsoletos con pocas
personas disponibles con estos conocimientos lingüísticos
 Documentación inadecuada del sistema
 Degradación de la estructura del sistema
 Las optimizaciones de los programas pueden dificultar su
comprensión
 Errores de datos, duplicación e incoherencia

30/10/2014 Chapter 9 Software Evolution 85

Legacy system management

 Las organizaciones que dependen de sistemas

heredados deben elegir una estrategia para evolucionar
estos sistemas
 Desechar el sistema por completo y modificar los procesos
empresariales para que deje de ser necesario;
 Seguir manteniendo el sistema;
 Transformar el sistema mediante reingeniería para mejorar su
mantenimiento;
 Sustituir el sistema por otro nuevo.
 La estrategia elegida debe depender de la calidad del
sistema y de su valor empresarial.

30/10/2014 Chapter 9 Software Evolution 86

Figure 9.13 An example of a legacy system
assessment

Alto valor empresarial

Alto valor empresarial
Baja calidad
Alta calidad
Valor comercial

Escaso valor empresarial Bajo valor empresarial

Baja calidad Alta calidad

Calidad del sistema

30/10/2014 Chapter 9 Software Evolution 87

Legacy system categories

 Baja calidad, escaso valor empresarial

 Estos sistemas deben desecharse.
 Baja calidad, alto valor empresarial
 Aportan una contribución empresarial importante, pero su
mantenimiento es costoso. Deberían rediseñarse o sustituirse si
se dispone de un sistema adecuado.
 Alta calidad, escaso valor comercial
 Sustituir por COTS, desechar por completo o mantener.
 Alta calidad, alto valor comercial
 Seguir funcionando con el mantenimiento normal del sistema.

30/10/2014 Chapter 9 Software Evolution 88

Business value assessment

 La evaluación debe tener en cuenta diferentes puntos de

vista
 Usuarios finales del sistema;
 Clientes empresariales;
 Jefes de línea;
 Responsables de TI;
 Altos directivos.
 Entrevistar a las distintas partes interesadas y cotejar los
resultados.

30/10/2014 Chapter 9 Software Evolution 89

Issues in business value assessment

 El uso del sistema

 Si los sistemas sólo se utilizan ocasionalmente o por un número
reducido de personas, es posible que tengan un escaso valor
empresarial.
 Los procesos empresariales que soportan
 Un sistema puede tener un valor empresarial bajo si obliga a utilizar
procesos empresariales ineficaces.
 Fiabilidad del sistema
 Si un sistema no es fiable y los problemas afectan directamente a los
clientes de la empresa, el sistema tiene un valor empresarial bajo.
 Los resultados del sistema
 Si la empresa depende de los resultados del sistema, éste tiene un
alto valor empresarial.

30/10/2014 Chapter 9 Software Evolution 90

System quality assessment

 Evaluación del proceso empresarial

 ¿En qué medida apoya el proceso empresarial los objetivos
actuales de la empresa?
 Evaluación del entorno
 ¿Cuál es la eficacia del entorno del sistema y cuánto cuesta
mantenerlo?
 Evaluación de la aplicación
 ¿Cuál es la calidad del sistema de software de aplicación?

30/10/2014 Chapter 9 Software Evolution 91

Business process assessment

 Utilice un enfoque orientado al punto de vista y busque

respuestas de las partes interesadas del sistema
 ¿Existe un modelo de procesos definido y se sigue?
 ¿Utilizan distintas partes de la organización procesos diferentes
para la misma función?
 ¿Cómo se ha adaptado el proceso?
 ¿Cuáles son las relaciones con otros procesos empresariales y
son necesarias?
 ¿Se apoya eficazmente el proceso en el software de aplicación
heredado?
 Ejemplo: un sistema de pedidos de viajes puede tener
escaso valor empresarial debido al uso generalizado de
pedidos por Internet.

30/10/2014 Chapter 9 Software Evolution 92

Factors used in environment assessment

Factor Questions
Estabilidad de los ¿Sigue existiendo el proveedor? ¿Es estable desde el punto de vista
proveedores financiero y tiene posibilidades de seguir existiendo? Si el proveedor
ya no existe, ¿se encarga otra persona del mantenimiento de los
sistemas?
Tasa de fracaso ¿Tiene el hardware un alto índice de fallos notificados? ¿Se bloquea
el software de apoyo y obliga a reiniciar el sistema?
Edad ¿Qué antigüedad tienen el hardware y el software? Cuanto más
antiguos sean el hardware y el software de apoyo, más obsoletos
estarán. Puede que aún funcione correctamente, pero cambiar a un
sistema más moderno puede reportar importantes beneficios
económicos y empresariales.
Rendimiento ¿Es adecuado el rendimiento del sistema? Los problemas de
rendimiento, ¿tienen un efecto significativo en los usuarios del
sistema?

30/10/2014 Chapter 9 Software Evolution 93

Factors used in environment assessment

Factor Questions
Requisitos de apoyo ¿Qué soporte local requieren el hardware y el software? Si
los costes asociados a esta asistencia son elevados, puede
que merezca la pena plantearse la sustitución del sistema.
Gastos de mantenimiento ¿Cuáles son los costes de mantenimiento del hardware y
de las licencias de software de apoyo? El hardware antiguo
puede tener costes de mantenimiento más elevados que los
sistemas modernos. El software de soporte puede tener
unos costes de licencia anuales elevados.
Interoperabilidad ¿Hay problemas para interconectar el sistema con otros
sistemas? ¿Pueden utilizarse compiladores, por ejemplo,
con las versiones actuales del sistema operativo? ¿Es
necesaria la emulación de hardware?

30/10/2014 Chapter 9 Software Evolution 94

Factors used in application assessment

Factor Questions
Comprensibilidad ¿Es difícil entender el código fuente del sistema actual? ¿Hasta
qué punto son complejas las estructuras de control que se
utilizan? ¿Las variables tienen nombres significativos que reflejen
su función?
Documentación ¿De qué documentación del sistema se dispone? ¿Es la
documentación completa, coherente y actual?
Datos ¿Existe un modelo de datos explícito para el sistema? ¿En qué
medida se duplican los datos en los distintos archivos? ¿Los
datos utilizados por el sistema están actualizados y son
coherentes?
Rendimiento ¿Es adecuado el rendimiento de la aplicación? ¿Los problemas
de rendimiento tienen un efecto significativo en los usuarios del
sistema?

30/10/2014 Chapter 9 Software Evolution 95

Factors used in application assessment

Factor Questions
Lenguaje de programación ¿Existen compiladores modernos para el lenguaje de
programación utilizado para desarrollar el sistema? ¿Se
sigue utilizando el lenguaje de programación para el
desarrollo de nuevos sistemas?
Gestión de la ¿Se gestionan todas las versiones de todas las partes del
configuración sistema mediante un sistema de gestión de la configuración?
¿Existe una descripción explícita de las versiones de los
componentes que se utilizan en el sistema actual?
Datos de la prueba ¿Existen datos de prueba del sistema? ¿Existe un registro
de las pruebas de regresión realizadas cuando se han
añadido nuevas funciones al sistema?
Competencias del ¿Hay personas capacitadas para mantener la aplicación?
personal ¿Hay personas con experiencia en el sistema?

30/10/2014 Chapter 9 Software Evolution 96

System measurement

 Puede recopilar datos cuantitativos para hacer una

evaluación de la calidad del sistema de aplicación
 El número de solicitudes de cambio del sistema; Cuanto mayor
sea este valor acumulado, menor será la calidad del sistema.
 El número de interfaces de usuario diferentes utilizadas por el
sistema; cuantas más interfaces, más probable es que haya
incoherencias y redundancias en ellas.
 El volumen de datos utilizados por el sistema. A medida que
aumenta el volumen de datos (número de archivos, tamaño de
la base de datos, etc.) procesados por el sistema, también
aumentan las incoherencias y errores en esos datos.
 Limpiar los datos antiguos es un proceso muy costoso y que
lleva mucho tiempo.

30/10/2014 Chapter 9 Software Evolution 97

 Mantenimiento del software

30/10/2014 Chapter 9 Software Evolution 98

Software maintenance

 Modificar un programa después de haberlo puesto en

marcha.
 El término se utiliza sobre todo para modificar software a
medida. Se dice que los productos de software
genéricos evolucionan para crear nuevas versiones.
 El mantenimiento no suele implicar cambios importantes
en la arquitectura del sistema.
 Los cambios se implementan modificando los
componentes existentes y añadiendo nuevos
componentes al sistema.

30/10/2014 Chapter 9 Software Evolution 99

Types of maintenance

 Reparación de fallos
 Modificación de un sistema para arreglar fallos/vulnerabilidades
y corregir deficiencias en la forma de cumplir sus requisitos.
 Adaptación al entorno
 Mantenimiento para adaptar el software a un entorno operativo
diferente
 Modificación de un sistema para que funcione en un entorno
(ordenador, sistema operativo, etc.) distinto al de su
implantación inicial.
 Adición y modificación de funcionalidades
 Modificación del sistema para satisfacer nuevos requisitos.

30/10/2014 Chapter 9 Software Evolution 100

Maintenance effort distribution

Reparación de
averías

Adaptación
medioambiental Adición o
modificación de
funciones

30/10/2014 Chapter 9 Software Evolution 101

Maintenance costs

 Suelen ser superiores a los costes de desarrollo (de 2* a

100* según la aplicación).
 Afectados por factores técnicos y no técnicos.
 Aumenta a medida que se mantiene el software. El
mantenimiento corrompe la estructura del software y
dificulta el mantenimiento posterior.
 Los programas antiguos pueden tener costes de soporte
elevados (lenguajes antiguos, compiladores, etc.).

30/10/2014 Chapter 9 Software Evolution 102

Maintenance costs

 Suele ser más caro añadir nuevas funciones a un

sistema durante el mantenimiento que añadir las
mismas funciones durante el desarrollo.
 Un nuevo equipo tiene que entender los programas que se
mantienen.
 Separar mantenimiento y desarrollo significa que no hay
incentivo para que el equipo de desarrollo escriba software que
se pueda mantener.
 El trabajo de mantenimiento de programas es impopular
• El personal de mantenimiento suele carecer de experiencia y tener
un conocimiento limitado del sector.
 A medida que los programas envejecen, su estructura se
degrada y se hacen más difíciles de cambiar.

30/10/2014 Chapter 9 Software Evolution 103

Maintenance prediction

 La predicción del mantenimiento se ocupa de evaluar

qué partes del sistema pueden causar problemas y tener
elevados costes de mantenimiento.
 La aceptación de los cambios depende de la mantenibilidad de
los componentes afectados por el cambio;
 La aplicación de cambios degrada el sistema y reduce su
mantenibilidad;
 Los costes de mantenimiento dependen del número de cambios
y los costes de cambio dependen de la mantenibilidad.

30/10/2014 Chapter 9 Software Evolution 104

Maintenance prediction

¿Qué partes del sistema

serán más caras de
¿Qué partes del sistema tienen más mantener?
probabilidades de verse afectadas
por las solicitudes de cambio?
Predecir la
mantenibilidad

¿Cuáles serán los costes de

mantenimiento de este sistema
Predecir los Predecir los a lo largo de su vida útil?
cambios del costes de
sistema mantenimiento

¿Cuáles serán los costes de

¿Cuántas solicitudes de mantenimiento de este sistema
cambio pueden durante el próximo año?
esperarse?

30/10/2014 Chapter 9 Software Evolution 105

Change prediction

 Predecir el número de cambios requiere comprender las

relaciones entre un sistema y su entorno.
 Los sistemas estrechamente acoplados requieren
cambios cada vez que se modifica el entorno.
 Los factores que influyen en esta relación son
 Número y complejidad de las interfaces del sistema;
 El número de requisitos inherentemente volátiles del sistema;
 Los procesos empresariales en los que se utiliza el sistema.

30/10/2014 Chapter 9 Software Evolution 106

Complexity metrics

 Las predicciones de mantenibilidad pueden hacerse

evaluando la complejidad de los componentes del
sistema.
 Los estudios han demostrado que la mayor parte del
esfuerzo de mantenimiento se dedica a un número
relativamente pequeño de componentes del sistema.
 La complejidad depende de
 La complejidad de las estructuras de control;
 Complejidad de las estructuras de datos;
 El tamaño de los objetos, métodos (procedimientos) y módulos.

30/10/2014 Chapter 9 Software Evolution 107

Process metrics

 Las métricas de proceso pueden utilizarse para evaluar

la mantenibilidad
 Número de solicitudes de mantenimiento correctivo;
 Tiempo medio necesario para el análisis de impacto;
 Tiempo medio necesario para aplicar una solicitud de cambio;
 Número de solicitudes de cambio pendientes.
 Si alguno de estos parámetros, o todos ellos, aumenta,
puede indicar un deterioro de la mantenibilidad.

30/10/2014 Chapter 9 Software Evolution 108

Software reengineering

 Reestructuración o reescritura parcial o total de un

sistema heredado sin cambiar su funcionalidad.
 Aplicable cuando algunos subsistemas de un sistema
mayor, pero no todos, requieren un mantenimiento
frecuente.
 La reingeniería implica añadir esfuerzos para facilitar su
mantenimiento. El sistema puede reestructurarse y
volver a documentarse.

30/10/2014 Chapter 9 Software Evolution 109

Advantages of reengineering

 Riesgo reducido
 El desarrollo de software nuevo conlleva un alto riesgo. Puede
haber problemas de desarrollo, de personal y de especificación.
 Coste reducido
 El coste de la reingeniería suele ser significativamente menor
que el del desarrollo de software nuevo.

30/10/2014 Chapter 9 Software Evolution 110

The reengineering process

Documentación Reingeniería del Datos

Programa originales
del programa programa
original

Ingeniería
inversa
Ingeniería
Traducción del Modularización inversa
código fuente de programas

Mejora de la
estructura del
programa

Programa Reingeniería de
reestructurado datos

30/10/2014 Chapter 9 Software Evolution 111

Reengineering process activities

 Traducción de código fuente

 Convertir código a un nuevo idioma.
 Ingeniería inversa
 Analizar el programa para comprenderlo;
 Mejora de la estructura del programa
 Reestructurar automáticamente para hacerlo más comprensible;
 Modularización del programa
 Reorganizar la estructura del programa;
 Reingeniería de datos
 Limpiar y reestructurar los datos del sistema.

30/10/2014 Chapter 9 Software Evolution 112

Reengineering approaches

Reestructuración Reestructuración de
automatizada de programas programas y datos

Conversión Reestructuración Reestructuración y cambios

automática del automatizada con cambios arquitectónicos
código fuente manuales

Mayor coste

30/10/2014 Chapter 9 Software Evolution 113

Reengineering cost factors

 La calidad del software que se va a rediseñar.

 El soporte de herramientas disponible para la
reingeniería.
 El alcance de la conversión de datos necesaria.
 La disponibilidad de personal experto en reingeniería.
 Esto puede ser un problema con los sistemas antiguos basados
en tecnología que ya no se utiliza de forma generalizada.

30/10/2014 Chapter 9 Software Evolution 114

Refactoring

 La refactorización es el proceso de introducir mejoras en

un programa para ralentizar su degradación por el
cambio.
 Se puede considerar la refactorización como un
"mantenimiento preventivo" que reduce los problemas
de futuros cambios.
 La refactorización consiste en modificar un programa
para mejorar su estructura, reducir su complejidad o
facilitar su comprensión.
 Cuando se refactoriza un programa, no hay que añadir
funcionalidad, sino concentrarse en mejorar el
programa.
30/10/2014 Chapter 9 Software Evolution 115
Refactoring and reengineering

 La reingeniería tiene lugar después de que un sistema

se haya mantenido durante algún tiempo y los costes de
mantenimiento estén aumentando. Se utilizan
herramientas automatizadas para procesar y rediseñar
un sistema heredado con el fin de crear un nuevo
sistema más fácil de mantener.
 La refactorización es un proceso continuo de mejora a lo
largo del proceso de desarrollo y evolución. Su objetivo
es evitar la degradación de la estructura y el código que
aumenta los costes y las dificultades de mantenimiento
de un sistema.

30/10/2014 Chapter 9 Software Evolution 116

‘Bad smells’ in program code

 Código duplicado
 El mismo código o uno muy similar puede incluirse en distintos
lugares de un programa. Esto puede eliminarse e implementarse
como un único método o función que se llame cuando sea
necesario.
 Métodos largos
 Si un método es demasiado largo, debe rediseñarse como varios
métodos más cortos.
 Sentencias switch (case)
 Suelen estar duplicadas, ya que el cambio depende del tipo de
valor. Las sentencias switch pueden estar dispersas por todo el
programa. En los lenguajes orientados a objetos, a menudo se
puede utilizar el polimorfismo para lograr lo mismo.
30/10/2014 Chapter 9 Software Evolution 117
‘Bad smells’ in program code

 Agrupación de datos
 La aglomeración de datos se produce cuando el mismo grupo
de datos (campos en clases, parámetros en métodos) se repite
en varios lugares de un programa. A menudo pueden sustituirse
por un objeto que encapsule todos los datos.
 Generalidad especulativa
 Se produce cuando los desarrolladores incluyen generalidades
en un programa por si son necesarias en el futuro. A menudo
puede eliminarse.

30/10/2014 Chapter 9 Software Evolution 118

Key points

 El desarrollo y la evolución del software pueden considerarse un

proceso integrado e iterativo que puede representarse mediante
un modelo en espiral.
 En el caso de los sistemas personalizados, los costes de
mantenimiento del software suelen ser superiores a los de
desarrollo.
 El proceso de evolución del software está impulsado por las
solicitudes de cambios e incluye el análisis del impacto de los
cambios, la planificación de las versiones y la implementación de
los cambios.
 Los sistemas heredados son sistemas de software antiguos,
desarrollados con tecnologías de software y hardware obsoletas,
que siguen siendo útiles para una empresa.
30/10/2014 Chapter 9 Software Evolution 119
Key points

 A menudo resulta más barato y menos arriesgado

mantener un sistema heredado que desarrollar un
sistema de sustitución con tecnología moderna.
 El valor empresarial de un sistema heredado y la calidad
de la aplicación deben evaluarse para ayudar a decidir si
un sistema debe sustituirse, transformarse o
mantenerse.
 Hay tres tipos de mantenimiento de software: corrección
de errores, modificación del software para que funcione
en un nuevo entorno e implantación de requisitos
nuevos o modificados.

30/10/2014 Chapter 9 Software Evolution 120

Key points

 La reingeniería de software consiste en reestructurar y

documentar el software para que sea más fácil de
entender y modificar.
 La refactorización, es decir, la introducción de cambios
en el programa para preservar su funcionalidad, es una
forma de mantenimiento preventivo.

30/10/2014 Chapter 9 Software Evolution 121