PRACTICA DE FUNDAMENTOS DE

INGENIERÍA DEL SOFTWARE

CURSO: 2009-10

GRUPO 1.5

Luis Villazón Esteban

TEMA: Mantenimiento de Sistemas de Información.

Esta obra está bajo una licencia Reconocimiento-No comercial 3.0 España de Creative
Commons. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-
nc/3.0/es/ o envie una carta a Creative Commons, 171 Second Street, Suite 300, San Francisco,
California 94105, USA.

2
Índice
1. Desarrollo Conceptual ....................................................................................................... 4
2. Desarrollo Metodológico ................................................................................................... 8
3. Aportaciones Personales ................................................................................................. 22
4. Bibliografía ...................................................................................................................... 27
5. Presentación ................................................................................................................... 28

3
 1. Desarrollo Conceptual

Índice Conceptual
1. Definiciones Inherentes al Mantenimiento

2. Tipos de Mantenimiento

3. Costes del Mantenimiento

4. Factores del Mantenimiento

5. Reingeniería

6. Ingeniería Inversa

Definiciones inherentes al Mantenimiento

Mantenimiento: Llamamos mantenimiento a las modificaciones que se realizan en el
producto software después de la entrega al usuario. Estas modificaciones podrán ser
realizadas para mejorar el rendimiento, corregir defectos, adaptar el producto software a un
nuevo de entorno, software o hardware, u otras propiedades deseables en el producto.

Barrera de Mantenimiento: Se define como el porcentaje máximo o límite de los recursos

que son necesarios para el mantenimiento del software. El llegar a la barrera de
mantenimiento imposibilitaría la realización de nuevos desarrollos.

Actividades de Mantenimiento: También llamadas Proceso de Mantenimiento, son cada

una de las actividades que se deben realizar en el proceso del mantenimiento, estas
actividades serán: Gestión de peticiones, comprensión del software y de los cambios que se
deben realizar sobre el mismo, modificación del software (modificando código y actualizando
documentación) y realización de pruebas.

4
Tipos de Mantenimiento
Correctivo: Se trata del mantenimiento que se realiza a cabo para corregir los errores
detectados durante la explotación del sistema.

Perceptivo (evolutivo): Se trata del mantenimiento que se realiza para mejorar o añadir
alguna característica nueva al programa. Es el mantenimiento que mayor coste supone (hasta
un 60% relativo respecto al resto de mantenimientos).

Adaptativo: Se trata del mantenimiento llevado a cabo para adaptar el sistema a un nuevo
entorno tecnológico (software, hardware, etc.).

Preventivo/ perfectivo (reingeniería): Se trata del mantenimiento que se realiza para

prevenir futuros problemas o para facilitar el mantenimiento futuro del sistema.

Costes del Mantenimiento

Definición: Los costes del Mantenimiento se refieren a los costes tanto en tiempo como
dinero y recursos de la empresa que son utilizados para la realización del proceso de
mantenimiento. Puede suponer hasta el 80%-90% del coste total del ciclo de vida del Software.
Existen dos tipos, Directos e Indirectos.

Directos: Son los costes referidos a las actividades de Mantenimiento enumeradas

anteriormente. La comprensión del software y los cambios a realizar en el mismo suponen
prácticamente el 50% del coste y las pruebas un 28%.

Indirectos: Son los costes ajenos a la realización del mantenimiento y no involucrados

directamente en el ciclo de vida del Software, entre los cuales se pueden encontrar los
siguientes:

Costes de Mantenimiento Indirectos (Insatisfacción del Cliente): Se refiere a la

imposibilidad de realizar en un tiempo razonable una petición de mantenimiento.

Costes de Mantenimiento Indirectos (Deterioro del Software): Al modificar el software

en el proceso de mantenimiento se puede producir una disminución de la calidad y aparición
de nuevos errores en el software.

Costes de Mantenimiento Indirectos (Perdida de Oportunidades): Al utilizar

demasiados recursos en el proceso de mantenimiento es posible que se dejen de realizar
nuevos desarrollos al carecer de los recursos necesarios.

5
Factores del Mantenimiento
Definición: Se tratan de factores que dificultan el mantenimiento del software, entre los
cuales se encuentran:

Código Heredado: Código antiguo, el cual la mayoría fue construido para ocupar poco
espacio, sin importar la eficiencia, diseño y mantenimiento del mismo. A su vez el código se
encuentra muy deteriorado lo que aumenta el coste y la dificultad de su mantenimiento.

Evolución del Software: El software va sufriendo cambios a lo largo del tiempo, lo que
disminuye su calidad y lo hace menos eficiente, aumentando su complejidad y deteriorándolo.
Si tampoco se ha llevado un control de la documentación su mantenimiento se vuelve más
costoso.

Ausencia de herramientas: No se utilizan herramientas, métodos ni técnicas que faciliten la

