1_-_No._8

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

Universidad de Camagey, Cuba. [email protected], [email protected]

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 oca-sionando cambios de grandes dimensiones en muchas organizaciones.

En especial, la aplicacin de la reingeniera en el software ha estado sujeta a la evolu-cin 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 siste-mas 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 for-man 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 tene-mos?, 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.


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

The application of Reingeneering in Softwares has especially evolved since it has gone through system changes, which had their own characteristics or trends. One rele-vant trend that can be mentioned is the sofware crisis.

It would be thus unproductive and with major negative impact on the company perfor-mance to keep using rigid systems within dynamic organizations, when those obsolete systems are the legacy of specialists with proper programming and undocumented te-chniques that no longer work for the company.

So, what decisions can we make to solve the current problem? Shall we apply rein-geneering 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 rpida-mente a la fase de alto impacto y di-seminacin del enfoque en el mundo empresarial, producindose casi de inmediato la fase crtica, en que desde diversos ngulos se cuestionaron va-rias de sus propuestas. Ahora est por ingresar en la fase madura, donde la experiencia acumulada enriquece sus-tancialmente 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 em-presarial 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

en sus negocios por medio del redi-seo de sus procesos. Era la poca en que emerga este enfoque y su aplicacin se circunscriba a unas cuantas corporaciones estadouni-denses.

La segunda fase se inicia en 1993, al publicarse los casos de las em-presas 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 divulga-cin 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: reingenie-ra por medio de la tecnologa de la informacin, de Thomas H. Da-venport, profesor de la Universidad de Boston, considerado una de las mximas autoridades en el tema.

Durante este periodo las empresas en muchos pases iniciaron proce-sos de reingeniera y el enfoque tuvo


Reingeniera de software, un camino o el camino?

1

rea del conocimiento: gestin e innovacin

una expansin extraordinaria. Esta fase incluye a las primeras empre-sas seguidoras del enfoque. Breve tiempo despus siguen el camino de la reingeniera las empresas ms conservadoras, dando paso a la ter-cera fase.

A partir de 1995 se inicia la cuarta fase: la fuerte crtica a la reingeniera. Consultores, investigadores uni-versitarios y ejecutivos empezaron a acumular experiencias que mos-traban algunas limitaciones de la versin original de este enfoque y detectaron los factores que atenta-ban 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 Reen-geineering Revolution, Michael Hammer y Steven Stanton, en el segundo, Rein-geniera 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 re-plantear 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 respon-der ahora a una moda ms, revolucio-nan radicalmente la forma en que se ha diseado el trabajo en el siglo XX, y constituyen una alternativa permanen-te de efectividad organizacional para los ejecutivos.

La reingeniera, segn Hammer y Stanton, es repensar de manera fun-damental los procesos de negocios y redisearlos radicalmente, con el fin de obtener dramticos logros en el desem-peo. 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 apli-caran 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 fundamental-mente a la forma inadecuada en que se interpretan sus conceptos y se ponen en prctica. Pues la reingeniera cons-tituye ms que un dogma una filosofa para enfrentar la competencia y mejo-rar los procesos.

Michael Hammer, uno de los pione-ros de la reingeniera, admita: No fui



suficientemente inteligente, y agrega-ba: Por mis antecedentes de ingenie-ro, no prest suficiente atencin a la dimensin humana. He aprendido que es un factor vital. Si bien tanto Ham-mer como Champy han admitido cam-bios importantes al enfoque original, no coinciden en cules son los adecua-dos, al punto que han preferido plan-tear cada uno su propio enfoque por separado en sus libros posteriores.

Otra crtica generalizada seala que la reingeniera ha servido como excu-sa gerencial para despedir personal y recargar el trabajo a quienes perma-necen en la empresa. En la prctica, una cantidad considerable de empre-sas anuncian procesos de reingeniera, pero aplican otra cosa: reestructuracio-nes o adelgazamiento organizacional, acompaado normalmente por despido de personal. A veces se hace a propsi-to, a fin de confundir a la opinin pblica y al personal, pero en otras oportunida-des es por desconocimiento de lo que es realmente la reingeniera. [2] Esto ha provocado que los trabajadores le teman y su sola mencin puede cau-sar sospechas, repliegue, resistencia y desnimo.

