Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Evolución del Software
Temas
 Procesos de evolución
 Procesos de cambio para sistemas de software
 Dinámica de la evolución del programa
 Com...
Cambio de software
 El cambio de software es inevitable
 Nuevos requisitos surgen cuando se utiliza el software;
 El en...
Importancia de la evolución
 Las organizaciones tienen enormes inversiones en sus sistemas de software -
son activos crít...
Un modelo espiral de desarrollo y
evolución
Evolución y mantenimiento
Evolución y mantenimiento
 Evolution
 The stage in a software system’s life cycle where it is in operational use and is
...
Procesos de evolución
 Los procesos de evolución del software dependen de
 El tipo de software que se mantiene;
 Los pr...
Cambiar los procesos de identificación y
evolución
El proceso de evolución del software
Cambiar la implementación
Cambiar la implementación
 eración del proceso de desarrollo donde las revisiones del sistema son
diseñadas, implementada...
Solicitudes urgentes de cambio
 Los cambios urgentes pueden ser implementados sin pasar por todas las
etapas del proceso ...
El proceso de reparación de emergencia
Métodos ágiles y evolución
 Los métodos ágiles se basan en el desarrollo incremental, de modo que la
transición del desar...
Problemas de entrega
 Cuando el equipo de desarrollo ha utilizado un enfoque ágil, pero el equipo
de evolución no está fa...
Dinámica de la evolución del programa
 La dinámica de la evolución del programa es el estudio de los procesos de
cambio d...
El cambio es inevitable
 Es probable que los requisitos del sistema cambien
mientras el sistema se está desarrollando por...
Lehman’s laws
Ley Descripción
Cambio continuo Un programa que se utiliza en un entorno del mundo real debe
necesariamente ...
Lehman’s laws
Ley Descripción
Conservación de la
familiaridad
Durante el tiempo de vida de un sistema, el cambio
increment...
Aplicabilidad de las leyes de Lehman
 Las leyes de Lehman parecen ser generalmente aplicables a sistemas grandes
y adapta...
Puntos clave
 El desarrollo y la evolución del software pueden considerarse como un
proceso integrado e iterativo que pue...
Mantenimiento del software
 Modificación de un programa después de haber sido puesto en uso.
 El término se utiliza prin...
Tipos de mantenimiento
 Mantenimiento para reparar fallas de software
 Cambiar un sistema para corregir deficiencias en ...
Costos de mantenimiento
 Generalmente mayores que los costos de desarrollo (2 * a?
100 * dependiendo de la aplicación).
...
Maintenance cost factors
 Estabilidad del equipo
 Los costos de mantenimiento se reducen si el mismo personal
está invol...
Predicción de mantenimiento
 La predicción de mantenimiento se refiere a evaluar qué
partes del sistema pueden causar pro...
Predicción de mantenimiento
Cambiar la predicción
 La predicción del número de cambios requiere y la
comprensión de las relaciones entre un sistema y...
Métricas de complejidad
 Las predicciones de mantenibilidad pueden hacerse evaluando
la complejidad de los componentes de...
Métricas de proceso
 Se pueden usar métricas de proceso para evaluar la capacidad de
mantenimiento
 Número de solicitude...
Reingeniería del sistema
 Reestructuración o reescritura parcial o total de un
sistema heredado sin cambiar su funcionali...
Ventajas de la reingeniería
 Riesgo reducido
 Existe un alto riesgo en el desarrollo de nuevos programas informáticos. P...
El proceso de reingeniería
Actividades del proceso de Reingeniería
 Traducción de código fuente
 Convertir código a un nuevo idioma.
 Ingeniería i...
Factores de coste de la reingeniería
 La calidad del software a ser reingeniería.
 El soporte de herramienta disponible ...
Mantenimiento preventivo por
refactorización
 Refactorización es el proceso de hacer mejoras a un programa para frenar la...
Refactorización y reingeniería
 Reingeniería se lleva a cabo después de un sistema se ha mantenido durante
algún tiempo y...
'Malos olores' en el código del programa
 Código duplicado
 El mismo o código muy similar puede ser incluido en diferent...
'Malos olores' en el código del programa
 Agrupamiento de datos
 Los agrupamientos de datos ocurren cuando el mismo grup...
Gestión de sistemas heredados
 Las organizaciones que dependen de sistemas legados deben
