Curso:

INGENIERÍA DE SOFTWARE
 Sesión 13

MANTENIMIENTO Y EVOLUCIÓN DEL SOFTWARE

2
Contenido

SEMANA 1: ESTRUCTURA DE LA GUÍA SWEBOK

SEMANA 2: INTRODUCCIÓN AL SEBOK

SEMANA 3: PROCESOS DEL CICLO DE VIDA DEL SISTEMA: ISO/IEC 15288

SEMANA 4: PROCESOS DEL CICLO DE VIDA DEL SOFTWARE: ISO/IEC 12207

SEMANA 5: INGENIERÍA DE SOFTWARE E INGENIERÍA DE SISTEMAS

SEMANA 6: APLICACIONES DE LA INGENIERÍA DE SISTEMAS CON APOYO DE LA ISW

SEMANA 7: INGENIERÍA Y GESTIÓN DE SISTEMAS

SEMANA 8. Sistema “F”

3
UNIDAD III: GESTIÓN DE INGENIERÍA DE SISTEMAS Y DE COMPONENTES

SEMANA 9: GESTIÓN DE INGENIERÍA DE SISTEMAS

SEMANA 10: COMPONENTES DE SISTEMAS Y DE SOFTWARE

UNIDAD IV: CICLO DE VIDA DEL SOFTWARE

SEMANA 11: PROCESO DE DESARROLLO DE SOFTWARE

SEMANA 12: MODELOS DE DESARROLLO DE SOFTWARE

SEMANA 13: MANTENIMIENTO Y EVOLUCIÓN DEL SOFTWARE

SEMANA 14: ESTIMACIÓN DE COSTOS Y MÉTRICAS DEL PROCESO SOFTWARE

SEMANA 15: EXPOSICIONES GRUPALES DEL TRABAJO FINAL

SEMANA 16: Sistema “F”

4
MANTENIMIENTO Y EVOLUCIÓN
DEL SOFTWARE
SEMANA 13: MANTENIMIENTO Y EVOLUCIÓN DEL SOFTWARE
13.1 Naturaleza y Categorías de Temario
Mantenimiento
13.2 Aspectos técnicos y de gestión en el mantenimiento de software
13.3 Técnicas para Mantenimiento:
• Comprensión del programa
• Reingeniería
• Ingeniería inversa
• Migración
• Retiro

• Fuente: Guide SWEBoK, v.3.0 / CHAPTER 5 - SOFTWARE MAINTENANCE

1. INTRODUCCIÓN

2. OBJETIVOS

3. DESCRIPCIÓN

4. EL PROCESO DE MANTENIMIENTO DE SISTEMAS

4.1. Recepción del Requerimiento –Fase de Incepción …………………………..........

4.2. Análisis del Requerimiento –Fase de Elaboración

4.3. Preparación de la Implementación de la Modificación. –Fase de Elaboración..

4.4. Implementación de la Modificación –Fase de Construcción

4.5. Evaluación y Aceptación de la Modificación –Fase de Construcción

4.6. Pase a Producción –Fase de Transición

4.7. Flujo de Trabajo de Mantenimientos (Actividades y Tareas)

4.8. Documentación de las actividades de mantenimiento

5. ANEXOS

5.1. PL-MAN.F_01 Registro de OT v.1

 INTRODUCCIÓN

Presentacion de una metodología para el mantenimiento de sistemas, orientada al enfoque de procesos y adecuada
según las fases del Proceso Unificado de Desarrollo de Software (Rational Unified Process RUP®).

Las actividades de mantenimiento, en esta metodología, son mostradas a través de un flujo de trabajo donde se indica
los roles competentes del personal Desarrollador de Sistemas y del Usuario. Siendo el mantenimiento de software
un proceso, la metodología se convierte en un marco de trabajo genérico que puede aplicarse para una gran variedad
de sistemas de software como son las aplicaciones Web ó aplicaciones usuario / servidor.
 OBJETIVOS

❑ Proporcionar un flujo de trabajo que describa las actividades a realizar para cumplir con los requisitos que

garantizarán la adecuada atención de un requerimiento de modificación del sistema.

❑ Gestionar todos los aspectos relativos al mantenimiento de sistemas hasta lograr la satisfacción de los usuarios.
3. DESCRIPCIÓN

La metodología de mantenimiento ha sido definida con un enfoque de procesos adecuado a las fases del
Proceso Unificado de Desarrollo de Software.
Un proceso es definido como el conjunto de actividades mutuamente relacionadas o que interactúan,
transformando elementos de entrada en resultados (Ver Gráfico - Proceso).

