Evolución del software

Objetivos Explicar porque el cambio es inevitable si se quiere mantener útiles a los sistemas de software. Discutir el mantenimiento del software y los factores de costo de dicho mantenimiento. Describir el proceso de evolución del software Discutir un enfoque de asistencia para las estrategias de evolución para sistemas heredados

Tópicos cubiertos Dinámica de evolución de programas Mantenimiento de software Procesos de evolución Evolución de sistemas heredados

El cambio en el software El cambio en el software es inevitable Surgen nuevos requerimientos cuando el software se usa El entorno del negocio cambia Los errores deben de repararse Nuevas computadoras y equipos son añadidos al sistema El desempeño o la fiabilidad del sistema tal vez necesite mejorar Un problema clave para las organizaciones es implementar y administrar cambios a sus sistemas de software existentes.

Importancia de la evolución Las organizaciones han realizado grandes inversiones en sus sistemas de software – son activos de negocio críticos Para mantener el valor de estos activos para el negocio, deben de cambiarse y actualizarse En las grandes compañías, la mayor parte del presupuesto del software se dedica a la evolución de software existente más que a la creación de nuevo software

Modelo en espiral de la evolución

Dinámica de evolución de programas Dinámica de evolución de programas es el estudio de los procesos de cambios del sistema Posterior a grandes estudios empíricos, Lehman y Belady propusieron que existían un número de ´leyes´ que se aplicaban a todos los sistemas a medida que evolucionan. Se tratan de reflexiones sensatas mas que leyes. Se aplican a sistemas grandes desarrollados por grandes organizaciones. Tal vez es menos aplicable en otros casos.

Leyes de Lehman

Aplicabilidad de las leyes de Lehman Las leyes de Lehman parecen ser de aplicación general para sistemas de medida grandes desarrollados por grandes organizaciones Confirmado en trabajos más recientes de Lehman en el proyecto FEAST (ver más de esto en el libro en el website) No está claro cómo se debería modificar para Productos de software comerciales Sistemas que incorporan un número significativo de componentes COTS Organizaciones pequeñas Sistemas de mediano tamaño

Mantenimiento de Software Modificar un programa después de haber sido puesto en uso El mantenimiento normalmente no hace referencia a cambios mayores en la arquitectura del sistema Los cambios se implementan al modificar componentes existentes y añadir nuevos componentes al sistema

El mantenimiento es inevitable Los requerimientos del sistemas son propensos a cambiar a medida que el sistema esta siendo desarrollado porque el entorno está cambiando. Por tanto, ¡un sistema entregado no se ajustará a sus requerimientos! Los sistemas están estrechamente asociados a su entorno. Cuando el sistema se instala en un entorno, cambia ese entorno y por tanto cambia los requerimientos del sistema Los sistemas deben mantenerse si quieren mantenerse útiles en un entorno.

Tipos de mantenimiento Mantenimiento para reparar defectos del software Cambiar un sistema para corregir defectos a medida que se ajusta a sus requerimientos Mantenimientos para adaptar un software a diferentes entornos operativos Cambiar un sistema para que opere en un entorno diferente (computadora, SO, etc.) al de su implementación inicial Mantenimiento para añadir o modificar las funcionalidades del sistema Modificar el sistema para satisfacer nuevos requerimientos

Distribución del esfuerzo de mantenimiento

Costos de mantenimiento Usualmente mayor que los costos de desarrollo (2* a 100* veces más grande dependiendo de la aplicación) Afectado por factores técnicos y no técnicos Se incrementa a medida que el software se mantiene. El mantenimiento corrompe la estructura del software haciendo del mantenimiento posterior más difícil Software en envejecimiento pueden tener alto costo de soporte (e.g. Lenguajes viejos, compiladores etc.)

Costos de desarrollo/mantenimiento

