You are on page 1of 57

Capitulo 9 – Evolución del Software

Ciclo de conferencia 1

Capitulo 9 Evolución del Software 1

Temas tratados

Procesos de Evolución
 Procesos de cambio para los sistemas del software
Dinámica de evolución del programa
 Entender la evolución del software
Mantenimiento del software
 Realizar cambios en los sistemas de software de operación
Gestión de sistemas heredados
 Toma de decisiones sobre el cambio de software

Capitulo 9 Evolución del Software 2

Cambio del software

Cambio del software es inevitable
 Nuevos requerimientos surgen cuando se utiliza el software;
 El entorno empresarial cambia;
 Los errores deben ser reparados;
 Los nuevos ordenadores y equipo se agregan al sistema;
 El rendimiento o la confiabilidad del sistema pueden tener que
ser mejorados.
Un problema clave para todas las organizaciones es
poner en práctica y gestionar el cambio en los sistemas
de software existentes.

Capitulo 9 Evolución del Software 3

Importancia de la evolución

Las organizaciones tienen grandes inversiones en sus
sistemas de software - son activos críticos de negocio.
Para mantener el valor de estos activos a la empresa,
deben ser cambiados y actualizados.
La mayor parte del presupuesto de software en las
grandes empresas se dedica al cambio y evolución de
software existentes en lugar de desarrollar un nuevo
software.

Capitulo 9 Evolución del Software 4

Un modelo espiral del desarrollo y la evolución

Capitulo 9 Evolución del Software 5

Evolución y mantenimiento Capitulo 9 Evolución del Software 6 .

correcciones y cambios de errores operacionales para reflejar los cambios en el entorno del software. No se agrega ninguna funcionalidad nueva. pero no se realizan más cambios en este. Prestación de servicios  En esta etapa. el software sigue siendo útil. Capitulo 9 Evolución del Software 7 . pero los únicos cambios realizados son los necesarios para mantenerlo es decir.Evolución y mantenimiento Evolución  Es la etapa en el ciclo de vida de un software en la cual este está en uso operacional y evoluciona cada vez que nuevos requerimientos son propuestos e implementados en el sistema. Eliminación  El software se puede utilizar todavía.

 Deberían ser vinculadas con los componentes que son afectados por el cambio. Capitulo 9 Evolución del Software 8 .Procesos de evolución Procesos de evolución del software dependen de  El tipo de software que está siendo mantenido.  Las habilidades y la experiencia de las personas involucradas. La identificación de cambios y evolución continúa durante toda la vida del sistema.  Los procesos de desarrollo utilizados. Las propuestas de cambio son el motor de la evolución del sistema. permitiendo así que el coste e impacto puedan ser estimados.

Identificación de cambios y proceso de evolución Capitulo 9 Evolución del Software 9 .

El proceso de evolución del software Capitulo 9 Evolución del Software 10 .

Implementación de cambios Capitulo 9 Evolución del Software 11 .

implementadas y probadas. usted tiene que entender cómo se estructura el programa. Una diferencia fundamental es que la primera etapa de implementación del cambio puede implicar la comprensión del programa. cómo se ofrece la funcionalidad y la forma en que el cambio propuesto podría afectar el programa. Durante la fase de comprensión del programa. sobre todo si los desarrolladores de sistemas originales no son responsables de la implementación del cambio. donde las revisiones del sistema son diseñadas.Implementación de cambios La iteración del proceso de desarrollo. Capitulo 9 Evolución del Software 12 .