Gráfico 1- El Proceso
TIPOS DE MANTENIMIENTO
Los requerimientos de modificación han sido clasificados en los siguientes tipos de mantenimiento:

Tipo de mantenimiento Descripción

Mantenimiento Correctivo. Son aquellos cambios precisos para corregir
errores del producto software.
Mantenimiento Evolutivo. Son las incorporaciones, modificaciones y
eliminaciones necesarias en un producto software
para cubrir la expansión o cambio en las
necesidades del usuario.
Mantenimiento Adaptativo. Son las modificaciones que afectan a los entornos
en los que el sistema opera, por ejemplo, cambios
de configuración del hardware, software de base,
gestores de base de datos, comunicaciones, etc.

Mantenimiento Perfectivo. Son las acciones llevadas a cabo para mejorar la

calidad interna de los sistemas en cualquiera de
sus aspectos: reestructuración del código,
definición más clara del sistema y optimización
del rendimiento y eficiencia.
1. EL PROCESO DE MANTENIMIENTO DE SISTEMAS

Un proceso define quién está haciendo qué, cuándo y cómo alcanzar un determinado objetivo. En el
mantenimiento de sistemas el objetivo es mejorar un software existente o corregirlo.

Graf.2 El proceso de mantenimiento de sistemas

Pasos del proceso de mantenimiento:

1) Realizar el registro de los requerimientos de mantenimiento que se han recibido del usuario, con el fin de llevar
el control de los mismos y de proporcionar, si fuera necesario, la información siguiente:

•datos estadísticos de los requerimientos recibidos o atendidos en un determinado periodo,

•sistemas que se han visto afectados por los cambios, en qué medida y
•el tiempo empleado en la resolución de dichos cambios.

Es una buena práctica de gestión, llevar un catálogo de requerimientos de mantenimiento sobre los sistemas
de información, para registrar una serie de datos que nos permitirán disponer de la información antes
mencionada.
En el momento que se registra el requerimiento, se procede a diagnosticar qué tipo de mantenimiento se
trata.

2) Una vez registrado el requerimiento e identificado el tipo de mantenimiento y su origen, se determina de

quién es la responsabilidad de atender el requerimiento.
El requerimiento puede ser denegado. En este caso, se notifica al usuario y acaba el proceso.

3) Según se trate de un mantenimiento correctivo o evolutivo, se verifica y reproduce el problema, o se

estudia la viabilidad del cambio propuesto por el usuario. En ambos casos se estudia el alcance de la
modificación.
4) Hay que analizar las alternativas de solución, identificando, según el tipo de mantenimiento de que se trate,
cuál es la más adecuada.
El plazo y urgencia de la solución del requerimiento se fija de acuerdo al estudio anterior.

5) La definición de la solución incluye el estudio del impacto de la solución propuesta en los sistemas afectados.
Mediante el análisis de dicho estudio, la persona responsable del Proceso de Mantenimiento valora el esfuerzo y
coste necesario para la implementación de la modificación.

6) Cuando el requerimiento lo amerita, la explicación del análisis de los requerimientos que incorporan una nueva
funcionalidad al sistema, se hace mediante el uso de los diagramas de estado, diagramas de interacción, diagramas
de colaboración y diagramas de actividades; que son parte de la notación UML.

UML, por sus siglas en inglés, Unified Modeling Language, es el lenguaje de modelado de sistemas de software más conocido y
utilizado en la actualidad. Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software.
7) Las tareas de los procesos de desarrollo que va a ser necesario realizar son determinadas en función
de la identificación de los componentes del sistema actual u otros sistemas afectados por la modificación.

8) Y, antes de la aceptación del usuario, es preciso establecer un plan de pruebas de regresión que asegure
la integridad del sistema de información afectado.

Las pruebas de regresión tratan de eliminar el llamado efecto onda, es decir, que los cambios provocados por una petición no
introduzcan un comportamiento no deseado o errores adicionales en otros componentes no modificados. A tal fin, se deben
especificar los casos de prueba en función de las relaciones existentes entre los distintos componentes identificados en la tarea
Identificación de Componentes Afectados.

9) Por último, actualizar la documentación técnica. documentando los cambios realizados.

La mejor forma de mantener el coste de mantenimiento bajo control es una gestión efectiva del Proceso de
Mantenimiento; siendo necesario registrar de forma disciplinada los cambios realizados en los sistemas de
información y en su documentación. Esto repercutirá directamente en la mayor calidad de los sistemas actualizados.
El proceso de mantenimiento comprende las
siguientes actividades:

•Recepción del Requerimiento

(Pre – Análisis)

•Análisis del Requerimiento

•Preparación de la Implementación de la
Modificación

•Implementación de la Modificación

•Evaluación y Aceptación de la
Modificación. Capacitación

•Pase a producción

Graf. 3- Actividades del Proceso de Mantenimiento

Actividades del Proceso de Mantenimiento:
1. Recepción del Requerimiento –Fase de Incepción

El objetivo de esta actividad es establecer un sistema estandarizado de registro de información para las peticiones de
mantenimiento (Sistema de Atención de Requerimientos), con el fin de controlar y canalizar los cambios propuestos por un
usuario, mejorando el flujo de trabajo y proporcionando una gestión efectiva del mantenimiento.

Es importante asignar responsabilidades para evitar la realización de cambios que beneficien a un usuario, pero que produzcan un
impacto negativo sobre otros muchos.
Por tanto, es necesario que todas las peticiones de mantenimiento sean presentadas de una forma estandarizada, que permita su
clasificación y facilite la identificación del tipo de mantenimiento requerido.

Una vez que el requerimiento ha sido registrado, que se ha determinado el tipo de mantenimiento y los sistemas de
información a los que inicialmente puede afectar, se comprueba su viabilidad, de acuerdo a las prestaciones de
mantenimiento establecidas para dichos sistemas de información.

Esta actividad está compuesta por las siguientes tareas:

Registro del Requerimiento (Orden de Trabajo)
Registro en el Catálogo de Requerimiento
Análisis de Factibilidad del Requerimiento
Aprobación del Análisis de Factibilidad del Requerimiento por parte del Usuario

Entregables – Hitos de Control

Se elaborará el documento denominado ‘Análisis de Factibilidad del Requerimiento’.
El Usuario autorizado aprobará el documento ‘Análisis de Factibilidad del Requerimiento’.
4.1. Análisis del Requerimiento –Fase de Elaboración

En esta actividad se lleva a cabo el diagnóstico y análisis del cambio para dar
respuesta a los requerimientos de mantenimiento que han sido aceptados en
la actividad anterior.

Se analiza el alcance del requerimiento en lo referente a los sistemas de

información afectados, valorando hasta qué punto pueden ser modificados en
función del ciclo de vida estimado para los mismos y determinando la
necesidad de evaluar la factibilidad o el análisis en función del impacto sobre
los sistemas de información afectados.

El enfoque de este estudio varía según el tipo de mantenimiento, teniendo en

cuenta que en el caso de un mantenimiento correctivo que implique un error
crítico debe abordarse el cambio de forma inmediata sin profundizar en el
origen del mismo. No obstante, una vez reanudado el servicio, es
imprescindible analizar el problema y determinar cuál es la solución definitiva.

Esta actividad consta de las siguientes tareas:

• Análisis y elaboración del Documento de Análisis
• Revisión y aprobación del Documento de Análisis por Parte del
Usuario

Entregables – Hitos de Control

• Se elaborará el documento denominado ‘Análisis del
Requerimiento’.
• El Coordinador del Área Usuaria y el Usuario autorizado
aprobarán el documento ‘Análisis del Requerimiento’.
4.3. Preparación de la Implementación de la Modificación. –Fase de Elaboración

Realizado el análisis, se ajustará el cronograma, valorando la necesidad de realizar un reajuste de dichos indicadores,
con el fin de cumplir el plazo máximo de entrega. Al mismo tiempo, se elaborara el documento de Plan de Pruebas.

Se deberán definir y documentar los criterios de evaluación y prueba para probar y evaluar las partes del sistema
(unidades, componentes y elementos de la configuración) modificadas y no modificadas.

Las tareas que contempla la actividad de Preparación de la Implementación de la Modificación son las siguientes:

• Elaborar Plan de Pruebas, incluye los Casos de Prueba.

Entregables – Hitos de Control

Se elaborará el documento denominado ‘Plan de Pruebas’.
El Coordinador del Área Usuaria y el Usuario autorizado aprobarán el documento ‘Plan de Pruebas’.
4.4 Implementación de la Modificación –Fase de Construcción
Una vez culminada la fase de elaboración se activan los correspondientes procesos de desarrollo para llevar a cabo la
implementación de la solución.

