CAPITULO 27 REINGENIERIA

El software suele ser la realización de las reglas de negocios. A medida que cambian estas reglas, el
soft. tiene que cambiar también.

27.1 REINGENIERÍA DE PROCESOS DE NEGOCIO.

La reingeniería de procesos de negocio (BPR) va más alla del ámbito de las tecnologías de la
información y de la ingeniería del software.
Def: búsqueda e implementación, de cambios radicales en los procesos de negocios para lograr
resultados emergentes.
La tecnología de la información es el medio para hacer que los negocios sean más competitivos. El
que la BPR tenga su papel sigue debatiéndose en la actualidad.

27.1.1. Procesos de negocio.

Def: conjunto de tareas lógicamente relacionadas que se efectúan con el objeto de obtener un
determinado resultado de negocios. Se combinan en el: personas, equipos, recursos materiales y
procedimientos de negocios con el objeto de producir un resultado concreto. Ej: diseño de un nuevo
producto, pago a proveedores, la adquisición de servicios y suministros, etc.
Cada proceso del negocios posee un cliente bien definido – una persona o grupo que recibe el
resultado. Requieren que participen distintos grupos de la organización en las tareas lógicamente
relacionadas que definen el proceso.

Cada sistema de negocios (negocio global) está compuesto por uno o más procesos de negocio y
cada proceso de negocio esta definido por un conjunto de subprocesos.
Se puede aplicar BPR a cualquier nivel de la jerarquía pero a medida que se asciende dentro de la
jerarquía los riegos asociados a la BPR crecen de forma dramática. Por esto la mayor parte de los
esfuerzos de BPR se centran en procesos o subprocesos individuales. A medida que crecen las
capacidades de TI (Tecnologías de la información) pueden generar cambios en los procesos de
negocio.

27.1.2. Principios de reingeniería de procesos de negocios.

En muchos aspectos, la BPR tiene un objetivo y un ámbito idéntico al proceso de la ingeniería de la

información. En un entorno ideal, la BPR debería de producirse de forma descendente, comenzando
por la identificación de los objetivos principales del negocio y culminando con una especificación
mucho más detallada de las tareas que definen un proceso específico de negocios.
Principios que informan las actividades de la BPR cuando éstas comienzan en el nivel superior
( negocios):
• Organizarse en torno a los resultados, no en torno a las tareas
• Hay que hacer que quienes utilicen la salida del proceso llevan a cabo el proceso
• Hay que incorporar el trabajo de procesamiento de información al trabajo real que produce la
información pura.
• Hay que dotar los recursos geográficamente dispersos como si estuvieran centralizados (oficina
virtual).
• Hay que enlazar las actividades paralelas en lugar de integrar sus resultados.
• Hay que poner el punto de decisión en el lugar en el que se efectúa el trabajo y hay que
incorporar el control al proceso.
• Hay que capturar los datos una sola vez, en el lugar donde se producen.

27.1.3. Un modelo de BPR

La reingeniería de procesos de negocios es iterativa. Los objetivos y los procesos que lo logran,
deben de adaptarse a un entorno de negocios cambiante. por esta razón no existe un principio ni un
fin en la BPR, se trata de un proceso evolutivo.

1
Este modelo define seis actividades:
- Definición del negocio: se identifican los objetivos de negocio en el contexto de 4 controladores
principales:
1) reducción de costes
2) reducción de tiempos
3) mejora de calidad
4) desarrollo y potenciación del personal.
Los objetivos se pueden definir en el nivel de negocios o para un componente específico de ese
negocio.

- Identificación de procesos: se deben identificar los procesos que sean críticos para alcanzar
las metas definidas en la definición del negocio deben de ser identificados. Se les pude asignar
prioridades por importancia.

- Evaluación de procesos: los procesos existentes deben de analizarse y medirse. Se

identificaran las tareas de procesos; los costes y los tiempos consumidos por las tareas de
proceso se anotarán; se aislarán los problemas de calidad y rendimiento.

- Especificación y diseño de procesos: basándose en la infor. obtenida en las tres etapas

anteriores de la BPR, se preparan casos prácticos para cada proceso que haya que rediseñar.
Los casos prácticos identifican un escenario que proporciona algún resultado a algún cliente.
Mediante el usos de casos prácticos como especificación del proceso, se diseña para el proceso
un nuevo conjunto de tareas.

