Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas Mantenimiento de Sistemas 17.

Presentación del tema: "Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas Mantenimiento de Sistemas 17."— Transcripción de la presentación:

1 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas Mantenimiento de Sistemas 17

2 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 2 Contenido Mantenimiento Tipos de Mantenimiento: Perfectivo Adaptativo Correctivo Preventivo Estructural Reingeniería: Reestructuración Reingeniería Reingeniería Reversa Distribución Porcentual Costo de Mantenimiento: Evolución en el Tiempo Datos del Mercado Pasos Metodológicos: Evaluar Planificar Diseñar Codificar y Probar Documentar Implantar

3 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 3 Top Companies Turnaround Cambio y Muerte de Empresas 13 de las primeras 20 compañías de la selecta lista de FORTUNE de 1955 no figuran en el ranking de 2004, por diversas razones. Un tercio de las compañías de FORTUNE 500 desaparecieron entre 1970 y 1983. Casi la mitad de las compañías de FORTUNE 500 desaparecieron entre 1980 y 1990. Analizando la lista original de 1955, sólo 71 de aquellas compañías aún permanecen en la lista de 2004. El promedio de vida de una compañía en Japón y la mayoría de Europa es de 12,5 años. En USA, el 50% de las pequeñas compañías desaparece en 4 años, el 70% en 8 años y el 98% en 11 años.

4 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 4 Mantenimiento de Sistemas Introducción El manejo del cambio es una de las actividades esenciales en el desarrollo de un sistema y por lo tanto, de la Ingeniería de Software. Los cambios en los requerimientos conducen a cambios en el diseño y estos a cambios en el código de los programas. Una deficiente administración del cambio produce, por ejemplo: Programas que funcionaban bien de pronto dejan de hacerlo. Errores corregidos vuelven a aparecer. Cambios en los requerimientos o especificaciones que nunca llegan a completarse. Actualizaciones simultáneas al código de los programas. Es imposible o muy difícil volver atrás cambios ya efectuados. No se puede saber el estado en que se encuentran los cambios. II.113

5 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 5 Mantenimiento de Sistemas Definición Son todos los cambios, mejoras y correcciones que ocurren después que una aplicación ha sido puesta en producción. I.283

6 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 6 Tipos de Mantenimiento Introducción I.291 – II.214 Perfectivo Adaptativo Correctivo Preventivo Estructural Existen cinco tipos de mantenimiento para un sistema

7 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 7 Tipos de Mantenimiento Perfectivo Para agregar al sistema los cambios solicitados por los usuarios para cubrir nuevas necesidades del negocio o para modificar el sistema por requerimientos de mejora que hacen los usuarios a funciones existentes. Ejemplos: I.291 – II.214 Modificar la consulta de ordenes de compra. Agregar nuevas condiciones de cobranza para mejorar las opciones comerciales de los clientes. Incluir una leyenda publicitaria en las facturas. También se denomina Evolutivo

8 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 8 Tipos de Mantenimiento Adaptativo I.294 – II.214 Para ajustar el sistema a cambios en el entorno. Ejemplos: Ajustar el sistema a las nueva reglamentación de retenciones de ingresos brutos. Emitir un listado con las compras, según disposiciones de la AFIP. Realizar las modificaciones para aprovechar mejor la funcionalidad del nuevo sistema operativo.

9 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 9 Tipos de Mantenimiento Correctivo I.295 – II.214 Para corregir errores detectados en el sistema. Ejemplos: La orden de pago no actualiza correctamente la cuenta corriente. Cuando un cliente es de cuenta corriente, no debe mostrarse el descuento en la factura. El kardex suma mal la columna del Debe.

10 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 10 Tipos de Mantenimiento Preventivo II.214 Para modificar el sistema con cambios que hacen falta para mantener la eficiencia y la confiabilidad. Ejemplos: Modificar el diseño de la estructura de datos para mejorar la performance que se está degradando paulatinamente con el incremento de los datos almacenados.

11 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 11 Tipos de Mantenimiento Estructural II.214 Para modificar el sistema a fin de mejorar el futuro mantenimiento. Ejemplos: Mejorar la documentación del sistema. Modificar el código del módulo KY821.

12 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 12 Tipos de Mantenimiento Estructural III.240/242 Dentro del Mantenimiento Estructural existen las siguientes variantes: Reestructuración: transforma código desestructurado (“platos de fideos”) en un programa funcionalmente equivalente, pero menos complejo y mejor documentado (“más limpio”). Reingeniería: tampoco modifica la funcionalidad, pero cambia la forma en que está hecho, haciéndolo más eficiente y más claro. En parte se superpone con el Mantenimiento Perfectivo. Variantes

