You are on page 1of 13

Reingeniera DE SOFTWARE,

Un camino o El camino?
Fernando Garca Tosca, Rixal Martnez Fernndez
Resumen
La reingeniera es uno de los fenmenos gerenciales de mayor impacto en las ltimas
dcadas, debido a que su rpida y abrumadora expansin ha provocado y contina ocasionando cambios de grandes dimensiones en muchas organizaciones.
En especial, la aplicacin de la reingeniera en el software ha estado sujeta a la evolucin por la que han pasado los sistemas, lo cual se enmarca en varias etapas en las cuales
cada una ha experimentado caractersticas o tendencias que la distinguen de las otras.
Una de ellas es la llamada crisis del software. Sera poco productivo sostener con sistemas rgidos organizaciones que son dinmicas y mucho menos cuando en su mayora lo
constituyen sistemas legados que han sido desarrollado por especialistas que ya no forman parte de la empresa, muchos, con tcnicas propias de programacin que no estn
documentadas. Esta situacin va incidiendo de manera negativa en el buen desempeo
de la organizacin, entonces, qu decisin tomar para resolver el problema que tenemos?, aplicamos reingeniera o seguimos desarrollando arreglos (parches) a estos
sistemas?
Palabras clave: reingeniera, innovacin, sistema.

Abstract
Reingeneering has been one of the managerial phenomena of greater impact in the last
decades, due to the fact that its quick and overwhelming expansion has caused and
keeps on provoking changes of huge dimensions in many organizations.

Universidad de Camagey, Cuba. fernando.garcia@datys.co.cu, rixal.martinez@datys.co.cu

Revista Internacional La Nueva Gestin Organizacional, ao 4, nm.8, enero-junio, 2009, issn: 1870205-8, pp. 13-25

13

Fernando Garca Tosca, Rixal Martnez Fernndez

The application of Reingeneering in Softwares has especially evolved since it has


gone through system changes, which had their own characteristics or trends. One relevant trend that can be mentioned is the sofware crisis.
It would be thus unproductive and with major negative impact on the company performance to keep using rigid systems within dynamic organizations, when those obsolete
systems are the legacy of specialists with proper programming and undocumented techniques that no longer work for the company.
So, what decisions can we make to solve the current problem? Shall we apply reingeneering or shall we continue applying patches to those rigid systems?
Key words: reengineering, innovation, system.

Introduccin
En apenas diez aos la reingeniera ha
completado casi todas las etapas por
las que pasan los enfoques. En efecto,
de la fase emergente transit rpidamente a la fase de alto impacto y diseminacin del enfoque en el mundo
empresarial, producindose casi de
inmediato la fase crtica, en que desde
diversos ngulos se cuestionaron varias de sus propuestas. Ahora est por
ingresar en la fase madura, donde la
experiencia acumulada enriquece sustancialmente la aplicacin del enfoque,
y disminuye el riesgo de fracaso en su
aplicacin. [1]
Cada una de las fases por las que
pasa este fenmeno en el mundo empresarial est bien descrita en el libro
de C. Morales, Reingeniera, Revista
enlaces de rr.hh:
En la dcada de los aos ochenta
se dio la primera fase, cuando varias
empresas dieron un vuelco radical
14

en sus negocios por medio del rediseo de sus procesos. Era la poca
en que emerga este enfoque y su
aplicacin se circunscriba a unas
cuantas corporaciones estadounidenses.
La segunda fase se inicia en 1993,
al publicarse los casos de las empresas que haban rediseado con
xito sus procesos y en qu forma lo
haban logrado. Michael Hammer y
James Champy, por medio del libro
Reingeniera, permitieron la divulgacin masiva y rpida del rediseo.
Antes de un ao se haban vendido
1.7 millones de copias de ese ttulo.
Ese mismo ao se public el libro
Innovacin de procesos: reingeniera por medio de la tecnologa de
la informacin, de Thomas H. Davenport, profesor de la Universidad
de Boston, considerado una de las
mximas autoridades en el tema.
Durante este periodo las empresas
en muchos pases iniciaron procesos de reingeniera y el enfoque tuvo