elegir una estrategia para la ev...
Categorías de sistemas heredados
 Baja calidad, bajo valor de negocio
 Estos sistemas deben ser desechados.
 De baja ca...
Valoración de valor de negocio
 La evaluación debe tener en cuenta diferentes puntos de vista
 Usuarios finales del sist...
Cuestiones relativas a la evaluación del
valor de los negocios
 El uso del sistema
 Si los sistemas sólo se utilizan oca...
Evaluación de la calidad del sistema
 Evaluación de procesos empresariales
 ¿Qué tan bien soporta el proceso empresarial...
Evaluación de procesos empresariales
 Utilizar un enfoque orientado al punto de vista y buscar
respuestas de los interesa...
Factores utilizados en la evaluación del
medio ambiente
Factor Preguntas
Estabilidad del
proveedor
¿Sigue existiendo el pr...
Factores utilizados en la evaluación del
medio ambiente
Factor Preguntas
Requisitos de soporte ¿Qué soporte local es reque...
Factores utilizados en la evaluación de la
aplicación
Factor Preguntas
Comprensibilidad ¿Qué tan difícil es entender el có...
Factores utilizados en la evaluación de
la aplicación
Factor Preguntas
Lenguaje de programación ¿Hay compiladores modernos...
Medición del sistema
 Puede recopilar datos cuantitativos para hacer una evaluación de la calidad
del sistema de aplicaci...
Resumen
 Existen 3 tipos de mantenimiento de software, a saber, corrección de errores,
modificación de software para trab...
Upcoming SlideShare
Loading in …5
×

Ingenieria de Software: Evolución del Software

271 views

Published on

