Mantenimiento del Software - Kybele · 2012-04-11 · Tipos de Mantenimiento de SW Mantenimiento...

Mantenimiento del

Software

Santiago Moral GarcíaIngeniería del Software I

© 2012 Grupo Kybele

Índice

1. Introducción

2. Tipos de Mantenimiento de SW

3. Dificultades del Mantenimiento de SW

4. Soluciones al problema del Mantenimiento de SW

5. Mantenibilidad

6. Métodos de Mantenimiento de SW

7. Externalización del Mantenimiento del SW

2


Índice

1. Introducción

• Origen

• Definiciones

• El Efecto Iceberg

• Causas del Alto Coste

• Actividades del Mantenimiento




5. Mantenibilidad



3


Introducción

Origen

Rápida evolución de la Ingeniería de

Computadores.

Sin embargo, el desarrollo de SW ha sufrido un

retraso histórico.

En 1970, ya se había popularizado el término Crisis

de Software.

Para resolver este problema surgió un área de la

informática que recibió el nombre de Ingeniería

del Software [Sommerville, 1992].

4


Introducción

Origen

Una de las principales causas de esta situación ha sido

la poca importancia que se ha dado al Mantenimiento

del Software.

Aunque se sitúa al final del ciclo de vida, el

mantenimiento es un proceso de suma importancia por

su repercusión económica, temporal y de recursos.

5

Análisis Diseño Implementación Pruebas Mantenimiento

IMPORTANCIA


Introducción

Origen

6

Referencia Periodo % Mantenimiento

[Pressman, 1993] años 70 35%-40

[Pigoski, 1997] 1980-1984 55%

[Pressman, 1993] Años 80 60%

[Rock-Evans y Hales,

1990]1987 67%

[Schach, 1990] 1987 67%

[Pigoski, 1997] 1985-1989 75%

[Frazer, 1992] 1990 80%

[Pressman, 1993]Años 90

(prev.)90%

Según varios estudios, el Mantenimiento es la fase mas costosa del ciclo de vida del SW.

Mayor parte del presupuesto: Mantener software existente.

Sobrepasando la Barrera de Mantenimiento se imposibilitan nuevos desarrollos.


Introducción

Definiciones

Estándar ISO 12207: “el

proceso de mantenimiento

contiene las actividades y tareas

realizadas por el mantenedor.

Este proceso se activa cuando el

producto software sufre

modificaciones en el código y la

documentación asociada, debido

a un problema o a la necesidad

de mejora o adaptación. El

objetivo es modificar el

producto software existente

preservando su integridad. Este

proceso incluye la migración y

retirada del producto software”.

7

PROCESOS PRINCIPALES

ADQUISICIÓN

SUMINISTRO

DESARROLLO

EXPLOTACIÓN

MANTENIMIENTO

PROCESOS DE SOPORTE

DOCUMENTACIÓN

GESTIÓN DE CONFIGURACIÓN

ASEGURAMIENTO DE CALIDAD

VERIFICACIÓN

VALIDACIÓN

REVISIÓN CONJUNTA

AUDITORÍA

RESOLUCIÓN DE PROBLEMAS

USABILIDAD

EVALUACIÓN DE PRODUCTO

PROCESOS DE SOPORTE

DOCUMENTACIÓN

GESTIÓN DE CONFIGURACIÓN

ASEGURAMIENTO DE CALIDAD

VERIFICACIÓN

VALIDACIÓN

REVISIÓN CONJUNTA

AUDITORÍA

RESOLUCIÓN DE PROBLEMAS

USABILIDAD

EVALUACIÓN DE PRODUCTO

PROC. ORGANIZACIONALES

GESTIÓN

INFRAESTRUCTURA

MEJORA

RECURSOS HUMANOS

GESTIÓN DE ACTIVOS

GEST. PROG. REUTILIZACIÓN

INGENIERÍA DE DOMINIO

PROC. ORGANIZACIONALES

GESTIÓN

INFRAESTRUCTURA

MEJORA

RECURSOS HUMANOS

GESTIÓN DE ACTIVOS

GEST. PROG. REUTILIZACIÓN

INGENIERÍA DE DOMINIO

PROCESO

DE

ADAPTACIÓN


Introducción

Definiciones

IEEE 1219:

“Modificación de un

producto software

después de haber sido