realización del mantenimiento. Por lo tanto la mayoría de las veces el mantenimiento se
realiza Ad-hoc.

Reingeniería
Definición: Alternativa al mantenimiento. Modificación del producto software o
componentes del mismo para mejorar su mantenimiento futuro.

La reingeniería del software se compone de los siguientes pasos:

Análisis de inventarios: Lista con información de las aplicaciones candidatas a la

reingeniería, ordenadas para conocer cual son las mejores candidatas para la misma.

Restructuración de documentos: Realizar la documentación necesaria para llegar

comprender el sistema y hacer que el software sea más fácil de entender y cambiar. También
se puede definir como una representación funcionalmente equivalente dentro de un mismo
nivel de abstracción.

Ingeniería inversa: Es el proceso de analizar un programa con la finalidad de conocer su

comportamiento. De esta forma se logra una representación del programa con una mayor
abstracción que la ofrecida por el código fuente y proporciona información del diseño y la
arquitectura del programa.

Ingeniería directa: También llamada renovación, consiste en utilizar los principios, métodos
y conceptos de la ingeniería del software para volver a implementar la aplicación.
6
Herramientas CASE: Se tratan de Aplicaciones destinadas a facilitar y aumentar la
productividad en el desarrollo Software. Uno de los objetivos de la Reingeniería es capturar
información en un repositorio que será utilizado posteriormente por estas herramientas.

Migración: Consiste en trasladar la aplicación de un sistema a otro nuevo en condiciones de

compatibilidad. La reingeniería facilita esta acción.

Esperanza de vida: Es el tiempo que la aplicación puede estar funcionando sin presentar
inconvenientes graves. La reingeniería permite aumentar la esperanza de vida de la aplicación.

Prototipo de Software: Versión inicial de una aplicación Software la cual se va refinando a

través de diferentes versiones. Aumenta la productividad al utilizarse Ingeniería Directa.

Ingeniería inversa
Extracción de Abstracciones: Extracción a partir del código fuente una documentación
significativa del proceso que se realiza, así como de la interfaz de usuario y de las estructuras
de datos que se utilizan.

Completitud: Se refiere al nivel de detalle que se obtiene, a medida que aumenta el nivel de
abstracción la completitud disminuye.

Interactividad: Se refiere al grado con el cual las personas se integran con las herramientas
de ingeniería inversa, para de este modo crear un proceso más efectivo. A medida que crece la
abstracción hay que aumentar la interactividad.

Direccionalidad Monodireccional: toda la documentación extraída del código fuente se

utilizará para facilitar la actividad de mantenimiento.

Direccionalidad Bidireccional: documentación obtenida del código fuente se utiliza

adicionalmente para el proceso de ingeniería directa.

7
 2. Desarrollo Metodológico

Previo
Para la realización del desarrollo metodológico se ha decido utilizar el modelo unificado como
modelo de procesos, por lo tanto se va a utilizar un enfoque orientado a objetos, pues este
modelo de procesos nos obliga a ello. A su vez, dentro del modelo de procesos se incluye la
utilización de prototipos como una actividad del modelo.

Para la realización del desarrollo se ha realizado un Estudio de Viabilidad del Sistema, y se ha

decidido realizar un desarrollo a medida, no utilizando por ello otros tipos de desarrollo como
el desarrollo por componentes.

Debido a que el mantenimiento depende de actividades previas del ciclo de vida, se tendrá en
cuenta aquellas actividades realizadas que condicionan el desarrollo de la actividad propuesta,
en este caso estas actividades son “Preparación del mantenimiento del Sistema” y
“Establecimiento del acuerdo de nivel de Servicio” , ambas pertenecientes al proceso de
Implantación y Aceptación del Sistema.

Los tipos de mantenimiento que se van a realizar en el desarrollo metodológico van a ser el
mantenimiento correctivo y el perfectivo o evolutivo, ya que ambos se encuentran
estrechamente relacionados. Los mantenimientos adaptativo y preventivo se dejan fuera de
este desarrollo debido a que quedan fuera del alcance del mismo y no son contemplados en el
proceso de Mantenimiento de Sistemas de Información de Métrica v3.

Inventario de Actividades y Tareas

Actividad MSI 1: Registro de la Petición
Tarea
MSI 1.1 Registro de la Petición.
MSI 1.2 Asignación de la Petición.

8
Actividad MSI 2: Análisis de la Petición.
Tarea
MSI 2.1 Verificación y Estudio de la Petición.
MSI 2.2 Estudio de la Propuesta de la Solución.

Actividad MSI 3: Preparación de la Implementación de la Modificación.

Tarea
MSI 3.1 Identificación de Elementos Afectados.
MSI 3.2 Establecimiento del Plan de Acción.
MSI 3.3 Especificación del Plan de Pruebas de Regresión.

Actividad MSI 4: Seguimiento y Evaluación de los Cambios hasta la Aceptación.

