Evolucion del Software_INGENIERIA DEL SOFTWARE

Vista previa del material en texto

CONTENIDO 
 
 TEMAS A DESARROLLAR FUENTE BIBLIOGRÁFICA 
 - Sommerville I., Cap. 9 
 
 
 
 
 
 
Curso de Auditorías 3 
“El desarrollo del software no se 
detiene cuando un sistema se 
entrega, sino que continúa a lo 
largo de la vida de éste” 
 
 
 
 
Curso de Auditorías 4 
-Es importante porque las 
organizaciones invierten 
grandes cantidades de 
dinero en ES y 
actualmente poseen una 
total dependencia de los 
sistemas. 
Puede potenciarse: 
-Al cambiar los requerimientos 
empresariales,. 
-Con reportes de defectos del 
software . 
-Por cambios a otros sistemas en un 
entorno del sistema de software. 
- La evolución de un sistema rara vez puede ser considerada en “aislamiento”,. 
- Los cambios al entorno conducen a cambios en el sistema, que a la vez, 
pueden generar más cambios en el entorno. 
Curso de Auditorías 5 
“La IS debe considerarse como un proceso 
en espiral con requerimientos, diseño, 
implementación y pruebas continuas, a lo 
largo de la vida del sistema” 
 
 
 
 
“Este modelo de evolución de software implica 
que una sola organización es responsable tanto 
del desarrollo del software inicial como de la 
evolución del mismo” 
 
 
 
 
Curso de Auditorías 6 
 
 
 
 
Curso de Auditorías 7 
La mayoría de los 
productos de 
software enlatados se 
desarrollan siguiendo 
este enfoque. 
Para software a medida, una 
empresa desarrolla el sistema 
para el cliente, luego el 
personal de desarrollo del 
cliente se hace cargo del 
sistema.(Evolución) 
* Alternativa: el cliente contrata 
a otra empresa para dar 
soporte al sistema y continúe 
su evolución 
Curso de Auditorías 8 
“Cuando la transición del desarrollo a la evolución no es 
uniforme (existe discontinuidad en el proceso espiral), 
el proceso de cambiar el software después de la entrega 
se conoce como “mantenimiento de software” 
 
 
 
 
 
 
DESARROLLO EVOLUCIÓN 
Transición no uniforme (Dicontinuidad 
en el proceso en espiral) 
MANTENIMIENTO 
DEL SOFTWARE 
Curso de Auditorías 9 
Rajlich y Bennet 
(2000) propusieron 
una visión alternativa 
del ciclo de vida de la 
evolución del 
software 
En este modelo se distingue entre 
evolución y servicio: 
. Evolución: es la fase donde es 
posible hacer cambios 
significativos a la arquitectura 
y la funcionalidad del 
software. 
. Servicio: se pueden realizar 
únicamente pequeños 
cambios. 
Curso de Auditorías 10 
 
 
 
 
Desarrollo 
Inicial 
Evolución Servicio 
Retiro 
gradual 
En alguna etapa de su ciclo de vida, el 
software alcanza un punto de transición 
donde los cambios significativos que 
implementan nuevos requerimientos se 
vuelven cada vez menos rentables. 
-En dicha etapa, el software avanza de la 
evolución al servicio. 
- Durante la fase de servicio la empresa 
normalmente considera cómo reemplazar 
el software. 
.En la fase final , de retiro gradual (Phase 
– out), el software todavía puede usarse, 
aunque no se implementen más cambios. 
Curso de Auditorías 11 
-Los procesos de evolución 
del software varían 
dependiendo de: 
1. El tipo de software que se 
mantiene 
2. Los procesos de desarrollo 
usados en la organización 
3. Las habilidades de las 
personas que intervienen 
En algunas organizaciones la 
evolución es un proceso informal, 
donde las solicitudes de cambios 
provienen sobre todo de 
conversaciones entre los usuarios 
del sistema y los desarrolladores 
- En otras organizaciones se trata de un proceso formalizado con 
documentación estructurada generada en cada etapa del proceso. 
Curso de Auditorías 12 
“Los procesos de identificación de 
cambios y evolución del sistema son 
cíclicos y continúan a lo largo de la vida 
de un sistema” 
 
 
 
 
Curso de Auditorías 13 
Proceso de identificación del 
cambio 
Proceso de evolución del 
software 
Propuestas de cambio Nuevo Sistema 
1 
2 
3 
4 
Curso de Auditorías 14 
 
 
Peticiones 
de cambio 
Análisis del 
impacto 
Reparación de 
fallas 
Mejora del 
sistema 
Planeación de la 
versión 
Cambio de 
implementación 
Liberación del 
sistema 
Adaptación de 
plataforma 
Curso de Auditorías 15 
 
 
Cambios 
propuestos 
Análisis de 
requerimientos 
Actualización de 
requerimientos 
Desarrollo del 
Software 
La etapa de implementación del cambio de este proceso debe modificar la 
especificación, el diseño y la implementación del sistema para reflejar los 
cambios al mismo. 
Curso de Auditorías 16 
-Las peticiones de cambio se relacionan con problemas del 
sistema que tienen que enfrentarse de manera urgente. 
-Estos cambios urgentes surgen por tres razones: 
1. Si ocurre una falla seria del sistema que deba repararse 
para permitir que continúe la operación manual. 
2. Si los cambios a los sistemas que operan el entorno tienen 
efectos inesperados que perturban la operación manual. 
3. Si hay cambios no anticipados a la empresa que opera el 
sistema, como el seguimiento de competidores nuevos o la 
introducción de nueva legislación que afecte el sistema 
 
 
 
 
 