entregado (a los usuarios

o clientes) con el fin de

corregir los defectos,

mejorar el rendimiento u

otros atributos, o

adaptarlo a un cambio

de entorno”.

Pressman [1998]: “la fase de mantenimiento se centra en el cambio que va a asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software, y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente”.

8


Introducción

el Efecto Iceberg

A la hora de planificar los costes de

mantenimiento, los analistas-programadores

tienen la impresión de que el mantenimiento es

algo descontrolado, nunca se sabe que va a pasar

(sería predecir el futuro).

Esta situación se asemeja a un Iceberg, del cual

sólo se percibe una pequeña parte, pero bajo cuya

superficie se esconde una gran cantidad de

problemas potenciales y costes encubiertos

[Canning, 1972].

9


Introducción

el Efecto Iceberg

En la parte sumergida de este Iceberg se ocultan

costes, menos tangibles que los monetarios.

Los costes intangibles del mantenimiento del software

están vinculados a las oportunidades de desarrollo que

se deben posponer o se pierden [McCracken, 1980].

Otros costes intangibles son:

Insatisfacción del cliente, cuando no se pueden atender a

tiempo las reparaciones o modificaciones.

Errores ocultos introducidos al realizar el mantenimiento.

Perjuicio en otros proyectos de desarrollo, cuando la

plantilla tiene que dejarlos.

10


Introducción

el Efecto Iceberg

Al final, el coste de mantenimiento de un SW

es la reducción que se produce en la

productividad de los informáticos.

Algunos autores [Boehm, 1979], han calculado

que el coste de mantener una línea de código

(LCD) puede llegar a ser 40 veces más alto que

en el proceso de desarrollo.

11


Introducción

Causas del Alto Coste

1 2 3 5 35

100

020406080

100120

Coste de detectar y corregir defectos

12

¿A qué se debe que sea más económico solucionar los

errores en las etapas iniciales del ciclo de vida?


Introducción


Una gran cantidad del SW actual ha sido

desarrollado hace más de 15-20 años.

Aunque fuese creado utilizando las mejores

técnicas:

Restricciones de tamaño.

Restricciones de espacio de almacenamiento.

Herramientas tecnológicamente desfasadas.

13


Introducción


Cambios Incontrolados

Los programas sufren migraciones a nuevas

plataformas o SO.

Los programas experimentan mejoras y

adaptaciones para satisfacer las nuevas

necesidades de los usuarios.

Problema: Los cambios se realizan sin tener en

cuenta la arquitectura del sistema. No se aplican

técnicas de ingeniería inversa o reingeniería.

14


Introducción


Escasez de métodos, técnicas y herramientas que puedan proporcionar una solución global al mantenimiento:

Las metodologías de desarrollo no reflejan costes necesarios ni esfuerzo.

Las metodologías se centran en el desarrollo de nuevos sistemas.

Complejidad de los sistemas aumenta:

Debido a continuas modificaciones.

Pérdida de información; cada vez hay menos personas en el equipo que conocen el software.

15


Introducción


Documentación del sistema defectuosa o inexistente: Muchas veces no se actualiza cuando cambia el

sistema.

Actividad poco creativa: A diferencia del desarrollo, se considera mas sencilla

y menos importante

La realiza personal con menor experiencia.

Se cree que tiene un menor soporte de herramientas y menos esfuerzo de gestión (FALSO).

¿Qué perfil profesional es encargado del mantenimiento en los equipos de trabajo?

16


Introducción


Actividades de mantenimiento bajo presión

de tiempo.

Poco tiempo para realizar modificaciones

(generalmente sobre el código).

No actualización de la documentación.

Problema: Las correcciones imperfectas dan

lugar a nuevos esfuerzos de corrección en el

futuro.

17


Introducción


Por todo esto, en la actualidad nos podemos encontrar sistemas SW con una escasa calidad debida a: Estructuras de datos con un diseño pobre.

Mala codificación.

Lógica defectuosa.

Documentación escasa o errónea.

Estas mismas razones provocan que el coste de solucionar un defecto en la etapa de mantenimiento sea mucho mayor que en tiempo de análisis (2/100).

18


Introducción

Actividades del Mantenimiento

19

Muchos de los problemas anteriores vienen

dados por el desconocimiento de la

actividades durante el mantenimiento.