Tarea
MSI 4.1 Seguimiento de los Cambios.
MSI 4.2 Realización de las Pruebas de Regresión.
MSI 4.3 Aprobación y Cierre de la Petición.

Diagrama de Actividades

Desarrollo de la Actividad
Para la realización de este apartado se ha decidido desarrollar la actividad 2 del
Mantenimiento de Sistemas de Información (MSI): Análisis de la petición.

Descripción de la Actividad: productos de entrada, descripción de la actividad,

productos de salida, técnica y participante
En esta actividad, como su propio nombre indica, se llevará a cabo un análisis de la petición y
un diagnóstico de la misma para dar una respuesta sobre la decisión tomada en la misma, es
decir, si la petición ha sido aceptada, o rechazada.

9
En caso de que la actividad haya sido aceptada se llevará a cabo un análisis del alcance que
tiene la petición, estimando cual sería el alcance de la misma en el ciclo de vida de la
aplicación, llegando el caso de estudiar la necesidad de desviar la petición a un nuevo proceso,
en este caso Viabilidad del Sistema (EVS) o Análisis de Información (ASI).

Por último el enfoque sobre el que se realiza esta actividad, se verá afectada por el tipo de
mantenimiento que se va a realizar, siendo diferente el enfoque que se realiza sobre un tipo
de mantenimiento correctivo que sobre un mantenimiento evolutivo.

Productos de Entrada
 Plan de Mantenimiento (IAS 7.2).
 Acuerdo de Nivel de Servicio (IAS 8.3).
 Catálogo de Peticiones (MSI 1.2).
 Resultado del Estudio de la Petición (MSI 2.1).

Productos de Salida
 Catálogo de Peticiones
o Verificación de la Petición.
o Estudio del Impacto.
o Aceptación / Rechazo de la Petición.
 Resultado del Estudio de la Petición.
 Propuesta de la Solución.

Técnicas y Prácticas
 Sesiones de Trabajo.
 Catalogación.

Participantes
 Responsable de Mantenimiento.
 Equipo de Mantenimiento.

Inventario de Tareas de la Actividad Seleccionada

Verificación y Estudio de la petición
Antes de iniciar el estudio de la petición, se verifica que la información registrada es correcta.
Para determinar su validez:

10
 o Si se trata de un mantenimiento correctivo, se debe reproducir el problema.

o En el caso de un mantenimiento evolutivo, hay que comprobar que la petición

es razonable o factible.

Una vez examinada la petición comienza su estudio, que será diferente en función del tipo de
mantenimiento establecido:

o Si se trata de una petición de mantenimiento correctivo, y según el acuerdo de

nivel de servicio establecido para los sistemas de información afectados, se
evalúa hasta qué punto es crítico el problema. Así es posible determinar si la
solución es a corto plazo, es decir, urgente o inmediata, o si es a medio o a
largo plazo:

 Si el problema es crítico, su análisis y solución comienza

inmediatamente con el fin de reanudar rápidamente el nivel de
servicio. Sin embargo, este modo de actuación no elimina la necesidad
de una revisión posterior del problema para valorar los posibles
efectos secundarios, establecer una solución definitiva y actualizar
todos los productos implicados.

 Si no es crítico, la petición se clasifica para proceder en la tarea

siguiente a determinar cuál es la solución más adecuada.

o En el caso de un mantenimiento evolutivo se delimita su alcance

determinando si se trata de una modificación a los sistemas de información
inicialmente afectados o de una incorporación para cubrir nuevas
funcionalidades no contempladas hasta el momento en dichos sistemas de
información.

Estudio de la Propuesta de Solución

A partir del catálogo de peticiones, y para cada una de ellas, se estima su alcance valorando la
prioridad inicialmente asignada, de acuerdo a los requisitos planteados. A continuación, se
analiza la relación entre peticiones. Se decide cuáles pueden abordarse de forma conjunta
asignando, si procede, una prioridad global a los grupos identificados y determinando en qué
secuencia deben implementarse los cambios.

11
Asimismo, es necesario concretar los requisitos solicitados para cada petición y analizar con
más detalle los sistemas de información implicados, valorando las características de
mantenimiento de los mismos y la cantidad de cambios sufridos desde su puesta en
producción.

También se debe comprobar la existencia de otras peticiones en curso que afecten a los
mismos sistemas de información, evaluando la repercusión que puede tener la realización de
la petición de mantenimiento sobre estos cambios o desarrollos y analizar su convivencia.
Además, se analiza el impacto que la modificación puede provocar en el entorno tecnológico y
en los niveles de servicio inicialmente acordados para cada uno de los sistemas de
información, valorando hasta qué punto pueden verse comprometidos.

En el caso de una petición de mantenimiento evolutivo, se estudia cómo atenderla teniendo

en cuenta la política de versiones vigente en ese momento. Si se trata de una incorporación o
eliminación, se determina la necesidad de llevar a cabo algunas actividades del proceso
Análisis del Sistema de Información de modo previo a la identificación de los elementos
afectados.

