Liberando el sistema - fing.edu.uy

May-12 Ing. de Software Liberación y Mantenimiento - 1

Liberando el sistema

• Ayudar a los usuarios a entender y usar el sistema

�Distintos tipos de usuarios

• Entrenamiento

• Documentación

• Solución de Problemas

• Conversión

• Instalación


Entrenamiento• Dos grupos a entrenar:

�Usuarios finales

�Operadores/Administradores

• Usuarios�Presentar lo que hace el sistema

�Cómo usarlo

• Operadores o Administradores�Funciones de soporte

�Explicar cómo funciona

• Diferentes necesidades�usuarios frecuentes/eventuales

�usuarios nuevos/experientes


Revisión del entrenamiento

• Evaluar el entrenamiento

�Grado de uso del sistema

�Eficiencia en el uso

�Cumplimiento de objetivos

• Entrenamiento debe tomar en cuenta:

�características y preferencias personales

�estilos de trabajo

�presiones de la organización


Ayudas al entrenamiento

• Documentos� cuidado con el tamaño (asegurar lectura y relación costo/beneficio)° Guías/referencias

• Ayuda en línea

• Demostraciones

• Talleres� ¿cuándo hacerlo?

° conflictos por: disponibilidad, validación temprana, olvido por desuso

• Usuarios expertos�entrenadores

�pueden dar primer nivel de soporte (descentralización)

Parte importante de la Validación


Documentación• Parte de enfoque adecuado del entrenamiento

• Facilita soporte y solución de problemas

• Importancia depende de:�número de usuarios (+)

�dispersión (+)

• Atributos de calidad� legibilidad

° estructura

° tamaño

° ilustraciones

° facilidad para ubicar información relevante

� completo

� correcto


Documentación• atender las distintas visiones/necesidades

�usuarios finales

�administradores/operadores

� instalación/configuración

�personalización/mantenimiento

�visión general/detalles específicos

• Para operador� configuraciones de hardware y software

�procedimientos para° autorizar acceso a usuarios

° agregar o suprimir equipo periférico

° generar copias de respaldo

° solucionar problemas


Soporte y solución de problemas

• Guía de mensajes de error

�ayuda para detectar, informar y manejar problemas

�utilizado para solución de problemas

• Guía rápida

�con las funciones más importantes

• Ayuda en línea

• Asistencia activa y entrenamiento en línea


Conversión• Sustituir un sistema anterior por uno nuevo

�manual o automatizado

�carga inicial de° datos básicos

° información histórica (calidad de datos)

• Estrategia de conversión�big-bang

�paulatina° convivencia (-)

° ajuste de procedimientos (+)

�procesamiento en paralelo° uno en producción, el otro en prueba/control


Instalación

• Instalar el software de forma que quede disponible y operativo

�Su complejidad depende de:° Tecnología utilizada

° Restricciones funcionales (por ejemplo temporales)

° Requerimientos de disponibilidad

�La facilidad de instalación afecta la liberación inicial y las sucesivas liberaciones durante el mantenimiento


Preguntas

• ¿Cuándo corresponde comenzar la planificación de la liberación de un sistema? ¿Por qué?

• ¿Qué aspectos resulta necesario atender durante la liberación?

• ¿Qué relevancia tiene la documentación del software para su puesta en funcionamiento?

• ¿Por qué resulta conveniente asignar recursos para la solución de problemas durante el período inicial de la implantación de un sistema?

• ¿Qué distintas estrategias de conversión existen? ¿Qué ventajas y desventajas presenta cada una de ellas?


Manteniendo el Sistema

• El sistema cambiante...

• Naturaleza del mantenimiento

• Problemas

• Medición de las características

• Técnicas y Herramientas

• Rejuvenecimiento del software


El sistema cambiante...

• Cualquier modificación realizada a un sistema luego de entrar en operación se considera mantenimiento

• El hardware se gasta y deteriora ¿el software también?

• Tipos de sistemas: S, P, E


Sistema S – solución bien conocida

Realidad

Problema

Especificación de Requerimientos

Sistema

Información

Comparación

Puede cambiar

“Specifiable”

Se puede especificar

formalmente y de forma completa.Un

cambio en la especificación

cambia el problema

S No es candidato a cambiar.

Otra especificación corresponde a otro

problema

¿Cumple la Especificación?



Sistema P – basado en una abstracción práctica del problema

Realidad

Problema

Sistema

Información

Comparación

Puede cambiar

Se especifica una abstracción

(simplificación) del problema

“Problem-Solving”

P es candidato a cambiar

¿Es una solución

aceptable al problema?

Pueden haber soluciones mejores



Sistema E – embebido en el mundo real y cambia con la realidad

Realidad

Problema

Sistema

Información

Comparación

Puede cambiar

¿Es una solución