Dejo con ustedes la novena y ultima parte de una serie de tutoriales enfocado en la ingenieria de software

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Ingenieria de Software: Evolución del Software

  1. 1. Evolución del Software
  2. 2. Temas  Procesos de evolución  Procesos de cambio para sistemas de software  Dinámica de la evolución del programa  Comprender la evolución del software  Mantenimiento del software  Realización de cambios en los sistemas operativos de software  Gestión de sistemas heredados  Tomar decisiones sobre el cambio de software
  3. 3. Cambio de software  El cambio de software es inevitable  Nuevos requisitos surgen cuando se utiliza el software;  El entorno empresarial cambia;  Los errores deben ser reparados;  Nuevos ordenadores y equipos se agregan al sistema;  El rendimiento o la fiabilidad del sistema puede tener que ser mejorado.  Un problema clave para todas las organizaciones es implementar y gestionar el cambio a sus sistemas de software existentes.
  4. 4. Importancia de la evolución  Las organizaciones tienen enormes inversiones en sus sistemas de software - son activos críticos del negocio.  Para mantener el valor de estos activos para el negocio, deben ser cambiados y actualizados.  La mayoría del presupuesto de software en las grandes empresas se dedica a cambiar y desarrollar el software existente en lugar de desarrollar un nuevo software.
  5. 5. Un modelo espiral de desarrollo y evolución
  6. 6. Evolución y mantenimiento
  7. 7. Evolución y mantenimiento  Evolution  The stage in a software system’s life cycle where it is in operational use and is evolving as new requirements are proposed and implemented in the system.  Servicing  At this stage, the software remains useful but the only changes made are those required to keep it operational i.e. bug fixes and changes to reflect changes in the software’s environment. No new functionality is added.  Phase-out  The software may still be used but no further changes are made to it.
  8. 8. Procesos de evolución  Los procesos de evolución del software dependen de  El tipo de software que se mantiene;  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.  Debe estar vinculado con los componentes que se ven afectados por el cambio, lo que permite calcular el costo y el impacto del cambio.  La identificación y evolución del cambio continúa durante toda la vida del sistema.
  9. 9. Cambiar los procesos de identificación y evolución
  10. 10. El proceso de evolución del software
  11. 11. Cambiar la implementación
  12. 12. Cambiar la implementación  eración del proceso de desarrollo donde las revisiones del sistema son diseñadas, implementadas y probadas.  Una diferencia crítica es que la primera etapa de la implementación del cambio puede implicar la comprensión del programa, especialmente si los desarrolladores del sistema original no son responsables de la implementación del cambio.  Durante la fase de comprensión del programa, usted tiene que entender cómo el programa está estructurado, cómo ofrece funcionalidad y cómo el cambio propuesto podría afectar el programa.
  13. 13. Solicitudes urgentes de cambio  Los cambios urgentes pueden ser implementados sin pasar por todas las etapas del proceso de ingeniería de software  Si se debe 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 hay cambios en el negocio que requieren una respuesta muy rápida (por ejemplo, la liberación de un producto competidor).
  14. 14. El proceso de reparación de emergencia
  15. 15. Métodos ágiles y evolución  Los métodos ágiles se basan en el desarrollo incremental, de modo que la transición del desarrollo a la evolución es perfecta.  La evolución es simplemente una continuación del proceso de desarrollo basado en versiones frecuentes del sistema.  Las pruebas automatizadas de regresión son particularmente valiosas cuando se realizan cambios en un sistema.  Los cambios pueden expresarse como historias de usuarios adicionales.
  16. 16. Problemas de entrega  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 el plan.  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 el plan para el desarrollo, pero el equipo de evolución prefiere usar métodos ágiles.  El equipo de evolución puede tener que comenzar desde cero desarrollando pruebas automatizadas y el código en el sistema puede no haber sido refactorizado y simplificado como se espera en el desarrollo ágil.
  17. 17. Dinámica de la evolución del programa  La dinámica de la evolución del programa es el estudio de los procesos de cambio del sistema.  Después de varios estudios empíricos importantes, Lehman y Belady propusieron que había una serie de "leyes" que se aplicaban a todos los sistemas a medida que evolucionaban.  Hay observaciones sensatas más que leyes. Son aplicables a grandes sistemas desarrollados por grandes organizaciones.  No está claro si estos son aplicables a otros tipos de sistema de software.
  18. 18. El cambio es inevitable  Es probable que los requisitos del sistema cambien mientras el sistema se está desarrollando porque el entorno está cambiando. ¡Por lo tanto un sistema entregado no cumplirá sus requisitos!  Los sistemas están fuertemente acoplados con su entorno. Cuando un sistema se instala en un entorno ?, cambia ese entorno y, por lo tanto, cambia los requisitos del sistema.  Los sistemas DEBEN ser cambiados si deben permanecer útiles en un ambiente.
  19. 19. Lehman’s laws Ley Descripción Cambio continuo Un programa que se utiliza en un entorno del mundo real debe necesariamente cambiar, o bien ser progresivamente menos útil en ese entorno. Mayor complejidad A medida que cambia un programa en evolución, su estructura tiende a ser más compleja. Se deben dedicar recursos adicionales a preservar y simplificar la estructura. Gran evolución del programa La evolución del programa es un proceso de autorregulación. Atributos del sistema tales como tamaño, tiempo entre releases y el número de errores reportados es aproximadamente invariante para cada versión del sistema. Estabilidad organizacional Durante la vida útil de un programa, su tasa de desarrollo es aproximadamente constante e independiente de los recursos dedicados al desarrollo del sistema. 19
  20. 20. Lehman’s laws Ley Descripción Conservación de la familiaridad Durante el tiempo de vida de un sistema, el cambio incremental en cada liberación es aproximadamente constante. Crecimiento continuo La funcionalidad ofrecida por los sistemas tiene que aumentar continuamente para mantener la satisfacción del usuario. Calidad decreciente La calidad de los sistemas disminuirá a menos que se modifiquen para reflejar los cambios en su entorno operacional. Sistema de retroalimentación Los procesos de Evolution incorporan sistemas de retroalimentación multiagente y multiloop, y usted tiene que tratarlos como sistemas de retroalimentación para lograr una mejora significativa del producto.
  21. 21. Aplicabilidad de las leyes de Lehman  Las leyes de Lehman parecen ser generalmente aplicables a sistemas grandes y adaptados desarrollados por grandes organizaciones.  Confirmado a principios de 2000 por el trabajo de Lehman en el proyecto FEAST.  No está claro cómo se deben modificar para  Shrink-envuelto productos de software;  Sistemas que incorporen un número significativo de componentes COTS;  Pequeñas organizaciones;  Sistemas de tamaño mediano.
  22. 22. Puntos clave  El desarrollo y la evolución del software pueden considerarse como un proceso integrado e iterativo que puede representarse utilizando un modelo en espiral.  Para sistemas personalizados, los costos de mantenimiento del software generalmente exceden los costos de desarrollo de software.  El proceso de evolución del software está 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.  Las leyes de Lehman, tales como la noción de que el cambio es continuo, describen una serie de ideas derivadas de estudios a largo plazo de la evolución del sistema.
  23. 23. Mantenimiento del software  Modificación de un programa después de haber sido puesto en uso.  El término se utiliza principalmente para cambiar el software personalizado. Se dice que los productos genéricos de software 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.
  24. 24. Tipos de mantenimiento  Mantenimiento para reparar fallas de software  Cambiar un sistema para corregir deficiencias en el camino cumple con sus requisitos.  Mantenimiento para adaptar el software a un entorno operativo diferente  Cambiar un sistema para que funcione en un entorno diferente (equipo, sistema operativo, etc.) desde su implementación inicial.  Mantenimiento para agregar o modificar la funcionalidad del sistema  Modificar el sistema para satisfacer nuevos requisitos.
  25. 25. Costos de mantenimiento  Generalmente mayores que los costos de desarrollo (2 * a? 100 * dependiendo de la aplicación).  Afectados por factores tanto técnicos como no técnicos.  Aumenta a medida que se mantiene el software. • El mantenimiento daña la estructura del software, por lo que hace más difícil el mantenimiento.  El software de envejecimiento puede tener altos costos de soporte (por ejemplo, lenguajes antiguos, compiladores, etc.).
  26. 26. Maintenance cost factors  Estabilidad del equipo  Los costos de mantenimiento se reducen si el mismo personal está involucrado con ellos durante algún tiempo.  Responsabilidad contractual  Los desarrolladores de un sistema pueden no tener responsabilidad contractual por el mantenimiento por lo que no hay incentivos para diseñar para el cambio futuro.  Habilidades del personal  El personal de mantenimiento es a menudo inexperto y tiene conocimiento limitado del dominio.  Edad y estructura del programa  A medida que los programas envejecen, su estructura se degrada y se vuelven más difíciles de entender y cambiar.
  27. 27. Predicción de mantenimiento  La predicción de mantenimiento se refiere a evaluar qué partes del sistema pueden causar problemas y tener altos costos de mantenimiento  La aceptación del cambio depende de la capacidad de mantenimiento de los componentes afectados por el cambio;  La implementación de cambios degrada el sistema y reduce su capacidad de mantenimiento;  Los costos de mantenimiento dependen del número de cambios y los costos del cambio dependen de la capacidad de mantenimiento.
  28. 28. Predicción de mantenimiento
  29. 29. Cambiar la predicción  La predicción del número de cambios requiere y la comprensión de las relaciones entre un sistema y su entorno.  Los sistemas de acoplamiento rígido requieren cambios siempre que se cambie el entorno.  Los factores que influyen en esta relación son:  Número y complejidad de las interfaces del sistema;  Número de requisitos inherentemente volátiles del sistema;  Los procesos de negocio donde se utiliza el sistema.
  30. 30. Métricas de complejidad  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 destina a un número relativamente pequeño de componentes del sistema.  La complejidad depende de  Complejidad de las estructuras de control;  Complejidad de las estructuras de datos;  Objeto, método (procedimiento) y tamaño del módulo.
  31. 31. Métricas de proceso  Se pueden usar métricas de proceso para evaluar la capacidad de mantenimiento  Número de solicitudes de mantenimiento correctivo;  Tiempo medio requerido para el análisis de impacto;  Tiempo medio empleado para implementar una solicitud de cambio;  Número de solicitudes de cambio pendientes.  Si alguno o todos estos está aumentando, esto puede indicar una disminución en la capacidad de mantenimiento.
  32. 32. Reingeniería del sistema  Reestructuración o reescritura parcial o total de un sistema heredado sin cambiar su funcionalidad.  Aplicable donde algunos pero no todos los subsistemas de un sistema más grande requieren mantenimiento frecuente.  Reingeniería implica agregar esfuerzo para que sean más fáciles de mantener. El sistema puede ser reestructurado y re-documentado.
  33. 33. Ventajas de la reingeniería  Riesgo reducido  Existe un alto riesgo en el desarrollo de nuevos programas informáticos. Puede haber problemas de desarrollo, problemas de personal y problemas de especificación.  Costo reducido  El costo de la reingeniería es a menudo significativamente menor que el costo de desarrollar un nuevo software.
  34. 34. El proceso de reingeniería
  35. 35. Actividades del proceso de Reingeniería  Traducción de 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 la comprensibilidad;  Modularización de programas  Reorganizar la estructura del programa;  Reingeniería de datos  Limpiar y reestructurar los datos del sistema.
  36. 36. Factores de coste de la reingeniería  La calidad del software a ser reingeniería.  El soporte de herramienta disponible para la reingeniería.  La extensión de la conversión de datos que se requiere.  La disponibilidad de personal experto para la reingeniería.  Esto puede ser un problema con sistemas antiguos basados en tecnología que ya no se utiliza ampliamente.
  37. 37. Mantenimiento preventivo por refactorización  Refactorización es el proceso de hacer mejoras a un programa para frenar la degradación a través del cambio.  Se puede pensar en la refactorización como "mantenimiento preventivo" que reduce los problemas del cambio futuro.  La refactorización implica modificar un programa para mejorar su estructura, reducir su complejidad o hacerla más fácil de entender.  Al refactorizar un programa, no debe agregar funcionalidad sino concentrarse en la mejora del programa.
  38. 38. Refactorización y reingeniería  Reingeniería se lleva a cabo después de un sistema se ha mantenido durante algún tiempo y los costos de mantenimiento están aumentando. Utiliza herramientas automatizadas para procesar y reorganizar un sistema heredado para crear un nuevo sistema que sea 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. Se pretende evitar la estructura y la degradación del código que aumenta los costos y las dificultades de mantener un sistema.
  39. 39. 'Malos olores' en el código del programa  Código duplicado  El mismo o código muy similar puede ser incluido en diferentes lugares en un programa. Esto se puede quitar e implementar como un único método o función que se llama como se requiere.  Métodos largos  Si un método es demasiado largo, debe ser rediseñado como un número de métodos más cortos.  Interruptor (caso) declaraciones  Éstos a menudo implican duplicación, donde el cambio depende del tipo de un valor. Las sentencias switch pueden estar dispersas alrededor de un programa. En lenguajes orientados a objetos, a menudo se puede usar el polimorfismo para lograr lo mismo.
  40. 40. 'Malos olores' en el código del programa  Agrupamiento de datos  Los agrupamientos de datos ocurren cuando el mismo grupo de elementos de datos (campos en clases, parámetros en métodos) vuelve a producirse en varios lugares en un programa. Éstos a menudo se pueden reemplazar 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 a menudo puede ser simplemente eliminado.
  41. 41. Gestión de sistemas heredados  Las organizaciones que dependen de sistemas legados deben elegir una estrategia para la evolución de estos sistemas  Desechar completamente el sistema y modificar los procesos empresariales para que ya no sea necesario;  Continuar manteniendo el sistema;  Transformar el sistema mediante la reingeniería para mejorar su capacidad de mantenimiento;  Sustituya el sistema por un nuevo sistema.  La estrategia elegida debe depender de la calidad del sistema y de su valor comercial.
  42. 42. Categorías de sistemas heredados  Baja calidad, bajo valor de negocio  Estos sistemas deben ser desechados.  De baja calidad, de alto valor comercial  Éstos hacen una contribución importante del negocio pero son costosos de mantener. Debe ser re-diseñado o reemplazado si un sistema adecuado está disponible.  Alta calidad, bajo valor de negocio  Reemplazar con COTS, desechar completamente o mantener.  Alta calidad, alto valor de negocio  Continúe funcionando con el mantenimiento normal del sistema.
  43. 43. Valoración de valor de negocio  La evaluación debe tener en cuenta diferentes puntos de vista  Usuarios finales del sistema;  Clientes empresariales;  Los gerentes de línea;  Gerentes de TI;  Altos directivos.  Entreviste a diferentes partes interesadas y compile los resultados.
  44. 44. Cuestiones relativas a la evaluación del valor de los negocios  El uso del sistema  Si los sistemas sólo se utilizan ocasionalmente o por un pequeño número de personas, pueden tener un valor de negocio bajo.  Los procesos empresariales que se admiten  Un sistema puede tener un valor de negocio bajo si fuerza el uso de procesos de negocio ineficientes.  Confiabilidad del sistema  Si un sistema no es confiable y los problemas afectan directamente a los clientes empresariales, el sistema tiene un valor empresarial bajo.  Las salidas del sistema  Si el negocio depende de las salidas del sistema, entonces el sistema tiene un alto valor de negocio.
  45. 45. Evaluación de la calidad del sistema  Evaluación de procesos empresariales  ¿Qué tan bien soporta el proceso empresarial los objetivos actuales del negocio?  Evaluación ambiental  ¿Qué tan efectivo es el entorno del sistema y cuán caro es mantenerlo?  Evaluación de la aplicación  ¿Cuál es la calidad del sistema de software de aplicación?
  46. 46. Evaluación de procesos empresariales  Utilizar un enfoque orientado al punto de vista y buscar respuestas de los interesados del sistema  ¿Existe un modelo de proceso definido y se sigue?  ¿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 necesarios?  ¿El proceso es efectivamente soportado por el software de aplicaciones heredado?  Ejemplo: un sistema de pedidos de viajes puede tener un bajo valor comercial debido al uso generalizado de pedidos basados en la web.
  47. 47. Factores utilizados en la evaluación del medio ambiente Factor Preguntas Estabilidad del proveedor ¿Sigue existiendo el proveedor? ¿Está el proveedor financieramente estable y es probable que siga existiendo? Si el proveedor ya no está en el negocio, ¿alguien más mantiene los sistemas? Tasa de fracaso ¿El hardware tiene una alta tasa de errores reportados? ¿El software de soporte falla y obliga a reiniciar el sistema? Años ¿Qué edad tiene el hardware y el software? Cuanto más viejo sea el hardware y soporte de software, más obsoleto será. Puede que siga funcionando correctamente, pero podría haber importantes beneficios económicos y comerciales para pasar a un sistema más moderno. Actuación ¿Es adecuado el rendimiento del sistema? ¿Los problemas de rendimiento tienen un efecto significativo en los usuarios del sistema?
  48. 48. Factores utilizados en la evaluación del medio ambiente Factor Preguntas Requisitos de soporte ¿Qué soporte local es requerido por el hardware y el software? Si hay altos costos asociados con este soporte, puede ser conveniente considerar el reemplazo del sistema. Costos de mantenimiento ¿Cuáles son los costos de mantenimiento de hardware y licencias de software de soporte? Un hardware más antiguo puede tener mayores costos de mantenimiento que los sistemas modernos. El software de soporte puede tener altos costos de licencia anuales. Interoperabilidad ¿Hay problemas para conectar el sistema a otros sistemas? ¿Se pueden utilizar compiladores, por ejemplo, con las versiones actuales del sistema operativo? ¿Se requiere emulación de hardware?
  49. 49. Factores utilizados en la evaluación de la aplicación Factor Preguntas Comprensibilidad ¿Qué tan difícil es entender el código fuente del sistema actual? ¿Cuán 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? ¿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 entre los archivos? ¿Los datos utilizados por el sistema están actualizados y son consistentes? Actuación ¿Es adecuado el desempeño de la aplicación? ¿Los problemas de rendimiento tienen un efecto significativo en los usuarios del sistema?
  50. 50. Factores utilizados en la evaluación de la aplicación Factor Preguntas Lenguaje de programación ¿Hay compiladores modernos disponibles 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 configuración ¿Todas las versiones de todas las partes del sistema son gestionadas por 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 prueba ¿Existen datos de prueba para el sistema? ¿Existe un registro de las pruebas de regresión realizadas cuando se han agregado nuevas características al sistema? Habilidades del personal ¿Hay personas disponibles que tengan las habilidades para mantener la aplicación? ¿Hay personas disponibles que tengan experiencia con el sistema?
  51. 51. Medición del sistema  Puede recopilar datos cuantitativos para hacer una evaluación de la calidad del sistema de aplicación  El número de solicitudes de cambio de sistema;  El número de interfaces de usuario diferentes utilizadas por el sistema;  El volumen de datos utilizado por el sistema.
  52. 52. Resumen  Existen 3 tipos de mantenimiento de software, a saber, corrección de errores, modificación de software para trabajar en un nuevo entorno e implementación de requisitos nuevos o modificados.  La reingeniería de software se ocupa de reestructurar y volver a documentar el software para que sea más fácil de entender y cambiar.  Refactorizar, hacer cambios en el programa que preserven la funcionalidad, es una forma de mantenimiento preventivo.  El valor comercial de un sistema heredado y la calidad de la aplicación deben evaluarse para ayudar a decidir si un sistema debe ser reemplazado, transformado o mantenido.

×