Igualmente, se puede tomar la decisión de abordar el proceso Estudio de Viabilidad del

Sistema atendiendo a los requisitos a cubrir, al alcance de la modificación, a las implicaciones
en el entorno tecnológico, y al ciclo de vida estimado para los sistemas de información
afectados, así como a la existencia de opciones de mercado más idóneas.

En el caso de peticiones de mantenimiento correctivo que hayan precisado de una solución de

emergencia, no se darán por cerradas hasta que, o bien se compruebe que con dicha solución
el sistema no se ha visto comprometido ni tampoco otros sistemas relacionados con él, o bien
que después de haber aplicado una solución a corto/medio plazo y realizadas las pruebas
pertinentes, el sistema conserva su integridad y operatividad. Por tanto, una vez que se ha
reanudado el servicio, hay que realizar las restantes actividades para detectar el origen del
problema y asegurar que los cambios introducidos no generan otros de mayor envergadura o
comprometen el correcto funcionamiento de otros sistemas de información relacionados.

En cualquiera de las situaciones anteriores, se hace una estimación preliminar del esfuerzo
requerido mediante los indicadores establecidos en el acuerdo de nivel de servicio para cada
sistema de información, según la tecnología aplicada, naturaleza y tamaño del sistema de
información y los tipos de lenguajes utilizados, bases de datos, etc.

12
Por último, si se considera necesario, hay que proponer alternativas de solución para dar
respuesta de forma satisfactoria a los requisitos planteados o problemas detectados,
determinando una fecha límite de implantación y un coste aproximado en función de la
estimación realizada anteriormente. Se elige, junto con el usuario, la solución más adecuada, y
se obtiene la aprobación o rechazo de la petición. En caso de rechazo, la petición se da por
cerrada en el catálogo.

Desarrollo de todas y cada una de las tareas: productos de entrada,

descripción de la tarea, productos de salida, técnica y participante
Registro de la Petición (MSI 1.1)

Descripción

Los responsables de mantenimiento recogen las peticiones de los usuarios, siendo estas
peticiones fuente de problemas o de posibles mejoras en el sistema de información.

En esta tarea se lleva a cabo la creación de un catálogo donde se realiza una descripción
detallada de todas las peticiones realizadas por el usuario. Este catálogo será la base para el
posterior análisis de la petición, así como de las modificaciones que se lleven a cabo sobre el
sistema de información.

Productos de Entrada

 Petición de mantenimiento (externo, realizado por el usuario).

Productos de Salida

 Catálogo de peticiones

Técnicas y Prácticas

 Catalogación.

Participantes

 Responsable de mantenimiento.

13
Asignación de la Petición (MSI 1.2)

Descripción

En esta tarea se decide si se acepta, o no, la petición de mantenimiento, para ello se lleva un
estudio sobre las peticiones anotadas en el catalogo de peticiones. En este estudio se
determinará el tipo de mantenimiento requerido por la petición, así como comprobar si el tipo
de mantenimiento necesario ha sido definido en el Plan de mantenimiento y un estudio de
todos los sistemas de información que se verían afectados por la petición.

En caso de que la petición haya sido aceptada, se determinará quién será el encargado de
atender la solicitud para estudios posteriores.

Productos de Entrada

 Plan de mantenimiento (IAS 7.2).

 Catalogo de peticiones (MSI 1.1).

Productos de Salida

 Catálogo de peticiones
 Aceptación/Rechazo de la petición.
 Asignación de Responsable.

Técnicas y Prácticas

 Catalogación.

Participantes

 Responsable de mantenimiento.

Verificación y estudio de la petición (MSI 2.1)

Descripción
En esta tarea se lleva a cabo la verificación de la petición, para ello según el tipo de
mantenimiento a realizar se realizará, o bien una reproducción del problema en caso de un
mantenimiento correctivo, o una comprobación de lo razonable y factible que puede llegar a
ser el cambio a realizar en el mantenimiento evolutivo.

14
Una vez realizada la verificación se procede a realizar el estudio de la petición. En este punto si
se lleva a cabo un mantenimiento correctivo se llevará a cabo un estudio sobre el nivel crítico
de la petición y tomar las medidas oportunas en virtud del mismo. En caso de tratarse de un
mantenimiento evolutivo, se realizará un estudio para comprobar el alcance que la
modificación, determinando si se trata de una modificación de un sistema ya creado o una
nueva funcionalidad que se desea añadir al sistema.

Productos de Entrada

 Catálogo de peticiones (MSI 1.2).

 Acuerdo de nivel de servicio (IAS 8.3).

Productos de Salida

 Catálogo de peticiones:
 Verificación de la petición.
 Resultado del estudio de la petición.

Técnicas y prácticas

 Sesiones de trabajo.
 Catalogación.

Participantes

 Equipo de mantenimiento.