Algunas definiciones solo consideran como

mantenimiento la corrección de defectos.

Ampliación de nuevos requisitos se

consideran proyecto de desarrollo

continuado o redesarrollo.


Introducción

Actividades del Mantenimiento

20

¿Qué actividades consideramos entonces

como mantenimiento [IEEE 1219]?

Corrección de defectos en el software.

Creación de nuevas funcionalidades en el

software por nuevos requisitos de usuario.

Mejora de la funcionalidad y del rendimiento.


Índice

1. Introducción


• Mantenimiento Correctivo

• Mantenimiento Adaptativo

• Mantenimiento Perfectivo

• Mantenimiento Preventivo

• Tareas del Mantenimiento



5. Mantenibilidad



21


Tipos de Mantenimiento de SW22

Usuarios

del Sistema

Base

Tecnológica

Entorno de

Trabajo

Sistema

Software

Mantenimiento Perfectivo

Mantenimiento Adaptativo

Mantenimiento

Preventivo

Mantenimiento

Correctivo


Tipos de Mantenimiento de SW23

¿Qué estimación en esfuerzo podemos realizar

sobre cada uno de los tipos de mantenimiento?

60%18%

17%5%

Costes estimados por tipo de Mantenimiento

Perfectivo

Adaptativo

Correctivo

Preventivo


Tipos de Mantenimiento de SW

Mantenimiento Correctivo

24

Aún habiendo superado las etapas de prueba y verificación, el software puede contener defectos.

Este tipo de mantenimiento tiene como objetivoencontrar y eliminar estos defectos del software.

Defectos Vs. Fallos: Un defecto en un sistema es una característica del

sistema con el potencial de causar un fallo [Piattini, 2000].

Un fallo ocurre cuando el comportamiento de un sistema es diferente del establecido en la especificación [Piattini, 2000].




25

Podríamos llegar a considerar los siguientes fallos:

Procesamiento: Salidas incorrectas en un programa.

Rendimiento: Demasiado tiempo de respuesta.

Programación: Diseño inconsistente de un sistema.

Documentación: Diferencias entre la funcionalidad de un programa y el manual de usuario.




26

38%

26%

36%

Origen de los defectos del SW

Requisitos

Diseño

Codificación




27

Este tipo de mantenimiento responde a una situación en la que se produce algún cambio en el SW o HW del entorno en el que se ejecuta el sistema.

Estos cambios pueden deberse a:

Cambio en el SO.

Cambio del tipo de arquitectura en la que se ejecuta(red local a Internet/Intranet).

Entorno de desarrollo del software (nuevoselementos y herramientas como ODBC).

La envergadura del cambio necesario puede sermuy diferente.




28

Los cambios en el entorno SW pueden ser: En el entorno de los datos (Sistema Ficheros Vs.

BBDD).

En el entorno de los procesos (Sistemas Distribuidos, Java, …).

El mantenimiento adaptativo cada vez es más usual debido a: Nuevas generaciones de HW cada poco tiempo.

Nuevos sistemas operativos.

Mejoras en las prestaciones y elementos.

Frente a esto, la vida útil de un sistema SW puede superar fácilmente los 10 años.




29

Este tipo de mantenimiento está asociado a cambios en los requisitos de un producto SW.

Se podría definir como “el conjunto de actividadespara mejorar o añadir nuevas funcionalidadesrequeridas por el usuario”.

A su vez, este tipo de mantenimiento se puede dividir en dos: Mantenimiento de Ampliación: orientado a la

incorporación de nuevas funcionalidades.

Mantenimiento de Eficiencia: busca la mejora de las prestaciones del sistema en tiempo de ejecución.




30

Este tipo de mantenimiento aumentacuando un producto SW tiene éxito

comercial.

¿Por qué?



Mantenimiento Preventivo

31

El principal objetivo de este tipo de mantenimiento es mitigar o evitar las consecuenciasde los fallos.

Para ello: Comprobación de la validez de los datos de entrada.

Reestructuración del software para mejorar la

legibilidad y su futuro mantenimiento.

Adición de comentarios.

Monitorización de las prestaciones del sistema en todo momento (Almacenamiento, Procesamiento, Ancho de Banda, …).



Mantenimiento Preventivo

32

Otros Mantenimientos Vs. Preventivo

Los otros tipos de mantenimientos se realizan, generalmente a causa de una petición.