Curso de Auditorías 17 
 
 
Peticiones 
de cambio 
Analizar el 
código fuente 
Modificar el 
código fuente 
Entregar el 
sistema 
modificado 
-La necesidad de realizar el cambio rápidamente significa que quizás 
no pueda seguir el proceso formal de análisis del cambio. 
- En vez de modificar los requerimientos y el diseño, se puede hacer 
una reparación de emergencia al programa para resolver el 
problema de inmediato. 
 
Curso de Auditorías 18 
“ Los métodos y procesos ágiles se 
utilizan tanto para la evolución del 
programa como para su desarrollo” 
 
 
 
 
“ En resumen, la evolución 
simplemente implica la continuación 
del proceso de desarrollo ágil” 
 
 
 
 
Curso de Auditorías 19 
-Pueden surgir problemas cuando haya 
transferencia de un equipo de desarrollo a un 
equipo separado responsable de la 
evolución. 
Cuando el equipo de desarrollo 
haya usado un enfoque ágil, pro el 
equipo de evolución no esté 
familiarizado con los métodos 
ágiles y prefiera un enfoque 
basado en un plan. 
(DOCUMENTACIÓN INCOMPLETA) 
Cuando se haya utilizado un 
enfoque basado en un plan para 
el desarrollo, pero el equipo de 
evolución prefiera usar métodos 
ágiles. (REINGENIERÍA O 
REFACTORIZACIÓN ) 
Curso de Auditorías 20 
“La dinámica de evolución del programa 
es el estudio del cambio al sistema” 
- Lehman establece la importancia de la 
retroalimentación en los procesos de 
evolución. 
- Propone Leyes relacionadas al cambio 
del sistema. 
 
 
 
 
 
Curso de Auditorías 21 
Curso de Auditorías 22 
“Es el proceso general de cambiar un 
sistema después que fue entregado al 
cliente” 
 
 
 
 
 
- Los cambios van desde los simples para corregir errores de 
codificación, los más extensos para corregir errores de 
diseño, hasta mejorías significativas para corregir errores 
de especificación o incorporar nuevos requerimientos 
 
 
 
 
 
Curso de Auditorías 23 
“Los cambios se implementan 
modificando los componentes del 
sistema existente y agregándoles 
nuevos componentes donde sea 
necesario” 
 
 
 
 
 
