Capitulo 9 –Evolución del Software · del sistema. §Deberían ser vinculadas con los componentes que son afectados por el cambio, permitiendo así que el coste e impacto puedan

Capitulo 9 – Evolución del Software

Ciclo de conferencia 1

1Capitulo 9 Evolución del Software

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


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.


Importancia de la evolución

²Las organizaciones tienen grandes inversiones en sussistemas 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 lasgrandes empresas se dedica al cambio y evolución desoftware existentes en lugar de desarrollar un nuevosoftware.


Un modelo espiral del desarrollo y la evolución


Evolución y mantenimiento


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 nuevosrequerimientos son propuestos e implementados en el sistema.

²Prestación de servicios§En esta etapa, el software sigue siendo útil, pero los únicos cambios realizados son los necesarios para mantenerlo es decir, correcciones y cambios de errores operacionales para reflejar los cambios en el entorno del software. No se agrega ninguna funcionalidad nueva.

²Eliminación§El software se puede utilizar todavía, pero no se realizan más cambios en este.


Procesos de evolución

²Procesos de evolución del software dependen de§El tipo de software que está siendo mantenido; §Los procesos de desarrollo utilizados; §Las habilidades y la experiencia de las personas involucradas.

²Las propuestas de cambio son el motor de la evolución del sistema.

§Deberían ser vinculadas con los componentes que son afectados por el cambio, permitiendo así que el coste e impacto puedan ser estimados.

²La identificación de cambios y evolución continúa durante toda la vida del sistema.


Identificación de cambios y proceso de evolución


El proceso de evolución del software


Implementación de cambios


Implementación de cambios

²La iteración del proceso de desarrollo, donde lasrevisiones del sistema son diseñadas, implementadas yprobadas.²Una diferencia fundamental es que la primera etapa deimplementación del cambio puede implicar la comprensióndel programa, sobre todo si los desarrolladores desistemas originales no son responsables de laimplementación del cambio.²Durante la fase de comprensión del programa, ustedtiene que entender cómo se estructura el programa, cómose ofrece la funcionalidad y la forma en que el cambiopropuesto podría afectar el programa.


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 parapermitir que el funcionamiento normal continúe;§Si los cambios en el entorno del sistema (por ejemplo, unaactualización del sistema operativo) tienen efectos inesperados;§Si hay cambios de negocio que requieren una respuesta muyrápida (por ejemplo, el lanzamiento de un producto de lacompetencia).


El proceso de reparación de emergencia


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.

§La evolución es simplemente una continuación del proceso de desarrollo basado en las versiones del sistema frecuentes.

²Las pruebas de regresión automatizadas sonparticularmente valiosas cuando se realizan cambios en unsistema.²Los cambios pueden ser expresados como casos de usoadicionales.


Problemas de traspaso

²Cuando el equipo de desarrollo ha utilizado un enfoque ágil, pero el equipo de la evolución no está familiarizado con los métodos ágiles y prefieren un enfoque basado en el plan.

§El equipo de la evolución puede esperar una documentacióndetallada para apoyar la evolución y esto no se produce en procesoságiles.

²Cuando un enfoque basado en el plan se ha utilizado para el desarrollo, pero el equipo evolución prefieren utilizar métodos ágiles.

§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.


²Dinámica de evolución del programa es el estudio de los procesos de cambio del sistema. ²Después de varios estudios empíricos más importantes,Lehman y Belady propusieron que había una serie de"leyes" que se aplica a todos los sistemas a medida queevolucionaban.²Hay observaciones sensatas en vez de leyes. Son aplicables a los grandes sistemas desarrollados por las grandes organizaciones.

§No está claro si estas son aplicables a otros tipos de sistema de software.

Dinámica de evolución del programa


²Los requisitos del sistema pueden cambiar mientras elsistema se está desarrollando porque el entorno estácambiando. Por lo tanto, un sistema de entrega nocumplirá con sus requisitos!²Los sistemas están estrechamente vinculados con suentorno. Cuando un sistema se instala en un entornocambia ese ambiente y por lo tanto, cambia los requisitosdel sistema.²Los sistemas deben ser cambiados si van a seguirsiendo útiles en un entorno.