Revista Internacional La Nueva Gestin Organizacional, ao 4, nm. 8, enero-junio, 2009, issn: 1870205-8, pp. 13-25

rea del conocimiento: gestin e innovacin

Reingeniera de software, un camino o el camino?

una expansin extraordinaria. Esta


fase incluye a las primeras empresas seguidoras del enfoque. Breve
tiempo despus siguen el camino de
la reingeniera las empresas ms
conservadoras, dando paso a la tercera fase.
A partir de 1995 se inicia la cuarta
fase: la fuerte crtica a la reingeniera. Consultores, investigadores universitarios y ejecutivos empezaron
a acumular experiencias que mostraban algunas limitaciones de la
versin original de este enfoque y
detectaron los factores que atentaban contra su xito.

Desarrollo
Reingeniera y reingeniera de procesos

A los crticos de la concepcin inicial


de la reingeniera se unieron tambin
sus principales promotores: Hammer y
Champy; cada uno escribi un nuevo
libro con sus propios puntos de vista y
experiencias sobre la forma en que se
estaba aplicando la reingeniera y la
necesidad de hacer ajustes a la versin
original. En el primer caso, The Reengeineering Revolution, Michael Hammer
y Steven Stanton, en el segundo, Reingeniera de la gerencia: cmo modificar
el trabajo gerencial, James Champy.
La quinta fase empieza a emerger
al concluir los aos noventa y tomar
fuerza al iniciar el nuevo siglo, al replantear el rediseo en un clima menos

influido por la moda y dejando de lado


a los detractores superficiales de la
reingeniera. Los principios en que se
basa la reingeniera, lejos de responder ahora a una moda ms, revolucionan radicalmente la forma en que se
ha diseado el trabajo en el siglo XX, y
constituyen una alternativa permanente de efectividad organizacional para
los ejecutivos.
La reingeniera, segn Hammer y
Stanton, es repensar de manera fundamental los procesos de negocios y
redisearlos radicalmente, con el fin de
obtener dramticos logros en el desempeo. Los factores clave del concepto
son: la orientacin hacia los procesos,
el cambio radical y la gran magnitud de
los resultados esperados.
Todo esto provoc que para que las
empresas se adaptaran y modificaran
su entorno competitivo y dinmico aplicaran mecanismos de reingeniera para
imponer un nuevo producto, proceso
productivo o paradigma organizacional,
constituyendo esto una nueva tendencia
en el desarrollo de las organizaciones y
que ha sido el resultado de los cambios
cada vez ms rpidos en su entorno.
No obstante, la reingerira no est
libre de crticas, debido fundamentalmente a la forma inadecuada en que se
interpretan sus conceptos y se ponen
en prctica. Pues la reingeniera constituye ms que un dogma una filosofa
para enfrentar la competencia y mejorar los procesos.
Michael Hammer, uno de los pioneros de la reingeniera, admita: No fui

Revista Internacional La Nueva Gestin Organizacional, ao 4, nm. 8, enero-junio, 2009, issn: 1870205-8, pp. 13-25

15

Fernando Garca Tosca, Rixal Martnez Fernndez

suficientemente inteligente, y agregaba: Por mis antecedentes de ingeniero, no prest suficiente atencin a la
dimensin humana. He aprendido que
es un factor vital. Si bien tanto Hammer como Champy han admitido cambios importantes al enfoque original, no
coinciden en cules son los adecuados, al punto que han preferido plantear cada uno su propio enfoque por
separado en sus libros posteriores.
Otra crtica generalizada seala que
la reingeniera ha servido como excusa gerencial para despedir personal y
recargar el trabajo a quienes permanecen en la empresa. En la prctica,
una cantidad considerable de empresas anuncian procesos de reingeniera,
pero aplican otra cosa: reestructuraciones o adelgazamiento organizacional,
acompaado normalmente por despido
de personal. A veces se hace a propsito, a fin de confundir a la opinin pblica
y al personal, pero en otras oportunidades es por desconocimiento de lo que
es realmente la reingeniera. [2] Esto
ha provocado que los trabajadores le
teman y su sola mencin puede causar sospechas, repliegue, resistencia y
desnimo.
Otros tipos de crticas se han centrado en su relacin con la automatizacin.
La automatizacin a menudo ha
sido confundida con la reingeniera,
lo que ha provocado que muchas
empresas automaticen sus errores.
La reingeniera se apoya en la au-