13 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 13 Tipos de Mantenimiento Reingeniería Reversa III.246 La idea de la Reingeniería Reversa es “redescubrir” la especificación original y el diseño del sistema desde la lógica de los programas. Existen herramientas CASE que recorren los programas, extrayendo la lógica oculta. A partir de ella, reconstruyen las especificaciones y el diseño del sistema. Algunas de estas herramientas, mejoran el diseño y entregan nuevas especificaciones para los programas.

14 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 14 Tipos de Mantenimiento Distribución Porcentual I.292 AdaptativoPerfectivo Correctivo 20% 25%55% Dentro del Perfectivo se incluye al Preventivo y al Estructural

15 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 15 Sembrados Removidos Ratio de Remoción Defectos Tiempo Cuándo Liberar? Siembra vs. Remoción V.202 MantenimientoDesarrollo La diferencia entre los errores sembrados y los removidos son los errores latentes del sistema. De acuerdo con la oportunidad de la decisión de liberación, es la cantidad de errores en el producto final.

16 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 16 Cuándo Liberar? Rápida Liberación del Producto En muchos casos se producen liberaciones apresuradas de productos. Gartner Group Area C Area A X Y Area B Tiempo Costo Beneficio Beneficio del “Time to Market” Beneficio de Probar (p.ej.: Remover Errores) Costo de Probar A: Area de “Suficientemente Bueno”. B: Area de ROI Positivo de la Prueba. C: Area de Retornos Descendentes. X: Punto de Liberación Y: Punto Optimo de Liberación

17 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 17 Costo de Mantenimiento Evolución en el Tiempo Costo Tiempo

18 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 18 Costo de Mantenimiento Las Tres Fuerzas del Mantenimiento Legacy Nuevos Sistemas Presupuesto Cuando el costo de mantenimiento anual supera el 30% del costo de desarrollo a nuevo, la aplicación debiera reemplazarse. I.285

19 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 19 Costo de Mantenimiento Datos del Mercado IV.146 El 60% de las 500 empresas de Fortune tienen altos costos de mantenimiento (*) (*) Los costos y recursos destinados a mantenimiento superan los asignados al desarrollo de nuevos sistemas.

20 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 20 Costo de Mantenimiento Datos del Mercado IV.146 En los casos más severos, el presupuesto anual destinado a mantenimiento supera el 65% del presupuesto total de desarrollo. En los mejores casos, no llega al 25%.

21 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 21 Costo de Mantenimiento Datos del Mercado IV.148 Las empresas con altos costos de mantenimiento no soportan, en promedio, más de 500PF por persona al año. Las empresas exitosas, por el contrario, llegan a tener un promedio de 1500PF por persona al año.

22 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 22 Puntos de Función Definición Desarrollados por Alan Albrecht en 1983. Establecen el esfuerzo de desarrollo del sistema en base a la productividad. La “funcionalidad” permanece constante. Para calcular la funcionalidad utiliza el número de inputs, outputs, archivos, interfaces y consultas que poseerá el sistema a desarrollar (Aspectos de Evaluación). Pasos : Se determinan los aspectos de evaluación. Se identifica el número de veces que cada aspecto aparece en el sistema. Se pondera cada aspecto (simple, medio o complejo). Mediante tablas, se obtiene el puntaje total. Se ajusta el puntaje con 14 factores de corrección.

23 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 23 Puntos de Función Algunos Valores del Mercado La productividad promedio en USA es de 5 PF por persona al mes. Para aplicaciones típicas de una organización es de 8 PF por persona al mes. Una productividad alta está alrededor de los 25PF por persona al mes. El costo de producir un PF en USA para proyectos civiles es de alrededor de US$ 600.-. En la India es de aprox. US$ 125.-. En Argentina, podría estar en el rango de $250.- a $350.- por PF. Los proyectos cancelados tuvieron una productividad promedio de 2 PF’s por persona por mes. El atraso y los altos costos son una de las causas más destacadas de cancelación de proyectos. IV.54/58

24 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 24 Pasos Metodológicos Introducción 1 Evaluar 2 Planificar 3 Diseñar 4 Codificar y Probar 5 Document ar 6 Implantar II.217

25 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 25 Pasos Metodológicos 1. Evaluar Objetivo: Analizar los requerimientos recibidos para modificar o mejorar un sistema existente en producción. Recibir y analizar la Requisición de Mantenimiento. Entender cómo trabaja el sistema. Identificar la modificación o mejora a realizar. Evaluar el impacto de la Requisición. Efectuar una estimación preliminar de costos y tiempos. Tareas a Realizar Requisición de Mantenimiento. Documentación del Sistema. Programas Fuentes. Entradas II.216218/227229 Productos Propuesta para corregir o mejorar el sistema. 1 Evaluar 2 Planificar 3 Diseñar 4 Codificar y Probar 5 Documentar 6 Implantar

