Tecnicas de mantenimiento de software

1. MANTENIMIENTO
DE SOFTWARE

2. Definición de
Mantenimiento
(1)
El estándar IEEE 1219 [IEEE, 1993]
define el Mantenimiento del Software
como “la modificación de un producto
software después de haber sido
entregado (a los usuarios o clientes)
con el fin de corregir defectos,
mejorar el rendimiento u otros
atributos, o adaptarlo a un cambio en
el entorno”.

3. Definición de
Mantenimiento
(2)
En el estándar ISO 12207, de Procesos
del Ciclo de Vida del Software
[ISO/IEC, 2017] se establece que el
propósito del proceso de
mantenimiento es conservar la
capacidad del sistema de proporcionar
un servicio.

4. Definición de
Mantenimiento
(3)
Pressman(2014) dice que: El
mantenimiento del software es el proceso
general de cambiar un sistema después de
que éste se entregó. El término
usualmente se aplica a software
personalizado, en el que grupos de
desarrollo separados intervienen antes y
después de la entrega. Los cambios
realizados al software van desde los
simples para corregir errores de
codificación, los más extensos para
corregir errores de diseño, hasta mejorías
significativas para corregir errores de
especificación o incorporar nuevos
requerimientos. Los cambios se
implementan modificando los
componentes del sistema existentes y
agregándole nuevos componentes donde
sea necesario.

5. • correctivo,
• adaptativo,
• perfectivo y
• preventivo.
En las anteriores definiciones de
mantenimiento aparecen indicados, directa o
indirectamente, cuatro tipos de mantenimiento.

6. Usuario del
Sistema
Base
tecnológica
Entorno de
trabajo
Sistema
Software
Mantenimiento Perfectivo
Mantenimiento Correctivo
Mantenimiento Preventivo
Mantenimiento Adaptativo

7. Mantenimiento
Correctivo
El mantenimiento correctivo tiene por objetivo
localizar y eliminar los posibles defectos de los
programas. Un defecto en un sistema es una
característica del sistema con el potencial de causar
un fallo. Un fallo ocurre cuando el comportamiento
de un sistema es diferente del establecido en la
especificación.
Entre otros, los fallos en el software pueden ser de:
• Procesamiento, por ejemplo, salidas incorrectas de un
programa.
• Rendimiento, por ejemplo, tiempo de respuesta
demasiado alto en una búsqueda de información.
• Programación, por ejemplo, inconsistencias en el diseño de
un programa.
• Documentación,por ejemplo, inconsistencias entre la
funcionalidad de un programa y el manual de usuario.

8. Origen de los
defectos del
software

9. /
Mantenimiento Adaptativo
ESTE TIPO DE MANTENIMIENTO CONSISTE
EN LA MODIFICACIÓN DE UN PROGRAMA
DEBIDO A CAMBIOS EN EL ENTORNO
(HARDWARE O SOFTWARE) EN EL CUAL SE
EJECUTA.
ESTOS CAMBIOS PUEDEN AFECTAR AL
SISTEMA OPERATIVO (CAMBIO A UNO MÁS
MODERNO), A LA ARQUITECTURA FÍSICA DEL
SISTEMA INFORMÁTICO (PASO DE UNA
ARQUITECTURA DE RED DE ÁREA LOCAL A
INTERNET/INTRANET) O AL ENTORNO DE
DESARROLLO DEL SOFTWARE
(INCORPORACIÓN DE NUEVOS ELEMENTOS
O HERRAMIENTAS COMO ODBC).
EL TIPO DE CAMBIO NECESARIO PUEDE SER
MUY DIFERENTE: DESDE UN PEQUEÑO
RETOQUE EN LA ESTRUCTURA DE UN
MÓDULO HASTA TENER QUE RE ESCRIBIR
PRÁCTICAMENTE TODO EL PROGRAMA
PARA SU EJECUCIÓN EN UN AMBIENTE
DISTRIBUIDO EN UNA RED.

10. Mantenimiento
Adaptativo
Los cambios en el entorno software pueden ser
de dos clases:
• Enelentornode losdatos,por ejemplo, al dejar
de trabajar con un sistema de ficheros
clásico y sustituirlo por un sistema de gestión
de bases de datos relacionales y sustituirlo
por una base de datos NoSQL.
• En el entorno de los procesos, por ejemplo,
migrando a una nueva plataforma de
desarrollo con componentes distribuidos,
Java, ActiveX,etc.

