Tema 1
Summary: Tema 1 Mantenimiento del Software
1. Introducción
Para comenzar con la discusión de este capítulo hace falta entrar en materia con alguna definición. La definición posiblemente más utilizada de la Ingeniería del Software es la siguiente (IEEE, 1990):
- La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, la operación y el mantenimiento1 del software; esto es, la aplicación de la ingeniería al software.
- El estudio de enfoques como los mencionados en (1).
En la propia definición aparece el mantenimiento como una de las actividades de la Ingeniería del Software. Ahora bien ¿en qué se diferencia el mantenimiento de otras actividades de la Ingeniería del Software? – concretamente, ¿en qué se diferencia de lo que se suele denominar “desarrollo”?. Para clarificar esta delimitación, hay que buscar un criterio que separe unas actividades de las otras, como se intentará a lo largo de este documento.
No obstante, como primera aproximación, podemos decir que las actividades de mantenimiento del software son actividades de Ingeniería del Software orientadas a la modificación o cambio del mismo (por diferentes motivos, que se verán más adelante). El cambio tiene como característica fundamental el hecho de que primero se necesita una comprensión del objeto que se ha de cambiar, para poder hacer efectiva la modificación. Esto hace que la comprensión del software como actividad humana, sea un elemento esencial en la Ingeniería del Software. Es decir, es conveniente que el software tenga una estructura y una documentación asociada que facilite su comprensión.
La importancia del mantenimiento es de carácter económico – como toda actividad de Ingeniería. Podemos partir de la siguiente afirmación.
En un sistema que es fácilmente mantenible, se puede implementar un cambio con un menor esfuerzo que en un sistema que es menos mantenible.
Esto nos lleva a pensar que puede resultar rentable el hacer el software más mantenible. Claro está, esto solo será así si los cambios son frecuentes en el software. Esto nos conduce a una segunda afirmación, en este caso de carácter empírico.
Todo software evoluciona para adaptarse a las necesidades de sus usuarios.
La combinación de los dos enunciados – que más adelante se volverá a tratar en el contexto de las Leyes de la Evolución del Software – nos indica que es importante prever la mantenibilidad (es decir, la “facilidad de mantenimiento”), aún antes de la entrega del producto.
El estado de la práctica del mantenimiento del software
Diferentes estudios han resaltado que el esfuerzo consumido en mantenimiento del software es en proporción al tiempo de desarrollo, muy elevado, con cifras entre el 50% y el 80% dependiendo de los estudios. En cualquier caso, es claro que el mantenimiento es una -actividad que consume muchos recursos.
Las actividades de mantenimiento incluyen entre otros, los siguientes elementos:
- Es necesario comprender el software y comprender los cambios que se deben realizar.
- Es necesario modificar el software y actualizar la documentación.
- Es necesario volver a realizar las pruebas del software (prueba de regresión), además de probar específicamente las partes añadidas.
Además de esos costes directos, hay costes ocultos que son de gran importancia, como:
- oportunidades de desarrollo que se han de posponer o que se pierden, debido a que los recursos disponibles están dedicados a las tareas de mantenimiento.
- Insatisfacción del cliente cuando no se puede atender en un tiempo aceptable una petición de reparación o modificación que parece razonable.
- Los errores ocultos introducidos al cambiar el software durante el mantenimiento reducen la calidad global del producto.
- Perjuicio en otros proyectos de desarrollo cuando la plantilla tiene que dejarlos, total o parcialmente, para atender peticiones de mantenimiento.
En 1970 ya se había popularizado el término “Crisis del Software” para referir a la situación que acabamos de describir. Los síntomas de esta crisis han estado repercutiendo desde entonces en la industria de desarrollo de software y todavía se sienten sus efectos. Para resolver el problema surgió un área de la informática que recibe el nombre de Ingeniería del Software.
Una de las principales causas de esta situación ha sido la poca importancia que se le ha dado al proceso de Mantenimiento del Software
El mantenimiento del software como un caso especial de mantenimiento
El software no se deteriora con el uso ni con el paso del tiempo, a diferencia de los materiales mecánicos que son producto de otras actividades de ingeniería. Mejor dicho, no sufre de un deterioro físico. No obstante, se suele considerar que el software tiene un deterioro en su estructura, cuando a lo largo del tiempo se van incluyendo más y más cambios que hacen que su estructura interna sea cada vez más difícil de entender. En ocasiones se ha denominado a este fenómeno como “erosión del diseño”.
Esta idea del deterioro de la estructura da lugar a la idea relacionada de la mantenibilidad. La mantenibilidad es una propiedad del diseño del software relativa a su facilidad de mantenimiento. Esto lleva a que en ocasiones se introduzcan cambios en el software sólo para hacerlo más mantenible, lo cual rara vez se encuentra en otras ramas de la ingeniería.
2. ¿Qué es el mantenimiento del software?
La consideración de qué tipo de actividades de Ingeniería del Software se consideran mantenimiento ha evolucionado en el tiempo. Es importante conocer las diferentes definiciones, ya que las actividades de mantenimiento suelen regirse por contratos de mantenimiento que deben especificar la responsabilidad de las partes en las actividades post-entrega. Además, en algunas concepciones del mantenimiento, este no cubre además actividades previas a la entrega del software.
El mantenimiento como actividad post-entrega
Cualquier esfuerzo de Ingeniería del Software – si termina con éxito – acaba por producir un determinado producto software, orientado a satisfacer ciertos requisitos previamente establecidos. El mantenimiento en este contexto se entiende de manera general como las actividades de cambio de ese producto. Ahora bien, el cambio se puede entender de diferentes maneras.
Comenzando por lo básico, la definición de “Mantenimiento del Software” del estándar IEEE 1219 es la siguiente.
|
|
El mantenimiento del software es la modificación de un producto software después de la entrega para corregir fallos, para mejorar el rendimiento u otros atributos, o para adaptar el producto a un entorno modificado. |
Esta definición implica que las actividades de mantenimiento de un producto comienzan en el tiempo sólo después de que el producto se ha entregado, es decir, después de que el producto está en operación. No obstante, en ocasiones se considera que algunas actividades de mantenimiento puede comenzar antes de la entrega del producto.
|
|
Se puede considerar que ciertas actividades de mantenimiento comienzan antes de la entrega. Algunas de estas actividades son la planificación de las actividades posteriores a la entrega, así como toda actividad orientada a facilitar el mantenimiento, como la revisión de la documentación. No obstante, estas pueden considerarse actividades de preparación para el mantenimiento, más que de mantenimiento en sí. |
Una vision más amplia del mantenimiento del software
Por ejemplo, Pigoski (1997) resalta que hay una necesidad de comenzar a considerar el mantenimiento desde el mismo momento en que comienza el desarrollo:
|
|
El mantenimiento del software es la totalidad de las actividades necesarias para proporcionar soporte económico (cost-effective) al sistema software. Estas actividades se desarrollan tanto antes como después de la entrega. Las actividades previas a la entrega incluyen la planificación de las operaciones posteriores a la entrega, planificación del soporte y determinación de la logística. Las actividades posteriores a la entrega incluyen la modificación del software, la formación de usuarios, y la operación de un help desk. |
Como se ve, hay una diferenciación en las diferentes definiciones entre actividades pre- y post- entrega del software.
Para clarificar los conceptos, en esta obra diferenciaremos entre:
- actividades de mantenimiento propiamente dichas (posteriores a la entrega) y
- actividades de preparación para el mantenimiento.
El criterio para diferenciarlo de otras actividades es el hecho de la entrega del producto software. Se debe tener en cuenta que en ocasiones esa entrega es un acto formal dentro de un contrato, pero en muchas otras es una simple decisión de disponibilidad pública de un grupo de desarrollo. Por ejemplo, en los proyectos de fuente abierto, desarrollados de manera voluntaria, el qué es una entrega lo determinan los propios desarrolladores cuando piensan que la funcionalidad implementada ha llegado a un determinado nivel.
|
|
La guía SWEBOK considera que el mantenimiento ocurre durante todo el ciclo de vida, y coincide en su definición con la de Pigoski antes mencionada. |
Es importante resaltar que el concepto de mantenimiento del software difiere de la concepción de mantenimiento en otras disciplinas de ingeniería. Esto es debido a que el software no se “deteriora” con el uso. En la ingeniería mecánica, el mantenimiento consiste en las acciones de reparación necesarias para que la máquina o sistema mecánico siga funcionando. En la Ingeniería del Software, el mantenimiento tiene un significado más amplio, cubriendo su adaptación a necesidades
3. La evolución del software
Las Evolución del software
El término “evolución” del software se utiliza desde los sesenta para denominar la dinámica de crecimiento del software. Una definición atribuida a Lehman y Ramil dice que la evolución del software es “todas las actividades de programación que se orientan a generar una nueva versión de un software a partir de una versión anterior operativa. Ned Chapin (1999) lo definió como “la aplicación de las actividades y procesos de mantenimiento del software que generan una nueva versión operative de un software con una funcionalidad de usuario o propiedades cambiadas a partir de una versión anterior […] junto con los procesos y actividades de garantía de calidad y con la gestión de esos procesos”. De estas definiciones se desprende que la evolución cubre el ajuste a funcionalidades adicionales.
|
|
La guía SWEBOK considera que la causa del mantenimiento está tanto en la necesidad de “cambios” como de “evolución” en el software. |
Las Leyes de la Evolución del software
Lehman (1974) formuló las primeras “leyes de la evolución del software” por primera vez a partir de un estudio del proceso de programación en IBM. Con el tiempo, se han llegado a formular ocho de estas leyes. Una ley es según el Diccionario de la Academia de la Lengua Española “regla y norma constante e invariable de las cosas, nacida de la causa primera o de las cualidades y condiciones de las mismas”. En el ámbito de ciencias de la ingeniería, una ley debe entenderse como una característica común a muchos fenómenos o que se presenta con regularidad. La siguiente Tabla resume la formulación de las leyes del mantenimiento tal y como se describen en (Lehman, 1997). Todas ellas hacen referencias a programas “de tipo E”, es decir, a aquellos programas destinados a solucionar un problema del mundo real determinado.
Cada ley se puede poner como un LO:
| Ley | Enunciado | Notas |
| I | Cambio continuo. Un programa de tipo-E que se utiliza debe adaptarse continuamente, en caso contrario, el programa se hace progresivamente menos satisfactorio. | Esas adaptaciones son el resultado del cambio en la operación del entorno en el cual la aplicación cumple una función. |
| II | Complejidad creciente. A medida que evoluciona un programa, su complejidad se incremente, a menos que se trabaje para mantenerla o reducirla. | Esta ley implica un tipo de “degradación” o “entropía” en la estructura del programa. Esto a su vez implica un aumento progresivo del esfuerzo de mantenimiento, a menos que se realice algún tipo de mantenimiento perfectivo a este respecto. |
| II | Autorregulación. El proceso de evolución del programa se auto-regula con una distribución de medidas de atributos de producto y procesos cercana a la normal. | La evolución de programas industrial tipo-E se lleva a cabo por un equipo que opera en una organización más grande. Las decisiones de gestión respecto a los cambios en el programa constituyen una dinámica que determina las características de crecimiento del producto. |
| IV | Conservación de la estabilidad organizativa (velocidad de trabajo invariante).La velocidad de actividad global efectiva media en un sistema en evolución es invariante a lo largo del ciclo de vida del producto. | Usualmente se considera que el esfuerzo gastado en la evolución del sistema se determina por decisiones de dirección. Esto es por supuesto así en un cierto grado, pero su influencia está limitada por factores externos respecto al empleo, la disponibilidad de personal competente, etc. No obstante, también influyen los atributos del sistema, por ejemplo, la complejidad. Los datos empíricos sugieren que la actividad lleva a una estabilización de actividad aproximadamente constante. |
| V | Conservación de la familiaridad. Durante la vida activa de un programa en evolución, el contenido de las versiones sucesivas es estadísticamente invariante. | Uno de los factores que determina el progreso de un desarrollo de software es la familiaridad de todos los implicados. Cuantos más cambios y adiciones se hacen a una versión, es más difícil que todos los implicados la conozcan. Debido a que el crecimiento está limitado por la capacidad de adquirir información de los participantes, una evolución “grande” dificultaría ese aprendizaje, por lo que los cambios tienden a ser de un tamaño parecido y limitado. |
| VI | Crecimiento continuoEl contenido funcional de un programa debe incrementarse continuamente para mantener la satisfacción del usuario durante su ciclo de vida. | Esta ley refleja un aspecto del mismo fenómeno que refleja la primera. Habitualmente, los sistemas se crean con una limitación en cuanto a la funcionalidad del dominio cubierta, por motivos de tiempo o recursos. Esto hace que con el tiempo, los requisitos que se descartaron vuelvan a aparecer como necesidades. |
| VII | Calidad decrecienteLos programas de tipo-E serán percibidos como de calidad decreciente a menos que se mantengan de manera rigurosa y se adapten al entorno operativo cambiante. | Esta percepción de la calidad decreciente tiene que ver con los cambios en los criterios de aceptabilidad de los usuarios. |
Estas leyes no son otra cosa que el resultado del estudio científico de experiencia acumulada en Ingeniería del Software. Como tales, nos pueden servir como base para la planificación de las actividades de mantenimiento y para la toma de decisiones al respecto.
4. El mantenimiento en el ciclo de vida del software
La guía SWEBOK considera el siguiente esquema de actividades para los cambios del software.
 |