Factores de costos de mantenimiento Estabilidad de equipo Los costos de mantenimiento se reducen si el mismo personal se involucra en el mantenimiento por un tiempo Responsabilidad contractual Los desarrolladores del sistema pueden no tener responsabilidad contractual por razones de mantenimiento, por tanto no hay incentivo para diseñar cambios futuros Habilidades del personal El personal de mantenimiento es a menudo inexperto y con poco conocimiento del dominio Edad y estructura del programa A medida que los programas envejecen, su estructura se degrada y se vuelven mas difíciles de entender y cambiar.

Predicción de mantenimiento La predicción del mantenimiento se refiere a evaluar que partes del sistema pueden causar problemas y tener altos costos de mantenimiento Aceptar el cambio depende de la mantenibilidad de los componentes afectados por dicho cambio Implementar cambios degrada el sistema y reduce la mantenibilidad Los costos de mantenimiento dependen del número de cambios y los costos de cambio dependen de la mantenibilidad

Predicción de mantenimiento

Predicción del cambio Predecir el número de cambios requiere un entendimiento de las relaciones entre el sistema y su entorno Sistemas estrechamente relacionados requieren cambios siempre que el entorno cambia Los factores que influencian estas relaciones son Número y complejidad de las interfaces del sistema Número de requerimientos del sistema intrínsecamente volátiles Los procesos de negocio donde se usa el sistema

Medidas de la complejidad Predicciones de la mantenibilidad pueden ser realizadas por la evaluación de la complejidad de los componentes el sistema Estudios han demostrado que la mayoría del esfuerzo del mantenimiento se genera en un número relativamente pequeño de componentes de sistema La complejidad depende de Complejidad de estructuras de control Complejidad de estructuras de datos Objeto, método (procedimiento) y tamaño del módulo

Medidas de proceso Las medidas de proceso pueden usarse para evaluar la mantenibilidad Número de peticiones de mantenimiento correctivo Tiempo promedio requerido para el análisis de impacto Tiempo promedio empleado en implementar una petición de cambio Número de peticiones de cambio pendientes Si uno o todos éstos está incrementando, puede indicar una disminución en la mantenibilidad

Procesos de evolución Los procesos de evolución dependen de El tipo de software en mantenimiento El proceso de desarrollo utilizado Las habilidad y la experiencia de las personas involucradas Las propuestas de cambio son los conductores de la evolución de los sistemas. La identificación y la evolución del cambio continúan durante toda la vida del sistema

Identificación y evolución del cambio

El proceso de evolución del sistema

Implementación del cambio

Peticiones de cambio urgente Cambios urgentes pueden ser implementados sin pasar por todas las etapas del proceso de ingeniería de software SI un defecto serio en el sistema debe ser reparado Si cambios en el entorno del sistema (e.g. mejora del SO) tiene resultados inesperados Si hay cambios en el negocio que requieren una respuesta bastante rápida (e.g. lanzamiento de un producto de la competencia)

Reparación de emergencia

Re-ingeniería de sistemas Re-estructurar o re-escribir parte o todo un sistema heredado sin cambiar su funcionalidad Aplicable cuando algunos, no todos, los subsistemas de un sistema grande requieren mantenimiento frecuente La re-ingeniería implica añadir esfuerzo para hacerlos fácil de mantener. Los sistemas pueden ser re-estructurados y re-documentados

Ventajas de la re-ingeniería Riesgo reducido Existe un alto riesgo en el desarrollo de nuevos sistemas. Pueden haber problemas de desarrollo, problemas de personal y problemas de especificación Coste reducido El coste de la re-ingeniería es a menudo significativamente más pequeño que el coste de desarrollo de un nuevo software

Ingeniería hacia adelante y re-ingeniería

El proceso de la re-ingeniería

Actividades del proceso de la re-ingeniería Traducción del código fuente Convertir el código a un nuevo lenguaje Ingeniería inversa Analizar el programa para entenderlo Mejora de la estructura de los programas Reestructurar de forma automática para la comprensibilidad Modularización de los programas Reorganizar la estructura de los programas Re-ingeniería de datos Limpiar y re-estructurar los datos del sistema