aceptable al problema en determinado contexto?

Termina formando parte de la realidad que modela


Cambio durante el ciclo de vida

• Todo puede cambiar

• Considerar el cambio durante el desarrollo

• Facilitar el cambio durante el mantenimiento

• ¿Es posible construir el sistema correcto la 1a. vez?

• Mantenimiento = evolución

• Sistemas legados (legacy) construidos para otras necesidades y ambiente


Sistemas legados (legacy)

• construidos hace años

• normalmente con herramientas y tecnología hoy obsoletas

• pueden resultar críticos para las organizaciones

�aplicación central al negocio

�difícil (costo, riesgo) de sustituir

�alto costo de mantenimiento/operación (personal, conocimiento, documentación,...)


Desarrollo vs. Mantenimiento

• Desarrollo típico 6 meses – 2 años

• Mantenimiento: 5, 10, + años...

• Evolución ¿declinación?

�Costo de mantenimiento

�Confiabilidad

�Adaptabilidad

�Desempeño

�Funciones de poca utilidad

�Otros sistemas hacen lo mismo a menor costo


“Leyes de la evolución del software”(Lehman 80)

a partir de observación de sistemas grandes en orgs. grandes

• Continuidad del Cambio: � cambia o se vuelve menos útil

• Complejidad creciente: � deterioro de la estructura y complejidad crece (a menos que se actúe para disminuirla)

• Ley fundamental de la evolución de un programa� Dinámica con tendencia e invariantes estadísticos

• Conservación de la estabilidad organizacional� La producción tiende a ser estadísticamente invariante (agregar más personas no la incrementa)

• Conservación de la familiaridad (complejidad percibida)� Contenido de las sucesivas versiones es estadísticamente invariante


Naturaleza del mantenimiento

• Correctivo�Respuesta a los problemas que surgen en el uso diario

• Adaptativo�Respuesta a cambios en el ambiente

• Perfectivo�Mejorar algún aspecto ya presente

• Preventivo� Introducir cambios para prever fallas


Distrib. Esfuerzo mantenimiento en 487

proyectos (Lientz-Swanson 81)

Perfectivo50%

Adaptativo25%

Correctivo21%

Preventivo

4%


Problemas con el mantenimiento

• Necesidad de balancear la necesidad de cambio con la disponibilidad del sistema

• Problemas

�de Personal

�Técnicos

�Necesidades conflictivas

�Costo


Problemas de Personal

• Comprensión limitada�47% de esfuerzo dedicado a entender el sistema (Parikh-Zvegintzov 83)

� Impacto de un cambio

� Información incompleta o incorrecta al reportar problemas

• Prioridades de la gerencia�Mantenimiento y mejora más o menos importante que desarrollar nuevas aplicaciones

�Según estudio de Lientz-Swanson 81:

- Motivación - 11,9% de problemas

- Prioridades múltiples o cambiantes - 8% de problemas


Problemas Técnicos

• Especificaciones de diseño inadecuadas

• Programas y documentos de mala calidad

• Dificultades en pruebas

�Ambiente

�Datos – volumen


Necesidades conflictivas

• elegancia y principios de diseño y urgencia de la solución

• Solucionar un problema en un sistema que no domina�Solución adecuada y a la vez rápida

�Impacto del cambio

• Necesidades de corto plazo y de largo plazo�Costos actuales vs. Futuros

• Política de versiones�Planificación de incorporación de cambios


Costo del mantenimiento

• Todos los problemas contribuyen a elevar los costos de mantenimiento

• Tendencia creciente de los costos de mantenimiento�40-60 % del costo total en los 80

� ¿80% en 2000?

• Factores adicionales�Secuencia de reparaciones y mejoras centradas en soluciones de corto plazo incrementan costos de mantenimientos subsiguientes

�Especialización del personal


Factores que inciden en el

costo del mantenimiento

• Estabilidad del equipo de mantenimiento

• Responsabilidad contractual�desarrolladores sin responsabilidad por el mantenimiento pueden no haber diseñado para el cambio

• habilidades del personal�a menudo con poca formación/entrenamiento en herramientas y dominio de aplicación

• Edad y estructura de los programas�Con el paso del tiempo, los programas “envejecen” y se degrada la estructura, con lo que se vuelven másdifíciles de entender y modificar


Técnicas y Herramientas

• Gestión de la Configuración

�Comité de Control de Cambios

�Procedimiento de cambios

• Análisis de Impacto


Comité de Control de Cambios

Objetivo: controlar los cambios (mejoras o corrección de defectos)

° Integra Cliente, Usuarios, Desarrolladores

Pasos

�Solicitud de Cambio (o reporte de problema)

�CCC califica (defecto, cambio)

�evalúa (severidad, impacto)

�prioriza

�Asigna su atención

Procedimiento

�Asegura que se cumplan los pasos y su registro