Las solicitudes de cambio de urgencia Cambios urgentes pueden tener que ser ejecutados sin pasar por todas las etapas del proceso de ingeniería de software  Si un fallo grave del sistema tiene que ser reparado para permitir que el funcionamiento normal continúe. el lanzamiento de un producto de la competencia).  Si los cambios en el entorno del sistema (por ejemplo. una actualización del sistema operativo) tienen efectos inesperados. Capitulo 9 Evolución del Software 13 .  Si hay cambios de negocio que requieren una respuesta muy rápida (por ejemplo.

El proceso de reparación de emergencia Capitulo 9 Evolución del Software 14 .

Métodos ágiles y evolución Los métodos ágiles se basan en desarrollo incremental de modo que la transición desde el desarrollo hasta la evolución es fluida. Las pruebas de regresión automatizadas son particularmente valiosas cuando se realizan cambios en un sistema. Capitulo 9 Evolución del Software 15 .  La evolución es simplemente una continuación del proceso de desarrollo basado en las versiones del sistema frecuentes. Los cambios pueden ser expresados como casos de uso adicionales.

pero el equipo evolución prefieren utilizar métodos ágiles. Cuando un enfoque basado en el plan se ha utilizado para el desarrollo.  El equipo de la evolución puede esperar una documentación detallada para apoyar la evolución y esto no se produce en procesos ágiles. Capitulo 9 Evolución del Software 16 .Problemas de traspaso Cuando el equipo de desarrollo ha utilizado un enfoque ágil.  El equipo de la evolución puede tener que empezar desde cero el desarrollo de pruebas automatizadas y el código en el sistema puede no haber sido reprogramado y simplificado como se espera en el desarrollo ágil. pero el equipo de la evolución no está familiarizado con los métodos ágiles y prefieren un enfoque basado en el plan.

Después de varios estudios empíricos más importantes. Capitulo 9 Evolución del Software 17 .  No está claro si estas son aplicables a otros tipos de sistema de software. Son aplicables a los grandes sistemas desarrollados por las grandes organizaciones. Hay observaciones sensatas en vez de leyes. Lehman y Belady propusieron que había una serie de "leyes" que se aplica a todos los sistemas a medida que evolucionaban.Dinámica de evolución del programa Dinámica de evolución del programa es el estudio de los procesos de cambio del sistema.

un sistema de entrega no cumplirá con sus requisitos! Los sistemas están estrechamente vinculados con su entorno. Capitulo 9 Evolución del Software 18 . Cuando un sistema se instala en un entorno cambia ese ambiente y por lo tanto. Los sistemas deben ser cambiados si van a seguir siendo útiles en un entorno.El cambio es inevitable Los requisitos del sistema pueden cambiar mientras el sistema se está desarrollando porque el entorno está cambiando. cambia los requisitos del sistema. Por lo tanto.

Leyes de Lehman Ley Descripción Cambio continuo Un programa que se utiliza en un ambiente del mundo real debe necesariamente cambiar. El aumento de la Como un programa en evolución cambia. Atributos programa del sistema. y el número de errores notificados es aproximadamente invariante para cada versión del sistema. Recursos adicionales deben ser dedicados a la preservación y la simplificación de la estructura. tales como el tamaño. Capitulo 9 Evolución del Software 19 . o de lo contrario ser progresivamente menos útil en ese entorno. su estructura tiende a ser complejidad más compleja. Estabilidad Durante toda la vida de un programa. el tiempo entre los lanzamientos. Gran evolución del Evolución del programa es un proceso de auto-regulación. su ritmo de desarrollo es organizacional aproximadamente constante e independiente de los recursos dedicados al desarrollo del sistema.

Leyes de Lehman Ley Descripción Conservación de Durante la vida útil de un sistema. Disminución de la calidad La calidad de los sistemas se reducirá a menos que se modifiquen para reflejar los cambios en su entorno operativo. Capitulo 9 Evolución del Software 20 . el cambio incremental en familiaridad cada versión es aproximadamente constante. El continuo crecimiento La funcionalidad ofrecida por los sistemas tiene que aumentar continuamente para mantener la satisfacción del usuario. Sistema de Los procesos de evolución incorporan sistemas de retroalimentación retroalimentación de bucles y agentes múltiples y hay que tratarlos como sistemas de retroalimentación para lograr una mejora significativa del producto.

 Sistemas de tamaño mediano.  Las organizaciones pequeñas.Aplicabilidad de las leyes de Lehman Las leyes de Lehman parecen ser aplicables en general a grandes y adaptados sistemas desarrollados por las grandes organizaciones.  Los sistemas que incorporan un número significativo de componentes COTS (Commercial Off-The-Shelf).  Confirmado a principios del 2000 por obra de Lehman en el proyecto FEAST. No está claro cómo deben ser modificadas para  Productos de software empaquetado. Capitulo 9 Evolución del Software 21 .

Las leyes de Lehman. los costos de mantenimiento de software suelen superar los costos de desarrollo de software. como la noción de que el cambio es continuo. Para los sistemas personalizados. Capitulo 9 Evolución del Software 22 .Puntos clave El desarrollo de software y la evolución pueden ser considerados como un proceso integrado e iterativo que se puede representar mediante un modelo de espiral. describen una serie de ideas derivadas de los estudios a largo plazo de la evolución del sistema. El proceso de evolución del software es impulsado por las solicitudes de cambios e incluye el análisis del impacto del cambio. la planificación de la liberación y la implementación del cambio.

Capitulo 9 – Evolución del Software Ciclo de conferencia 2 Capitulo 9 Evolución del Software 23 .

El mantenimiento de software Es la modificación de un programa después de que se ha puesto en uso. Productos de software genéricos deben evolucionar para crear nuevas versiones. Mantenimiento normalmente no implica grandes cambios en la arquitectura del sistema. El término se utiliza sobre todo para cambiar el software a medida. Los cambios se implementan mediante la modificación de los componentes existentes y la adición de nuevos componentes al sistema. Capitulo 9 Evolución del Software 24 .

Mantenimiento para adaptar el software a un entorno operativo diferente  El cambio de un sistema para que opere en un entorno diferente (ordenador. Capitulo 9 Evolución del Software 25 .Tipos de mantenimiento Mantenimiento para reparar los fallos del software  El cambio de un sistema para corregir las deficiencias en la forma que responde a sus exigencias. Mantenimiento para agregar o modificar la funcionalidad del sistema  Modificar el sistema para satisfacer las nuevas necesidades. sistema operativo. etc) de su aplicación inicial.

Distribución del esfuerzo de mantenimiento Capitulo 9 Evolución del Software 26 .

Afectados por ambos factores técnicos y no técnicos. lenguajes antiguos.Costos de mantenimiento Por lo general. etc. compiladores. Software antiguo puede tener altos costos de mantenimiento (Por ejemplo. Capitulo 9 Evolución del Software 27 . mayor que los costos de desarrollo (2 * al 100 *. dependiendo de la aplicación).). Aumenta a medida que el software se mantiene. Mantenimiento corrompe la estructura del software así hace aún más difícil el mantenimiento.

Los costos de desarrollo y mantenimiento Capitulo 9 Evolución del Software 28 .

Responsabilidad contractual  Los desarrolladores de un sistema no pueden tener ninguna responsabilidad contractual de mantenimiento por lo que no hay ningún incentivo para diseñar el cambio futuro. Capitulo 9 Evolución del Software 29 .Factores de costo de mantenimiento La estabilidad del equipo  Los costos de mantenimiento se reducen si el mismo personal está involucrado con estos durante algún tiempo. su estructura es degradada y se vuelven más difíciles de entender y cambiar. La edad y la estructura del programa  A medida que los programas envejecen. Habilidades del personal  El personal de mantenimiento son a menudo sin experiencia y con conocimiento limitado del dominio.

Predicción de mantenimiento Predicción de mantenimiento se ocupa de la evaluación de las partes del sistema que pueden causar problemas y tienen altos costos de mantenimiento  Cambiar la aceptación depende de la capacidad de mantenimiento de los componentes afectados por el cambio.  Los costos de mantenimiento dependen del número de cambios y los costos del cambio dependerán del mantenimiento. Capitulo 9 Evolución del Software 30 .  Implementar cambios degrada el sistema y reduce su mantenimiento.

Predicción de mantenimiento Capitulo 9 Evolución del Software 31 .

Factores que influyen en esta relación son  Número y complejidad de las interfaces del sistema.Predicción de cambios Predecir el número de cambios requiere una comprensión de las relaciones entre un sistema y su entorno.  Número de requisitos del sistema inherentemente volátiles.  Los procesos de negocio donde se utiliza el sistema. Sistemas fuertemente acoplados requieren cambios cada vez que se cambia el entorno. Capitulo 9 Evolución del Software 32 .

Métricas de complejidad Las predicciones de mantenimiento se pueden realizar mediante la evaluación de la complejidad de los componentes del sistema. Capitulo 9 Evolución del Software 33 .  La complejidad de las estructuras de datos. La complejidad depende  La complejidad de las estructuras de control. Los estudios han demostrado que el mayor esfuerzo de mantenimiento se gasta en un número relativamente pequeño de componentes del sistema. método (procedimiento) y el tamaño del módulo.  Objeto.

 Promedio del tiempo requerido para el análisis de impacto. Si alguno de estos o todos incrementan.  Número de solicitudes de cambio pendientes. Capitulo 9 Evolución del Software 34 .Métricas de complejidad Las métricas de proceso pueden utilizarse para evaluar la mantenibilidad  Número de solicitudes para el mantenimiento correctivo.  Tiempo medio necesario para implementar una solicitud de cambio. esto puede indicar un descenso en el mantenimiento.

El sistema puede ser re-estructurado y re-documentado.Sistema de reingeniería Re-estructuración o re-escribir todo o parte de un sistema heredado sin cambiar su funcionalidad. Aplicable cuando algunos pero no todos los subsistemas de un sistema más grande requieren mantenimiento frecuente. Reingeniería involucra la adición de esfuerzo para hacer que sean más fáciles de mantener. Capitulo 9 Evolución del Software 35 .

Ventajas de la reingeniería Riesgo reducido  Hay un alto riesgo en el desarrollo de software nuevo. Costo reducido  El costo de la reingeniería es a menudo mucho menos que los costos de desarrollo de un nuevo software. Capitulo 9 Evolución del Software 36 . Puede haber problemas de desarrollo. problemas de personal y problemas de especificación.

El proceso de reingeniería Capitulo 9 Evolución del Software 37 .

Reingeniería de datos  Limpieza y reestructurar los datos del sistema. Ingeniería inversa  Analizar el programa para entenderlo.Actividades del proceso de reingeniería Traducción del código fuente  Convertir código a un nuevo idioma. Capitulo 9 Evolución del Software 38 . Modularización de programa  Reorganizar la estructura del programa. Mejora de la estructura del programa  Reestructurar automáticamente para mejorar la comprensibilidad.

Enfoques de la reingeniería Capitulo 9 Evolución del Software 39 .

Capitulo 9 Evolución del Software 40 .  Esto puede ser un problema con los antiguos sistemas basados en la tecnología que ya no se utiliza ampliamente.Factores del costo de reingeniería La calidad del software a ser rediseñado. El apoyo disponible de la herramienta para la reingeniería. El alcance de la conversión de datos que se requiere. La disponibilidad de personal especializado para la reingeniería.

La refactorización trata de modificar un programa para mejorar su estructura. reducir su complejidad o que sea más fácil de entender.El mantenimiento preventivo de refactorización La refactorización es el proceso de hacer mejoras a un programa para reducir la velocidad de degradación a través del cambio. Capitulo 9 Evolución del Software 41 . Usted puede pensar en la refactorización como 'mantenimiento preventivo' que reduce los problemas del cambio futuro. no debes agregar funcionalidad sino más bien concentrarte en la mejora del programa. Cuando refactorizas un programa.

Utiliza las herramientas automatizadas para procesar y re-diseñar un sistema heredado para crear un nuevo sistema que sea más fácil de mantener. Se tiene la intención de evitar la degradación de la estructura y el código que aumenta los costos y las dificultades de mantenimiento de un sistema. La refactorización es un proceso continuo de mejora en todo el proceso de desarrollo y evolución.Refactorización y reingeniería Re-ingeniería tiene lugar después de que un sistema ha sido mantenido por algún tiempo y los costos de mantenimiento están aumentando. Capitulo 9 Evolución del Software 42 .

En lenguajes orientados a objetos.  Métodos largos  Si un método es demasiado largo. Esto se puede quitar e implementar como un único método o función que se llama según se requiera. donde el switch depende del tipo de un valor. debe ser rediseñado como un número de métodos más cortos."Malos olores" en el código del programa  Duplicar código  El mismo o muy similar código puede ser incluido en diferentes lugares en un programa. Las sentencias switch pueden estar dispersas en torno a un programa. a menudo se puede utilizar el polimorfismo para lograr lo mismo. Capitulo 9 Evolución del Software 43 .  Declaraciones switch(case)  Estos a menudo implican la duplicación.

parámetros en los métodos) se repiten en varios lugares en un programa. Esto puede ser a menudo simplemente retirado. Capitulo 9 Evolución del Software 44 . Estos a menudo pueden ser reemplazados con un objeto que encapsula todos los datos. Generalidad especulativa  Esto ocurre cuando los desarrolladores incluyen generalidad en un programa en caso de que sea necesario en el futuro."Malos olores" en el código del programa Agrupamiento de datos  Se producen acumulaciones de datos cuando el mismo grupo de elementos de datos (campos en clases.

Capitulo 9 Evolución del Software 45 . La estrategia elegida dependerá de la calidad del sistema y de su valor para el negocio.  Transformar el sistema por reingeniería para mejorar su capacidad de mantenimiento.Gestión de sistemas heredados Las organizaciones que se basan en sistemas heredados deben elegir una estrategia para la evolución de estos sistemas  Desechar el sistema por completo y modifica los procesos de negocio de manera que ya no es necesario.  Continuar el mantenimiento del sistema.  Reemplazar el sistema con un nuevo sistema.

Un ejemplo de una evaluación de un sistema legado Capitulo 9 Evolución del Software 46 .

bajo valor comercial  Estos sistemas deben ser desechados. alto valor comercial  Estos hacen una contribución importante de negocios. Alta calidad. Baja calidad. pero son caros de mantener. Alta calidad. Puede ser rediseñado por reingeniería o reemplazado si un sistema adecuado esta disponible. bajo valor comercial  Reemplazar con COTS.Categorías del sistema heredado Baja calidad. desechar por completo o mantener. alto valor comercial  Continuar en la operación utilizando el mantenimiento normal del sistema. Capitulo 9 Evolución del Software 47 .

Evaluación de valor de negocios La evaluación debe tomar en cuenta diferentes puntos de vista  Los usuarios finales del sistema.  Los administradores de TI. Capitulo 9 Evolución del Software 48 .  Los gerentes de línea.  Los altos directivos.  Los clientes de negocios. Entrevistar a los diferentes interesados y recopilar los resultados.

Capitulo 9 Evolución del Software 49 . Los procesos de negocio que son soportados  Un sistema puede tener un bajo valor comercial si se impone el uso de procesos de negocio ineficientes. estos pueden tener un bajo valor comercial. Las salidas del sistema  Si la empresa depende de los resultados del sistema.Problemas en la evaluación del valor de negocio El uso del sistema  Si los sistemas se utilizan solamente de vez en cuando o por un pequeño número de personas. La fiabilidad del sistema  Si un sistema no es confiable y los problemas afectan directamente a los clientes comerciales. entonces el sistema tiene un alto valor comercial. el sistema tiene un bajo valor comercial.

Evaluación de la calidad del sistema Evaluación de procesos de negocio  ¿En qué medida el proceso de negocio apoya los objetivos actuales de la empresa? Evaluación del entorno  ¿Qué tan efectivo es el entorno del sistema y lo caro que es para mantener? Evaluación de la solicitud  ¿Cuál es la calidad del sistema de software de aplicación? Capitulo 9 Evolución del Software 50 .

un sistema de pedidos de viaje puede tener un bajo valor comercial debido al uso generalizado de la ordenación basada en la web.Evaluación de procesos de negocio Utilizar un enfoque de perspectiva orientada y buscar respuestas de los interesados en el sistema  ¿Existe un modelo de proceso definido y es seguido?  ¿Las diferentes partes de la organización utilizan diferentes procesos para la misma función?  ¿Cómo se ha adaptado el proceso?  ¿Cuáles son las relaciones con otros procesos de negocio y son éstos necesarios?  ¿El proceso recibe apoyo eficaz de la aplicación de software legado? Ejemplo . Capitulo 9 Evolución del Software 51 .

Todavía puede funcionar correctamente. pero podrían existir beneficios significantes de negocios y economía al moverse a un sistema más moderno. más obsoleto es. no hay otra persona para mantener los sistemas? Porcentaje de ¿El hardware tiene una alta tasa de fallas reportadas? ¿El software fallas de soporte deja de funcionar y fuerza un reinicio del sistema? Edad ¿Qué edad tiene el hardware y el software? Cuanto mayor sea el hardware y el software de soporte. Rendimiento ¿El rendimiento del sistema es adecuado? ¿Los problemas de rendimiento tienen un efecto significativo sobre los usuarios del sistema? Capitulo 9 Evolución del Software 52 .Los factores utilizados en la evaluación del entorno Factor Preguntas Estabilidad del El proveedor aún existe? Es el proveedor financieramente estable y proveedor es probable que continúe en la existencia? Si el proveedor ya no está en el negocio.

ser usados en las versiones actuales del sistema operativo? ¿Se requiere de emulación de hardware? Capitulo 9 Evolución del Software 53 . Interoperabilidad ¿Hay problemas de interconexión del sistema con otros sistemas? ¿Pueden los compiladores. por ejemplo.Los factores utilizados en la evaluación del entorno Factor Preguntas Requisitos de soporte ¿Qué soporte local es requerido por el hardware y el software? Si hay altos costos asociados con este soporte. Los costos de ¿Cuáles son los costos de mantenimiento de hardware y de mantenimiento las licencias de software de soporte? Hardware antiguo puede tener costos de mantenimiento mayores a los de los sistemas modernos. puede valer la pena considerar el reemplazo del sistema. Software de soporte puede tener altos costos de licencias anuales.

Los factores utilizados en la evaluación de la aplicación Factor Preguntas Comprensibilidad ¿Cuán difícil es entender el código fuente del sistema actual? ¿Qué tan complejas son las estructuras de control que se utilizan? ¿Las variables tienen nombres significativos que reflejan su función? Documentación ¿Qué documentación del sistema está disponible? ¿La documentación es completa. consistente y actual? Datos ¿Existe un modelo de datos explícito para el sistema? ¿En qué medida se duplican los datos a través de los archivos? ¿Los datos utilizados por el sistema son actualizados y consistentes? Rendimiento ¿El rendimiento de la aplicación es adecuado? ¿Los problemas de rendimiento tienen un efecto significativo sobre los usuarios del sistema? Capítulo 9 Evolución del software 54 .

Los factores utilizados en la evaluación de la aplicación Factor Preguntas Lenguaje de ¿Los compiladores modernos están disponibles para el programación lenguaje de programación utilizado para desarrollar el sistema? ¿El lenguaje de programación todavía se utiliza para el desarrollo de nuevos sistemas? Gestión de la ¿Están todas las versiones de todas las partes del sistema configuración gestionadas por un sistema de gestión de la configuración? ¿Hay una descripción explícita de las versiones de los componentes que se utilizan en el sistema actual? Los datos de prueba ¿Existen datos de prueba para el sistema? ¿Hay un registro de pruebas de regresión realizadas cuando se han añadido nuevas características al sistema? Habilidades del personal ¿Hay personas disponibles que tienen las habilidades para mantener la aplicación? ¿Hay personas disponibles que no tienen experiencia con el sistema? Capítulo 9 Evolución del software 55 .

 El volumen de los datos utilizados por el sistema. Capítulo 9 Evolución del software 56 .  El número de diferentes interfaces de usuario utilizados por el sistema.Medición del sistema Se pueden 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.

y la implementación de requisitos nuevos o modificados. la modificación de software para trabajar en un entorno nuevo. La reingeniería del software tiene que ver con la reestructuración y el redocumentado del software para que sea más fácil de entender y cambiar. transformado o mantenido. El valor de negocio de un sistema heredado y la calidad de la aplicación se deben evaluar para ayudar a decidir si un sistema debe ser cambiado. Capítulo 9 Evolución del software 57 .Puntos clave Hay 3 tipos de mantenimiento de software. La refactorización hace cambios en el programa que conservan la funcionalidad. es una forma de mantenimiento preventivo. la corrección de errores.