11. Mantenimiento
Perfectivo
Desde algo tan simple como cambiar el
formato de impresión de un informe, hasta la
incorporación de un nuevo módulo aplicativo.
Podemos definir el mantenimiento perfectivo
como el conjunto de actividades para mejorar
o añadir nuevas funcionalidades requeridas
por el usuario
Cambios en la especificación,
normalmente debidos a cambios
en los requisitos de un producto
software, implican un nuevo tipo
de mantenimiento llamado
perfectivo.

12. Mantenimiento
Perfectivo
Algunos autores
dividen este
tipo de
mantenimiento
en dos:
Mantenimiento de Ampliación:
Orientado a la incorporación de nuevas
funcionalidades o soportar mayor carga de
trabajo. Ejemplo aumento de usuarios.
Mantenimiento de Eficiencia:
Que busca la mejora de la eficiencia de
ejecución.
Este tipo de mantenimiento aumenta
cuando un producto software tiene éxito
comercial y es utilizado por muchos
usuarios, ya que cuanto más se utiliza un
software, más peticiones de los usuarios se
reciben demandando nuevas
funcionalidades o mejoras en las existentes

13. Mantenimiento Preventivo
Este último tipo de mantenimiento consiste en la
modificación del software para mejorar sus propiedades
(por ejemplo, aumentando su calidad y/o su
mantenimiento) sin alterar sus especificaciones
funcionales.
Por ejemplo, se pueden reestructurar los programas para
mejorar su legibilidad, o incluir nuevos comentarios que faciliten
la posterior comprensión del programa.
Este tipo de mantenimiento es el que más
partido saca de las técnicas de ingeniería
inversa y reingeniería.

14. Soportabilidad del Software
La capacidad de dar soporte a un sistema de software
durante toda la vida del producto. Esto implica
satisfacer cualquier necesidad o requisito, pero
también provisión de equipo, infraestructura de
soporte, software adicional, instalaciones, mano de
obra o cualquier otro recurso requerido para
mantener el software operativo y capaz de satisfacer
su función.

15. Reingeniería
En la actualidad, las principales compañías tienen decenas de miles de
programas de cómputo que soportan las “antiguas reglas
empresariales”. Conforme los administradores trabajan para modificar
las reglas a fin de lograr mayor efectividad y competitividad, el software
debe seguirles el paso. En algunos casos, esto significa la creación de
grandes y novedosos sistemas basados en cómputo. Pero en muchos
otros, significa la modificación o reconstrucción de las aplicaciones
existentes.

16. Reingeniería de procesos de
empresa - RPE
La reingeniería de procesos de empresa (RPE) se extiende
más allá del ámbito de las tecnologías de la información y de
la ingeniería de software. Entre las muchas definiciones (la
mayoría u tanto abstractas) que se han sugerido para la RPE,
está una publicada en Fortune Magazine [Ste93]: “la
búsqueda, e implementación, de cambios radicales en los
procesos de las empresas para lograr resultados
innovadores”.

17. Reingeniería de Software
El escenario es demasiado común: una aplicación que atendió las
necesidades empresariales de una compañía durante 10 o 15
años. Durante ese tiempo se corrigió, adaptó y mejoró muchas
veces. Las personas realizaban esta tarea con las mejores
intenciones, pero las buenas prácticas de ingeniería siempre se
hicieron a un lado (debido a la presión de otros asuntos). Ahora la
aplicación es inestable. Todavía funciona, pero cada vez que se
intenta un cambio, ocurren inesperados y serios efectos
colaterales. Aun así, la aplicación debe seguir evolucionando

18. Reingeniería de Software
Un modelo de proceso de reingeniería de software
La reingeniería toma tiempo, cuesta cantidades significativas de
dinero y absorbe recursos que de otro modo pueden ocuparse
en preocupaciones inmediatas. Por todas estas razones, la
reingeniería no se logra en pocos meses o incluso en algunos
años. La reingeniería de los sistemas de información es una
actividad que absorberá recursos de tecnología de la
información durante muchos años. Por esto, toda organización
necesita una estrategia pragmática para la reingeniería de
software.