16

tomatizacin, pero automatizar no


es hacer reingeniera. Una empresa
puede automatizar un proceso ya
existente, haciendo que sea ms
eficiente, pero no necesariamente
lo redisea. Algunos han llamado a
esto pavimentar la acera. La reingeniera en cambio es el rediseo de
los procesos, es disear una nueva
va por donde pasar la acera. [2]

Para llevar a cabo este cambio, una


herramienta fundamental es, sin duda,
la automatizacin .
Los directivos y su esencia humana
constituyen un factor decisivo en el xito de un proceso reingenieril, pues son
los encargados de percibir cuando sus
mecanismos de negocio estn obsoletos o fuera de contexto, incluso cuando
podra ser preciso aplicar reingeniera
en los procesos sin que stos llegaran
a tal punto, siendo factor clave la iniciativa, el dominio de informacin relevante de la empresa y su entorno, pues
redisear es reinventar el negocio, no
mejorarlo ni modificarlo. Al aplicar la
reingeniera a un proceso lograremos
condiciones ptimas en los flujos de
trabajo y la productividad, dando resultados que deben ser notables y hasta
sorprendentes, esto debido a que el
programa de reingeniera es difcil y
los resultados no se vern de un golpe
sino de manera creciente.
De aqu que se pueda decir que la
reingeniera de procesos en una empresa constituye un cambio radical, y es
esto precisamente lo que las empresas

Revista Internacional La Nueva Gestin Organizacional, ao 4, nm. 8, enero-junio, 2009, issn: 1870205-8, pp. 13-25

rea del conocimiento: gestin e innovacin

Reingeniera de software, un camino o el camino?

desean siempre evitar, y a ello se debe


que se haga muy difcil la decisin de
asumirla. A eso obedece tambin que
las organizaciones casi siempre opten
por la mejora continua paulatina, lo que
implica ir hacindole pequeos cambios
a los procesos relevantes en ejecucin,
sin necesidad de volver a redefinirlos y
esto pueda traer un caos en el resultado final, inferior al que tenan antes de
aventurarse. Pero, qu pasara en una
organizacin donde aplico mejoras paulatinas y continuas a un proceso en un
entorno que ya no es continuo ni se rige
por los mismos paradigmas?, pues fracasara ineludiblemente, o estara atada a sistemas ya obsoletos a los cuales
se le agregan parches para que vaya
solucionando los problemas que van
surgiendo en el tiempo con todos los
conflictos que esto ocasiona, o simplemente, la organizacin dejar de ser
competitiva y no podr aspirar a estar
en la cima de las necesidades de sus
clientes, pues estas necesidades se hacen cada da ms singulares, y surgen
nuevas producto, entre otras cosas,
del desarrollo de las tic, las cuales
ya no se podrn satisfacer.
La aplicacin de la reingeniera en
el software tambin estuvo sujeta a la
evolucin por la que ste ha pasado,
la cual se enmarca en varias etapas
donde cada una ha experimentado caractersticas o tendencias que la distinguen de las otras, por ejemplo, la
llamada crisis del software, en cuyo
escenario el hardware deja de ser un
impedimento para el desarrollo de la

informtica, al reducirse los costos y


mejorarse la calidad y eficiencia en el
software producido. La crisis se caracteriz por los siguientes problemas:
Imprecisin en la planificacin del
proyecto y estimacin de los costos.
Baja calidad del software.
Dificultad de mantenimiento de programas con un diseo poco estructurado, etctera.
A raz de esta crisis se vio la necesidad de crear estndares de desarrollo del software. Esto dio lugar a lo
que hoy llamamos ingeniera de software, la cual es el establecimiento y
uso de principios de la ingeniera a fin
de obtener econmicamente software
que sea confiable y que funcione eficientemente. [3]
A pesar de la creacin de estos estndares, muchos de los sistemas que
actualmente se realizan siguen siendo
desarrollados y mantenidos sin aplicar
ninguna prctica de ingeniera de software, por lo que en la actualidad, muchas organizaciones se ven obligadas
a seguir viviendo en esta crisis dado
que sus sistemas son vitales para el
funcionamiento de dichas organizaciones y stos no tienen la arquitectura
orientada a objetos y muchas veces ni
se logra concebir su documentacin.
Las organizaciones usualmente tienen un problema relacionado con el
software, que es la existencia de un software que constituye su columna vertebral, pues ayuda a determinar los