El mantenimiento preventivo se produce tras un estudio de posibilidades de mejora en los diferentes módulos del sistema.



Ejercicio

33

Partiendo de los tipos de mantenimiento:

Correctivo

Adaptativo

Perfectivo

Preventivo

Buscar un ejemplo de cada uno de ellos, básandose en la práctica de

Patrones de Diseño



Tareas del Mantenimiento

34




35

I - 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.




36

II - 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.




37

III - 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.




38

Partiendo de las distintas categorías:

Comprensión de los cambios

Modificación del software

Realización de pruebas

Identificar actividades de mantenimiento

llevadas a cabo por un analista/programador




39

Categoría Actividad % Tiempo

Comprensió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

pruebasDiseñar y realizar pruebas 28%


Índice

1. Introducción



• Código Heredado

• Problemas del Mantenimiento

• Efectos Secundarios del Mantenimiento


5. Mantenibilidad



40


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?

41



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 complicaporque el código heredado fue objeto de múltiples actividades de mantenimiento.

42



Código Heredado

Leyes del Mantenimiento del Software

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.

43



Código Heredado


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).

44



Código Heredado


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.

45



Código Heredado


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).

46



Problemas del Mantenimiento

Además de las dificultades de mantenimiento

mostradas en 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

47





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.

48





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”.

49




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.

50



Efectos Secundarios

La posibilidad de error al modificar un

sistema actual es muy grande.

Una de las mayores dificultades es el riesgo del

llamado “Efecto Bola de Nieve”:

Los cambios producidos por una petición

introducen efectos secundarios, implicando

nuevos mantenimientos.

Estos nuevos mantenimientos a su vez pueden

producir más efectos secundarios.

51



Efectos Secundarios

• 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

52



Efectos Secundarios

• 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

53



Efectos Secundarios

• Modificar el formato de las Entradas Interactivas.

• Nuevos Mensajes de Error no documentados.

• Tablas o Índices no actualizados.

• Texto no actualizado correctamente.

Documentación

54


Índice

1. Introducción




• Soluciones de Gestión

• Soluciones Técnicas

5. Mantenibilidad



55


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.

56


Soluciones al Problema del

Mantenimiento del SW

57

• 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 SoftwareTécnicas


Soluciones al Problema del Mantenimiento del SW

Soluciones de Gestión

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,

…).

58




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.

59




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 y segto).

Supervisor del sistema SW (Conocimiento).

Gestor de la configuración (actualiza SW).

Desarrollador de mantenimiento (codificación).

60




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.

61



Soluciones 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

62



Soluciones 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].

63


Índice

1. Introducción




5. Mantenibilidad

• Propiedades

• Métricas



64


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.

65


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.

66


Mantenibilidad

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.

¿Son fácilmente medibles? ¿Qué criterios utilizaríais?

67


Mantenibilidad

Métricas

68

MANTENIBILIDAD

CRITERIOS MÉTRICAS

SIMPLICIDAD• Nº ciclomático v(G)• Nº de sentencias• Frecuencia de operandos

CONCISIÓN• Longitud de programa• Nivel de módulo

AUTODESCRIPTIVO • Frecuencia de comentarios

LEGIBILIDAD• Longitud de programa• Niveles anidados (MAX)• Nº de sentencias

FACILIDAD DE PRUEBA• V(g)• Niveles anidados (MAX)


Índice

1. Introducción




5. Mantenibilidad


• Conceptos Básicos

• Proceso de Reingeniería del Software

• Costes y Beneficios de la Reingeniería


69


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.

70



Conceptos Básicos

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.

71



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].

72



Conceptos Básicos

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.

73



Proceso de Reingeniería del SW

74

Definición Diseño Implement.

Ingeniería directa (1) Ingeniería directa (2)

Reing.(6) Reing.(8)

Redocumentación

(5)Redocumentación

(7)

Redocumentación

(8)

Ing. inversa

(4)

Ing. inversa

(3)

(Piattini et al. 98)



Costes y Beneficios de la Reing.

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.

75




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.

76




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.

77




I - Justificación del Proyecto de Reingeniería

Requiere:

Análisis del Software existente.

Análisis de los procesos de mantenimiento actuales.

Análisis del valor de negocio de las aplicaciones.

