2.

3 Reingeniera del Software

La ingeniera se produce en dos niveles distintos de abstraccin. En
el nivel de negocios, la reingeniera se concentra en el proceso de
negocios con la intencin de efectuar cambios que mejoren la
competitividad en algn aspecto de los negocios. En el nivel del
software, la reingeniera examina los sistemas y aplicaciones de
informacin con la intencin de reestructurarlos o reconstruirlos de tal
modo que muestren una mayor calidad.
Qu es la Reingeniera?
Tenga en consideracin cualquier producto de tecnologa que haya
adquirido. Lo ve con regularidad, pero est envejeciendo. Se rompe con
frecuencia, tarda en repararse y ya no representa la ltima tecnologa.

Qu se puede hacer?
Si el producto es de hardware, probablemente lo tirar y se comprar
uno nuevo. Pero si es un software personalizado, no dispondr la opcin
de tirarlo. Necesitar reconstruirlo. Crear un producto con una
funcionalidad nueva, un mejor rendimiento y fiabilidad, y un
mantenimiento mejorado. Eso es lo que llamamos reingeniera.
Quin lo hace?
A nivel de negocio, la reingeniera es ejercida por especialistas de
negocio (frecuentemente empresas de consultora). A nivel de software,
la reingeniera es ejecutada por ingenieros del software.

Por qu es importante?
Vivimos en un mundo en constante cambio. Las demandas de funciones
de negocios y de tecnologa de informacin que las soportan estn
cambiando a un ritmo que impone mucha presin competitiva en todas
las organizaciones comerciales. Tanto los negocios como el software que
soportan (o es) el negocio debern disearse una vez ms para
mantener el ritmo

Cules son los Pasos?

1.
2.
3.

Define las Metas comerciales.

Identifica y evala los procesos de negocios existentes.
Crea Procesos Comerciales revisados que mejoren
comerciales.

las

metas

El Proceso de la Reingeniera del Software

Acompaa el anlisis de inventarios.

La reestructuracin de documentos.
La ingeniera Inversa.
La estructuracin de Programas y datos.
La ingeniera directa.

Cmo puedo estar seguro de que lo he hecho correctamente?

Utilizando las mismas prcticas que se aplican en todos los procesos de
ingeniera del software:
Revisiones tcnicas formales.
Revisiones especializadas.
La comprobacin.
Cul es el producto obtenido?
El resultado final es un proceso de reingeniera de negocios y/o el
software de reingeniera que lo soporta.

REINGENIERIA DE PROCESOS DE NEGOCIOS.

La reingeniera constituye una recreacin y reconfiguracin de las

actividades y procesos de la empresa, lo cual implica volver a crear y
configurar de manera radical l o los sistemas de la compaa a los
efectos de lograr incrementos significativos, y en un corto perodo de
tiempo, en materia de rentabilidad, productividad, tiempo de respuesta,
y calidad, lo cual implica la obtencin de ventajas competitivas.
Reingeniera es el rediseo rpido y radical de los procesos
estratgicos de valor agregado y de los sistemas, las polticas y las

estructuras organizacionales que los sustentan para optimizar los flujos

de trabajo y la productividad de una organizacin.
Procesos de Negocios

Entre los ejemplos de negocio se incluyen el diseo de un nuevo