Revista Internacional La Nueva Gestin Organizacional, ao 4, nm. 8, enero-junio, 2009, issn: 1870205-8, pp. 13-25

17

Fernando Garca Tosca, Rixal Martnez Fernndez

objetivos estratgicos y apoya la toma


de decisiones. Estas aplicaciones en
su gran mayora se realizaron en sistemas obsoletos, con funcionalidades
que ya no son suficientes para modelar la nueva infraestructura de negocio
que los rodea, no presentan interfaces
ni infraestructuras para la integracin
con los nuevos paradigmas de la programacin y las comunicaciones, casi
nunca tienen documentacin asociada
tanto para el usuario como para los
desarrolladores, por lo cual se hace
muy difcil ampliarlas o crear sobre ellas
nuevos mdulos de funcionalidades.
Adems, cuando una aplicacin ha servido para necesidades del negocio durante varios aos, se vuelve inestable
debido a las correcciones, adaptaciones y mejoras que se realizaron. Esto
provoca que cada vez que se intenta
efectuar un cambio se produzcan efectos colaterales graves e inesperados.
Estas aplicaciones son llamadas Sistemas de informacin heredados, para
lo cual una posible solucin es aplicar
la reingeniera del software. Jean Marc
von der Weid propone las siguientes
categoras de solucin al respecto:
Mantenimiento: es un proceso paulatino e iterativo en el cual se hacen
pequeas modificaciones al sistema.
Modernizacin: implica cambios ms
extensos que el mantenimiento pero
conserva partes considerables del
sistema existente.
Remplazarlo: consiste en reconstruir
el sistema desde los inicios. Esta
18

solucin consiste en aplicarle al sistema actividades de reingeniera de


software. [3]
La decisin estara entonces determinada por una relacin de costo-beneficio, en cuyo caso cada organizacin
tomar la decisin que le proporcione
mayores beneficios en relacin con el
costo que estn dispuestos a pagar
para lograrlo.

Reingeniera de software
La reingeniera de software ha tenido
varios nombres como: modernizacin,
transformacin, restructuracin, rediseo, aunque todos tienen metas comunes: aumentar la capacidad para
competir en el mercado mediante la
reduccin de costos, el incremento en
la calidad y una mayor velocidad de
respuesta. La reingeniera de software
pretende cancelar dialcticamente los
sistemas existentes toma lo bueno
que tienen y lo perfecciona imposibles de mantener, y crea uno nuevo
confiable, eficiente, eficaz y de fcil
mantenimiento.
La reingeniera de software es una
forma de poner en contexto las capacidades o la medida en que pueden
mantenerse los sistemas de informacin heredados mediante la aplicacin
de tecnologas y prcticas modernas.
Ofrece una disciplina de preparacin
para migrar un sistema de informacin
heredado hacia un sistema que evolu-

Revista Internacional La Nueva Gestin Organizacional, ao 4, nm. 8, enero-junio, 2009, issn: 1870205-8, pp. 13-25

rea del conocimiento: gestin e innovacin

Reingeniera de software, un camino o el camino?

ciona. El proceso aplica principios de


ingeniera para un sistema existente
con el objetivo de encontrar nuevos requerimientos.[3]
Existen mltiples referencias al concepto de reingeniera de sistema en
toda la web. Algunos, como Arnold, la
definen como una actividad que mejora la comprensin del software, o
bien, lo prepara o mejora para incrementar su facilidad de mantenimiento,
reutilizacin o evolucin. Para otros
como Chikofsky en [4], es el examen
y la alteracin de un sistema para reconstruirlo en una nueva forma y la
subsiguiente implementacin de esa
forma. Otros lo ven como el proceso
de ingeniera inversa seguida de una
ingeniera directa. El concepto de reingeniera esta muy relacionado con los
conceptos de reutilizacin, innovacin,
gnesis, desarrollo y as se puede
comprobar en los conceptos de Perlis
y Biggerstoff en [6], donde se refieren
a la reutilizacin como
la reaplicacin de una variedad de
tipos de conocimientos de un sistema a otro para reducir el esfuerzo
de desarrollo y mantenimiento de
ese otro sistema; es decir, la reutilizacin est enfocada a mejorar
la calidad y reducir el esfuerzo haciendo uso de parte de un sistema
en un nuevo contexto.