19. Análisis de
inventarios
Reestructu
ración de
documento
s
Ingeniería
inversa
Reestructu
ración de
código
Reestructu
ración de
datos
Ingeniería
hacia
adelante
Actividades de
reingeniería
de software

20. Análisis de inventarios. Toda organización de
software debe tener un inventario de todas las
aplicaciones.
Reestructuración de documentos. La
documentación débil es el distintivo de
muchos sistemas heredados.
Ingeniería inversa. El término ingeniería inversa tiene su origen en el mundo
del hardware. Una compañía desensambla un producto de hardware de otra
empresa con la intención de entender los “secretos” de diseño y fabricación
de su competidor. Dichos secretos podrían entenderse fácilmente si se
obtuvieran las especificaciones de diseño y fabricación. Pero esos documentos
son propiedad de la empresa competidora y no están disponibles para la
compañía que hace la ingeniería inversa. En esencia, la ingeniería inversa
exitosa deriva en una o más especificaciones de diseño y fabricación para un
producto al examinar especímenes reales del mismo.

21. Reestructuración de código. El tipo más común de reingeniería (en realidad, en
este caso es cuestionable el uso del término reingeniería) es la reestructuración
de código. Algunos sistemas heredados tienen una arquitectura de programa
relativamente sólida, pero los módulos individuales fueron codificados en una
forma que los hace difíciles de entender, poner a prueba y mantener. En tales
casos, el código dentro de los módulos sospechosos puede reestructurarse. Para
realizar esta actividad se analiza el código fuente con una herramienta de
reestructuración.
Reestructuración de datos. Un programa
con arquitectura de datos débil será difícil
de adaptar y mejorar. De hecho, para
muchas aplicaciones, la arquitectura de
información tiene más que ver con la
viabilidad a largo plazo de un programa
que con el código fuente en sí

22. Ingeniería hacia adelante. En un mundo ideal, las aplicaciones se
reconstruirían usando un “motor de reingeniería” automático. El programa
antiguo se alimentaría en el motor, se analizaría, se reestructuraría y luego se
regeneraría de manera que mostrara los mejores aspectos de la calidad del
software. A corto plazo es improbable que tal “motor” aparezca, pero los
proveedores introdujeron herramientas que proporcionan un subconjunto
limitado de dichas capacidades y que abordan dominios de aplicación
específicos (por ejemplo, aplicaciones que se implementan usando un sistema
de base de datos específico). Más importante, dichas herramientas de
reingeniería se vuelven cada vez más sofisticadas.

23. La ingeniería inversa
puede extraer información de diseño a partir del código
fuente, pero el nivel de abstracción, la completitud de la
documentación, el grado en el que las herramientas y
un analista humano trabajan en conjunto, y la
direccionalidad del proceso son enormemente variables.

24. ACTIVIDADES DE
MANTENIMIENTO

25. Introducción
El desconocimiento de las actividades que implica el mantenimiento del software
puede inducir a minusvalorar su importancia, y se tiende a asociar el
mantenimiento del software con la corrección de errores en los programas.
Por esta causa, la impresión mas generalizada entre los gestores, usuarios,
e incluso entre los propios informáticos, es que la mayor parte del
mantenimiento que se realiza en el mundo es de tipo correctivo. Sin
embargo, varios autores ([McKee, 1984], [Frazer, 1992], [Basili et al., 1996])
indican que esta impresión es equivocada, mostrando cómo los mayores
porcentajes de esfuerzo se dedican a mantenimiento perfectivo (véase
Figura 3, tomada de Frazer [1992]).

26. Tareas del Mantenimiento
Comprensión
del SW y de
los cambios
Modificación
del SW
Realización
de Pruebas

27. Comprensión del SW y de los cambios a realizar
• Se deben conocer la funcionalidad, el objetivo, la
estructura interna y los requisitos.
• Si no respetamos esto, podríamos introducir nuevos errores
que nos lleven a más gastos por mantenimiento
adicionales.

28. Modificación del Software
• Se deben crear y modificar las estructuras de datos, la lógica de los
procesos, las interfaces y la documentación.
• Para evitar los efectos secundarios, los programadores deben conocer las
repercusiones de las modificaciones que van a introducir.

29. Realización de Pruebas
• Es necesario realizar pruebas para validar los cambios.
• Las pruebas verificaran que no se han introducido a la vez otros errores.
• Incluso el cambio más pequeño puede inducir defectos que reduzcan la
calidad y la fiabilidad del SW.

