Tipos de Mantenimiento Preventivo: actividades para facilitar el mantenimiento futuro. Validación de datos entrada Mejoras en su legibilidad
Costos por Tipo Mantenimiento
Distribución del tiempo en tareas de mantenimiento (MCclure,1992)
El Proceso de Mantenimiento Varía considerablemente dependiendo del tipo de Software Proceso informal o formal. Actividades fundamentales: Análisis del cambio Planeación de la versión Implementación del sistema Entrega
Proceso mantenimiento, Arthur (1988) Peticiones de Cambio Análisis de Impacto Planeación de versiones Implementación de cambios Liberación del Sistema Reparación de fallas Adaptación de plataforma Perfeccionamiento del Sistema
Mito de los Desarrolladores Mito: Una vez que se escribe un programa y se hace funcionar el mismo, el trabajo de programación ha terminado. Realidad: Alguien dijo una vez "cuanto más pronto se comience a escribir código, más se tardara en terminarlo". Los datos indican que entre el cincuenta y sesenta por ciento de todo el esfuerzo dedicado a un programa se realizará después de la primera entrega del software al cliente.
Mito: Hasta que no se cuente con un programa ejecutable, realmente no se puede comprobar su calidad. Realidad: Desde el inicio de un proyecto de software debe aplicarse uno de los mecanismos más efectivos para garantizar la calidad del software: la revisión técnica formal. La revisión del software es un filtro de calidad que es mucho más efectivo que la prueba, para encontrar ciertas clases de defectos en el software.
Mito: Lo único que se entrega al terminar el proyecto es el programa funcionando. Realidad: Un programa que funciona es sólo una parte de una configuración de software que incluye programas, documentos y datos. La documentación es la base de un buen desarrollo y, lo que es más importante, proporciona guías para la tarea de mantenimiento de software
Predicción del Mantenimiento Mantenimiento Previsto Cambios previstos del Sistema Costos previstos de mantenimiento ¿Qué partes del sistema son mas probables de afectarse por las peticiones de cambio? ¿Cuántas peticiones de cambios se esperan? ¿Qué partes del sistema serán más costosas de mantener? ¿Cuáles serán los costos de mantenimiento durante el período de vida del sistema? ¿Cuáles serán los costos de mantenimiento de este sistema el próximo año? Predecir el numero de peticiones de cambios para un sistema requiere entender la relación entre el sistema y sus entorno
Evaluación relación sistema y su entorno Número y complejidad de las interfaces del sistema. Número de requerimientos inherentemente volátiles del sistema. Los procesos de negocios en los que se utiliza el sistema.
Ejemplos de métricas para evaluar la mantenibilidad: Número de peticiones de mantenimiento correctivo. Tiempo promedio requerido para el análisis de impacto. Tiempo promedio para implementar una petición de cambio. Número de peticiones de cambio pendientes. COCOMO 2
Otras estrategias de cambio del Software. Sommerville Cap. 27,28 Transformación Arquitectónica: cambios del SW para seguir dándole mantenimiento conforme se implementan cambios más importantes en la arquitectura del Sistema de Software. Evolución de una arquitectura centralizada a una Cliente-Servidor
Reingeniería del Software: No se agrega funcionalidad al sistema. Se modifica el SW para hacerlo más fácil de comprender y cambiar. Comprende algunas modificaciones estructurales y no cambios arquitectónicos mayores
Cambios del Sistema. Leyes de Lehman (y Belady) Ley: Cambio Continuo Un programa utilizado en un entorno real necesariamente debe cambiar o llegar a ser progresivamente menos útil en ese entorno. El mantenimiento es un proceso inevitable.
Ley: Incremento de la Complejidad. Puesto que un programa evolutivo cambia, su estructura tiende a ser mas compleja. Se deben dedicar recursos extra para preservar y simplificar la estructura. Puesto que el sistema cambia su estructura se degrada. Invertir en mantenimiento preventivo evita que esto pase.
Ley: Evolución prolongada del Programa. La evolución del programa es un proceso autoregulatorio. Los atributos del sistema, como el tamaño , el tiempo entre entregas y el número de errores reportados son aproximadamente invariantes para cada entrega del sistema
Ley: Estabilidad organizacional En el tiempo de vida de un programa, su tasa de desarrollo es aproximadamente constante e independiente de los recursos dedicados al desarrollo del sistema. Un cambio a los recursos o al personal tiene efectos imperceptibles en la evolución a largo plazo del sistema
Ley: Conservación de la familiaridad. En el tiempo de vida del sistema , el cambio incremental en cada entrega es aproximadamente constante. Incorporar nuevas funcionalidades al sistema introduce nuevas fallas al sistema.
Reingeniería del Software Nueva área de la Ingeniería del SW. Reducción del esfuerzo Reutilización de componentes Falta de estándares
Actividades (Arnold,1993)oTecnología de la Reingeniería Mejora del Software: Reestructuración Redocumentación, anotación, actualización de documentación Ingeniería para reutilización Remodularización Reingeniería de Procesos (BPR) Reingeniería de datos Análisis de facilidades de mantenimiento, análisis económico
Comprensión del Software: Visualización Análisis, mediciones. Ingeniería inversa, recuperación de diseño.
Captura, Conservación y extensión del Conocimiento sobre el Software. Descomposición Ingeniería inversa y recuperación de diseño Recuperación de objetos Comprensión de programas Transformaciones y bases de conocimiento
Razones de la importancia de la reingeniería del SW. Puede reducir los riesgos evolutivos de una organización. Puede ayudar a las organizaciones a recuperar sus inversiones de SW. Puede hacer el SW más fácilmente modificable. Amplía las capacidades de las herramientas CASE. Es un catalizador para la automatización del mantenimiento del SW. Puede actuar como catalizador para la aplicación de técnicas de inteligencia artificial (IA) para resolver problemas de reingeniería.
Evolución arquitectónica y el mantenimiento Desde los 80, los precios de los sistemas basados en computadoras han cambiado radicalmente. Los sistemas distribuidos son mas costeables que los centralizados. Las empresas se ven obligados a evolucionar de grandes mainframe a sistemas distribuidos.
Razones de esta evolución Los costos del hardware Las expectativas de la interfaz de usuario. Apariencia y funcionamiento mas modernos y que permite el trabajo distribuido. El acceso distribuido a los sistemas
Factores que influyen en la decisión de distribución del sistema Importancia en los negocios Edad del Sistema Estructura del sistema Políticas de adquisición del hardware
Principales dificultades en el cambio Interfaz de Usuario Servicios Base de datos Interfaz de usuario Servicios Base de Datos Modelo ideal para la distribución Sistemas heredados reales
Distribución se sistemas heredados Base de datos Servicios de aplicación Interfaz del usuario Terminales de caracteres Capa de middleware (sobrepuesta) Sistema Heredado Sistema Heredado
Modelo de distribución en capas
Opciones de distribución Control de la interacción Validación Servicios Base de datos Servidor: Servicios Base de datos Base de datos Servidor: Servidor: Cliente: Presentación Presentación Control de la interacción Validación de datos Presentación Control de la interacción Validación de datos Servicios Cliente: Cliente: Incremento del costo y el esfuerzo
Distribución de la interfaz de usuario Aprovecha el poder local de procesamiento disponible de los PCs para suministrar una interfaz gráfica mas adecuada. Existen dos estrategias de implementación para la distribución: Utilizando el sistema de administración de ventanas nativo del PC. E implementar comunicación con el servidor. Utilizando navegador WWW.
Utilizando Ventanas Ventajas: Acceso a todas las funciones de UI por lo que no existen restricciones reales sobre el diseño UI. Mejor desempeño de la UI. Desventajas: Dependiente de la plataforma Es más difícil lograr la consistencia de la interfaz.
Utilizando navegador WWW Ventaja: Independiente de la plataforma. Bajos costos de capacitación y familiaridad del usuario con el navegador. Es más fácil lograr la consistencia de la interfaz. Desventaja: El desempeño de la UI es potencialmente pobre. El diseño de la UI se restringe por los recursos suministrados por los navegadores Web.
Consideraciones sobre el diccionario de datos El modelo de análisis acompaña representaciones de objetos de datos, funciones y control. Estos juegan un papel importante. Es necesario proporcionar un enfoque organizado para presentar las características de cada objeto de datos y elementos de control .
Diccionario de datos Listado organizado de todos los elementos de datos que son pertinentes para el sistema , con definiciones precisas y rigurosas que permiten que el usuario y el analista tengan una misma comprensión de las entradas, salidas , de las componentes de almacenes y de los cálculos intermedios. El formato varía según las herramientas utilizadas (Case o de diseño estructurado).
Contenido del diccionario de datos (comúnmente) Nombre: el nombre principal del elemento de datos o de control, de almacén de datos , o de una entidad externa. Alias: otros nombres usados para la primera entrada. Donde se usa/cómo se usa: listado de los procesos que usan el elemento de datos o de control y cómo lo usan ( Ej. Como entrada al proceso, como salida al proceso, como almacén de datos ó como entidad externa).
Descripción del contenido: el contenido representado mediante una notación. Información adicional: otra información sobre los tipos de datos, los valores implícitos, las restricciones o limitaciones, etc.
Principales problemas No se le da importancia la información “donde se usa/cómo se usa” siendo tal vez una de la principales ventajas. No se toma en cuenta los efectos de los cambios en el análisis y menos en los procesos de mantenimiento. Efectos en los sistemas complejos y grandes, sobre todo problemas de consistencia. No se toma conciencia del aporte para la consistencia del modelo y lo que apoya al reducir errores. Difícil de mantener en forma manual y generalmente se utilizan herramientas Case.
Preguntas que se hacen los analistas sobre los datos… ¿Dónde se usa este elemento de datos? ¿Qué mas hay que cambiar simlo modificamos? ¿Cuál será el impacto general del cambio?
Notación utilizada para la descripción
Notación.. Permite representar una composición de datos en una de las tres alternativas fundamentales que pueden ser construidas: Como una secuencia de elementos de datos. Como una selección de entre un conjunto de elementos de datos. Como una agrupación repetitiva de elementos de datos.
Ejemplo: ( 01327 546381) Nombre: número de teléfono Alias: Fono Donde se usa/cómo se usa: Comprobar con ajustes iniciales (salida) Marcar número (entrada) Descripción: número de teléfono = prefijo + número acceso. Prefijo= [*un número de cuatro dígitos que comience en 0 ó un número de cinco dígitos que comience por ()] Número de acceso= *secuencia numérica de cualquier tamaño*
| Página siguiente |