Evolución del software

Presentación del tema: "Evolución del software"— Transcripción de la presentación:

1 Evolución del software

2 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

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

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

5 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

6 Modelo en espiral de la evolución

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

8 Leyes de Lehman

9 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

10 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

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

12 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

13 Distribución del esfuerzo de mantenimiento

14 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.)

15 Costos de desarrollo/mantenimiento

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

17 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

18 Predicción de mantenimiento

19 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

20 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

21 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

22 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

23 Identificación y evolución del cambio

24 El proceso de evolución del sistema

25 Implementación del cambio

26 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)

27 Reparación de emergencia

28 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

29 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

30 Ingeniería hacia adelante y re-ingeniería

31 El proceso de la re-ingeniería

32 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

33 Aproximaciones de re-ingeniería

34 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

35 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

36 Calidad del sistema y valor del negocio

37 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

38 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

39 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?

40 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

41 Evaluación del entorno 1

42 Evaluación del entorno 2

43 Evaluación de aplicación 1

44 Evaluación de aplicación 2

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

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

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