Está en la página 1de 4

Contenidos:

Dinmica de evolucin de los programas


Mantenimiento de software
Procesos de evolucin
Evolucin de sistemas heredados

1. Dinmica de evolucin de los programas: Estudio de los cambios del sistema.


Leyes Lehman:
- Cambio continuado: Debe cambiar o se volver menos til.
- Complejidad creciente: Crece la complejidad al realizar cambio. (simplificar)
- Evolucin prolongada del programa:
- Estabilidad Organizacional: Velocidad de desarrollo cte. (independiente)
- Conservacin de la familiaridad: Cambios cte, no abrupto.
- Crecimiento continuado: Crecer siempre, mantener satisfaccin.
- Decremento de la Calidad: Debe adaptarse al entorno, o bajara calidad.
- Realimentacin del Sistema: Sistemas multiagenda y multibucle.

2. Mantenimiento del Software: Proceso de cambiar el sistema despus de que se ha


entregado. (Errores de cdigo, diseo, nuevos requerimientos).
Tres tipos de mantenimiento:
- Reparar defectos del software: generalmente errores de cdigo.
- Adaptar el Software: cambios en el entorno del sistema (hardware).
- Aadir o modificar funcionalidad: cambio de requerimientos.
(mantenimiento correctivo, adaptativo, perfectivo)
Es ms caro aadir funcionalidad a un sistema que ya est hecho, que aadirlas al
momento de su desarrollo, factores que hacen el coste de mantenimiento elevado:
-

Estabilidad del equipo: El equipo que desarrolla no se preocupa del


mantenimiento, si no, de hacer su trabajo eficiente en el momento.
Responsabilidad Contractual: El equipo de desarrollo ahorrar esfuerzos, ya que
no seguir trabajando en el sw.
Habilidad del personal: El mantenimiento tiene menos importancia, se les asigna a
personas principiantes.
Edad y estructura del programa: Programas no estructurados, son complejos a
medida que pasa el tiempo.

Prediccin del mantenimiento:


- Mantenimiento previsto
- Cambios previos del sistema
- Costes previstos de mantenimiento

El mantenimiento de un sistema tiene relacin directa con el entorno de este, es por esto que
las mantenciones previstas deben considerar:
-

Nmero y complejidad de las interfaces.


Numero de requerimientos intrnsecamente voltiles.
Proceso de negocios en los que se utiliza el sistema.

Despus de que el sistema se haya puesto en funcionamiento, es posible usar los datos del
proceso para predecir la mantenibilidad. (cuando es necesario disminuir el mantenimiento)
Ejemplos:
-

Nmero de peticiones de mantenimiento correctivo.


Tiempo medio requerido para el anlisis de impacto.
Tiempo medio empleado para implementar una peticin de cambio.
El nmero de peticiones de cambio pendientes.

3. Procesos de evolucin: Incluyen actividades fundamentales de anlisis de cambios,


planificacin de entregas, implementacin de un sistema y entrega de un sistema a los
clientes. (Proceso iterativo).
Identificacin de cambios Propuestas de Cambio Evolucin de Sw Nuevo
Sistema
Evolucin del Sistema

Implementacin de cambios

Hay cambios que deben ser solucionados en el momento o con urgencia, se pueden
dar por las siguientes razones:
- Defecto del sistema que impida el funcionamiento normal de este.
- Cambios en el entorno impiden el funcionamiento normal del sistema.
- Cambios no anticipados en la empresa que utiliza el sistema.

Reingeniera de sistemas: Re implementacin de sistemas heredados, para hacerlos


ms mantenibles. Re documentar, organizar y reestructurar el sistema. Traducir a un
lenguaje ms moderno y modificar la estructura.
Ventajas:
- Riesgo Reducido: Volver a desarrollar puede traer errores y perdidas.
- Coste Reducido: Es ms barato que desarrollar.

Costes de la reingeniera:
-

Calidad del sw sobre el que se va hacer la reingeniera.


Las herramientas e soporte disponibles para la reingeniera.
La amplitud de la conversin de datos requerida.
La disponibilidad de personal experto.

4. Evolucin de sistemas heredados: Mantener y actualizar un sistema.


4 opciones:
- Desechar completamente.
- Dejar sistema sin cambios y continuar con mantenimiento regular.
- Hacer reingeniera para mejorar su mantenibilidad.
- Remplazar todo o parte por un nuevo sistema.
Puedes aplicarse varias opciones a un sistema, para tomar una decisin hay que verlo desde
una perspectiva tcnica y una de negocio. Esto se divide en cuatro clases de sistema:
-

Baja calidad y bajo valor de negocio. Desecharse


Baja calidad y alto valor de negocio. Reingeniera
Alta Calidad y bajo valor de negocio. No hacer nada, cambios carosDesechar.
Alta Calidad y alto valor de negocio. No modificar.

Para evaluar el valor de negocio, es necesario identificar:


-

El uso del sistema


Los procesos de negocios que estn soportados.
Confiabilidad en el sistema
Salidas del sistema

Para evaluar su valor tcnico, hay que recoger datos cuantitativos para juzgar su calidad,
ejemplos:
-

Nmero de peticiones de cambio de sistema


Numero de interfaces de usuario
El volumen de datos utilizado por el sistema