En definitiva, el concepto de reingeniera de software se refiere a la


reutilizacin de sistemas heredados

productos de un esfuerzo anterior y


que garantizan una serie de requisitos
del negocio como base para crear
otro ms eficiente y mantenible.
Estos sistemas suelen tener algunos problemas como son los expuestos por Schimidt en [7], debido a que
normalmente han sido desarrollados
y mantenidos por muchas personas, y
en muchas ocasiones, utilizando tcnicas y estilos de programacin propios
y que en 90% de los casos no tienen la
adecuada documentacin del cdigo y
la arquitectura; adems, con el tiempo
normalmente los requisitos y las especificaciones del negocio han cambiado, pues mediante estos sistemas se
trata de modelar organizaciones dinmicas.
Las dos ventajas fundamentales
que presenta la reingeniera partiendo
de un sistema heredado son: la reduccin del riesgo, ya que si hay una aplicacin que funciona previamente se
conocen sus resultados y, por tanto, ya
se dispone de una especificacin del
sistema reduciendo el costo; se han
realizado estudios reflejados por Ulrich
[8] que muestran que la reduccin del
costo puede ser de un 75 por ciento.
Pero, por otra parte, hacerlo tambin significa una serie de dificultades,
como las indicadas por Presuman en
[9]:
falta de planificacin exhaustiva
para la reutilizacin del software,
no utilizacin por parte de los desarrolladores de software de herra-

Revista Internacional La Nueva Gestin Organizacional, ao 4, nm. 8, enero-junio, 2009, issn: 1870205-8, pp. 13-25

19

Fernando Garca Tosca, Rixal Martnez Fernndez

mientas o componentes diseados


especficamente para ayudar e impulsar la reutilizacin, falta de entrenamiento para ayudar a ingenieros
de software y administradores a
comprender y explicar la reutilizacin, resistencia del personal especializado contra el concepto de
reutilizacin, propugnar metodologas que no facilitan la reutilizacin,
como puede ser la descomposicin
funcional en detrimento de enfoques
orientados a objetos, falta de incentivos en las compaas para producir componentes reutilizables.

Es muy importante tener en cuenta


que no en todos los sistemas es adecuado realizar un proceso de reingeniera. Antes de tomar esa decisin hay
que ponderar una serie de variables,
por ejemplo, la matriz de decisin de
Jacobson [10], para determinar si el sistema tiene un gran valor de negocio y
por tanto es conveniente realizar reingeniera.
Segn Jones [11], se pueden definir
diez elementos del software susceptibles de reutilizarse:
planes de proyecto, estimaciones de
costo, arquitectura, especificaciones
y modelos de requisitos, diseos,
cdigo fuente, documentacin de
usuario y tcnica, interfaces humanas, datos, y casos de prueba.

Es conveniente, entonces, valorar todos estos aspectos antes de realizar un


20

proceso de reingeniera a los sistemas


que determinen objetivos estratgicos
en la organizacin. Es importante determinar cules elementos del software
pueden reutilizarse para tener, de ese
modo, un mejor clculo del costo que
significara la creacin de un sistema
superior. Para esa estimacin deben
analizarse entre otras cosas las
posibles acciones a realizar segn lo
planteado por Jean Marc von der Weid
y otros autores, as como cul ser la
relacin costo-beneficio mas apropiada
que asumiremos. Para determinar los
pasos que deben darse en cada etapa
de reingeniera es necesario consultar
distintas variantes publicadas, pues no
existe una solucin axiomtica ni bien
definida al respecto.
Hay autores que conciben el proceso
de reingeniera de software en dos fases fundamentales (vase la figura 1).
La primera: comprender el software
existente, donde el diseo del sistema
se recupera desde su cdigo fuente con
actividades como anlisis de dependencias, comprensin del programa, deteccin, extraccin y almacenamiento del
diseo. La segunda incluye todas las
actividades que se realizan para transformar el software existente en uno ms
fcil de mantener, entre las cuales cabe
mencionar descomposicin, reestructuracin, remodularizacin, redocumentacin, etctera. [1]
Otros trabajos se centran en la reingeniera y la reutilizacin, como los realizados por Sametinger en [12], donde
se expone cmo construir o retocar el