Estudio de la Propuesta de Solución (MSI 2.2)

Descripción
En esta tarea se lleva a cabo una estimación de la prioridad de cada una de las peticiones
teniendo en cuenta los requisitos planteados, se realiza un análisis de los mismos y se
comprueba si algunos de ellos se pueden agrupar para abordarlos de forma conjunta,
asignándoles una prioridad y el orden de implantación de los mismos.
En esta tarea también se lleva a cabo una validación de las características del mantenimiento ,
la concreción de los requisitos solicitados por la petición y la comprobación de la existencia de
otras peticiones que afecten a los mismos sistemas que la petición que se encuentra en
estudio, una valoración de los sistemas que se podrían ver comprometidos por la modificación
15
, una estimación preliminar de los esfuerzos que se llevarían a cabo para la labor de
mantenimiento y la propuesta de soluciones alternativas que cumplan con los requisitos
solicitados por la petición.

Productos de Entrada

 Plan de Mantenimiento (IAS 7.2).

 Acuerdo de nivel de servicio (IAS 8.3).
 Catálogo de peticiones (MSI 2.1).
 Resultado del estudio de petición (MSI 2.1).

Productos de Salida

 Propuesta de Solución.
 Catálogo de Peticiones:
 Estudio de impacto.
 Aceptación / Rechazo de la petición.

Técnicas y prácticas

 Sesiones de trabajo.
 Catalogación.

Participantes

 Responsable de Mantenimiento.
 Equipo de Mantenimiento.

Identificación de elementos afectados (MSI 3.1)

Descripción
En esta tarea se llevará a cabo un análisis detallado de la petición, para de esta forma conocer
el alcance y el número de sistemas afectados por la misma. Gracias a este paso se puede
realizar una planificación y secuencia de los pasos a llevar a cabo para el desarrollo de los
cambios.
Una vez realizado el análisis se tendrán reflejados los elementos implicados en la modificación
y una asociación entre los elementos de la petición así como referencias cruzadas de los
mismos.
16
Uno de los motivos de reflejar las referencias cruzadas de los elementos implicados es facilitar
la labor de la tarea de Especificación del Plan de Pruebas de Regresión, indicando de esta
forma todas las referencias que tiene la modificación a realizar con diferentes módulos del
sistema y que pueden dar lugar a efectos no deseados en estos.

Productos de Entrada

 Catálogo de Peticiones (MSI 2.2).

 Propuesta de Solución (MSI 2.2).

Productos de Salida

 Catálogo de peticiones:
 Elementos Afectados.
 Análisis de Impacto de los Cambios.

Técnicas y Prácticas

 Catalogación.
 Análisis de Impacto.

Participantes

 Equipo de Mantenimiento.
 Jefe de Proyecto.

Establecimiento del Plan de Acción (MSI 3.2)

Descripción
En esta tarea se lleva a cabo la identificación de las actividades y tareas a realizar en el modelo
de procesos de la aplicación, es decir: Estudio de Viabilidad, Análisis del Sistema de
Información, Diseño del Sistema de Información, Construcción del Sistema de Información e
Implantación y Aceptación del Sistema de Información, así como la complejidad y el alcance de
los cambios.
Una vez delimitado el plan de acción se establecerá un Plan de Trabajo determinando los
plazos, costes, equipo de trabajo, esfuerzo, etc..., requeridos para el plan de trabajo.
Finalmente se realizan unos puntos de control para llevar un seguimiento del plan de trabajo.

17
Productos de Entrada

 Plan de Mantenimiento (IAS 7.2).

 Propuesta de Solución (MSI 2.2).

 Análisis de Impacto de los Cambios (MSI 3.1).

 Catálogo de Peticiones (MSI 3.1).

Productos de Salida

 Catálogo de peticiones.
 Actividades y tareas de los procesos de Desarrollo a Realizar.

 Plan de Acción de la modificación.

Técnicas y Prácticas

 Planificación.

 Catalogación.

Participantes

 Responsable de Mantenimiento.
 Equipo de Mantenimiento.

 Jefe de Proyecto.

Especificación del Plan de Prueba de Regresión (MSI 3.3)

Descripción
En esta tarea se intenta evitar que modificaciones en una parte del sistema tengan efectos
contraproducentes (comportamientos no deseados o errores adicionales) en otras partes del
sistema que no han sido modificadas, asegurando de esta forma que la nueva versión satisface
todas las necesidades planteadas.

Productos de Entrada

 Propuesta de la Solución (MSI 2.2).

 Análisis del Impacto de los Cambios (MSI 3.1).
 Catálogo de Peticiones (MSI 3.2).

18
Productos de Salida

 Plan de Pruebas de Regresión.

Participantes

 Equipo de Mantenimiento.

 Jefe de Proyecto.

Seguimiento de los Cambios (MSI 4.1)