30. Partiendo de las distintas categorías:
• Comprensión de los cambios
• Modificación del software
• Realización de pruebas
Tareas del Mantenimiento
Identificar actividades de mantenimiento llevadas a
cabo por un analista/programador

31. Tareas del Mantenimiento
Categoría Actividad % Tiempo
Compresión del
software y de los
cambios a realizar
Estudiar las peticiones 18%
Estudiar la
documentación
6%
Estudiar el código 23%
Modificación del
Software
Modificar el código 19%
Actualizar la
documentación
6%
Realización de
pruebas
Diseñar y realizar
pruebas
28%

32. Dificultades del Mantenimiento
Se debe realizar el mantenimiento del SW de forma que la calidad no se
deteriore como resultado del proceso.
¿Cómo debe mantenerse el SW para preservar
su fiabilidad?

33. Código Heredado
• Con el paso de los años se ha ido produciendo un volumen muy grande
de SW.
• En la actualidad, la mayor parte del SW está formado por código
heredado (legacy code), es decir:
 Código desarrollado hace algún tiempo.
 Con técnicas y herramientas en desuso.
 Desarrollado por personas que ya no pertenecen al colectivo.
• En muchas ocasiones, la situación se complica porque el código
heredado fue objeto de múltiples actividades de mantenimiento.

34. Código Heredado – Leyes del mantenimiento del SW
Los problemas específicos del mantenimiento de código heredado han sido
caracterizados en las llamadas Leyes del Mantenimiento del Software
[Lehman, 1980]:
• Continuidad del Cambio: Un programa evoluciona con su entorno para no
hacerse obsoleto.
• Ideas de los usuarios.
• Nuevas características HW -> Mejoras SW.
• Corrección de defectos.
• Migración del sistema a otra máquina o SO.
• El software necesita ser más eficiente.

35. Código Heredado – Leyes del mantenimiento del SW
• Incremento de la Complejidad:
 Cuando un programa es modificado, se incrementa la complejidad de
la estructura del mismo, salvo que se haga un esfuerzo para evitarlo.
 Esto sucede cuando los programadores no utilizan técnicas de
Ingeniería del SW (en este caso no cuenta el mantenimiento
preventivo)

36. Código Heredado – Leyes del mantenimiento del SW
• Evolución del Programa
 Es un proceso autorregulado.
 La medición de determinadas propiedades (tamaño, tiempo entre
versiones, numero de errores) permiten evaluar esta tendencia.
• Conservación de la Estabilidad Organizacional
 La carga que supone el desarrollo de un sistema es aproximadamente
constante e independiente de los recursos dedicados.
• Conservación de la Familiaridad
 Durante todo el tiempo de vida de un sistema, el incremento en el
número de cambios incluidos con cada versión (release) es
aproximadamente constante.
 Según [Lehman et al, 1998], los grandes programas no llegan nunca a
completarse y están en constante evolución (Mantenimiento Perfectivo
y Adaptativo).

37. Además de las dificultades de mantenimiento que señalan las leyes anteriores,
existen otros problemas clásicos que complican el mantenimiento
[Schneidewind, 1987]:
• Problemas de carácter técnico
 Ausencia metodológica.
 Tendencia a la des-estructuración.
 Disminución de la comprensibilidad.
• Problemas de gestión

38. Además de las dificultades de mantenimiento que señalan las leyes anteriores,
existen otros problemas clásicos que complican el mantenimiento
[Schneidewind, 1987]:
• Problemas de carácter técnico
 Ausencia Metodológica
 Las metodologías no suelen contemplar la participación
del usuario.
 Si no se satisfacen las necesidades, hay que realizar un
esfuerzo adicional para adaptar el SW.
 Tendencia a la des-estructuración
 Documentación desfasada.
 El código no cumple los estándares.
 Incremento en el tiempo necesitado para comprender el
código.

39. Además de las dificultades de mantenimiento que señalan las leyes anteriores,
existen otros problemas clásicos que complican el mantenimiento
[Schneidewind, 1987]:
• Problemas de carácter técnico
 Disminución de la Comprensividad
 Los sucesivos cambios producidos por el mantenimiento hacen que el