Muchas organizaciones sólo tienen en cuenta el proceso de Reingeniería cuando el costede un nuevo desarrollo es muy alto (Ej. Hardware).

78




II - Análisis de la Cartera de Aplicaciones

En esta etapa se cotejan la calidad técnica y

el valor de negocio de cada una de las

aplicaciones.

Objetivo: Constituir una lista de

aplicaciones, ordenada según sus

prioridades en el proceso de Reingeniería.

La calidad técnica de un producto es una

medida relativa, dependiente de cada

organización.

79





80

ALTA CALIDAD,

BAJO VALOR

BAJA CALIDAD,

ALTO VALOR

BAJA CALIDAD,

BAJO VALOR

ALTA CALIDAD,

ALTO VALOR

Valor de Negocio

Calidad T

écnic

a





Cuadrante superior izquierdo => No requieren

Reingeniería.

Cuadrante inferior izquierdo => Desarrolladas

de nuevo o reemplazadas por productos

comerciales.

Cuadrante superior derecho => Se puede aplicar

Reingeniería, pero sin excesiva prioridad.

Cuadrante inferior derecho => Primeras

candidatas a la Reingeniería.

81




III - Estimación de Costes

Identificar y ponderar todos los componentes del software que se van a modificar.

Para ello, se deben utilizar métricas adecuadas (existe gran diversidad de métricas).

Comprobar si es rentable hacer Reingeniería, empezar de nuevo el desarrollo o comprar en el mercado (pedir presupuestos a partners).

82




IV - Análisis de Costes Vs. Beneficios

La última etapa es comparar los costes

estimados de cada uno de los presupuestos:

Reingeniería.

Nuevo Desarrollo.

Comprar en el Mercado.

Con los beneficios estimados de cada uno de

los aplicativos.

83


Índice

1. Introducción




5. Mantenibilidad



• Concepto de Outsourcing

• Objetivos de la Externalización

84


Externalización del

Mantenimiento de SW

Sistemas de Información han crecido

considerablemente, incrementando el

porcentaje de inversiones.

En algunos casos ha puesto en peligro los

resultados de las compañías.

Se ha comprobado que realizar outsourcing

total sobre los mantenimientos de los sistemas

de información tiene una buena relación

coste/beneficio.

85


Externalización del Mantenimiento de SW

Concepto de Outsourcing

Externalización de una parte o la totalidad de

cualquier actividad.

Se pueden identificar dos enfoques distintos:

Una actividad que era realizada

tradicionalmente en el ámbito interno pasa a ser

desarrollada por un proveedor externo.

Cualquier externalización de actividades de la

empresa, independientemente si ésta lo realizó

con anterioridad.

86



Objetivos de la Externalización

• Aumentar la competitividad de su negocio.

• Aumentar los niveles de calidad del servicio.

• Aumentar el servicio dado a los usuarios.

Estratégicos

• Reducción de Costes.

• Aumento de la Productividad. Financieros

87




88

Estratégicos

• Mayor focalización en su Core Business.

• Cambios en la dedicación de los responsables de informática.

• Liberar recursos para desarrollos estratégicos.

Aumentar la Compe-titividad

de Negocio




89

Estratégicos

• Plan de Garantía de Calidad que asegure los compromisos adquiridos con el proveedor.

• Definiendo unos indicadores claros de mejora.

• Reduciendo las interrupciones del sistema (Ej. Batch).

Aumentar los niveles de calidad

del servicio




90

Estratégicos

• Sistema mecanizado que le permite al usuario conocer la evolución de sus demandas (CAU).

• Despersonalizando la actividad del mantenimiento.

Aumentar el servicio dado a los usuarios




91

Financieros

• Mayor facilidad para imputar costes.

• Ahorro en la gestión y formación de las personas (proveedor).

• Conocer y fijar costes antes de realizar el servicio.

Reducción de costes




92

Financieros

• Nuevos desarrollos eliminan las interferencias de mantenimiento.

• Beneficio de la especialización de los proveedores.

• Mantenimiento como un proyecto cerrado.

Aumento de la

productivi-dad

Mantenimiento del Software - Kybele · 2012-04-11 · Tipos de Mantenimiento de SW Mantenimiento...

Documents

Transcript of Mantenimiento del Software - Kybele · 2012-04-11 · Tipos de Mantenimiento de SW Mantenimiento...