- Prototipos: es preciso construir un prototipo del proceso de negocios rediseñado antes de

integrarlo por completo en el negocio. Esta actividad comprueba el proceso para que sea posible
efectuar refinamientos.

- Refinamiento e instalación: basándose en la realimentación procedente del prototipo, se refina

el proceso de negocios y después se instancia en el seno de un sistema de negocios.

Las actividades de BPR descritas anteriormente se utilizan en algunas ocasiones en conjunción con
herramientas de análisis de flujo de trabajo. El objetivo de estas herramientas es construir un modelo
del flujo de trabajo existente, en un esfuerzo por analizar mejor los procesos existentes.

27.1.4. Advertencias.

Si la BPR se lleva a cabo de forma efectiva, los sistemas de información se integran mejor con los
procesos de negocios.
Aun cuando la reingeniería de negocios sea una estrategia rechazada por parte de una compañía, la
reingenierìa del software es algo que debe de hacerse.

27.2. REINGENIERIA DEL SOFTWARE

27.2.1. Mantenimiento del software

El mantenimiento del soft. es algo que va mucho más allá de corregir errores. Se puede definir el
mantenimiento describiendo las cuatro actividades que se emprenden cuando se publica un
programa para su utilización:
- Mantenimiento correctivo
- Mantenimiento adaptivo
- Mejoras o mantenimiento de perfeccionamiento
- Mantenimiento preventivo o reingeniería

El 20 % de nuestros esfuerzos de mantenimiento se invertirán corrigiendo errores. El 80 % restante

se dedica a adaptar los sistemas existentes a los cambios de su entorno externo, a efectuar las
mejoras solicitadas por los usuarios y a rehacer la ingeniería de las aplicaciones para su posterior
utilización.

2
27.2.2. Un modelo de procesos de reingeniería del software

La reingeniería requiere tiempo; cuesta unas cantidades significativas de dinero y absorbe recursos,
la ingeniería no se lleva a cabo en unos pocos meses, ni siquiera en unos pocos años. La
reingeniería de sistemas de información es una actividad que absorberá recursos de las tecnologías
de la información durante muchos años.
La reingeniería es una tarea de reconstrucción.

El Modelo de proceso de reingeniería del software define seis actividades:

Análisis de inventario: toda organización de soft. debería disponer de un inventario de todas sus
aplicaciones; que contenga la información siguiente: nombre de la aplicación, año de creación,
número de cambios efectuados, base o bases de datos a las que se accede, número de usurarios,
calidad de la documentación, importancia para el negocio, fecha del último cambio importante, etc.
Al ordenar esta información según su importancia para el negocio, longevidad, mantenimiento actual
y otros criterios localmente importantes, aparecen los candidatos para la reingeniería.
El estado de las aplicaciones puede cambiar en función del tiempo y como resultado, cambiarán las
prioridades para la reingeniería.

Reestructuración de documentos: una documentación escasa es la marca de muchos sistemas

heredados. Opciones:
1. Opción 1: dejarlo así, sin documentar prácticamente.
2. Opción 2 : documentar si se modifica.
3. Opción 3: volver a documentarlo por completo , si el sistema es fundamental para el negocio.

Ingeniería inversa: la ingeniería inversa del software es el proceso consistente en analizar un

programa en un esfuerzo por crear una representación del programa con un nivel de abstracción más
elevado que el código fuente. La ingeniería inversa es un proceso de recuperación de diseño. Las
herramientas de ingeniería inversa extraen información acerca de los datos, arquitectura y diseño de
procedimientos de un programa ya existente.

Reestructuración del código: es el tipo más común de reingeniería. Se produce en un nivel bajo de
abstracción. Para llevar a cabo esta actividad, se analiza el código fuente utilizando una
herramienta de reestructuración. Las violaciones de las estructuras de programación
estructurada se indican y se reestructura el código. El código reestructurado resultante se
revisa y se comprueba para asegurar de que no se hayan introducido anomalías. Se actualiza
la documentación interna de código.