código sea más difícil de modificar -> aumento de los costes.
 Según Sommerville [1992], “cualquier cambio conlleva la corrupción de la
estructura del software y, a mayor corrupción, la estructura del programa
se torna menos comprensible y más difícil de modificar”

40. Además de las dificultades de mantenimiento que señalan las leyes anteriores,
existen otros problemas clásicos que complican el mantenimiento
[Schneidewind, 1987]:
• Problemas de gestión
 Hay programadores que consideran el trabajo del mantenimiento como una
actividad inferior.
 Personas dedicadas al mantenimiento peores condiciones laborables y
salariales.
 Como resultado, al realizar un mantenimiento:
 No se emplea una estrategia sistemática.
 Correcciones realizadas con precipitación.
 No se documentan adecuadamente.
 Pobremente integradas con el código existente.

41. •Cambios en el Diseño = cambios en el
Código.
•Eliminación o modificación de un
Subprograma.
•Eliminación o modificación de una Etiqueta.
•Eliminación o modificación de un
•Identificador.
•Cambios para mejorar el Rendimiento.
•Modificación de la apertura/cierre de
Ficheros.
•Modificación de Operaciones Lógicas.
Código
Efectos Secundarios

42. • Redefinición de Variables Locales o
Globales.
• Modificación de Permisos de los
Archivos.
• Modificación de las Rutas de Acceso a
Ficheros.
• Modificación del Tamaño de una
Matriz.
• Reinicialización de Punteros.
• Cambios en los Parámetros de los
Subprogramas.
Datos
Efectos Secundarios

43. • Modificar el formato de las
Entradas Interactivas.
• Nuevos Mensajes de Error
no documentados.
• Tablas o Índices no
actualizados.
• Texto no actualizado
correctamente
Documentación
Efectos Secundarios

44. Soluciones al Problema del Mantenimiento del SW
• Desde un punto de vista financiero, el mantenimiento del SW es un continuo
consumidor de recursos (beneficios???).
• Se necesita un apoyo por parte de la dirección de las organizaciones, siendo
conscientes:
 Importancia de las tecnologías de la información.
 El SW es un activo corporativo que puede suponer una ventaja
competitiva.

45. Soluciones al Problema del Mantenimiento del SW
• Recursos dedicados al mantenimiento
• Gestión de la Calidad
• Gestión estructurada del mantenimiento
• Organización del equipo humano
• Documentación de los cambios
Gestión
• Reingeniería
• Ingeniería Inversa
• Restructuración del Software
Técnicas

46. Recursos dedicados al Mantenimiento
• Principal recurso para el mantenimiento es el humano.
• Constitución de un equipo dedicado con experiencia.
Gestión de la Calidad
• Aumento de Recursos => Solución a corto plazo.
• Métodos para aumentar la calidad, tanto del producto SW como del proceso
de producción (Estándares, Diseño paso a paso, Código Estructurado,…).
Soluciones de Gestión

47. Soluciones de Gestión
Gestión Estructurada del Mantenimiento
• La existencia de una adecuada Configuración del Software reduce la
cantidad de esfuerzo requerido y mejora la calidad.
• Partiendo desde este punto, se deben subdividir las tareas a desarrollar,
para así realizar un seguimiento directo sobre cada una de las etapas:
 Comprensión del SW y de los cambios a realizar.
 Modificación del SW.
 Realización de las pruebas.

48. Soluciones de Gestión
Organización del Equipo Humano
• Las tareas relacionados con el mantenimiento comienzan mucho antes de la
primera petición.
• Establecer las personas que participarán en cada actividad.
• Delegación de responsabilidades [Pressman, 1993]:
 Controlador del Mantenimiento (gestión).
 Supervisor del sistema SW (Conocimiento).
 Gestor de la configuración (actualiza SW).
 Desarrollador de mantenimiento (codificación)

49. Soluciones de Gestión
Documentación de los cambios
• Información del programa.
• Tamaño: LDC programa fuente y ejecutable.
• Lenguaje de programación.
• Fecha de instalación del programa.
• Número de ejecuciones del programa desde la instalación.
• Número de fallos.
• Numero de sentencias añadidas, modificadas y eliminadas.
• Número de personas/hora.
• Persona responsable del cambio.
• Identificación de la petición.
• Tipo de mantenimiento.
• Fecha de inicio y fin de mantenimiento.
• Beneficios netos que supone el cambio