Revista Internacional La Nueva Gestin Organizacional, ao 4, nm. 8, enero-junio, 2009, issn: 1870205-8, pp. 13-25

rea del conocimiento: gestin e innovacin

Reingeniera de software, un camino o el camino?

Figura1. Proceso bsico de reingeniera

proceso de reingeniera para reutilizar


componentes de software existentes;
otros autores describen una metodologa de reingeniera para reutilizacin,
en la cual integran tcnicas especficas
de reutilizacin dentro del proceso de
reingeniera con nfasis en los componentes.[1]
A continuacin se definen determinadas fases que podran asumirse ante
un proyecto de este tipo como producto del anlisis de varias propuestas en
la documentacin revisada:
n Justificacin de la reingeniera

Esto implica, por un lado, convencer


a la direccin sobre el proceso de reingeniera y la necesidad imperiosa
de cambiar, creando a posteriori un
comit de direccin destinado a hacerse cargo del proyecto de reingeniera. Por otro lado, en esta misma
fase se deber preparar a la fuerza
de trabajo para el compromiso y el
cambio.[3]

La mayora de las organizaciones
slo toman en consideracin los

procesos de reingeniera cuando el


costo de un nuevo desarrollo es demasiado alto. En cualquier caso, y
aunque a primera vista parezca la
nica o la mejor opcin, es necesario
confirmar la necesidad de reconstruir
el sistema. Para esto se puede dar
una idea de los costos del proyecto
y del valor del software actual dentro
del negocio mediante algunos elementos como: evaluaciones de costo del mantenimiento; para lo cual
los autores recomiendan tres criterios para medir los procesos de mantenimiento: dominio del impacto o
proporcin de instrucciones y elementos de datos afectados por una
tarea de mantenimiento con respecto al total de instrucciones y elementos de datos del sistema; esfuerzo
empleado, que es el nmero de horas dedicadas a tareas de mantenimiento, con lo que se puede obtener
una media del nmero de horas por
tarea de mantenimiento; y tasa de
errores de segundo nivel, que es
el nmero de errores provocados
por acciones de mantenimiento. Si

Revista Internacional La Nueva Gestin Organizacional, ao 4, nm. 8, enero-junio, 2009, issn: 1870205-8, pp. 13-25

21

Fernando Garca Tosca, Rixal Martnez Fernndez

se observa que estas tres medidas


aumentan, es muy probable que los
costos de mantenimiento se incrementen con el tiempo [3]. El anlisis
de la calidad del software actual y la
evaluacin del valor de negocio del
sistema ser realizado por la mxima direccin de la organizacin.
n Anlisis de los niveles de calidad y
automatizacin de aplicaciones

En esta fase se determina la calidad


tcnica y el valor de negocio de cada
aplicacin medular en la empresa,
con el objetivo de construir una lista
de aplicaciones ordenada segn sus
prioridades en el proceso de reingeniera.

La calidad tcnica de un producto
es una medida relativa, dependiente
de cada organizacin, que se calcula
en funcin de diversas caractersticas (complejidad ciclomtica o errores/kldc).[3]

Para cada variable que interviene
en la calidad tcnica se fijan lmites
inferior y superior que representan
los valores mximos y mnimos de
calidad. Para hallar el nivel de calidad de la variable considerada se
puede utilizar la siguiente formula:


22

De donde se obtiene una grfica


que nos ayuda a determinar que apli-

caciones son prioritarias y cuales no


en el proceso de reingeniera. Asociando un punto de un plano para
cada aplicacin, e interpretando el
valor de negocio y la calidad tcnica
como coordenadas de estos puntos
[3] (vase la figura 2).