Reestructuración de datos: un programa que posea una estructura de datos débil será difícil de
adaptar y de mejorar. Se aplica reingeniería a los datos cuando la estructura de datos es débil. Se
produce en un nivel alto de abstracción. En la mayoría de los casos comienza con una ingeniería
inversa. Se disecciona la arquitectura de datos actual. Cuando es necesario, se definen modelos de
datos, objetos de datos, atributos y a continuación se revisan las estructuras de datos a efectos de
calidad.
La arquitectura de datos tiene una gran influencia sobre la arquitectura del programa, los cambios de
los datos darán invariablemente a cambios de arquitectura o bien del nivel de código.

Ingeniería progresiva: denominada también renovación o reclamación no solamente recupera la

información del diseño de un soft ya existente, sino que además, utiliza esta información para alterar
o reconstituir el sistema existente en un esfuerzo por mejorar su calidad global. En la mayoría de los
casos, el software procedente de una reingeniería vuelve a implementar la funcionalidad del sistema
existente, y añade además nuevas funciones y/o mejora el rendimiento global.

En algunas ocasiones, estas actividades se producen de forma secuencial lineal, pero no siempre es
así. Quizá la ingeniería inversa tenga que producirse antes de que pueda comenzar la
reestructuración de documentos. Cada una de las actividades como parte del paradigma pueden

3
volver a visitarse en otras ocasiones. Para cualquier ciclo particular, el proceso puede terminar
después de cualquiera de estas actividades.
27.3. INGENIERIA INVERSA

La ingeniería inversa puede extraer la información de diseño aparte del código fuente, pero el nivel
de abstracción, la completitud de la documentación, el grado con el cuál trabajan al mismo tiempo las
herramientas y el analista humano, y la direccionalidad del proceso son sumamente variables.

El nivel de abstracción de un proceso de ingeniería inversa y las herramientas que se utilicen para
realizarlo aluden a la sofisticación de la información de diseño que se puede extraer del código
fuente. Idealmente el nivel de abstracción sería lo más alto posible.
A medida que crece el nivel de abstracción se proporciona al ingeniero del software información que
le permitirá una comprensión más sencilla de estos programas.

La completitud de un proceso de ingeniería inversa alude al nivel de detalle que se proporciona en

un determinado nivel de abstracción. En la mayoría de los casos, la completitud decrece a medida
que aumenta el nivel de abstracción. La completitud mejora en proporción directa con la cantidad de
análisis efectuado por la persona que efectúe la ingeniería inversa.

La interactividad alude al grado con el cual el ser humano se integra con una herramientas
automatizadas para crear un proceso de ingeniería inversa efectivo. En la mayoría de los casos, a
medida que crece el nivel de abstracción, la interactividad debe de incrementarse o bien la
completirtud se verá reducida.

La direccionalidad del proceso de ingeniería inversa es monodireccional, toda la información

extraída del código fuente se proporcionará a la ingeniería del software que podrá entonces utilizarla
durante la actividad de mantenimiento. Si la direccionalidad es bidireccional, entonces la información
que se suministrará a una herramienta de la reingenieria que intentará reestructurar o regenerar el
viejo programa.

Antes de que pueda comenzar las actividades de ingeniería inversa, el código fuente no estructurado
se reestructura para que solamente contenga estructuras de programación estructurada. Esto hace
que el código fuente sea más fácil de leer y proporciona la base para todas las actividades de la
ingeniería inversa subsiguientes.

El núcleo de la ing. inversa es una actividad denominada extracción de abstracciones. El ingeniero

tiende a evaluar el viejo programa y a partir del código fuente tiene que extraer una especificación
significativa del procesamiento que se realiza, la interfaz de usuario que se aplica, y las estructuras
de datos o de la base de datos que se utiliza.

27.3.1 Ingeniería inversa para comprender el procesamiento.

La primera actividad real de la ingeniería de inversa comienza con un intento de comprender y

después extraer abstracciones de procedimientos representadas por el código fuente. Para
comprender las abstracciones de procedimientos, se analiza el código en distintos niveles de
abstracción, sistema, programa, módulo, trama y sentencia.
La funcionalidad general de todo sistema debe ser algo perfectamente comprendido antes de que se
produzca un trabajo de ingeniería inversa más detallado.
Para grandes sistemas, la ingeniería inversa suela efectuarse mediante el uso de un enfoque
semiautomático. Se utilizan herramientas CASE para analizar la semántica del código existente. La
salida de este proceso se pasa entonces a unas herramientas de reestructuración y de ingeniería
progresiva que completarán el proceso de reingeniería.