Curso de Auditorías 24 
Existen tres tipos de mantenimiento de software : 
1- Reparación de fallas (Mantenimiento Correctivo): fallas 
que pueden ser en la codificación, en el diseño. 
2- Adaptación ambiental (Mantenimiento Adaptativo): se 
requiere cuando el hardware, la plataforma operativa del 
sistema u otro soporte, tiende a cambiar el software 
desarrollado. 
3- Adición de funcionalidad (Mantenimiento Perfectivo): 
este tipo de mantenimiento es necesario cuando varían los 
requerimientos del sistema, en respuesta a cambios 
organizacionales o empresariales 
 
 
 
 
 
 
Curso de Auditorías 25 
-El Mantenimientodel software requiere 
mas presupuesto que el nuevo 
desarrollo. 
-Una mayor parte del mantenimiento se 
destina a la implementación de nuevos 
requerimientos y no a la reparación de 
bugs. 
 
 
 
 
 
 
Curso de Auditorías 26 
 
 
 
 
 
 
Adición o 
Modificación de 
funcionalidad 
(65 %) 
Adaptación 
ambiental 
(18 %) 
Reparación de 
fallas de 
desarrollo 
(17 %) 
Curso de Auditorías 27 
 
 
 
 
 
 
Sistema 1 
Sistema 2 
 100 200 300 400 500 600 700 $ 
Costos de desarrollo 
Costos de mantenimiento 
Curso de Auditorías 28 
“Resulta más costoso agregar funcionalidad después que un sistema 
está en operación, que implementarla durante el desarrollo” debido 
a: 
1- Estabilidad del equipo de desarrollo: una vez entregado el software, 
generalmente el equipo de desarrollo se disuelve. 
2- Práctica de desarrollo deficiente: el contrato para mantener un 
sistema por lo general está separado del contrato de desarrollo del 
sistema. 
3- Habilidades del personal: el personal de mantenimiento con 
frecuencia es relativamente inexperto y no está familiarizado con el 
dominio de aplicación. 
4- Antigüedad y estructura del programa: conforme se realizan 
cambios al programa, su estructura tiende a degradarse. 
 
 
 
 
 
 
Curso de Auditorías 29 
Mantenimiento del Software: 
1- Predicción de mantenimiento 
 
2- Reingeniería de Software 
 
3-Refactorización(Mantenimiento preventivo) 
 
 
 
 
 
