Ingeniería Software II

Unidad I

Mantenimiento

Mantenimiento del SoftwareDistribución del Costo del Ciclo de

Vida (Rock-Evans y Hales, 1990)

Pruebas Modulares

8%

Código7%

Diseño5%

Análisis de Requisitos

6%Pruebas de Integración

7%

Mantenimiento

67%

• Fase que se inicia de finalizada las Pruebas

•Fase más costosa del ciclo. El 80% del presupuesto de los CPD en 1987, 95% en 1995 (Frazer).

•Barrera de mantenimiento cuando sobrepasa límite de recursos

Factores que afectan el Costo Inexistencia de métodos, técnicas y

herramientas que proporcionen una solución global al mantenimiento.

La complejidad de los sistemas se incrementa paulatinamente por la realización de continuas modificaciones. Perdida de información, menos personas

conocen el SW. La documentación es defectuosa o

inexistente. Programación de baja calidad, no

estructurada o sin estilo estandarizado.

Factores que afectan el Costo

Considerada actividad poco creativa, supuestamente mas sencilla y menos importante.

Se realizan bajo presión de tiempo. Poca participación del usuario durante

el desarrollo del sistema.

Definición del Mantenimiento

Corrección de defectos en el software.

Creación de nuevas funcionalidades en el software por nuevos requisitos de usuario.

Mejora de la funcionalidad y del rendimiento.

Definición según el estándar IEEE, 1990

Proceso de modificar un sistema o componente software después de su entrega para corregir defectos, mejorar el rendimiento u otros atributos o adaptarlo a un entorno cambiante.

Tipos de Mantenimiento

Perfectivo:Mejoras al rendimientoAumento de facilidad para mantener

un programa ante cambios.Nuevas funcionalidades (de

ampliación) y mejoras de eficiencia de ejecución (Gorla,1991).

Tipos de Mantenimiento

Adaptativo: conjunto actividades para adaptar el sistema a los cambios (HW o SW) en su entorno tecnológico.El entorno de datos: cambio de

soporte de los datos de una aplicación• Archivos a sistema Relacional

El entorno de Proceso:• Nueva plataforma de explotación• Nuevo Sistema Operativo

Tipos de Mantenimiento

Correctivo: Corrección de defectos en el HW o SW

detectados por el usuario en la explotación .• Terminaciones anormales o salidas incorrectas…

Procesamiento• Tiempos de respuestas altos….Rendimiento• Violación de estándares de programación o

inconsistencias del diseño…Implementación

Pruebas y actualización de documentación luego de las modificaciones.

Tipos de Mantenimiento

Preventivo: actividades para facilitar el mantenimiento futuro.Validación de datos entradaMejoras en su legibilidad

Costos por Tipo Mantenimiento

Costos por Tipo Mantenimiento (Frazer, 1992)

Perfectivo60%

Correctivo17%

Preventivo5%

Adaptativo18%

Distribución del tiempo en tareas de mantenimiento (MCclure,1992)

Estudiar peticiones

18%

Estudiar documentación

6%

Estudiar código23%

Realizar pruebas28%

Actualizar documentación

6%

Implementar cambio

19%

El Proceso de Mantenimiento Varía considerablemente

dependiendo del tipo de Software Proceso informal o formal. Actividades fundamentales:

Análisis del cambioPlaneación de la versiónImplementación del sistemaEntrega

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 ContinuoUn 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 organizacionalEn 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ónAnálisis, mediciones.Ingeniería inversa, recuperación de

diseño.

Captura, Conservación y extensión del Conocimiento sobre el Software.DescomposiciónIngeniería inversa y recuperación de

diseñoRecuperación de objetosComprensión de programasTransformaciones 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

Presentación Despliegue y organización de las pantallas presentadas a los usuarios finales

Validación de datos

Comprobación de los datos de entrada por medio de una salida al usuario final.

Control de la interacción

Manejo de la secuencia de operaciones de los usuarios finales y a la secuencia de pantallas presentadas al usuario

Servicios de aplicación

Suministrar los cálculos básicos provistos por la aplicación.

Base de datos Suministra almacenamiento y administración a los datos de la aplicación.

Opciones de distribución

Control de la interacción

Validación

Servicios

Base de datos

Servidor: Servicios

Base de datos

Base de datosServidor: Servidor:

Cliente: PresentaciónPresentació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 plataformaEs 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

Construcción de datos

Notación Significado

Agregación = Está compuesto de

Secuencia + y

Selección [ I ] Uno u otro

Repetición { } “

( )

*…..*

N repeticiones de

Datos opcionales

Delimitadores de comentarios

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*