Otros tipos de crticas se han cen-trado en su relacin con la automatiza-cin.

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-

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 rein-geniera 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 xi-to de un proceso reingenieril, pues son los encargados de percibir cuando sus mecanismos de negocio estn obsole-tos 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 ini-ciativa, el dominio de informacin rele-vante 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 resul-tados 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 em-presa constituye un cambio radical, y es esto precisamente lo que las empresas



1


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 resulta-do final, inferior al que tenan antes de aventurarse. Pero, qu pasara en una organizacin donde aplico mejoras pau-latinas y continuas a un proceso en un entorno que ya no es continuo ni se rige por los mismos paradigmas?, pues fra-casara ineludiblemente, o estara ata-da 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 simple-mente, 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 ha-cen 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 ca-ractersticas o tendencias que la dis-tinguen 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 carac-teriz por los siguientes problemas:

Imprecisin en la planificacin del proyecto y estimacin de los costos.

Baja calidad del software. Dificultad de mantenimiento de pro-

gramas con un diseo poco estruc-turado, etctera.

A raz de esta crisis se vio la nece-

sidad de crear estndares de desa-rrollo del software. Esto dio lugar a lo que hoy llamamos ingeniera de soft-ware, la cual es el establecimiento y uso de principios de la ingeniera a fin de obtener econmicamente software que sea confiable y que funcione efi-cientemente. [3]

A pesar de la creacin de estos es-tndares, muchos de los sistemas que actualmente se realizan siguen siendo desarrollados y mantenidos sin aplicar ninguna prctica de ingeniera de soft-ware, por lo que en la actualidad, mu-chas organizaciones se ven obligadas a seguir viviendo en esta crisis dado que sus sistemas son vitales para el funcionamiento de dichas organizacio-nes y stos no tienen la arquitectura orientada a objetos y muchas veces ni se logra concebir su documentacin.

Las organizaciones usualmente tie-nen un problema relacionado con el software, que es la existencia de un software que constituye su columna ver-tebral, pues ayuda a determinar los



objetivos estratgicos y apoya la toma de decisiones. Estas aplicaciones en su gran mayora se realizaron en sis-temas obsoletos, con funcionalidades que ya no son suficientes para mode-lar la nueva infraestructura de negocio que los rodea, no presentan interfaces ni infraestructuras para la integracin con los nuevos paradigmas de la pro-gramacin 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 ser-vido para necesidades del negocio du-rante varios aos, se vuelve inestable debido a las correcciones, adaptacio-nes y mejoras que se realizaron. Esto provoca que cada vez que se intenta efectuar un cambio se produzcan efec-tos colaterales graves e inesperados. Estas aplicaciones son llamadas Sis-temas 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 pau-latino 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

solucin consiste en aplicarle al sis-tema actividades de reingeniera de software. [3]

La decisin estara entonces deter-minada por una relacin de costo-be-neficio, 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, redi-seo, aunque todos tienen metas co-munes: 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 imposi-bles 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 capa-cidades o la medida en que pueden mantenerse los sistemas de informa-cin 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-



1


ciona. El proceso aplica principios de ingeniera para un sistema existente con el objetivo de encontrar nuevos re-querimientos.[3]

Existen mltiples referencias al con-cepto de reingeniera de sistema en toda la web. Algunos, como Arnold, la definen como una actividad que me-jora la comprensin del software, o bien, lo prepara o mejora para incre-mentar su facilidad de mantenimiento, reutilizacin o evolucin. Para otros como Chikofsky en [4], es el examen y la alteracin de un sistema para re-construirlo 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 rein-geniera 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 siste-ma a otro para reducir el esfuerzo de desarrollo y mantenimiento de ese otro sistema; es decir, la reuti-lizacin est enfocada a mejorar la calidad y reducir el esfuerzo ha-ciendo uso de parte de un sistema en un nuevo contexto.

En definitiva, el concepto de rein-geniera 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 algu-nos problemas como son los expues-tos por Schimidt en [7], debido a que normalmente han sido desarrollados y mantenidos por muchas personas, y en muchas ocasiones, utilizando tcni-cas 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 espe-cificaciones del negocio han cambia-do, pues mediante estos sistemas se trata de modelar organizaciones din-micas.