27.3.2.Ingeniería inversa para comprender los datos.

La ingeniería inversa de datos suele producirse en distintos niveles de abstracción.

4
En el nivel de programa, es frecuente que sea preciso realizar una ingeniería inversa de las
estructuras de datos de programa internas, como parte de un esfuerzo global se reingeniería. En el
nivel de sistema, es frecuente que se efectué una reingeniería de las estructuras globales de datos
para ajustarlas a los nuevos paradigmas de gestión de bases de datos.

Estructuras de datos internas: las técnica de ingeniería inversa para datos de programa internos
se centran en la definición de clases de objetos. Esto se logra examinando el código del programa
con la intención de agrupar variables de programa que estén relacionadas.
Enfoque para la determinación de clases para la ing. Inversa:
1) Se identifican los indicadores y estructuras de datos locales dentro del programa que registren
información importante acerca de las estructuras de datos globales.
2) Se define la relación entre indicadores y estructuras de datos locales y las estructuras de datos
globales.
3) Para toda variable que represente una matriz o archivo, se enumeran todas las demás variables
que tengan una relación lógica con ella.

Estructuras de base de datos: independientemente de su organización lógica y de su estructura

física, las bases de datos permiten definir objetos de datos y admiten algún método para establecer
relaciones entre objetos. Consiguientemente, la reingeniería de un esquema de bases de datos para
formar otro exige una comprensión de los objetos ya existentes y de sus relaciones.

Pasos para definir el modelo de datos existente como precursor para una ing. que producirá un
nuevo modelo de base de datos:
1. Se construye un modelo de objetos inicial
2. Se determinan los candidatos a clases
3. Se refinan las clase tentativas: se determinan si ciertas clases similares pueden o no combinarse
en una única clase.
4. Se definen las generalizaciones se examinan las clases que puedan tener muchos atributos
similares para determinar si se debería o no construir una jerarquía de clases con una clase de
generalización como precursor de todos sus descendientes.
5. Se descubren las asociaciones. Mediante el uso de técnica análogas al enfoque de CRC se
establecen las asociaciones entre clases.

27.3.3. Ingeniería inversa de interfaces de usuario.

El nuevo desarrollo de interfaces de usuario ha pasado a ser uno de los tipos de actividades de
reingeniería. Antes de que sea posible reconstruir una interfaz de usuario suele ser necesario que se
produzca una actividad de ingeniería inversa.

Tres preguntas básicas a las cuales hay que responder cuando comienza la ingeniería inversa de la
IU:
¿ Cuales son las acciones básicas que debe de procesar la interfaz, por ejemplo, acciones de
teclado y clics de ratón?
¿cuál es la descripción compacta de la respuesta del sistema a estas acciones?
¿Qué quiere decir una “sustitución” o más exactamente que concepto de equivalencia de interface es
relevante en este caso?

Se puede utilizar álgebra de procesos para presentar el comportamiento de una interfaz de manera
formal.

Existen al menos dos entidades activas concurrentes: el sistema y el usuario. Uno tiene que ser
capaz de expresar ciertas opciones “externas” que no se encuentran bajo control del usuario. Estos
ingredientes, la reactividad, la concurrencia y las operaciones externas resultan básicos para el
álgebra del procesos.

La descripción de la interfaz hace uso de agentes y acciones. Un agente es algo que da vida a algún
aspecto del sistema. Las acciones permiten que los agentes se comuniquen entre sí. En esencia, el

5
álgebra de procesos es una notación taquigráfica para representar la forma en que los agentes y las
acciones dan vida a la función de una IU.
27.4. REESTRUCTURACION

La reestructuración del software modifica el código fuente y/o los datos en un intento de hacerlo
adecuado para cambios futuros. En general no modifica la arquitectura global del programa. Tiende a
centrase en los detalles de diseño individuales y en las estructuras de datos locales definidas dentro
de los módulo. Si el esfuerzo de la reestructuración se extiende más allá de los límites de los módulo
y abarca a la arquitectura del software, la reestructuración pasa a ser ingeniería progresiva.

Beneficios que se pueden lograr cuando se reestructura el soft (ARNOLD):