La aprobación del requerimiento se realiza al finalizar las pruebas de regresión, y después de comprobar que todo lo
que ha sido modificado o puede verse afectado por el cambio, funciona correctamente. Toda prueba debe realizarse
en el servidor de pruebas, por lo que se requiere transferir de manera formal los cambios efectuados en los ambientes
de programación, simulando un pase a producción preliminar.

Las tareas que contempla la actividad de Implementación de la Modificación son las siguientes:

• Implementar Modificaciones
• Pruebas Unitarias
• Control de Calidad Interno

Entregables – Hitos de Control

• Se elaborará el documento interno denominado ‘Control de Calidad Interno”.
Se realiza el seguimiento de los cambios que se están llevando a cabo en los procesos de desarrollo, de acuerdo a los
puntos de control del ciclo de atención del requerimiento. Durante este seguimiento, se comprueba que sólo se han
modificado los elementos que se ven afectados por el cambio y que se han realizado las pruebas correspondientes,
especialmente las pruebas de integración y del sistema.

Una vez finalizado el cambio en desarrollo, se realizan las pruebas de regresión que están especificadas en la actividad
anterior, comprobando que ningún sistema no modificado, pero con posibilidades de verse afectado, ha variado su
comportamiento habitual. Se informa si ha habido incidencias con el fin de que se resuelvan del modo más
conveniente.
La aprobación del requerimiento se realiza al finalizar las pruebas de regresión, y después de comprobar que todo lo
que ha sido modificado o puede verse afectado por el cambio, funciona correctamente.

Las tareas que contempla la actividad de Evaluación y Aceptación son las siguientes:
• Pruebas Operativas y aceptación. Ajustes
• Pruebas de Sistemas y aceptación. Ajustes
• Actualizar Documentación

Entregables – Hitos de Control

El ‘Documento de Aceptación de Pruebas Operativas’ será aprobado por el usuario autorizado y el Analista de
Sistemas.
El ‘Documento de Aceptación de Pruebas de Sistemas’ será aprobado por el usuario autorizado y el Analista de
Sistemas.
4.6. Pase a Producción –Fase de Transición
Cuando se realice un pase a producción, se deberá notificar a todos los involucrados. Se debe archivar, según sea
apropiado, toda la documentación, archivos y código del entorno antiguo.

Las tareas que contempla la actividad de Pase a Producción son las siguientes:

• Capacitación a los Usuarios

• Aprobar documento de Pase a Producción
• Archivar datos de entorno antiguo
• Pase a Producción (Ejecución)
• Inicio de Producción
• Comunicar Inicio de Pase a Producción a los usuarios

Entregables – Hitos de Control

• Se aprobará el documento denominado ‘Pase a Producción’ por el usuario autorizado y el Jefe de
Sistemas. En este documento se enumeran los objetos creados o modificados, y la forma en que deben
ejecutarse (pasos a seguir).
1. Flujo de Trabajo de Mantenimientos (Actividades y Tareas)

El siguiente cuadro muestra el conjunto de actividades a considerar en el flujo de trabajo que se acuerde con el
usuario.
…Flujo de Trabajo de Mantenimientos (Actividades y Tareas)
PRACTICA
CASO: Una empresa de TI gana un Concurso Publico para prestar
servicios de mantenimiento de sistemas.

Acuerdan realizar ciclos mensuales de mantenimiento sobre la base de

requerimientos de cambios (correctivos o de mejoras al software).
Los requerimientos son clasificados como complejos, medianas y simples y, se
estiman con una duracion promedio en dias:
• Compleja(C) : 20 dias, realizado por 5 AP
• Mediana(M) : 10 dias, realizado por 3 AP
• Simple(S) : 5 dias, realizado por 1 AP
El contrato establece que la empresa debe proveer 30 analistas-programadores
(AP) para realizar el mantenimiento.

1. Cuantos requerimientos u ordenes de mantenimiento (OM) deben recibir al

mes para ser atendidos? Estime una asignacion aleatoria de OM para 2 meses.
C no mayor de 20 ni menor de 10
M no mayor de 30 ni menor de 20
S no mayor de 40 ni menor de 30

2. Realizar un diagrama de flujo del servicio de mantenimiento (BIZAGI)

PÁGINA 26 26
PREGUNTAS?

PÁGINA 27 27
CONCLUSIONES
Esto es lo que hemos
aprendido
(a responder por los
estudiantes)
Logros de
Aprendizaje
• …
• …
• …

PÁGINA 28 28
Mg. Ing. Wilfredo Carranza
wcarranzab@[Link]

29