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 anterior | Volver al principio del trabajo | Página siguiente  |