Las dos ventajas fundamentales que presenta la reingeniera partiendo de un sistema heredado son: la reduc-cin del riesgo, ya que si hay una apli-cacin 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 tam-bin 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 de-sarrolladores de software de herra-



mientas o componentes diseados especficamente para ayudar e im-pulsar la reutilizacin, falta de entre-namiento para ayudar a ingenieros de software y administradores a comprender y explicar la reutiliza-cin, resistencia del personal es-pecializado contra el concepto de reutilizacin, propugnar metodolo-gas que no facilitan la reutilizacin, como puede ser la descomposicin funcional en detrimento de enfoques orientados a objetos, falta de incen-tivos en las compaas para produ-cir componentes reutilizables.

Es muy importante tener en cuenta que no en todos los sistemas es ade-cuado realizar un proceso de reinge-niera. 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 sis-tema tiene un gran valor de negocio y por tanto es conveniente realizar rein-geniera.

Segn Jones [11], se pueden definir diez elementos del software suscepti-bles de reutilizarse:

planes de proyecto, estimaciones de costo, arquitectura, especificaciones y modelos de requisitos, diseos, cdigo fuente, documentacin de usuario y tcnica, interfaces huma-nas, datos, y casos de prueba.

Es conveniente, entonces, valorar to-dos estos aspectos antes de realizar un

proceso de reingeniera a los sistemas que determinen objetivos estratgicos en la organizacin. Es importante de-terminar 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 fa-ses 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 dependen-cias, comprensin del programa, detec-cin, extraccin y almacenamiento del diseo. La segunda incluye todas las actividades que se realizan para trans-formar el software existente en uno ms fcil de mantener, entre las cuales cabe mencionar descomposicin, reestructu-racin, remodularizacin, redocumen-tacin, etctera. [1]

Otros trabajos se centran en la rein-geniera y la reutilizacin, como los rea-lizados por Sametinger en [12], donde se expone cmo construir o retocar el



21


proceso de reingeniera para reutilizar componentes de software existentes; otros autores describen una metodo-loga de reingeniera para reutilizacin, en la cual integran tcnicas especficas de reutilizacin dentro del proceso de reingeniera con nfasis en los compo-nentes.[1]

A continuacin se definen determi-nadas fases que podran asumirse ante un proyecto de este tipo como produc-to 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 re-ingeniera y la necesidad imperiosa de cambiar, creando a posteriori un comit de direccin destinado a ha-cerse cargo del proyecto de reinge-niera. 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 de-masiado 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 ele-mentos como: evaluaciones de cos-to del mantenimiento; para lo cual los autores recomiendan tres crite-rios para medir los procesos de man-tenimiento: dominio del impacto o proporcin de instrucciones y ele-mentos de datos afectados por una tarea de mantenimiento con respec-to al total de instrucciones y elemen-tos de datos del sistema; esfuerzo empleado, que es el nmero de ho-ras dedicadas a tareas de manteni-miento, 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

Figura1. Proceso bsico de reingeniera



se observa que estas tres medidas aumentan, es muy probable que los costos de mantenimiento se incre-menten 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 mxi-ma 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 reinge-niera.