El cambio es inevitable


Leyes de Lehman

Ley Descripción

Cambio continuo Un programa que se utiliza en un ambiente del mundo real debe necesariamente cambiar, o de lo contrario ser progresivamente menos útil en ese entorno.

El aumento de la complejidad

Como un programa en evolución cambia, su estructura tiende a ser más compleja. Recursos adicionales deben ser dedicados a la preservación y la simplificación de la estructura.

Gran evolución del programa

Evolución del programa es un proceso de auto-regulación. Atributos del sistema, tales como el tamaño, el tiempo entre los lanzamientos, y el número de errores notificados es aproximadamente invariante para cada versión del sistema.

Estabilidad organizacional

Durante toda la vida de un programa, su ritmo de desarrollo es aproximadamente constante e independiente de los recursos dedicados al desarrollo del sistema.


Leyes de Lehman

Ley DescripciónConservación de familiaridad

Durante la vida útil de un sistema, el cambio incremental en 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.

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.

Sistema de retroalimentación

Los procesos de evolución incorporan sistemas de retroalimentación de bucles y agentes múltiples y hay que tratarlos como sistemas de retroalimentación para lograr una mejora significativa del producto.


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.

§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; §Los sistemas que incorporan un número significativo de componentes COTS (Commercial Off-The-Shelf); §Las organizaciones pequeñas; §Sistemas de tamaño mediano.


Puntos clave

²El desarrollo de software y la evolución pueden ser consideradoscomo un proceso integrado e iterativo que se puede representarmediante un modelo de espiral.²Para los sistemas personalizados, los costos de mantenimiento desoftware suelen superar los costos de desarrollo de software.²El proceso de evolución del software es impulsado por las solicitudesde cambios e incluye el análisis del impacto del cambio, la planificaciónde la liberación y la implementación del cambio.²Las leyes de Lehman, como la noción de que el cambio es continuo,describen una serie de ideas derivadas de los estudios a largo plazode la evolución del sistema.


Capitulo 9 – Evolución del Software

Ciclo de conferencia 2


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

El mantenimiento de software


²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 adaptar el software a un entorno operativo diferente

§El cambio de un sistema para que opere en un entornodiferente (ordenador, sistema operativo, etc) de su aplicacióninicial.

²Mantenimiento para agregar o modificar la funcionalidad del sistema

§Modificar el sistema para satisfacer las nuevas necesidades.

Tipos de mantenimiento


Distribución del esfuerzo de mantenimiento


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

Costos de mantenimiento


Los costos de desarrollo y mantenimiento


²La estabilidad del equipo§Los costos de mantenimiento se reducen si el mismo personal está involucrado con estos durante algún tiempo.

²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.

²Habilidades del personal§El personal de mantenimiento son a menudo sin experiencia y con conocimiento limitado del dominio.

²La edad y la estructura del programa §A medida que los programas envejecen, su estructura es degradada y se vuelven más difíciles de entender y cambiar.

Factores de costo de mantenimiento


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; §Implementar cambios degrada el sistema y reduce su mantenimiento; §Los costos de mantenimiento dependen del número de cambios y los costos del cambio dependerán del mantenimiento.


Predicción de mantenimiento


Predicción de cambios

²Predecir el número de cambios requiere unacomprensión de las relaciones entre un sistema y suentorno.²Sistemas fuertemente acoplados requieren cambios cada vez que se cambia el entorno.²Factores que influyen en esta relación son

§Número y complejidad de las interfaces del sistema; §Número de requisitos del sistema inherentemente volátiles; §Los procesos de negocio donde se utiliza el sistema.


Métricas de complejidad

²Las predicciones de mantenimiento se pueden realizar mediante la evaluación de la complejidad de los componentes del sistema. ²Los estudios han demostrado que el mayor esfuerzo de mantenimiento se gasta en un número relativamente pequeño de componentes del sistema. ²La complejidad depende