Lo fundamental del esquema de actividades es que un cambio en el software sigue un “micro-ciclo” completo de ingeniería, al que debe preceder una actividad específica de clasificación, identificación y toma de decisiones respecto a los cambios que por diversos motivos deben hacerse en el software.
4. Tipos de actividades de mantenimiento del software
De la definición de mantenimiento del estándar IEEE 1219 cabe distinguir tres causas fundamentales que desencadenan las actividades de mantenimiento.
|
|
Las causas u origen de las actividades de mantenimiento del software pertenecen a tres grupos principales: FIXME: A LIST CAN NOT BE A TABLE ENTRY. Eliminación de defectos del producto software.Adaptar el producto software a Incluir mejoras en el diseño. |
Las causas por tanto son todas ellas resultado de tener que modificar el software para que cumpla con los requisitos del usuario ya establecidos (caso 1), para que siga cumpliéndolos cuando cambia su entorno (caso 2), o cuando se quiere mejorar la manera en que los cumple (caso 3). Por otro lado, la definición anterior implica que el mantenimiento debido a los defectos es a posteriori, es decir, se desencadena cuando el defecto tiene como resultado un fallo que se detecta. En ocasiones, se realizan actividades de mantenimiento preventivo, que intentan detectar y corregir fallos latentes (que se supone pueden existir, aunque aún no se han “manifestado”)
Estas causas tienen su correlación directa con las denominadas “categorías de mantenimiento”, que en el estándar ISO/IEC 14764 incluye las siguientes categorías.
|
|
Las categorías fundamentales de mantenimiento definidas por Lientz y Swanson (1978) son: FIXME: A LIST CAN NOT BE A TABLE ENTRY. Mantenimiento correctivo: modificaciones reactivas a un producto software hechas después de la entrega para corregir defectos descubiertos.Mantenimiento adaptativo: modificación de un producto software realizada después de la entrega para permitir que un producto software siga pudiéndose utilizar en un entorno diferente.Mantenimiento perfectivo: modificación de un producto software después de la entrega para mejorar el rendimiento o la mantenibilidad. |
Una consecuencia importante de las definiciones anteriores es que no se considera mantenimiento a los cambios introducidos para incluir nuevos requisitos funcionales. No obstante, no hay un consenso unánime en este sentido, y de hecho, el concepto de evolución del software, que tratamos a continuación, amplía el espectro del mantenimiento a cambios en un sentido amplio. De hecho, hay autores que consideran que el mantenimiento perfectivo sí incluye cambios en la funcionalidad. De hecho, las categorías adaptativa y perfectiva son ambas mejoras, en contraposición el mantenimiento correctivo.
El estándar ISO/IEC 14764 clasifica las categorías comentadas hasta ahora según la siguiente Tabla, que nos puede ayudar a ver sus diferencias.
| Corrección | Mejora | |
| Proactiva | Preventivo | Perfectivo |
| Reactiva | Correctivo | Adaptativo |
Por último, un estándar de mantenimiento del IEEE (1998) define una categoría adicional, la de mantenimiento de emergencia, cuando los cambios se deben hacer sin planificación previa, para mantener un sistema en operación.
Footer
More about this content: Metadata | Version History
This work is licensed by Verónica De la Morena under a Creative Commons Attribution License (CC-BY 2.0).
Last edited by Verónica De la Morena on Sep 4, 2008 10:48 am GMT-5.