26 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 26 Pasos Metodológicos 1. Evaluar La formalización del mantenimiento a través de Requisiciones es una best-practice de desarrollo de sistemas. Las Requisiciones de Mantenimiento son devueltas al usuario para su aprobación. En el caso de correcciones, propias del Mantenimiento Correctivo, no es necesaria una aprobación por parte del usuario. Sin embargo, el área de sistemas evalúa la urgencia. Las Requisiciones por mantenimiento Preventivo y Estructural son emitidas, generalmente, por la misma área de sistemas. Cuanto mejor haya sido el diseño del sistema y más actualizada esté la documentación, más fácil y precisa será la evaluación. Consideraciones II.216218/227229

27 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 27 Pasos Metodológicos 1. Evaluar Autorización del Cambio SCOCI Ejecución del Cambio En un proceso de cambio controlado existen 4 elementos básicos: Una Solicitud o Requerimiento de Cambio (SC) que emite quién desea hacer un cambio. Un procesos de evaluación y autorización o rechazo del cambio. Una Orden o Especificación de Cambio de Ingeniería (OCI). Un proceso de ejecución del cambio y control del mismo. Proceso Controlado

28 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 28 Pasos Metodológicos 1. Evaluar Solicitante: Problema: Justificación: Fecha:N°: Aprobó: Primer Análisis Costo: Impacto en los Plazos: Viabilidad: Vo. Bo. Usuario: Segundo Análisis Costo Detallado: Plazo: Módulos Impactados: Ventajas/Desventajas: Recursos: Vo.Bo. Director ProyectoVo.Bo. UsuarioVo.Bo. Comité

29 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 29 Pasos Metodológicos 2. Planificar Objetivo: Planificar y priorizar las Requisiciones de Mantenimiento aprobadas. II.223 Revisar las Requisiciones aprobadas aún abiertas. Determinar la prioridad y la dependencia con otras Requisiciones. Planificar la ejecución y la carga de trabajo en base a las estimaciones preliminares. Tareas a Realizar Requisición de Mantenimiento aprobada. Solución Propuesta. Entradas Productos Plan de Mantenimiento. 1 Evaluar 2 Planificar 3 Diseñar 4 Codificar y Probar 5 Documentar 6 Implantar

30 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 30 Pasos Metodológicos 3. Diseñar Objetivo: Preparar un diseño de la solución, evaluando diversas alternativas y seleccionando la mejor. II.224/225 Revisar en detalle la Requisición de Mantenimiento. Entrevistar al usuario. Realizar un Modelo Lógico de la solución. Evaluar la mejor manera de efectuar la corrección o mejora. Preparar un Diseño Detallado. Tareas a Realizar Plan de Mantenimiento. Requisición de Mantenimiento. Solución Propuesta. Programas Fuentes. Entradas Productos Diseño Detallado de la corrección o mejora. 1 Evaluar 2 Planificar 3 Diseñar 4 Codificar y Probar 5 Documentar 6 Implantar

31 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 31 Pasos Metodológicos 4. Codificar y Probar Objetivo: Desarrollar y probar los programas para concretar la modificación o mejora requerida. II.226 Crear un ambiente de mantenimiento. Rescatar los programas fuentes. Realizar la modificación o mejora (modificar programas o desarrollar nuevos). Hacer la prueba unitaria de programas Hacer las pruebas de regresión y de integración. Tareas a Realizar Diseño Detallado. Documentación del Sistema. Programas Fuentes. Entradas Productos Programas probados, listos para su puesta en producción. Modificaciones, para actualizar la documentación. 1 Evaluar 2 Planificar 3 Diseñar 4 Codificar y Probar 5 Document ar 6 Implantar

32 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 32 Pasos Metodológicos 4. Codificar y Probar Aunque la probabilidad de cometer errores durante el mantenimiento es mayor que durante el desarrollo, se presta poca atención al testing de los programas durante esta actividad. Se deben realizar muchos de los pasos propios del testing de sistemas: Efectuar tempranamente un Plan de Pruebas (durante el Diseño). Determinar los tipos de prueba a efectuar. Preparar los casos de prueba. Realizar pruebas de regresión e integración, fundamentales en las tareas de mantenimiento. Si se han guardado pruebas anteriores, estas se pueden reciclar al momento del mantenimiento. Consideraciones I.283/297/298/