§La complejidad de las estructuras de control; §La complejidad de las estructuras de datos; §Objeto, método (procedimiento) y el tamaño del módulo.


Métricas de complejidad

²Las métricas de proceso pueden utilizarse para evaluar la mantenibilidad

§Número de solicitudes para el mantenimiento correctivo;§Promedio del tiempo requerido para el análisis de impacto; §Tiempo medio necesario para implementar una solicitud de cambio; §Número de solicitudes de cambio pendientes.

²Si alguno de estos o todos incrementan, esto puede indicar un descenso en el mantenimiento.


Sistema de reingeniería

²Re-estructuración o re-escribir todo o parte de unsistema heredado sin cambiar su funcionalidad.²Aplicable cuando algunos pero no todos lossubsistemas de un sistema más grande requierenmantenimiento frecuente.²Reingeniería involucra la adición de esfuerzo para hacer que sean más fáciles de mantener. El sistema puede ser re-estructurado y re-documentado.


Ventajas de la reingeniería

²Riesgo reducido§Hay un alto riesgo en el desarrollo de software nuevo. Puedehaber problemas de desarrollo, problemas de personal yproblemas de especificación.

²Costo reducido§El costo de la reingeniería es a menudo mucho menos que los costos de desarrollo de un nuevo software.


El proceso de reingeniería


Actividades del proceso de reingeniería

²Traducción del código fuente§Convertir código a un nuevo idioma.

²Ingeniería inversa§Analizar el programa para entenderlo;

²Mejora de la estructura del programa§Reestructurar automáticamente para mejorar la comprensibilidad;

²Modularización de programa§Reorganizar la estructura del programa;

²Reingeniería de datos§Limpieza y reestructurar los datos del sistema.


Enfoques de la reingeniería


Factores del costo de reingeniería

²La calidad del software a ser rediseñado.²El apoyo disponible de la herramienta para lareingeniería.²El alcance de la conversión de datos que se requiere.²La disponibilidad de personal especializado para la reingeniería.

§Esto puede ser un problema con los antiguos sistemas basados en la tecnología que ya no se utiliza ampliamente.


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. ²Usted puede pensar en la refactorización como'mantenimiento preventivo' que reduce los problemas del cambiofuturo.²La refactorización trata de modificar un programa paramejorar su estructura, reducir su complejidad o que sea másfácil de entender.²Cuando refactorizas un programa, no debes agregar funcionalidad sino más bien concentrarte en la mejora del programa.


Refactorización y reingeniería

²Re-ingeniería tiene lugar después de que un sistema hasido mantenido por algún tiempo y los costos demantenimiento están aumentando. Utiliza las herramientasautomatizadas para procesar y re-diseñar un sistemaheredado para crear un nuevo sistema que sea más fácilde mantener.²La refactorización es un proceso continuo de mejora entodo el proceso de desarrollo y evolución. Se tiene laintención de evitar la degradación de la estructura y elcódigo que aumenta los costos y las dificultades demantenimiento de un sistema.


"Malos olores" en el código del programa

²Duplicar código§El mismo o muy similar código puede ser incluido en diferentes lugaresen un programa. Esto se puede quitar e implementar como un únicométodo o función que se llama según se requiera.

²Métodos largos§Si un método es demasiado largo, debe ser rediseñado como un número de métodos más cortos.

²Declaraciones switch(case)§Estos a menudo implican la duplicación, donde el switch depende del tipo de un valor. Las sentencias switch pueden estar dispersas en torno a un programa. En lenguajes orientados a objetos, a menudo se puede utilizar el polimorfismo para lograr lo mismo.


"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, parámetros en los métodos) se repiten en varios lugares en un programa. 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. Esto puede ser a menudo simplemente retirado.


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; §Transformar el sistema por reingeniería para mejorar su capacidad de mantenimiento; §Reemplazar el sistema con un nuevo sistema.

²La estrategia elegida dependerá de la calidad del sistema y de su valor para el negocio.


