Liberando el sistema
•
Ayudar a los usuarios a entender y usar el
sistema
Distintos tipos de usuarios
•
Entrenamiento
•
Documentación
•
Solución de Problemas
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
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
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
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 ° ilustracionesDocumentació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
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
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
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
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?
Sistema S – solución bien conocida
Realidad
Problema
Especificación
de Requerimientos
Sistema
Comparación “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?Especificación
de Requerimientos
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 solucionesEspecificación
de Requerimientos
Sistema E – embebido en el mundo
real y cambia con la realidad
Realidad
Problema
Sistema
Comparación ¿Es una solución aceptable al problema en determinado contexto? Termina formando parte de la realidad que modelaCambio 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
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
“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)
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
Distrib. Esfuerzo mantenimiento en 487
proyectos (Lientz-Swanson 81)
Perfectivo
50%
Adaptativo
25%
Correctivo
21%
P
re
v
e
n
Problemas con el mantenimiento
•
Necesidad de balancear la necesidad de
cambio con la disponibilidad del sistema
•
Problemas
de Personal
Técnicos
Necesidades conflictivas
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
Problemas Técnicos
•
Especificaciones de diseño inadecuadas
•
Programas y documentos de mala calidad
•
Dificultades en pruebas
Ambiente
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
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
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
Técnicas y Herramientas
•
Gestión de la Configuración
Comité de Control de Cambios
Procedimiento de cambios
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
Procedimientos de cambios
•
Solicitud de cambio (normal)
evaluación priorización análisis de impacto implementación pruebas puesta en producción
Actividades
Gestionar mantenimiento del software Analizar impacto Entender software a cambiar Implementarcambio Evaluar efectos secundarios (Re)test
Software afectado Preventivo Adaptativo Correctivo Perfectivo Nuevo Sistema Solicitud de Cambio
Trazabilidad Horizontal
Documento de Requerimientos r1 r2 r2.2 r3 . . d1 d2 . . d1 d2 d1 d2 d3 Code m.1 Code m.2 Code m.3 Code m.4 Code m.5 Code m.6 Test t.11 Test t.10 Test t.1 Test t.2 Test t.3 Test t.4 Test t.5 Test t.6 Test t.7 Test t.8 Test t.9 Prueba Acep-tación n.2 ... ... ... ... ... ... ... ... ... ... Diseño de componentes Código de componentes PruebasGrafo subyacente
D2 D1 D3 D4 D5 D6 D7 D8 . . R2 R1 R3 R4 R5 R6 . C2 C1 C3 C4 C5 C6 C7 C8 . . T2 T1 T3 T4 T5 T6 T7 T8 . .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)
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
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 el proceso Reestructura • a partir del código •Representar internamente Redocumentar • desde el código • análisis estático • informe sobre estructura, Ingeniería Reversa•A partir del código • produce diseño y especificación
Reingeniería
• A partir del código • ingeniería
Reversa 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?