De esta forma, las aplicaciones
ubicadas en el cuadrante superior
izquierdo tienen alta calidad y bajo
valor de negocio, por lo que no requieren reingeniera; las situadas en
el cuadrante inferior izquierdo tienen
poco valor en ambos parmetros, por
lo que pueden ser desarrolladas de
nuevo o remplazadas por productos
comerciales; las del superior derecho tienen un gran valor de negocio
y alta calidad: se les puede aplicar
reingeniera, pero sin excesiva prioridad; las del inferior derecho tienen
alto valor de negocio y baja calidad
tcnica, por lo que sern las primeras candidatas a la reingeniera.
n Estimacin de costo/beneficio

El siguiente paso debe ser determinar los costos de cada proyecto de


reingeniera que se vaya a enfrentar:
si stos son superiores a los beneficios, la reingeniera no ser una opcin viable y la aplicacin deber ser
desarrollada de nuevo o bien adquirirse en el mercado.

Para estimar los costos de la reingeniera, se tienen ciertas ventajas
respecto a ese clculo en proyectos
de ingeniera directa, debido a que

Revista Internacional La Nueva Gestin Organizacional, ao 4, nm. 8, enero-junio, 2009, issn: 1870205-8, pp. 13-25

rea del conocimiento: gestin e innovacin

Reingeniera de software, un camino o el camino?

Figura 2. Esquema para determinar aplicaciones prioritarias


en el proceso de reingeniera

como se apoyar el proceso sobre


una aplicacin ya realizada y que
satisface ciertos requisitos, entonces
no es necesario calcular factores influyentes como el nmero de lneas
de cdigo, sentencias ejecutables,
elementos de datos, accesos a archivos, etc., ya que son medidas que
se pueden tomar directamente de la
aplicacin.

Se recomienda utilizar como variables para calcular los costos las
que se ofrecen a continuacin, y que
deben ponderarse en funcin de su
influencia en el costo total [3]:
Nmero de lneas de cdigo no
comentadas.
Costo de los casos de prueba,
que se calcula multiplicando el

costo medio de cada caso de


prueba por el nmero de stos,
que es funcin de la complejidad
ciclomtica del problema.
Nmero de accesos a archivos,
bases de datos y campos. En la
ponderacin de estas entradas/
salidas consideramos la complejidad de las estructuras de informacin y el grado de independencia
de la aplicacin respecto de los
datos.
Nmero de operaciones que realizan los usuarios de la aplicacin,
nmero de ventanas, nmero de
informes, etc., para el caso de las
interfaces de usuario.

Una vez que se ha calculado el costo de la reingeniera, la ltima etapa

Revista Internacional La Nueva Gestin Organizacional, ao 4, nm. 8, enero-junio, 2009, issn: 1870205-8, pp. 13-25

23

Fernando Garca Tosca, Rixal Martnez Fernndez

es compararlos con los beneficios


esperados.
El beneficio proporcionado para
seguir manteniendo el producto sin
reingeniera es el siguiente:
BM = [P3 (P1 + P2)] * P16

Deber retocarse la frmula cuando los diversos costos varen de un


ao para otro. Si se desarrolla de
nuevo el sistema, se obtiene este
beneficio:
BD = [(P12 (P10 + P11)) * (P16 P14) (P13 * P15)] BM

El beneficio producido por la reingeniera es:


BR = [(P6 (P4 + P5)) * (P16 P8) (P7 * P9)] BM

Donde:
P1 = Costo de mantenimiento actual para
una aplicacin (anual).
P2 = Costo de operacin de una aplicacin (anual).
P3 = Valor del negocio actual (anual).
P4 = Costo previsto de mantenimiento
tras la reingeniera (anual).
P5 = Costo previsto de operaciones tras la
reingeniera (anual).
P6 = Valor de negocio previsto tras la reingeniera (anual).
P7 = Costo estimado de la reingeniera.
P8 = Duracin estimada de la reingeniera.
P9 = Factor de riesgo de la reingeniera.

24

P10 = Costo previsto de mantenimiento