Un ejemplo de una evaluación de un sistemalegado


Categorías del sistema heredado

²Baja calidad, bajo valor comercial§Estos sistemas deben ser desechados.

²Baja calidad, alto valor comercial§Estos hacen una contribución importante de negocios, pero son caros de mantener. Puede ser rediseñado por reingeniería o reemplazado si un sistema adecuado esta disponible.

²Alta calidad, bajo valor comercial§Reemplazar con COTS, desechar por completo o mantener.

²Alta calidad, alto valor comercial§Continuar en la operación utilizando el mantenimiento normal del sistema.


Evaluación de valor de negocios

²La evaluación debe tomar en cuenta diferentes puntos de vista

§Los usuarios finales del sistema; §Los clientes de negocios; §Los gerentes de línea; §Los administradores de TI; §Los altos directivos.

²Entrevistar a los diferentes interesados y recopilar los resultados.


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, estos pueden tener un bajo valor comercial.

²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.

²La fiabilidad del sistema§Si un sistema no es confiable y los problemas afectan directamente a losclientes comerciales, el sistema tiene un bajo valor comercial.

²Las salidas del sistema §Si la empresa depende de los resultados del sistema, entonces elsistema tiene un alto 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?


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 - un sistema de pedidos de viaje puede tener un bajo valor comercial debido al uso generalizado de la ordenación basada en la web.


Los factores utilizados en la evaluación del entorno

Factor Preguntas

Estabilidad del proveedor

El proveedor aún existe? Es el proveedor financieramente estable y es probable que continúe en la existencia? Si el proveedor ya no está en el negocio, no hay otra persona para mantener los sistemas?

Porcentaje de fallas

¿El hardware tiene una alta tasa de fallas reportadas? ¿El software 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, más obsoleto es. Todavía puede funcionar correctamente, pero podrían existir beneficios significantes de negocios y economía al moverse a un sistema más moderno.

Rendimiento ¿El rendimiento del sistema es adecuado? ¿Los problemas de rendimiento tienen un efecto significativo sobre los usuarios del sistema?


Los factores utilizados en la evaluación del entorno

Factor PreguntasRequisitos de soporte ¿Qué soporte local es requerido por el hardware y el

software? Si hay altos costos asociados con este soporte, puede valer la pena considerar el reemplazo del sistema.

Los costos de mantenimiento

¿Cuáles son los costos de mantenimiento de hardware y de las licencias de software de soporte? Hardware antiguo puede tener costos de mantenimiento mayores a los de los sistemas modernos. Software de soporte puede tener altos costos de licencias anuales.

Interoperabilidad ¿Hay problemas de interconexión del sistema con otros sistemas? ¿Pueden los compiladores, por ejemplo, ser usados en las versiones actuales del sistema operativo? ¿Se requiere de emulación de hardware?


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?

54Capítulo 9 Evolución del software

Los factores utilizados en la evaluación de la aplicación

Factor PreguntasLenguaje de programación

¿Los compiladores modernos están disponibles para el 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 configuración

¿Están todas las versiones de todas las partes del sistema 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?


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; §El número de diferentes interfaces de usuario utilizados por el sistema; §El volumen de los datos utilizados por el sistema.


Puntos clave

²Hay 3 tipos de mantenimiento de software, la corrección de errores,la modificación de software para trabajar en un entorno nuevo, y laimplementación de requisitos nuevos o modificados.²La reingeniería del software tiene que ver con la reestructuración y elredocumentado del software para que sea más fácil de entender ycambiar.²La refactorización hace cambios en el programa que conservan lafuncionalidad, es una forma de mantenimiento preventivo.²El valor de negocio de un sistema heredado y la calidad de laaplicación se deben evaluar para ayudar a decidir si un sistema debeser cambiado, transformado o mantenido.


Documents

Capitulo 9 –Evolución del Software · del sistema. §Deberían ser vinculadas con los componentes que son afectados por el cambio, permitiendo así que el coste e impacto puedan