Aproximaciones de re-ingeniería

Factores de costos de re-ingeniería La calidad del sfotware sobre el que se va a hacer la re-ingeniería Las herramientas de soporte disponibles para la re-ingeniería La amplitud de la conversión de datos requerida La disponibilidad de personal experto para la re-ingeniería Este puede ser un problema con sistemas antiguos basados en tecnología que ya no es utuilizada

Evolución de sistemas heredados Organizaciones que dependen de sistemas heredados deben escoger una estrategia para evolucionar estos sistemas Desechar completamente el sistema y modificar los procesos del negocio para que ya no sea requerido Continuar el mantenimiento del sistema Transformar el sistema mediante re-ingeniería para mejorar su mantenibilidad Reemplazar el sistema con un nuevo sistema La estrategia escogida debe depender de la calidad del sistema y el valor del negocio

Calidad del sistema y valor del negocio

Categorías de sistemas heredados Baja calidad y bajo valor de negocio Estos sistemas deben desecharse Baja calidad y alto valor del negocio Realizan una importante contribución al negocio pero son caros de mantener. Deben aplicárseles reingeniería o reemplazarlos si un sistema adecuado esta disponible Alta calidad y bajo valor de negocio Reemplazar con COTS, desechar completamente o realizar mantenimiento Alta calidad y alto valor de negocio Continuar su funcionamiento usando el mantenimiento normal del sistema

Evaluación del valor de negocio La evaluación deberia tomar distintos puntos en cuenta Usuarios finales del sistema Clientes del negocio Gerentes de línea Gerentes de tecnología de información (IT) Gerentes generales Entrevistar a los distintos stakeholders y recolectar resultados

Evaluación de la calidad del sistema Evaluación del procesos del negocio ¿Qué tan bien el proceso del negocio brinda soporte a los objetivos actuales del negocio? Evaluación del entorno ¿Qué tan efectivo es el entorno del sistema y qué tan caro es de mantener? Evaluación de la aplicación ¿Cuál es la calidad del sistema de software de aplicación?

Evaluación del proceso del negocio Utilizar un enfoque orientado a puntos de vista y buscar respuestas de los stakeholders del sistema ¿Existe un modelo del proceso definido y es seguido? ¿Diferentes partes de la organización usan diferentes procesos para la misma función? ¿Cómo se adaptó el proceso? ¿Cuáles son las relaciones con otros procesos del negocio y son éstos necesarios? ¿El proceso es soportado efectivamente por el software de aplicaciones heredadas ? Ejemplo – Un sistema de pedido de viajes puede tener un bajo valor de negocio debido al uso generalizado de órdenes basadas en web

Evaluación del entorno 1

Evaluación del entorno 2

Evaluación de aplicación 1

Evaluación de aplicación 2

Sistema de Medición Usted puede recoger datos cuantitativos para realizar una evaluación de la calidad del sistema de aplicación El número de solicitudes de cambio de sistema; El número de distintas interfaces de usuario que utiliza el sistema; El volumen de datos utilizados por el sistema.

Puntos clave El desarrollo de software y la evolución debe ser un proceso iterativo único. Las leyes de Lehman describen una serie de ideas sobre la evolución del sistema. Tres tipos de mantenimiento son corrección de errores, que modifica el software para un nuevo entorno y la aplicación de nuevos requisitos. Para los sistemas de medida, los costes de mantenimiento por lo general superior a los costes de desarrollo.

Puntos clave El proceso de evolución es impulsada por las solicitudes de cambios de las partes interesadas del sistema. La reingeniería del software se refiere a la re-estructuración y documentación de software para que sea más fácil de cambiar. El valor de negocio de un sistema de legado y su calidad debe determinar la estrategia de evolución que se utiliza.