producto, la adquisicin de servicios y suministros, la contratacin de
nuevos empleados o el pago a proveedores. Cada una requiere un
conjunto de tareas y se basa en diversos recursos dentro del negocio.
Cada proceso de negocio posee un cliente bien definido -una persona o
grupo que recibe el resultado (por ejemplo: una idea, un informe, un
diseo, un producto X . Adems, los procesos de negocio cruzan los
lmites organizativos. Requieren que distintos grupos de la organizacin
participen en las tareas lgicamente relacionadas que definen el
proceso.
Todo sistema es en realidad una jerarqua de subsistemas:

Cada uno de los sistemas de negocios (tambin llamados funcin de

negocios) estn compuestos por uno o ms procesos de negocio, y cada
proceso de negocio est definido por un conjunto de subprocesos.
La RPN se puede aplicar a cualquier nivel de la jerarqua, pero a medida
que se ampla el mbito de la RPN (esto es, a medida que se asciende
dentro de la jerarqua) los riesgos asociados a la RPN crecen de forma
dramtica. Por esta razn, la mayor parte de los esfuerzos de la RPN se
centran en procesos o subprocesos individuales.
Principios de reingeniera de procesos.
En muchos aspectos, la RPN tiene un objetivo y un mbito idntico al
proceso de la ingeniera de la informacin. Lo ideal sera que la RPN se
produjera de forma descendente, comenzando por la identificacin de
los objetivos principales del negocio, y culminando con una
especificacin mucho ms detallada de las tareas que definen un
proceso especfico de negocios.
Hammer sugiere una serie de principios que nos guiarn por las
actividades de la RPN cuando se comienza en el nivel superior (de
negocios):
Organizacin en torno a los resultados, no en torno a las tareas:
Hay muchas compaas que poseen actividades de negocio
compartimentadas, de tal modo que no existe una nica persona (u
organizacin) que tenga la responsabilidad (o el control) de un cierto
resultado de negocio. En tales casos, resulta difcil determinar el estado
del trabajo e incluso ms difcil depurar los problemas de proceso
cuando esto sucede. La RPN deber disear procesos que eviten este
problema.
Hay que hacer que quienes utilicen la salida del proceso lleven a
cabo el proceso:
El objetivo de esta recomendacin es permitir que quienes necesiten las
salidas del negocio controlen todas las variables que les permitan
obtener esa salida de forma temporalmente adecuada. Cuanto menor
sea el nmero de personas distintas implicadas en el proceso, ms fcil
ser el camino hacia un resultado rpido.
Hay que incorporar el trabajo de procesamiento de informacin al
trabajo real que produce la informacin pura. A medida que la TI se
distribuye, es posible localizar la mayor parte del procesamiento de
informacin en el seno de la organizacin que produce los datos. Esto
localiza el control, reduce el tiempo de comunicacin y la potencia de
computacin se pone en manos de quienes tienen fuertes intereses en
la informacin producida.

Hay que manipular recursos geogrficamente dispersos como si

estuviesen centralizados. Las comunicaciones basadas en computadoras
se han sofisticado tanto que es posible situar grupos geogrficamente
dispersos en una misma oficina virtual. Por ejemplo, en lugar de
emplear tres turnos de ingeniera en una nica localizacin, toda la
compaa podr tener un turno en Europa, un segundo turno en
Norteamrica y un tercer turno en Asia. En todos los casos, los
ingenieros trabajarn durante el da y se comunicarn empleando redes
de un elevado ancho de banda.
Hay que enlazar las actividades paralelas en lugar de integrar sus
resultados. Cuando se utilizan diferentes grupos de empleados para
realizar tareas en paralelo, es esencial disear un proceso que exija una
continuacin en la comunicacin y coordinacin. En caso contrario, es
seguro que se producirn problemas de integracin.
Hay que poner e1 punto de decisin en el lugar donde se efecta el
trabajo, e incorporar el control al proceso. Dentro de la jerga del diseo
del software, esto sugiere una estructura organizativa ms uniforme y
con menos factorizacin.
Hay que capturar los datos una sola vez, en el lugar donde se producen.
Los datos se debern almacenar en computadoras, de tal modo que una
vez recopilados no sea necesario volver a introducirlos nunca.
Todos y cada uno de los principios anteriores representan una visin
dotalmente general de la RPN. Una vez informados por estos principios,
los planificadores de
negocios y los diseadores de procesos debern empezar a procesar el
nuevo diseo. En la seccin siguiente, se examinar el proceso de RPN
ms detalladamente.
Un modelo de RPN
Al igual que la mayora de las actividades de ingeniera, la reingeniera
de procesos de negocio es iterativa. Los objetivos de negocio, y los
procesos que los logran, debern adaptarse a un entorno de negocio
cambiante. Por esta razn, no existe ni principio ni fin en la RPN -se trata
de un proceso evolutivo.

Reingeniera del Software:

Este escenario resulta sumamente conocido: Una aplicacin ha dado
servicio y ha cubierto las necesidades del negocio de una compaa
durante diez o quince aos. A lo largo de este tiempo, ha sido corregida,
adaptada y mejorada muchas veces. Las personas se dedicaban a esta
tarea con la mejor de sus intenciones, pero las prcticas de ingeniera
del software buenas siempre se echaban a un lado (por la urgencia de
otros problemas). Ahora la aplicacin se ha vuelto inestable. Sigue
funcionando, pero cada vez que intenta efectuar un cambio se producen
efectos colaterales graves e inesperados.
Qu se puede hacer?
La imposibilidad de mantener el software no es un problema nuevo. De
hecho, el gran inters por la reingeniera del software ha sido generado
por un iceberg de mantenimiento de software que lleva creciendo
desde hace ms de treinta aos.
Mantenimiento del software:
Hace
casi
treinta
aos,
el
mantenimiento
del
software se caracterizaba por ser como un iceberg. Esperbamos
que lo que era inmediatamente visible fuera de verdad lo que haba,
pero sabamos que una enorme masa de posibles problemas y costes
yaca por debajo de la superficie. A principios de los aos 70, el iceberg
de mantenimiento era lo suficientemente grande como para hundir un
portaaviones. En la actualidad podra hundir toda la Armada.

El mantenimiento del software existente puede dar cuenta de ms del

60 por 100 de las inversiones efectuadas por una organizacin de
desarrollo, y ese porcentaje sigue ascendiendo a medida que se produce
ms software. Los lectores que tengan menos conocimientos en estos
temas podran preguntarse por qu se necesita tanto mantenimiento, y
por qu se invierte tanto esfuerzo.
Gran parte del software del que dependemos en la actualidad tiene por
trmino medio entre diez y quince aos de antigedad. Aun cuando
estos programas se crearon empleando las mejores tcnicas de diseo y
codificacin conocidas en su poca (y la mayora no lo fueron), se
crearon cuando el tamao de los programas y el espacio de
almacenamiento eran las preocupaciones principales. A continuacin, se
trasladaron a las nuevas plataformas, se ajustaron para adecuarlos a
cambios de mquina y de sistemas operativos y se mejoraron para
satisfacer nuevas necesidades del usuario; y todo esto se hizo sin tener
en cuenta la arquitectura global.
El resultado son unas estructuras muy mal diseadas, una mala
codificacin, una lgica inadecuada, y una escasa documentacin de
los sistemas de software que ahora nos piden que mantengamos en
marcha .
Un modelo de procesos de reingeniera del software:
La reingeniera requiere tiempo; conlleva un coste de dinero enorme y
absorbe recursos que de otro modo podran emplearse en
preocupaciones ms inmediatas. Por todas estas razones, la reingeniera
no se lleva a cabo en unos pocos meses, ni siquiera en unos pocos aos.
La reingeniera de sistemas de informacin es una actividad que
absorber recursos de las tecnologas de la informacin durante muchos
aos. Esta es la razn por la cual toda organizacin necesita una
estrategia pragmtica para la reingeniera del software.

El paradigma de la reingeniera mostrado en la figura es un modelo

cclico. Esto significa que cada una de las actividades presentadas como
parte del paradigma puede repetirse en otras ocasiones. Para un ciclo en
particular, el proceso puede terminar despus de cualquiera de estas
actividades.
Anlisis de inventario. Todas las organizaciones de software debern
disponer de un inventario de todas sus aplicaciones. El inventario puede
que no sea ms que una hoja de clculo con la informacin que
proporciona una descripcin detallada (por ejemplo: tamao, edad,
importancia para el negocio) de todas las aplicaciones activas.

Los candidatos a la reingeniera aparecen cuando se ordena esta

informacin en funcin de su importancia para el negocio, longevidad,
mantenibilidad actual y otros criterios localmente importantes. Es
entonces cuando es posible asignar recursos a las aplicaciones
candidatas para el trabajo de reingeniera.
Es importante destacar que el inventario deber revisarse con
regularidad. El estado de las aplicaciones (por ejemplo, la importancia
con respecto al negocio) puede cambiar en funcin del tiempo y, como
resultado, cambiarn tambin las prioridades para la reingeniera.

Reestructuracin de documentos. Una documentacin escasa es la

marca de muchos sistemas heredados.
Ingeniera inversa: Es el proceso de construir especificaciones de un
mayor nivel de abstraccin partiendo del cdigo fuente de un sistema
software o cualquier otro producto (se puede utilizar como punto de
partida cualquier otro elemento de diseo, etc.).Estas especificaciones
pueden volver ser utilizadas para construir una nueva implementacin
del sistema utilizando, por ejemplo, tcnicas de ingeniera directa.
Ventajas de la Ingeniera Inversa:
Reducir la complejidad del sistema: al intentar comprender el
software se facilita su mantenimiento y la complejidad existente
disminuye. Generar diferentes alternativas: del punto de partida del
proceso, principalmente cdigo fuente, se generan representaciones
grficas lo que facilita su comprensin. Recuperar y/o actualizar la
informacin perdida (cambios que no se documentaron en su momento).
Detectar efectos laterales: los cambios que se puedan realizar en un
sistema puede conducirnos a que surjan efectos no deseados, esta serie
de anomalas puede ser detectados por la ingeniera inversa.

Facilitar la reutilizacin: por medio de la ingeniera inversa se pueden

detectar componentes de posible reutilizacin de sistemas existentes,
pudiendo aumentar la productividad, reducir los costes y los riesgos de
mantenimiento.
La finalidad de la ingeniera inversa es la de desentraar los misterios y
secretos de los sistemas en uso a partir del cdigo. Para ello, se emplean
una serie de herramientas que extraen informacin de los datos,
procedimientos y arquitectura del sistema existente.
TIPOS DE INGENIERIA INVERSA.
Ingeniera inversa de datos: Se aplica sobre algn cdigo de bases
datos (aplicacin, cdigo SQL, etc) para obtener los modelos relacionales
o sobre el modelo relacional para obtener el diagrama entidad-relacin.
Ingeniera inversa de lgica o de proceso: Cuando la ingeniera
inversa se aplica sobre cdigo de un programa para averiguar su lgica
o sobre cualquier documento de diseo para obtener documentos de
anlisis o de requisitos.
Ingeniera inversa de interfaces de usuario: Se aplica con objeto de
mantener la lgica interna del programa para obtener los modelos y
especificaciones que sirvieron de base para la construccin de la misma,
con objeto de tomarlas como punto de partida en procesos de ingeniera
directa que permitan modificar dicha interfaz.
HERRAMIENTAS PARA LA INGENIERIA INVERSA.

Los Depuradores: Un depurador es un programa que se utiliza para

controlar otros programas. Permite avanzar paso a paso por el cdigo,
rastrear fallos, establecer puntos de control y observar las variables y el
estado de la memoria en un momento dado del programa que se est
depurando. Los depuradores son muy valiosos a la hora de determinar el
flujo lgico del programa.

Las Herramientas de Inyeccin de Fallos: Las herramientas que

pueden proporcionar entradas malformadas con formato inadecuado a
procesos del software objetivo para provocar errores son una clase de
herramientas de insercin de fallos. Los errores del programa pueden ser
analizados para determinar si los errores existen en el software objetivo.
Algunos fallos tienen implicaciones en la seguridad, como los fallos que
permiten un acceso directo del asaltante al ordenador principal o red.
Hay herramientas de inyeccin de fallos basados en el anfitrin que
funcionan como depuradores y pueden alterar las condiciones del

programa para observar los resultados y tambin estn los inyectores

basados en redes que manipulan el trfico de la red para determinar el
efecto en el aparato receptor.

Los Desensambladores: Se trata de una herramienta que convierte

cdigo mquina en lenguaje ensamblador. El lenguaje ensamblador es
una forma legible para los humanos del cdigo mquina. Los
desensambladores revelan que instrucciones mquinas son usadas en el
cdigo. El cdigo mquina normalmente es especfico para una
arquitectura dada del hardware. De forma que los desensambladores
son escritor expresamente para la arquitectura del hardware del
software a desensamblar.

Los compiladores Inversos o Decompiladores: Un decompilador

es una herramienta que transforma cdigo en ensamblador o cdigo
mquina en cdigo fuente en lenguaje de alto nivel. Tambin existen de
compiladores que transforman lenguaje intermedio en cdigo fuente en
lenguaje de alto nivel. Estas herramientas son sumamente tiles para
determinar la lgica a nivel superior como bucles o declaraciones if-then
de los programas que son descompilados. Los descompiladores son
parecidos a los desensambladores pero llevan el proceso un importante
paso ms all.

Las Herramientas CASE: Las herramientas de ingeniera de

sistemas asistida por ordenador (Computer-Aided Systems Engineering
CASE) aplican la tecnologa informtica a las actividades, las tcnicas y
las metodologas propias de desarrollo de sistemas para automatizar o
apoyar una o ms fases del ciclo de vida del desarrollo de sistemas.

REESTRUCTURACION DEL SOFTWARE.

La reestructuracin del software modifica el cdigo fuente y/o los datos en
un intento de adecuarlo a futuros cambios. Tiende a centrarse en los
detalles de diseo de mdulos individuales y en estructuras de datos
locales definidas dentro de los mdulos. Los beneficios de la
reestructuracin son:
Programas de mayor calidad con mejor documentacin y menos
complejidad, y ajustados a las prcticas y estndares de la ingeniera del
software moderno.
Reduce la frustracin entre ingenieros del software que deban trabajar con
el programa, mejorando por tanto la productividad y haciendo ms
sencillo el aprendizaje.
Reduce el esfuerzo requerido para llevar a cabo las actividades de
mantenimiento.
Hace que el software es ms sencillo de comprobar y depurar.

La reestructuracin se produce cuando la arquitectura bsica de la

aplicacin es slida, aun cuando sus interioridades tcnicas necesiten un
retoque. Comienza cuando existen partes considerables del software que
son tiles todava y solamente existe un subconjunto de todos los
mdulos y datos que requieren una extensa modificacin.
1.
del cdigo.
2.
de datos.
Reestructuracin del cdigo.
La reestructuracin del cdigo se lleva a cabo para conseguir un diseo que
produzca la misma funcin pero con mayor calidad que el programa
original.
Reestructuracin de datos.
Primero se realiza el ANALISIS del cdigo.
Se evalan las definiciones de los datos, archivos, O/I e Interfaces.
Extraer elementos y objetos de datos para obtener informacin del flujo de
datos y comprender la estructura.
Ingeniera directa (forward engineering):
En un mundo ideal, las aplicaciones se reconstruyen utilizan utilizando un
motor de reingeniera automatizado. En el motor se insertma el
programa viejo, que lo analizara, reestructurma y despus regenerara
la forma de exhibir los mejores aspectos de la calidad del software.
Despus de un espacio de tiempo corto, es probable que llegue a
aparecer este motor, pero los fabricantes de CASE han presentado
herramientas que proporcionan un subconjunto limitado de estas
capacidades y que se enfrentan con dominios de aplicaciones
especficos (por ejemplo, aplicaciones que han sido implementadas
empleando un sistema de bases de datos especfico). Lo que es ms
importante, estas herramientas de reingeniera cada vez son ms
sofisticadas.
La
ingeniera
directa,
que
se
denomina
tambin renovacin oreclamacin, no
solamente
recupera
la
informacin de diseo de un software ya existente, sino que, adems,
utiliza esta informacin para alterar o reconstruir el sistema existente en
un esfuerzo por mejorar su calidad global. En la mayora de los casos, el
software procedente de una reingeniera vuelve a implementar la
funcionalidad del sistema existente, y aade adems nuevas funciones
y/o mejora el rendimiento global.