• Da lugar a programas de mayor calidad, con mejor documentación y menos complejidad.
• Reduce la frustración entre los ingenieros del software que deben de trabajar con el programa,
mejorando la productividad y haciendo más sencillo el aprendizaje.
• Reduce el esfuerzo requerido para llevar a cabo las actividades de mantenimiento.
• Hace que el soft. sea más sencillo de comprobar y de depurar.

La reestructuración se produce cuando la arquitectura básica de la aplicación es sólida y solamente

existe un subconjunto de todos los módulo y todos los datos que requiera extensa modificación.

27.4.1. Reestructuración del código

Se lleva a cabo para conseguir un diseño que produzca la misma función pero con una mayor calidad
que el programa original. Las técnica de reestructuración del código modelan la lógica del programa
empleando álgebra Booleana y a continuación aplican una serie de reglas de transformación que dan
lugar a una lógica reestructurada.

27.4.2. Reestructuración de los datos.

Antes de que pueda comenzar la reestructuración de datos, es preciso llevar a cabo una ingeniería
inversa, un análisis del código fuente. Todas las sentencias del lenguaje de programación que
contengan definiciones de datos, descripciones de archivos, E/S y descripciones de interfaz se
evalúan en primer lugar. El objetivo es extraer elementos y objetos de datos, para obtener
información acerca del flujo de datos, así como comprender las estructuras de datos ya existentes
que se hayan implementado. Esta actividad se denomina a veces análisis de datos.

Una vez finalizado el diseño comienza el rediseño de datos:

• Paso de estandarización de rediseño de datos: clarifica las definiciones de datos para lograr una
consistencia entre nombre de objetos de datos, o entre formatos de registro físicos en el seno de
una estructura de datos o formato de archivo existente
• Racionalización de nombres de datos: asegura que todas las convenciones de denominación de
datos se ajusten a los estándares locales y asegure también que se eliminen los alias a medida
que fluyen los datos a través del sistema.

Cuando la reestructuración va más allá de la estandarización y de la racionalización, se efectúan

modificaciones físicas en las estructuras de datos. ya existentes con objeto de hacer que el diseño de
datos sea más efectivo. Esto puede significar una traducción de un formato de archivo a otro, o en
algunos casos, una traducción de un tipo de base de datos a otra.

27.5. INGENIERIA PROGRESIVA (DIRECTA)

En un programa con un flujo de control que sea el equivalente al gráfico de un “plato de espaguetis”
se tiene las opciones siguientes:
1. Efectuar una modificación tras otra, luchando con el código fuente para implementar los cambios
necesarios.
2. Intentar comprender el funcionamiento interno en un esfuerzo por hacer que las modificaciones
sean más efectivas.

6
3. Se puede rediseñar, recodificar y comprobar aquellas partes del software que requieren
modificaciones, aplicando ingeniería del soft a todos los elementos revisados.
4. Se puede rediseñar, recodificar y comprobar el programa en su totalidad, usando herramientas
CASE que servirán para comprender el diseño actual.

En lugar de esperara a que se reciba una solicitud de mantenimiento, la organización de desarrollo o

de mantenimiento selecciona un programa
1. que seguirá siendo utilizado durante un número determinado de años
2. que se esté utilizando con éxito en la actualidad y
3. que tenga probabilidades de sufrir grandes modificaciones o mejoras en un futuro próximo.
Entonces se aplican las opciones 2,3 o 4.

Este enfoque de mantenimiento preventivo fue diseñado por MILLER con el nombre de reajuste
estructurado: aplicación de las metodologías de hoy a los sistemas de ayer para prestar apoyo a los
requisitos del mañana.

Puntos a considerar ante la sugerencia de volver a desarrollar un programa:

1. El coste de mantener la línea de código puede estar entre 20 y 40 veces por encima del
desarrollo inicial de la línea.
2. El rediseño de la arquitectura del soft empleando conceptos de diseño moderno puede facilitar
mucho el mantenimiento.
3. La productividad de desarrollo debería ser mucho más elevada que la media.
4. El usuario ya tiene experiencia con el soft por lo tanto los nuevos requisitos y la dirección del
cambio se podrán estimar con mucha más facilidad.
5. Las herramientas CASE automatizan partes del trabajo.
6. Cuando se finaliza el mantenimiento preventivo se dispone de una configuración completa del
software.

Cuando una organización de desarrollo de software vende un soft como producto, el mantenimiento
preventivo se ve como nuevas versiones del programa.