La calidad tcnica de un producto es una medida relativa, dependiente de cada organizacin, que se calcula en funcin de diversas caractersti-cas (complejidad ciclomtica o erro-res/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 ca-lidad de la variable considerada se puede utilizar la siguiente formula:

De donde se obtiene una grfica que nos ayuda a determinar que apli-

caciones son prioritarias y cuales no en el proceso de reingeniera. Aso-ciando 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 re-quieren 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 dere-cho tienen un gran valor de negocio y alta calidad: se les puede aplicar reingeniera, pero sin excesiva prio-ridad; las del inferior derecho tienen alto valor de negocio y baja calidad tcnica, por lo que sern las prime-ras candidatas a la reingeniera.

n Estimacin de costo/beneficio

El siguiente paso debe ser determi-nar los costos de cada proyecto de reingeniera que se vaya a enfrentar: si stos son superiores a los benefi-cios, la reingeniera no ser una op-cin viable y la aplicacin deber ser desarrollada de nuevo o bien adqui-rirse en el mercado.

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



23


como se apoyar el proceso sobre una aplicacin ya realizada y que satisface ciertos requisitos, entonces no es necesario calcular factores in-fluyentes como el nmero de lneas de cdigo, sentencias ejecutables, elementos de datos, accesos a ar-chivos, etc., ya que son medidas que se pueden tomar directamente de la aplicacin.

Se recomienda utilizar como va-riables 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 compleji-dad de las estructuras de informa-cin y el grado de independencia de la aplicacin respecto de los datos.

Nmero de operaciones que rea-lizan 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 cos-to de la reingeniera, la ltima etapa

Figura 2. Esquema para determinar aplicaciones prioritarias en el proceso de reingeniera



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 cuan-do 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 reinge-niera 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 aplica-cin (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 rein-

geniera (anual).P7 = Costo estimado de la reingeniera.P8 = Duracin estimada de la reingenie-

ra.P9 = Factor de riesgo de la reingeniera.

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 princi-palmente durante el mantenimiento del software, va ms all de una simple ayuda para el mantenimiento. La rein-geniera es el puente desde las viejas hacia las nuevas tecnologas que las organizaciones deben usar en la ac-tualidad 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 mane-jados mejor en bases de datos y que tenemos nuevos diseos de construc-cin y lenguajes de programacin que permiten disear programas notable-mente factibles.

Cuando el costo de mantener viejos edificios es excesivo, stos son rem-plazados por otros nuevos. Nosotros deberamos hacer lo mismo con los programas. Los programas se hacen obsoletos al paso del tiempo ya que fue-ron escritos para hardware y sistemas



2


operativos que ya no existen, donde muchos estn llenos de caractersticas y parches no documentados.[13, 1]

Mientras ms conocimiento se ges-tione en la organizacin y se aprenda de una forma dinmica y en constante intercambio con el entorno, entonces se tendrn las bases para saber cun-do es preciso dar un salto cualitativo que deje fuera de combate a la compe-tencia y que permita a la organizacin crecer en tecnologa y conocimiento. La reingeniera de software constitu-ye una poderosa herramienta para posibilitar que nuestras empresas se desarrollen tan rpido como nuestras mentes y los paradigmas tecno-infor-mticos.

Bibliografa

1. M. M. S. Juan Carlos lvarez Garca, Mara N. Moreno Garca (2005), Me-todologa de reingeniera del software para la remodelacin de aplicaciones cientficas heredadas, Universidad de Salamanca (informe tcnico).

2. Morales, C. (2005): Reingeniera, En-laces de Recursos Humanos, en http://www.losrecursoshumanos.com/reinge-nieria.htm; 10/12/2005.

3. F. C. N. Johnatan (2004), Reconstruc-cin de la arquitectura: una actividad de la reingeniera de software, en http://www.monografias.com/trabajos17/rein-genieria-software/reingenieria-software.shtml.

4. E. J. A. C. Chikofsky, J.H (1990), Re-verse engineering and design recovery: A taxonomy. IEEE software, 7(1).

5. R. S. Arnold (1993), Software reengi-neering. Los Alamitos, CA, IEEE Com-puter Society Press.

6. B. T. A. Perlis (1990), Software reusabil-ity. Addison-Wesley.

7. H. W. Postema M. y Schimidt (1998), Reverse engineering and abstraction of legacy systems. Informatica: An in-ternational journal of computing and in-formatics., vol 22, nm. 3: 359-371.

8. W. M. Ulrich (1990), The evolutionary growth of software reengineering and the decade ahead. American program-mer.

9. R. S. Pressman (2001), Software engi-neering: A practitioners approach. Fifth edition, McGraw-Hill.

10. I. Jacobson, Lindstrm, F. (1991), Re-engineering of old system to an ob-ject-oriented architecture. Acm sigplan conference on object-oriented program-ming, systems, languages and applica-tions, 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 reing-eniera de sistema y de capacitacin in-formtica, http://www.tribunalmmm.gob.mx/conferencias/2001/txtConfeHidalgo.htm

Documents

1_-_No._8