Curso de Auditorías 30 
1- Se debe tratar de predecir qué cambios 
deben proponerse al sistema y qué partes del 
sistema es probable que sean las más difíciles 
de mantener . 
2- Tratar de estimar los costos de 
mantenimiento globales para un sistema 
durante cierto lapso de tiempo. 
 
 
 
 
 
 
Curso de Auditorías 31 
Curso de Auditorías 32 
“Para hacer que los sistemas de software 
heredados sean más sencillos de mantener se 
pueden someter a reingeniería para mejorar 
su estructura y entendimiento” 
 
 
 
 
 
 
Curso de Auditorías 33 
-La reingeniería puede implicar volver a 
documentar el sistema, refactorizar su 
arquitectura, traducir los programas a un lenguaje 
de programación moderno y modificar y actualizar 
la estructura y los valores de los datos del sistema. 
-La funcionalidad del software no cambia y 
normalmente conviene tratar de evitar grandes 
cambios a la arquitectura del sistema. 
 
 
 
 
 
 
Curso de Auditorías 34 
-Hay dos beneficios de la reingeniería respecto de la 
sustitución: 
1. Reducción del riesgo: introducir nuevo software 
implica estar sujeto a errores o tener problemas al 
desarrollar que implican costos. 
2. Reducción de costos: el costo de la reingeniería 
puede ser significativamente menor que el costo 
de desarrollar software nuevo. 
 
 
 
 
 
 
Curso de Auditorías 35 
El proceso de reingeniería 
Curso de Auditorías 36 
 
 
 
 
 
 
Reestructuración 
Automatizada del programa 
Conversión 
automatizada del código 
fuente 
Enfoques de reingeniería 
Reestructuración 
del programa y datos 
Reestructuración 
automatizada con 
cambios manuales 
Reestructuración más 
cambios arquitectónicos 
Aumento de costo 
(Opción más barata) (Opción más costosa 
Curso de Auditorías 37 
“La refactorización es el proceso de hacer 
mejoras a un programa para frenar la 
degradación mediante el cambio” 
 
 
 
 
 
 
 
Significa modificar un programa para mejorar su 
estructura, reducir la complejidad o hacerlo más 
fácil de entender. 
 
 
 
 
 
 
 
Mientras se refactoriza un programa, no debe 
agregarse funcionalidad, sino que hay que 
concentrarse en la mejora del programa(Optimizar). 
 
 
 
 
 
 
 
Curso de Auditorías 38 
-Situaciones que se pueden mejorar con refactorización: 
1. Código duplicado: el mismo código o muy similar puede 
incluirse en diferentes lugares del programa. 
2. Métodos largos: si un método es demasiado largo, debe 
rediseñarse en varios métodos más cortos. 
3. Enunciados de switch (case): en gral. Éstos implican 
duplicación donde el cambio (switch) depende del tipo de 
algún valor. 
4. Aglomeración de datos: ocurre cuando el mismo grupo de 
objetos de datos(atributos en clases, parámetros en 
métodos) vuelven a ocurrir en muchos lugares del programa. 
5. Generalidad especulativa: ocurre cuando los desarrolladores 
incluyen generalidad en un programa, en caso que se 
requiera en el futuro. 
 
 
 
 
 
 
 
Curso de Auditorías 39 
-La mayoría de las organizaciones tienen un conjunto de sistemas 
heredados que se utilizan con presupuesto limitado para 
mantenimiento y actualización. 
 
-Es necesario realizar una valoración de los sistemas heredados y 
decidir la estrategia adecuada para la evolución de dicho sistemas. 
 
-Existen cuatro opciones estratégicas: 
 
1. Desechar el sistema 
2. Dejar sin cambios el sistema y continuar el mantenimiento 
regular 
3. Someter el sistema a reingeniería para mejorar su 
mantenibilidad 
4. Sustituir todo o parte del sistema con un nuevo sistema 
 
 
 
 
 
 
Curso de Auditorías 40 
-Cuando se valora un sistema heredado tiene 
que observarse la perspectiva empresarial y la 
técnica: 
. Perspectiva empresarial: decidir si la 
compañía necesita realmente o no el sistema 
. Perspectiva técnica: hay que valorar la 
calidad del software de aplicación así como el 
hardware y software de soporte al sistema. 
“Finalmente se utiliza una combinación de 
ambos factores para decidir que hacer con el 
sistema heredado” 
 
 
 
 
 
Curso de Auditorías 41 
Curso de Auditorías 42 
-Para calcular el valor empresarial de un sistema se tiene que 
identificar a los participantes del sistema, los usuarios finales, 
los administradores y se deberá analizar: 
1. El uso del sistema: si los sistemas se utilizan ocasionalmente 
o por un pequeño numero de individuos quizá tenga un escaso 
valor empresarial 
2. Los procesos empresariales que se mantienen: un sistema 
puede tener un escaso valor empresarial porque utiliza 
procesos empresariales ineficientes. 
3. Confiabilidad del sistema: si el sistema no es confiable para 
clientes y empleados de la empresa, entonces posee un escaso 
valor empresarial. 
4. Salidas del sistema: si la empresa depende de las salidas 
que brinda el sistema, entonces tiene alto valor empresarial 
 
 
 
 
Curso de Auditorías 43 
Para valorar un sistema de software desde una 
perspectiva técnica se necesita considerar: 
1- Tanto el sistema de aplicación 
2- Como el entorno donde operará (hardware, 
sistemas operativos, compiladores, entornos 
de desarrollo, etc.) 
 
 
 
 
Curso de Auditorías 44 
Curso de Auditorías 45