27.5.1. Ingeniería progresiva para arquitecturas cliente/servidor

muchas aplicaciones de grandes computadoras ha sufrido un proceso de reingeniería para

adaptarles a arquitecturas cliente/servidor. La aplicación típica de computadora central que sufre un
proceso de reingeniería para adoptar una arquitectura cliente/servidor posee las características
siguientes:
• La funcionalidad de la aplicación migra todas las computadoras cliente.
• Se implementan nuevas interfaces IGU en los centros clientes
• Las funciones de bases de datos se asignan al servidor
• La funcionalidad especializada pueden permanecer en el centro del servidor
• Los nuevos requisitos de comunicaciones, seguridad, archivado y control deben de establecerse
tanto en el centro cliente, como en el centro servidor.

La migración desde computadoras centrales a C/S requiere una ingeniería del negocio como una
reingeniería del soft.. Es preciso establecer una infraestructura de red de empresa.

La ingeniería de aplicaciones C/S comienza con un análisis del entorno de negocios que abarca la
computadora central. se identifican tres capas de abstracción:
Capa Bases de datos: se encuentra en los cimientos de la arquitectura C/S y gestiona las
transacciones y consultas. Las mismas tiene que ser controladas por un conjunto de reglas de
negocios. Las funciones del sistema de gestión de base de datos y la arquitectura de datos de la
base de datos existente deben de sufrir un proceso de ingeniería inversa como precedente para el
rediseño de la capa de fundamento de la base de datos.
Capa de reglas de negocios: representa un soft que está residente tanto en el cliente como en el
servidor. Este soft lleva a cabo las tareas de control y coordinación para asegurar que las

7
transacciones y consultas entre la aplicación cliente y la base de datos se ajusten a los procesos de
negocios.
Capa de aplicación de cliente: implementa las funciones de negocios requeridas por grupos
especificos de usuarios finales. En muchos casos se segmenta una aplicación de computadora
central en un cierto número de aplicaciones más pequeñas, sometidas a reingeniería ya adecuadas
para funcionamiento de sobremesa. La comunicación entre aplicaciones de sobremesa será
controlada por la capa de reglas de negocios.

27.5.2. Ingeniería progresiva para arquitecturas orientadas a objetos.

La reingeniería del soft convencional para producir una implementación orientada a objetos hace una
ingeniería inversa del soft existente para que sea posible crear los modelos adecuados de datos,
funcional y de comportamiento. Los modelos de datos creados durante la ingeniería inversa se
utilizan entonces en conjunción con un modelado CRC para establecer la base para definición de
clases. Las jerarquías de clases, los modelos de relaciones entre objetos, los modelos de
comportamiento de objetos y los subsistemas se definen a continuación y comienza el diseño
orientado a objetos.
A medida que progresa la ingeniería inversa orientada a Objetos desde el análisis hasta el diseño, el
modelo de proceso de reutilización se podrá invocar también.

27.5.3. Ingeniería progresiva para interfaces de usuario.

Una parte significativa de todos los esfuerzos invertidos en la transición desde la computación de
computadora central hasta la arquitectura cliente /servidor se pueden reinvertir en reingeniería de las
interfaces de usuario de la aplicación.

Modelo para reingeniería de interfaces de usuario (MERLO):

1. Comprender la interfaz original y los datos que se trasladan entre ella y el resto de la aplicación
2. Remodelar el comportamiento implícito por la interfaz existente para formar una serie de
abstracciones que tengan sentido en el contexto de una IGU.
3. Introducir mejoras que hagan que el modo de interacción sea más eficiente.
4. Construir e integrar la IGU.

27.6 ECONOMIA DE LA REINGENIERÌA.

Antes de que una organización intente efectuar una reingeniería de una aplicación existente, deberá
de llevar a cabo un análisis de costes y beneficios:

- Coste de mantenimiento actual para la aplicación

- Coste de operación anual actual de una aplicación
- Valor de negocios anual actual de una aplicación
- Coste de mantenimiento anual después de la reingeniería
- Coste de operaciones anual predicho después de la reingeniería
- Valor de negocio actual predicho después de la reingeniería
- Costes de reingeniería estimados
- Fecha de reingeniería estimada
- Factor de riesgo de la reingeniería
- Vida esperada del sistema.