Descripción
En esta tarea se realiza un seguimiento del plan de acción creado en la tarea "Establecimiento
del plan de Acción", siguiendo los puntos de control creados en dicha tarea. A su vez, se
realiza un seguimiento de cada una de las actividades involucradas en el modelo de procesos
identificadas anteriormente en la actividad de "Preparación de la Implementación de la
Modificación".
Otro paso en la realización de la tarea es el control de la planificación establecida, realizando:
Una traza de los cambios realizados, validación de los cambios realizados así como la
realización de test unitarios de integridad y de sistema, comprobar que solo se ha modificado
lo establecido, etc.

Productos de Entrada

 Producto Software en Desarrollo (externo, procedente de los procesos de desarrollo).

 Análisis de Impacto de los Cambios (MSI 3.1).

 Plan de Acción para la Modificación (MSI 3.2).

Productos de Salida

 Evaluación del Cambio.

Participantes

 Equipo de Mantenimiento.

 Responsable de Mantenimiento.
 Jefe de Proyecto.

19
Realización de las pruebas de Regresión (MSI 4.2)

Descripción

En esta tarea se realizan pruebas de regresión para asegurar que los cambios realizados en el
mantenimiento no han afectado el funcionamiento de otras partes del sistema. En caso de que
hubiesen afectado a otras partes del sistema se recogerán las incidencias y se tomarán las
medidas oportunas, en caso contrario se genera un informe con los resultados globales y la
aceptación de las pruebas.

Productos de Entrada

 Plan de Pruebas de Regresión (MSI 3.3).

 Producto Software en Desarrollo (externo).

Productos de Salida

 Resultado de las pruebas de Regresión.

 Evaluación del Resultado de las pruebas de Regresión.

Técnicas y Prácticas

 Pruebas de Regresión.

Participantes

 Responsable de Mantenimiento.

 Equipo de Mantenimiento.
 Jefe de Proyecto.

Aprobación y Cierre de la Petición (MSI 4.3)

Descripción

En esta tarea se realiza el cierre formar de la petición de mantenimiento y la actualización del

catalogo de peticiones. En esta tarea también es importante registrar datos cuantitativos como
el tiempo empleado en el análisis de la petición, estudio del impacto, resolución del cambio,
recursos utilizados, etc., para de esta forma tener una base cualitativa sobre la que tomar
decisiones relativas a la eficacia de las técnicas y procedimientos de mantenimiento utilizados.

20
Productos de Entrada

 Catálogo de Peticiones (MSI 3.2).

 Plan de Pruebas de Regresión (MSI 3.3).

 Evaluación del Cambio (MSI 4.1).

 Evaluación del Resultado de las pruebas de Regresión (MSI 4.2).

Productos de Salida

 Catálogo de Peticiones.

 Nueva Versión y Aprobación.

Técnicas y Prácticas

 Catalogación.

Participantes

 Directores de los Usuarios.

 Responsable de Mantenimiento.

21
 3. Aportaciones Personales

Aportaciones personales en el apartado desarrollo conceptual

En el desarrollo conceptual se ha decidido realizar los subapartados descritos por las siguientes
razones:

Definiciones inherentes al mantenimiento

Existen algunas definiciones que son comunes para todo tipo de mantenimiento, como puede
ser las actividades de mantenimiento, o proceso de mantenimiento. A su vez se han añadido
algunas definiciones sin las cuales sería imposible dar una definición de alguna de las
posteriores definiciones enumeradas en el desarrollo conceptual. Por ejemplo, no se podría
dar una definición de mantenimiento correctivo ni de reingeniería sin antes conocer la
definición mantenimiento.

Tipos de Mantenimiento
No existe un único tipo de mantenimiento. Según las necesidades extraídas en el proceso de
mantenimiento será necesario realizar un tipo de mantenimiento u otro diferente, siendo cada
uno independiente del resto. Por ejemplo, si existe un problema con una funcionalidad de la
aplicación, será necesario realizar un Mantenimiento Correctivo, y si se desea añadir una
nueva funcionalidad, se realizará un Mantenimiento Evolutivo.

Costes del Mantenimiento

Debido al gran coste, tanto en recursos como en tiempo, que conlleva el mantenimiento, se ha
realizado un subapartado donde se expone una definición de “Costes de Mantenimiento” y de
los tipos que existen del mismo. A su vez, dado que existen unos costes indirectos, se ha
realizado una lista con un subconjuto de los costes indirectos más comunes que afectan al
mantenimiento, como puede ser el deterioro del software y la pérdida de oportunidades
debidas a invertir demasiados recursos en el mantenimiento y no disponer de suficientes
recursos para el resto de proyectos.

Factores de Mantenimiento
Este subapartado se define justo a continuación de “Costes de Mantenimiento”, la razón para
ello es que estos son uno de los causantes de los costes de mantenimiento directos definidos
anteriormente. Se ha realizado una enumeración y definición de los tres factores más
importantes que influyen en el mantenimiento, los cuales han sido seleccionados por los
siguientes motivos:

22
  Código Heredado: La mayoría del código que se utiliza hoy en día tiene una gran
antigüedad y no fue pensado para perdurar. Este software fue pensado para realizar
una acción concreta y pensado para ocupar poco espacio, no para ser mantenido
(además de ser poco eficiente tanto en rendimiento como en diseño), lo cual dificulta
enormemente el mantenimiento del mismo. El mantenimiento del código heredado se
podría disminuir, y además aumentar la calidad del código, aplicando Reingeniería
sobre el mismo.
 Evolución del Software: Este factor también viene implícito en el código heredado. El
código se va modificando a lo largo del tiempo y por lo tanto va sufriendo cambios.
Estos cambios con el paso del tiempo van a ocasionar que disminuya la eficiencia y se
deteriore el software. A su vez, es muy normal realizar modificaciones únicamente en
el código sin plasmar estos cambios en la documentación, lo que en un futuro dificulta
el mantenimiento del mismo.
 Ausencia de Herramientas: Este es un factor dependiente del equipo encargado del
mantenimiento, pues, pese a existir herramientas para el mantenimiento del software,
normalmente estas no son utilizadas para la realización del mismo, realizándose todo
el proceso de una manera primitiva ad-hoc, por lo que el proceso de mantenimiento
se complica y no se obtienen los resultados esperados.

Reingeniería
Dado que la reingeniería se puede considerar un tipo especial de mantenimiento se ha
realizado un apartado específico para enumerar y definir todas las características principales
de la misma. Así, se ha realizado una definición de cada una de las tareas que se realiza en el
proceso de reingeniería: Análisis de inventario, Reestructuración de documentos, Ingeniería
inversa e Ingeniería directa.

A su vez se han definido varías características que pese no ser propias de la reingeniería en sí,
si son importantes e intervienen en la misma, como son por ejemplo las Herramientas CASE,
gracias a las cuales se facilita la reingeniería. Migración, pues al realizar la reingeniería se
disminuye la complejidad para poder realizar la migración de una aplicación software a otro
entorno (software o hardware). Esperanza de vida, la reingeniería al realizar modificaciones
tanto en el código como en la documentación puede aumentar la esperanza de vida de la
aplicación software. Prototipo Software, la reingeniería se basa en el producto anterior para
realizar un producto nuevo, por lo tanto se basa en un prototipo totalmente funcional y
operativo.

23
Ingeniería Inversa
Por último se ha dejado la definición tanto de Ingeniería Inversa como de sus propiedades, se
ha dejado para último lugar pues es necesario conocer las definiciones anteriores para
comprender lo que es la ingeniería inversa. Dentro de las características de la misma se ha
definido Extracción de Abstracciones, esta es sin duda la más importante de las tareas de la
Ingeniería Inversa pues mediante esta tarea es posible extraer una documentación y unas
interfaces del código que nos permitirán o bien disminuir los costes de mantenimiento, al
tener una documentación bien definida, o el crear una nueva aplicación (mediante ingeniería
directa), basada en la anterior, gracias a las interfaces extraídas.

Aportaciones personales en el apartado desarrollo metodológico

Para el desarrollo metodológico se ha decido el modelo unificado como modelo de procesos,
la elección de este modelo ha sido debida a la alta flexibilidad que ofrece: Es un modelo
altamente probado y configurable pudiéndose adaptar a proyectos de diferente tamaño y
complejidad, iterativo, por lo que el mantenimiento generaría una nueva versión de la
iteración del ciclo, orientado a objetos, lo que permite utilizar todas las características que
estos ofrecen así como la utilización de gran cantidad de herramientas que automatizan tanto
la OO, como las diferentes actividades del proceso unificado. Además de estas características,
el modelo unificado disminuye el proceso de especificación de requerimientos, asegura la
calidad del producto e intenta disminuir los riesgos de cada uno de los procesos o actividades y
permite una interacción total con el usuario desde el inicio del proyecto. A su vez, el proyecto
unificado se enfoca en la reutilización lo cual le hace idóneo para un desarrollo basado en
componentes, aún así en este desarrollo no se ha decidido utilizar un desarrollo basado en
componentes, lo cual se explicará a continuación.

Como paso previo, entre otros, se ha realizado un Estudio de Viabilidad del Sistema (Proceso
EVS de métrica v3). Con el EVS se pretende proporcionar un marco de trabajo estratégico que
sirva de referencia para el Sistema de Información proponiendo una solución a corto plazo que
tenga en cuenta todas las restricciones pertinentes. Una vez realizado el Estudio de Viabilidad
del Sistema se ha decidido realizar un desarrollo a medida pues se ha supuesto que no existen
en el mercado productos que se puedan reutilizar en el proyecto y no existe ningún proyecto
anterior sobre el cual reutilizar componentes. Por lo tanto, se realiza un desarrollo a medida
no utilizándose un desarrollo basado en componentes.