�Cuándo, quién, por qué, qué cambió, aprobó


Procedimientos de cambios

• Solicitud de cambio (normal)�evaluación

�priorización

�análisis de impacto

� implementación

�pruebas

�puesta en producción

• Solicitud de cambio (emergencia)


Actividades

Gestionar mantenimiento

del software

Analizarimpacto

Entendersoftware

a cambiar

Implementarcambio

Evaluar efectos secundarios

(Re)testSoftware afectado

PreventivoAdaptativoCorrectivoPerfectivo

NuevoSistema

Guía para definir Impacto/Alcance

Trazabilidad

ComplejidadModularidadDocumentaciónAuto descripcíon

Adaptabilidad EstabilidadConsistencia

Facilidad de PruebasVerificaciónCompletitud

SistemaExistente

Solicitud deCambio


Trazabilidad Horizontal

Documento de Requerimientos

r1r2r2.2r3..

d1d2..

d1d2..

d1d2d3

Code m.1

Code m.2

Code m.3

Code m.4

Code m.5

Code m.6 Test t.11Test t.12

Test t.10

Test t.1Test t.2Test t.3Test t.4Test t.5Test t.6Test t.7Test t.8Test t.9

PruebaAcep-tación

n.2

...

...

...

...

...

...

...

...

...

...

...

...

Diseño de componentes

Código decomponentes

Pruebas


Grafo subyacente

D2D1

D3D4D5D6

Dk

D7D8...

R2

R1

R3

R4

R5

R6

Rj

.

.

C2C1

C3C4C5C6

Cm

C7C8...

T2T1

T3T4T5T6

Tn

T7T8...

Requerimientos Diseño Código Pruebas


Herramientas para Mantenimiento

• Editores de Texto

• Compiladores y Linkers

• Debuggers

• Analizadores estáticos de código

• Generadores de Referencias Cruzadas (impacto)

• Gestión de Configuración� Manejo de versiones (original + delta; último y deltas inversos)

� Control de acceso concurrente

� Facilidades para reconstruir ejecutable (make)

� Comparadores de archivos (diff)

� Gestión de Paquetes de Cambio (versiones asociadas- etiquetas)


Métricas del proceso

• Permiten evaluar la mantenibilidad�número de solicitudes de mantenimiento correctivo

� tiempo promedio para análisis de impacto

� tiempo promedio para implementar solicitud de cambio

�número de solicitudes de cambio pendientes

• un incremento en cualquiera de ellos puede estar indicando problemas de mantenibilidad


Métricas del producto

• Complejidad�estructuras de control

�estructuras de datos

� tamaño de procedimientos y módulos

• permite predecir esfuerzo de mantenimiento


Historia de esfuerzo de mantenimiento

• Por componente, permite�evaluar conveniencia de re-escribir/re-diseñar en lugar de mantener

• Estudios muestran� concentración de esfuerzo de mantenimiento en pocos módulos


Rejuvenecimiento del software

• Trata de mejorar la calidad global de un producto (normalmente sistema heredado)

• Redocumentar – análisis del código fuente para proveer más información para asistir al mantenimiento

• Reestructurar – transformar código mal estructurado en código bien estructurado – transformar arquitectura

• Ingeniería Reversa – recrear diseño y especificación a partir del código

• Reingeniería – ingeniería reversa seguida de ingeniería directa para ajustar especificación, rediseñar y construir


Rejuvenecimiento del software

ESPECIFICACION

DISEÑO

CODIGO FUENTE

Ingeniería Directa• sigue elproceso

Reestructura• a partir del código•Representarinternamente•Simplificar la estructura y eliminar código muerto•Regenerar código

Redocumentar• desde el código• análisis estático • informe sobre estructura, complejidad,volumen, datos,etc.

Ingeniería Reversa•A partir del código• produce diseñoy especificaciónbasada en métodos de software aceptados• controla la representación

Reingeniería• A partir del código• ingenieríaReversa seguida de•Ingeniería directa


Preguntas• ¿Por qué resulta necesario realizar mantenimiento del

software? ¿Qué le pasa usualmente a un software que no se mantiene?

• ¿Cómo es posible clasificar los tipos de mantenimiento en función de sus objetivos?

• ¿Qué porcentaje del costo total del software corresponde a mantenimiento?

• ¿Qué problemas plantea el mantenimiento?• ¿Qué necesidades conflictivas aparecen durante el

mantenimiento?• ¿Qué hay que hacer para que los atributos de calidad del

software no se degraden durante el mantenimiento?• ¿Qué problema plantean los “sistemas legados”? ¿Por qué

siguen existiendo?• ¿Qué técnicas hay para rejuvenecer el software?

Liberando el sistema - fing.edu.uy

Documents

Transcript of Liberando el sistema - fing.edu.uy