50. Soluciones de Técnicas
Herramientas
• Ayudan al personal de mantenimiento, a la hora de comprender el
problema y probar las modificaciones.
• Muchas de estas herramientas son similares a las utilizadas en las
pruebas de SW:
 Depuradores
 Generadores de Datos de Prueba
 Documentadores
 Comparadores

51. Soluciones de Técnicas
Métodos
• Reingeniería
 Examen y Modificación de un sistema para reconstruirlo de una
nueva forma [Bennett, 1990].
• Ingeniería Inversa
 Proceso de analizar un sistema para identificar sus componentes
y las interrelaciones que existen entre ellos. [Chikofsky y Cross,
1990].
• Reestructuración del Software
 Modificación del software para hacerlo más fácil de entender y
cambiar [Arnold, 1986].

52. Mantenibilidad
• Medida cualitativa de la facilidad de comprender, corregir,
adaptar y/o mejorar el Software [Pressman, 1993].
• Hay muchos factores que influyen en la mantenibilidad.
Los más principales son:
 Proceso de Desarrollo.
 Comprensión de Programas.
 Documentación.

53. Mantenibilidad
Resumiendo…
• Debemos considerar el SW como un producto que estará
sujeto a cambios casi con total seguridad.
• Diseñar etapas previas considerando la mantenibilidad.
• Realizar una documentación estricta y estandarizada
desde el primer desarrollo hasta el último mantenimiento

54. Mantenibilidad
Son:
• Propiedades
• Métricas
Propiedades
• Reparabilidad
Un sistema SW es reparable si permite la corrección de sus defectos con una
cantidad de trabajo limitada y razonable.
• Flexibilidad
Un sistema SW es flexible si permite cambiar o incrementar sus
funcionalidades con una cantidad de trabajo limitada y razonable.

55. Mantenibilidad
Métricas
Criterios Metricas
Simplicidad • Nº de sentencias
• Frecuencia de operandos
Concisión • Longitud de programa
• Nivel de módulo
Autodescriptivo Frecuencia de comentario
Legibilidad Longitud de programa
Nº de sentencias
Facilidad de prueba Numero de pruebas

56. Métodos de Mantenimiento de SW
Conceptos Básicos
Reingeniería del SW
• Análisis y modificación de un sistema para reconstruirlo en una nueva forma
[Bennett et al., 1990].
• Beneficios…
 Ayuda a la gestión y automatización de las actividades de mantenimiento.
 Reducción del esfuerzo de mantenimiento.
 Reutilización de componentes
Ingeniería Inversa
• Es el proceso de análisis de un sistema para identificar sus componentes e
interrelaciones [CHIKOFSKY, 1990].
• Recuperación de diseño:
 Observación del sistema.
 Conocimientos sobre su dominio de aplicación.
 Información externa.
 Procesos deductivos.

57. Métodos de Mantenimiento de SW
Conceptos Básicos
Reestructuración
• Es la transformación de un sistema a otro en el mismo nivel de abstracción
relativo, manteniendo su comportamiento externo (funcionalidad y
semántica) [CHIKOFSKY, 1990].
• Es la modificación del software para hacerlo más fácil de entender y cambiar”
[ARNOLD, 1993]
Ingeniería Directa
• Desarrollo inicial de un sistema, basándose en una metodología o proceso
del software estandarizado.
Redocumentación
• La creación de información correcta y actualizada del SW

58. Métodos de Mantenimiento de SW
Proceso de Reingeniería del SW

59. Métodos de Mantenimiento de SW
Costes y Beneficios de la Reingenieria
• Antes de reconstruir un sistema en explotación, es altamente
recomendable analizar las alternativas:
 Dejar el producto como está.
 Adquirir uno en el mercado que realice la misma función.
 Reconstruirlo.
• Evidentemente, elegiremos la opción con mejor relación coste/beneficio.

60. Métodos de Mantenimiento de SW
Costes y Beneficios de la Reingenieria
Para calcular los costes de un proyecto de Reingeniería, Sneed [1995]
propone un modelo basado en cuatro etapas:
• Justificación del Proyecto de Reingeniería.
• Análisis de la cartera de aplicaciones.
• Estimación de costes.
• Análisis de costes Vs. Beneficios.