tras el redesarrollo (anual).
P11 = Costo previsto de operaciones tras el
redesarrollo (anual).
P12 = Valor de negocio previsto del nuevo
sistema (anual).
P13 = Costo estimado del redesarrollo.
P14 = Duracin estimada del redesarrollo.
P15 = Factor de riesgo del redesarrollo.
P16 = Vida esperada del sistema.

Conclusiones
Aunque la reingeniera se usa principalmente durante el mantenimiento del
software, va ms all de una simple
ayuda para el mantenimiento. La reingeniera es el puente desde las viejas
hacia las nuevas tecnologas que las
organizaciones deben usar en la actualidad para responder al cambio de
requerimientos del negocio.[8]
Los viejos programas representan
la tecnologa de ayer. Ahora sabemos
que los aos tienen cuatro dgitos y no
dos, que los datos pueden ser manejados mejor en bases de datos y que
tenemos nuevos diseos de construccin y lenguajes de programacin que
permiten disear programas notablemente factibles.
Cuando el costo de mantener viejos
edificios es excesivo, stos son remplazados por otros nuevos. Nosotros
deberamos hacer lo mismo con los
programas. Los programas se hacen
obsoletos al paso del tiempo ya que fueron escritos para hardware y sistemas

Revista Internacional La Nueva Gestin Organizacional, ao 4, nm. 8, enero-junio, 2009, issn: 1870205-8, pp. 13-25

rea del conocimiento: gestin e innovacin

Reingeniera de software, un camino o el camino?

operativos que ya no existen, donde


muchos estn llenos de caractersticas
y parches no documentados.[13, 1]
Mientras ms conocimiento se gestione en la organizacin y se aprenda
de una forma dinmica y en constante
intercambio con el entorno, entonces
se tendrn las bases para saber cundo es preciso dar un salto cualitativo
que deje fuera de combate a la competencia y que permita a la organizacin
crecer en tecnologa y conocimiento.
La reingeniera de software constituye una poderosa herramienta para
posibilitar que nuestras empresas se
desarrollen tan rpido como nuestras
mentes y los paradigmas tecno-informticos.

Bibliografa
1. M. M. S. Juan Carlos lvarez Garca,
Mara N. Moreno Garca (2005), Metodologa de reingeniera del software
para la remodelacin de aplicaciones
cientficas heredadas, Universidad de
Salamanca (informe tcnico).
2. Morales, C. (2005): Reingeniera, Enlaces de Recursos Humanos, en http://
www.losrecursoshumanos.com/reingenieria.htm; 10/12/2005.
3. F. C. N. Johnatan (2004), Reconstruccin de la arquitectura: una actividad de
la reingeniera de software, en http://
www.monografias.com/trabajos17/reingenieria-software/reingenieria-software.
shtml.

4. E. J. A. C. Chikofsky, J.H (1990), Reverse engineering and design recovery:


A taxonomy. Ieee software, 7(1).
5. R. S. Arnold (1993), Software reengineering. Los Alamitos, CA, Ieee Computer Society Press.
6. B. T. A. Perlis (1990), Software reusability. Addison-Wesley.
7. H. W. Postema M. y Schimidt (1998),
Reverse engineering and abstraction
of legacy systems. Informatica: An international journal of computing and informatics., vol 22, nm. 3: 359-371.
8. W. M. Ulrich (1990), The evolutionary
growth of software reengineering and
the decade ahead. American programmer.
9. R. S. Pressman (2001), Software engineering: A practitioners approach. Fifth
edition, McGraw-Hill.
10.
I. Jacobson, Lindstrm, F. (1991),
Re-engineering of old system to an object-oriented architecture. Acm sigplan
conference on object-oriented programming, systems, languages and applications, Phoenix, Arizona: 340-350.
11.
C. Jones (1994), The economics
of object-oriented software, American
programmer, vol. 7, nm. 10: 28-35.
12.
J. Sametinger (1997), Software
engineering with reusable components,
Springer-verlag.
13.
E. P. Jurez (2006), La reingeniera de sistema y de capacitacin informtica, http://www.tribunalmmm.gob.
mx/conferencias/2001/txtConfeHidalgo.
htm

Revista Internacional La Nueva Gestin Organizacional, ao 4, nm. 8, enero-junio, 2009, issn: 1870205-8, pp. 13-25

25

You might also like