33 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 33 Pasos Metodológicos 4. Codificar y Probar Algunas best-practices de codificación y prueba son: Tener procesos de Software Configuración Management. Si es posible, contar con herramientas automatizadas que colaboren con los procesos. Efectuar Pruebas de Regresión e Integración. Contar con herramientas automatizadas para realizar el testing. Disponer de ambientes específicos para realizar los cambios o mejoras y para la prueba de los programas. Tener técnicas probadas y maduras de diseño y codificación de programas. Consideraciones (Cont.)

34 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 34 Pasos Metodológicos 4. Codificar y Probar DesarrolloPruebaProducción Se realizan las Pruebas Unitarias en un ambiente aséptico y preparado para evitar inconvenientes entre programadores y con las aplicaciones en uso. Posee datos de prueba y un ambiente tecnológico similar al real, pero incompleto. Se efectúan las Pruebas de Integración, del Sistema y de Aceptación. Posee datos y un ambiente tecnológico similar al real. Ambiente real donde se implanta la aplicación Ambientes de Prueba

35 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 35 Pasos Metodológicos 5. Documentar Objetivo: Actualizar la documentación del sistema en base a las modificaciones o mejoras realizadas. II.226 Recibir y analizar las modificaciones efectuadas. Rescatar la documentación y actualizarla. Constatar la integridad de todos los componentes. Efectuar auditorías de documentación, a fin de comprobar su actualización. Tareas a Realizar Diseño Detallado. Documentación del Sistema. Modificaciones. Entradas Productos Documentación actualizada. 1 Evaluar 2 Planificar 3 Diseñar 4 Codificar y Probar 5 Documentar 6 Implantar

36 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 36 Pasos Metodológicos 6. Implantar Objetivo: Transferir las mejoras o modificaciones a producción. II.226 Preparar material de entrenamiento. Entrenar a los usuarios. Transferir a producción. Poner en marcha. Tareas a Realizar Programas probados. Documentación actualizada. Entradas Productos Mejora o modificación en producción. 1 Evaluar 2 Planificar 3 Diseñar 4 Codificar y Probar 5 Documentar 6 Implantar

37 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 37 Mantenimiento de Sistemas Métricas Cantidad de cambios exitosos. Cantidad de cambios revertidos y sus causas. Cantidad de cambios urgentes. Cantidad de incidentes post cambio. Costo por cambio. Cantidad de cambios hechos fuera del proceso formal. Cambios por programa, por aplicación, por usuario, por área. Tamaño de Back-log y variaciones período a período. Cumplimiento de plazos y costos programados.

38 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 38 Mantenimiento de Sistemas Métricas Algunos métricas características para el seguimiento y control de la calidad durante el mantenimiento de una aplicación son: Backlog de Defectos a Corregir. Índice de Administración del Backlog (BMI: Backlog Management Index). Tiempo de Respuesta de las Correcciones. Porcentaje de Correcciones Descuidadas o Negligentes. Calidad de las Reparaciones. Ejemplos de Métricas Típicas

39 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 39 Mantenimiento de Sistemas Métricas Backlog de Defectos a Corregir: Está relacionado tanto con la llegada de defectos como con la efectividad de corrección. Se mide como la cantidad de errores válidos pendientes de corrección al cierre de un período, generalmente un mes. Índice de Administración del Backlog (BMI: Backlog Management Index): Si el BMI es mayor a 100, significa que el backlog se está reduciendo. BMI = Cantidad de Defectos Cerrados Durante el Mes Cantidad de Defectos Llegados Durante el Mes x 100 Ejemplos de Métricas Típicas

40 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 40 Mantenimiento de Sistemas Métricas Tiempo de Respuesta de las Correcciones (TRC): Tiempo promedio que los defectos están abiertos durante un período dado. Normalmente se lleva por grado de severidad. Calidad de las Reparaciones: mide la cantidad de errores que vuelven a ser reportados por los usuarios, indicando una corrección defectuosa. Se mide respecto del período en que fue realizada la corrección, como un porcentaje de este tipo de errores respecto del total corregido. Ejemplos de Métricas Típicas

41 Ingeniería Informática Ingeniería de Software I © 2012 – Mantenimiento de Sistemas 41 Referencias Bibliográficas I.Software Testing and Continuous Quality Improvement; W. Lewis – 2000. II.Practical Guide to Structure System Development and Maintenance; R. Fournier – 1991. III.Decline & Fall of the American Programmer; E. Yourdon – 1993. IV.Assessment and Control of Software Risks; C. Jones – 1994. V.Controlling Software Projects; Tom DeMarco – 1991.