También se han tenido en cuenta actividades pertenecientes a otros procesos anteriores al

Mantenimiento de Sistemas Informáticos, estas actividades son: Preparación del

24
mantenimiento del Sistema y Establecimiento del acuerdo de nivel de Servicio
pertenecientes al proceso de Implantación y Aceptación del Sistema. Con la actividad
Preparación del Mantenimiento del Sistema se pretende que el equipo de mantenimiento se
encuentre familiarizado con el sistema antes de que este pase a producción y por lo tanto,
cuando se necesite realizar una tarea de mantenimiento este se pueda realizar con una mayor
facilidad y eficiencia. Con la actividad Establecimiento del acuerdo de nivel de Servicio se
pretenden determinar los servicios que se van a establecer así como definir el nivel del mismo
y los compromisos de entrega del sistema. Gracias a esta actividad se pueden tener
determinados, establecidos y definidos los ámbitos en los cuales el mantenimiento va a ser
requerido.

Para la realización del Mantenimiento de Sistemas de Información se han tenido en cuenta las
cuatro actividades que se contemplan en métrica v3, que concuerdan con los procesos de
mantenimiento definidos en el desarrollo conceptual, aunque variando en nombre. Así pues, la
actividad “Registro de Petición” de métrica se corresponde con “Gestión de Peticiones”, del
mismo modo, “Análisis de Petición” se corresponde con “Comprensión del software y de los
cambios que se deben realizar sobre el mismo”, “Preparación de la implementación de la
modificación” con “Modificación del software” y “Seguimiento y evaluación de los cambios
hasta aceptación” con “Realización de pruebas”.

En el desarrollo metodológico además de haber contemplado todas las actividades

pertenecientes al proceso de Mantenimiento de Sistemas de Información se han contemplado
todas las tareas pertenecientes a cada una de las actividades, pues se considera que todas
ellas son esenciales para el funcionamiento del proceso. Por ejemplo no tendría sentido
realizar la actividad de “Registro de Petición” sin la tarea “Asignación de la petición” pues en
esta tarea es donde se define el tipo de mantenimiento a realizar, y sin ella no se podrían
realizar todos los pasos siguientes del Mantenimiento de Sistemas de Información.

Uno de los puntos más importantes desde una perspectiva propia es la tarea “Establecimiento
del Plan de Acción” perteneciente a la actividad “Preparación de la Implementación de la
Modificación”. Esto es debido a que en esta tarea se lleva a cabo la identificación de todas las
actividades y tareas pertenecientes a los procesos realizados, dependiendo del alcance,
complejidad y propiedades del mantenimiento, así como del plan de mantenimiento. Gracias
a esta tarea es posible establecer un plan de trabajo determinando todas las características y
factores (costes, plazos de implementación, nivel de esfuerzo,…) que hagan que el
mantenimiento de sistemas de información finalice satisfactoriamente.

25
También se ha añadido al desarrollo metodológico la tarea “Especificación del Plan de
Regresión” perteneciente a la actividad “Preparación de la Implementación de la
Modificación”, y por ende la tarea “Realización de las Pruebas de Regresión” perteneciente a la
actividad “Seguimiento y Evaluación de los cambios hasta la Aceptación”. Estas dos tareas son
quizás de las más importantes del proceso de mantenimiento de sistemas de información
(aparte del “Establecimiento del Plan de Acción”), pues con estas tareas se pretende impedir
que cambios realizados en el mantenimiento afecten a otras partes, implicadas o no en el
mismo, produciendo nuevos errores y anomalías no deseadas. Para ello se especifican casos de
prueba en función de las relaciones existentes en los componentes afectados por la
modificación y se realizan las pruebas con el fin de asegurar que no se ha comprometido el
funcionamiento normal del sistema de información.

26
 4. Bibliografía
 [PAL09]Apuntes de la Universidad de Las Palmas de Gran Canarias de la Asignatura, Prueba
y Mantenimiento del Software.
o http://serdis.dis.ulpgc.es/~a013775/asignaturas/it-pms/Apuntes/6_Mantenimiento%20del%20software.pdf
o http://serdis.dis.ulpgc.es/~a013775/asignaturas/it-pms/Apuntes/7_Mantenimiento.%20M%e9trica%20v3.pdf

 [MET03]Métrica v3. Mantenimiento de Sistemas de Información.

o http://serdis.dis.ulpgc.es/~a013775/asignaturas/it-
pms/Apuntes/Mantenimiento%20de%20Sistemas%20de%20Informaci%f3n%20M%c9TRICA%20v3.pdf

 [UO09]Apuntes de la Universidad de Oviedo, Fundamentos de Ingeniería Software.

o https://euitio178.ccu.uniovi.es/foros/download.php?id=1556

 [PRES06] Ingeniería del Software. Un enfoque práctico. McGraw-Hill

27
5. Presentación

28