6 TO Nivel B UNIVERSIDAD LAICA ELOY ALFARO DE MANAB

FACULTAD DE CIENCIAS INFORMTICAS

TEMA:MANTENIMIENTO Y REINGENIERIA DE SOFTWAREGESTIN DE LA CALIDAD DEL SOFTWAREALUMNOS:GUTIERREZ QUIMIS GARY GABRIEL MERA GUARANDA YANDRY XAVIERPALMA TUAREZ LISSETH CAROLINAPROFESOR:ING. MARCO AYOVICURSO:SEXTO NIVEL BPARCIAL:2er PARCIAL

AO LECTIVO:2013 2014

INDICE1.INTRODUCCIN32.OBJETIVOS52.1.GENERAL52.2.ESPECIFICOS54. LECTURA COMPRESIVA............................65. DESARROLLO76 LISTA DE APLICACIONES QUE NECESITA UNA EMPRESA COMERCIAL137 PALABRAS CLAVES..138 FODA..149. CONCLUSIONES RECOMENDACIONES1510. BIBLIOGRAFIA16

INTRODUCCIONEn este siguiente trabajo hablaremos del mantenimiento y reingeniera del software y podemos conocer como la evolucin del software est dividida en varias etapas, una de ellas es la llamada "crisis del software". Esta crisis fue el resultado de la introduccin de la tercera generacin del hardware. El hardware dejo de ser un impedimento para el desarrollo de la informtica; redujo los costos y mejoro la calidad y eficiencia en el software producido. 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" el cual es el establecimiento y uso de principios de la ingeniera a fin de obtener econmicamente software que sea fiable y que funcione eficientemente.A pesar de la creacin de estos estndares, muchos sistemas siguieron siendo desarrollados y mantenidos sin aplicar ninguna practica de ingeniera de software por lo que hoy en da, muchas organizaciones se ven obligadas a seguir viviendo en esta crisis dado que sus sistemas son vitales para el funcionamiento de dichas organizaciones.Vemos como el mantenimiento de un software es importante ya que permite adaptarlo a las necesidades cambiantes de la organizacin para as tener xito, la reingeniera de software es la actividad con el cual se pretende dar solucin a estas organizaciones. La reingeniera de software pretende dejar morir esos sistemas imposibles de mantener, no sin antes extraer de ellos conocimientos que permitan crear un nuevo sistema fiable, eficiente y de fcil mantenimiento.Dado que en muchos de los casos, la reingeniera de software se convierte en la nica solucin a estos sistemas de baja calidad, esta monografa pretende dar una breve introduccin a dicha solucin para mostrarle al lector que a pesar de que el esfuerzo de aplicar reingeniera es un proceso difcil, trae grandes beneficios si se emplea de manera adecuada.

.

OBJETIVOSOBJETIVO GENERAL

Realizar una investigacin que permita obtener conocimientos del Mantenimiento de reingeniera del software mediante el uso de diferentes instrumentos (Libros, Internet etc.)

OBJETIVOS ESPECIFICOS

Elaborar una documentacin que muestre lo consultado de los respectivos temas. Consultar los tipos de mantenimiento que hay para un software. Analizar las actividades del modelo de proceso de reingeniera de software.

MANTENIMIENTO Y REINGIENERIA.Sin importar su dominio de aplicacin, su tamao o su complejidad, el software de computadora evolucionar con el tiempo. El cambio impulsa este proceso. Para el software de computadora, el cambio ocurre cuando se corrigen los errores, cuando el software se adapta a un nuevo entorno, cuando el cliente solicita nuevas caractersticas o funciones y cuando la aplicacin se somete a reingeniera para ofrecer beneficio en un contexto moderno.Durante los pasados 30 aos, Manny Lehman [por ejemplo, Leh97a] y sus colaboradores realizaron anlisis detallados de software de grado industrial y de sistemas con la intencin de desarrollar una teora unificada para evolucin del software. Los detalles de este trabajo estn ms all del mbito de este libro, pero vale la pena destacar las leyes subyacentes derivadas de ellaLey de cambio continuo (1974): El software que se implement en un contexto de cmputo del mundo real y que, por tanto, evolucionar con el tiempo (llamados sistemas tipo E) debe adaptarse continuamente o de otro modo se volver progresivamente menos satisfactorio.Ley de complejidad creciente (1974): Conforme un sistema tipo E evoluciona, su complejidad aumenta, a menos que se haga trabajo para mantenerlo o reducirlo.Ley de autorregulacin (1974): El proceso de evolucin del sistema tipo E es autorregulable con medidas de distribucin de producto y de proceso cercanas a lo normal.Ley de conservacin de estabilidad organizativa (1980): La tasa de actividad global efectiva promedio en un sistema tipo E en evolucin no vara durante el tiempo de vida del producto.Ley de conservacin de familiaridad (1980): Conforme un sistema tipo E evoluciona, todo lo asociado con l: desarrolladores, personal de ventas, usuarios, etc., deben mantener el dominio de su contenido y comportamiento para lograr evolucin satisfactoria. El crecimiento excesivo disminuye dicho dominio. Por tanto, el crecimiento incremental promedio permanece sin variacin conforme el sistema evoluciona.Ley de crecimiento continuo (1980): El contenido funcional de los sistemas tipo E debe aumentar continuamente para mantener la satisfaccin del usuario durante su tiempo de vida.Ley de declive de la calidad (1996): La calidad de los sistemas tipo E declinar, a menos que se mantengan y adapten rigurosamente a los cambios del entorno operativo.Ley de realimentacin del sistema (1996): Los procesos evolutivos tipo E constituyen sistemas de realimentacin multinivel, multibucle y multiagente, y deben tratarse como tales para lograr mejora significativa sobre cualquier base razonable.Las leyes que definieron Lehman y sus colegas son parte inherente de una realidad de la ingeniera de software. En este captulo se estudia el reto del mantenimiento del software y las actividades de reingeniera que se requieren para extender la vida efectiva de los sistemas heredados.

MANTENIMIENTO DE SOFTWAREste comienza casi de inmediato. El software se libera a los usuarios finales y, en cuestin de das, los reportes de errores se filtran de vuelta hacia la organizacin de ingeniera de software.En semanas, una clase de usuarios indica que el software debe cambiarse de modo que pueda ajustarse a las necesidades especiales de su entorno. Y en meses, otro grupo corporativo, que no quera saber nada del software cuando se liber, ahora reconoce que puede ofrecerle beneficios inesperados. Necesitar algunas mejoras para hacer que funcione en su mundo.El reto del mantenimiento del software comienza. Uno se enfrenta con una creciente lista de correccin de errores, peticiones de adaptacin y mejoras categricas que deben planearse, calendarizarse y, a final de cuentas, lograrse. Mucho antes, la fila creci bastante y el trabajo que implica amenaza con abrumar los recursos disponibles. Conforme pasa el tiempo, la organizacin descubre que emplea ms dinero y tiempo en mantener los programas existentes que en someter a ingeniera nuevas aplicaciones. De hecho, no es raro que una organizacin de software emplee entre 60 y 70 por ciento de todos sus recursos en mantenimiento del software.Acaso el lector pregunte por qu se requiere tanto mantenimiento y por qu se emplea tanto esfuerzo. Osborne y Chikofsky [Osb90] proporcionan una respuesta parcial:Mucho del software del que dependemos en la actualidad tiene en promedio una antigedad de 10 a15 aos. Aun cuando dichos programas se crearon usando las mejores tcnicas de diseo y codificacin conocidas en la poca [y muchas no lo fueron], se produjeron cuando el tamao del programa y el espacio de almacenamiento eran las preocupaciones principales. Luego migraron a nuevas plataformas, se ajustaron para cambios en mquina y tecnologa de sistema operativo, y aumentaron para satisfacer las necesidades de los nuevos usuarios, todo sin suficiente preocupacin por la arquitectura global. El resultado es estructuras pobremente diseadas, pobre codificacin, pobre lgica y pobre documentacin de los sistemas de software que ahora debemos seguir usando...Otra razn del problema del mantenimiento del software es la movilidad del personal. Es probable que el equipo (o la persona) de software que hizo el trabajo original ya no est ms por ah. Peor an, otras generaciones de personal de software modificaron el sistema y se mudaron.Y puede ser que ya no quede alguien que tenga algn conocimiento directo del sistema heredado.Como se anot en el captulo 22, la naturaleza ubicua del cambio subyace a todo el trabajo del software. El cambio es inevitable cuando se construyen sistemas basados en computadoras; por tanto, deben desarrollarse mecanismos para evaluar, controlar y realizar modificaciones.A lo largo de este libro se enfatiza la importancia de entender el problema (anlisis) y de desarrollar una solucin bien estructurada (diseo). De hecho, la parte 2 del libro se dedica a la mecnica de tales acciones de ingeniera de software y la 3 se enfoca en las tcnicas requeridas para asegurarse de que se hicieron correctamente. Anlisis y diseo conducen a una importante caracterstica del software que se llamar mantenibilidad. En esencia, la mantenibilidad es un indicio cualitativo1 de la facilidad con la que el software existente puede corregirse, adaptarse o aumentarse. Gran parte de lo que trata la ingeniera de software es acerca de la construccin de sistemas que muestren alta mantenibilidad.Pero qu es mantenibilidad? El software mantenible muestra modularidad efectiva (captulo8). Usa patrones de diseo (captulo 12) que permiten facilidad de comprensin. Se construy con estndares y convenciones de codificacin bien definida, que conducen a cdigo fuente autodocumentable y comprensible. Experiment varias tcnicas de aseguramiento de calidad (parte 3 de este libro) que descubrieron potenciales problemas de mantenimiento antes de que el software se liberara. Fue creado por ingenieros de software que reconocen que acaso ya no estn presentes cuando deban realizarse cambios. En consecuencia, el diseo y la implementacin del software debe auxiliar a la persona que realice el cambio.

SOPORTABILIDAD DEL SOFTWARECon la finalidad de dar soporte efectivo al software de grado industrial, su organizacin (o su encargado) deben poder realizar las correcciones, adaptaciones y mejoras que son parte de la actividad de mantenimiento. Pero, adems, la organizacin debe proporcionar otras importantes actividades de soporte que incluyen soporte operativo en marcha, soporte al usuario final y actividades de reingeniera durante el ciclo de vida completo del software. Una definicin razonable de soportabilidad del software es la capacidad de dar soporte a un sistema de software durante toda la vida del producto. Esto implica satisfacer cualquier necesidad o requisito, pero tambin provisin de equipo, infraestructura de soporte, software adicional, instalaciones, mano de obra o cualquier otro recurso requerido para mantener el software operativo y capaz de satisfacer su funcin [SSO08].En esencia, la soportabilidad es uno de los muchos factores de calidad que deben considerarse durante las acciones de anlisis y diseo que son parte del proceso de software. Deben abordarse como parte del modelo (o especificacin) de requisitos y considerarse conforme el diseo evoluciona y comienza la construccin.Por ejemplo, la necesidad de software antierrores en el nivel de componente y cdigo se estudi anteriormente en este libro. El software debe contener facilidades para auxiliar al personal de apoyo cuando se encuentre un defecto en el entorno operativo (y de no cometer equvocos, se encontrarn los defectos). Adems, el personal de apoyo debe tener acceso a una base de datos que contenga registros de todos los defectos que ya se encontraron: sus caractersticas, causas y cura. Esto permitir al personal de apoyo examinar defectos similares y poder brindar un medio para un diagnstico y correccin ms rpidos.Aunque los defectos encontrados en una aplicacin son un tema de soporte crucial, la soportabilidad tambin demanda que se proporcionen recursos para dar soporte diario a los conflictos del usuario final. La labor del personal de soporte al usuario final es responder las consultas del usuario acerca de instalacin, operacin y uso de la aplicacin.

REINGENERAEn un artculo fundamental escrito para Harvard Business Review, Michael Hammer [Ham90] sienta las bases para una revolucin en el pensamiento administrativo acerca de los procesos empresariales y la computacin:Es momento de dejar de pavimentar el camino de las vacas. En lugar de incrustar procesos caducos en silicio y software, debemos eliminarlos y comenzar de nuevo. Debemos reingeniar nuestras empresas: usar el poder de la moderna tecnologa de la informacin para redisear radicalmente nuestros procesos empresariales con la finalidad de lograr mejoras dramticas en su rendimiento.Toda compaa opera de acuerdo con un gran nmero de reglas desarticuladas [...] La reingeniera lucha por liberarse de las antiguas reglas acerca de cmo organizarnos y dirigir nuestros negocios.Como toda revolucin, el llamado a las armas de Hammer result en cambios tanto positivos como negativos. Durante los aos de 1990, algunas compaas hicieron un esfuerzo legtimo por someterse a reingeniera y los resultados condujeron a mejora competitiva. Otros se apoyaron exclusivamente en reduccin y subcontratacin (en lugar de en reingeniera) para mejorar su lnea de referencia. Con frecuencia resultaron organizaciones medias con poco potencial para crecimiento futuro [DeM95a].Hacia finales de la primera dcada del siglo XXI, la publicidad relacionada con la reingeniera disminuy, pero el proceso en s contina en las compaas grandes y pequeas. El nexo entre reingeniera empresarial e ingeniera de software yace en una visin de sistema.Con frecuencia, el software es la realizacin de las reglas empresariales que Hammer analiza.En la actualidad, las principales compaas tienen decenas de miles de programas de cmputo que soportan las antiguas reglas empresariales. Conforme los administradores trabajan para modificar las reglas a fin de lograr mayor efectividad y competitividad, el software debe seguirles el paso. En algunos casos, esto significa la creacin de grandes y novedosos sistemas basados en cmputo.2 Pero en muchos otros, significa la modificacin o reconstruccin de las aplicaciones existentes.En las secciones que siguen, se examina la reingeniera en una forma descendente, comenzando con un breve panorama de la reingeniera de los procesos de empresas y avanzando hacia un anlisis ms detallado de las actividades tcnicas que ocurren cuando el software sesomete a reingeniera.

REINGENIERA DE PROCESOS DE EMPRESALa reingeniera de procesos de empresa (RPE) se extiende ms all del mbito de las tecnologas de la informacin y de la ingeniera de software. Entre las muchas definiciones (la mayora un tanto abstractas) que se han sugerido para la RPE, est una publicada en Fortune Magazine [Ste93]: la bsqueda, e implementacin, de cambios radicales en los procesos de las empresas para lograr resultados innovadores. Pero cmo se realiza la bsqueda y cmo se logra la implementacin?Ms importante, cmo puede asegurarse que el cambio radical sugerido conducir realmente a resultados innovadores en lugar de a caos organizacional?Procesos empresarialesUn proceso empresarial es un conjunto de tareas lgicamente relacionadas, que se realizan para lograr un resultado empresarial definido [Dav90]. Dentro del proceso empresarial, personal, equipo, recursos materiales y procedimientos empresariales se combinan para producir un resultado especfico. Los ejemplos de procesos empresariales incluyen disear un nuevo producto, comprar servicios y suministros, contratar un nuevo empleado y pagar a proveedores.Cada uno demanda un conjunto de tareas y usa diversos recursos dentro de la empresa.Todo proceso empresarial tiene un cliente definido: una persona o grupo que recibe el resultado (por ejemplo, una idea, un reporte, un diseo, un servicio, un producto). Adems, los procesos empresariales atraviesan las fronteras de la organizacin. Requieren que diferentes grupos organizativos participen en las tareas lgicamente relacionadas que definen el proceso.Todo sistema es en realidad una jerarqua de subsistemas. Una empresa no es la excepcin.Toda la empresa est segmentada en la forma siguiente:Empresa sistemas empresariales procesos empresariales subprocesos empresarialesCada sistema empresarial (tambin llamado funcin empresarial) est compuesto de uno o ms procesos empresariales, y cada proceso empresarial se define mediante un conjunto de subprocesos.La RPE puede aplicarse en cualquier nivel de la jerarqua, pero conforme se ensancha su mbito (es decir, conforme se avanza hacia arriba en la jerarqua), los riesgos asociados con laRPE crecen de manera dramtica. Por esta razn, la mayora de los esfuerzos RPE se enfocan en procesos o subprocesos individuales.

Un modelo RPEComo la mayora de las actividades de ingeniera, la reingeniera de procesos de empresa es iterativa. Las metas de la empresa y los procesos que los logran deben adaptarse a un entorno empresarial cambiante. Por esta razn, no hay inicio ni fin de la RPE: es un proceso evolutivo.En la figura 29.1 se muestra un modelo para reingeniera de proceso de empresa. El modelo define seis actividades:

Definicin de la empresa. Las metas de la empresa se identifican dentro del contexto de cuatro motores clave: reduccin de costo, reduccin de tiempo, mejora de la calidad y desarrollo y fortalecimiento del personal. Las metas pueden definirse para toda la empresa o para un componente especfico de ella.Identificacin de procesos. Se identifican los procesos que son cruciales para lograr las metas definidas en la definicin de la empresa. Luego pueden clasificarse por importancia, por necesidad para cambiar o en cualquier otra forma que sea adecuada para la actividad de reingeniera.Evaluacin de procesos. Los procesos existentes se analizan y miden ampliamente. Se identifican las tareas de proceso, se anotan los costos y el tiempo consumido por ellas y se aslan los problemas de calidad/desempeo.Especificacin y diseo de procesos. Con base en la informacin obtenida durante las primeras tres actividades RPE, se preparan casos de uso (captulos 5 y 6) para cada proceso que deba someterse a reingeniera. Dentro del contexto de la RPE, los casos de uso identifican un escenario que entrega algn resultado a un cliente. Con el caso de uso como la especificacin del proceso, se disea un nuevo conjunto de tareas para el proceso.Prototipo. Un proceso empresarial rediseado debe convertirse en prototipo antes de que se integre plenamente en la empresa. Esta actividad pone a prueba el proceso, de modo que puedan hacerse refinamientos.Refinamiento y ejemplificacin. Con base en la realimentacin del prototipo, el proceso empresarial se refina y luego se ejemplifica dentro de un sistema empresarial.En ocasiones, dichas actividades RPE se usan en conjunto con herramientas de anlisis de flujo de trabajo. La intencin de dichas herramientas es construir un modelo del flujo de trabajo existente con la intencin de analizar mejor los procesos actuales.

REINGENIERA DE SOFTWARE.El escenario es demasiado comn: una aplicacin que atendi las necesidades empresariales de una compaa durante 10 o 15 aos. Durante ese tiempo se corrigi, adapt y mejor muchas veces. Las personas realizaban esta tarea con las mejores intenciones, pero las buenas prcticas de ingeniera siempre se hicieron a un lado (debido a la presin de otros asuntos). Ahora la aplicacin es inestable. Todava funciona, pero cada vez que se intenta un cambio, ocurren inesperados y serios efectos colaterales. Aun as, la aplicacin debe seguir evolucionando. Qu hacer?El software sin mantenimiento no es un problema nuevo. De hecho, el nfasis ampliado acerca de la reingeniera de software se produjo por los problemas de mantenimiento de software que se acumularon durante ms de cuatro dcadas.

Un modelo de proceso de reingeniera de softwareLa reingeniera toma tiempo, cuesta cantidades significativas de dinero y absorbe recursos que de otro modo pueden ocuparse en preocupaciones inmediatas. Por todas estas razones, la reingeniera no se logra en pocos meses o incluso en algunos aos. La reingeniera de los sistemas de informacin es una actividad que absorber recursos de tecnologa de la informacin durante muchos aos. Por esto, toda organizacin necesita una estrategia pragmtica para la reingeniera de software.Una estrategia factible se contempla en un modelo de proceso de reingeniera. Ms tarde, en esta seccin, se estudiar el modelo, pero primero se presentan algunos principios bsicos.La reingeniera es una actividad de reconstruccin. Para entenderla mejor, piense en una actividad anloga: la reconstruccin de una casa. Considere la siguiente situacin. Usted compra una casa en otro estado. En realidad nunca ha visto la propiedad, pero la adquiri a un precio sorprendentemente bajo, con la advertencia de que es posible que deba reconstruirla por completo. Cmo procedera? Antes de comenzar a reconstruir, parecera razonable inspeccionar la casa. Para determinar si necesita reconstruirse, usted (o un inspector profesional) crea una lista de criterios, de modo que su inspeccin sea sistemtica. Antes de demoler y reconstruir toda la casa, asegrese de que la estructura es dbil. Si la casa es estructuralmente slida, acaso sea posible remodelar sin reconstruir (a un costo mucho ms bajo y en mucho menos tiempo). Antes de comenzar a reconstruir, asegrese de entender cmo se construy la original.Eche un vistazo detrs de las paredes. Entienda cmo estn el alambrado, la plomera y la estructura interna. Incluso si tira todo a la basura, la comprensin que obtenga le servir cuando comience la construccin. Si comienza a reconstruir, use solamente los materiales ms modernos y ms duraderos. Esto puede costar un poco ms ahora, pero le ayudar a evitar costos y tardados mantenimientos posteriores. Si decide reconstruir, sea disciplinado en ello. Use prcticas que resultarn en alta calidad, hoy y en el futuro.Aunque estos principios se enfocan en la reconstruccin de una casa se aplican igualmente bien a la reingeniera de los sistemas y aplicaciones basados en cmputo.Para implementar estos principios puede usar un modelo de proceso de reingeniera de software que defina seis actividades, como se muestra en la figura 29.2. En algunos casos, dichas actividades ocurren en secuencia lineal, aunque no siempre. Por ejemplo, es posible que se tenga que recurrir a la ingeniera inversa (comprender el funcionamiento interno de un programa) antes de que pueda comenzar la reestructuracin de documentos.

Actividades de reingeniera de softwareEl paradigma de reingeniera que se muestra en la figura 29.2 es un modelo cclico. Esto significa que cada una de las actividades presentadas como parte del paradigma puede revisarse. Para algn ciclo particular, el proceso puede terminar despus de cualquiera de estas actividades.Anlisis de inventarios. Toda organizacin de software debe tener un inventario de todas las aplicaciones. El inventario puede ser nada ms que un modelo de hojas de clculo que contenga informacin que ofrezca una descripcin detallada (por ejemplo, tamao, edad, importancia empresarial) de cada aplicacin activa. Al ordenar esta informacin de acuerdo con importancia empresarial, longevidad, mantenibilidad actual, soportabilidad y otros importantes criterios locales, aparecen los candidatos para reingeniera. Entonces pueden asignarse recursos a esas aplicaciones.Es importante observar que el inventario debe revisarse con regularidad. El estado de las aplicaciones (por ejemplo, importancia empresarial) puede cambiar con el tiempo y, como resultado, cambiarn las prioridades para aplicar la reingeniera.Reestructuracin de documentos. La documentacin dbil es el distintivo de muchos sistemas heredados. Pero, qu puede hacer con ella? Cules son sus opciones?1. La creacin de documentacin consume demasiado tiempo. Si el sistema funciona puede elegir vivir con lo que tiene. En algunos casos, ste es el enfoque correcto. No es posible volver a crear documentacin para cientos de programas de cmputo. Si un programa es relativamente esttico, se aproxima al final de su vida til y es improbable que experimente cambio significativo, djelo as!2. La documentacin debe actualizarse, pero su organizacin tiene recursos limitados. Use un enfoque documente cuando toque. Acaso no sea necesario volver a documentar por completo una aplicacin. En vez de ello, aquellas porciones del sistema que en el momento experimenten cambio se documentan por completo. Con el tiempo, evolucionar una coleccin de documentacin til y relevante.3. El sistema tiene importancia empresarial y debe volver a documentarse por completo. Incluso en este caso, un enfoque inteligente es recortar la documentacin a un mnimo esencial.Cada una de estas opciones es viable. Su organizacin de software debe elegir aquella que sea ms adecuada para cada caso.Ingeniera inversa. El trmino ingeniera inversa tiene su origen en el mundo del hardware. Una compaa desensambla un producto de hardware de otra empresa con la intencin de entender los secretos de diseo y fabricacin de su competidor. Dichos secretos podran entenderse fcilmente si se obtuvieran las especificaciones de diseo y fabricacin. Pero esos documentos son propiedad de la empresa competidora y no estn disponibles para la compaa que hace la ingeniera inversa. En esencia, la ingeniera inversa exitosa deriva en una o ms especificaciones de diseo y fabricacin para un producto al examinar especmenes reales del mismo.La ingeniera inversa para el software es muy similar. No obstante, en la mayora de los casos, el programa que se va a someter a ingeniera inversa no es de un competidor: es el propio trabajo de la compaa (con frecuencia, elaborado muchos aos atrs). Los secretos por entender son oscuros porque jams se desarrollaron especificaciones. Por tanto, la ingeniera inversa para software es el proceso de analizar un programa con la intencin de crear una representacin del mismo en un nivel superior de abstraccin que el cdigo fuente. La ingeniera inversa es un proceso de recuperacin de diseo. Las herramientas de ingeniera inversa extraen informacin de diseo de datos, arquitectnico y procedimental de un programa existente.Reestructuracin de cdigo. El tipo ms comn de reingeniera (en realidad, en este caso es cuestionable el uso del trmino reingeniera) es la reestructuracin de cdigo.4 Algunos sistemas heredados tienen una arquitectura de programa relativamente slida, pero los mdulos individuales fueron codificados en una forma que los hace difciles de entender, poner a prueba y mantener. En tales casos, el cdigo dentro de los mdulos sospechosos puede reestructurarse.Para realizar esta actividad se analiza el cdigo fuente con una herramienta de reestructuracin.Las violaciones a los constructos de programacin estructurada se anotan y luego el cdigo se reestructura (esto puede hacerse automticamente) o incluso se reescribe en un lenguaje de programacin ms moderno. El cdigo reestructurado resultante se revisa y pone a prueba para garantizar que no se introdujeron anomalas. La documentacin de cdigo interna se actualiza.Reestructuracin de datos. Un programa con arquitectura de datos dbil ser difcil de adaptar y mejorar. De hecho, para muchas aplicaciones, la arquitectura de informacin tiene ms que ver con la viabilidad a largo plazo de un programa que con el cdigo fuente en s.A diferencia de la reestructuracin de cdigo, que ocurre en un nivel de abstraccin relativamente bajo, la reestructuracin de datos es una actividad de reingeniera a gran escala. En la mayora de los casos, la reestructuracin de los datos comienza con una actividad de ingeniera inversa. La arquitectura de datos existente se diseca y se definen modelos de datos necesarios (captulos 6 y 9). Se identifican los objetos y atributos de datos, y se revisa la calidad de las estructuras de datos existentes.Cuando la estructura de datos es dbil (por ejemplo, si se implementan archivos planos, cuando un enfoque relacional simplificara enormemente el procesamiento), los datos se someten a reingeniera.Puesto que la arquitectura de datos tiene una fuerte influencia sobre la arquitectura del programa y sobre los algoritmos que los pueblan, los cambios a los datos invariablemente resultarn en cambios arquitectnicos o en el nivel de cdigo.Ingeniera hacia adelante. En un mundo ideal, las aplicaciones se reconstruiran usando unmotor de reingeniera automtico. El programa antiguo se alimentara en el motor, se analizara, se reestructurara y luego se regenerara de manera que mostrara los mejores aspectos de la calidad del software. A corto plazo es improbable que tal motor aparezca, pero los proveedores introdujeron herramientas que proporcionan un subconjunto limitado de dichas capacidades y que abordan dominios de aplicacin especficos (por ejemplo, aplicaciones que se implementan usando un sistema de base de datos especfico). Ms importante, dichas herramientas de reingeniera se vuelven cada vez ms sofisticadas.La ingeniera hacia adelante no slo recupera informacin de diseo del software existente, sino que tambin usa esta informacin para alterar o reconstituir el sistema existente con la intencin de mejorar su calidad global. En la mayora de los casos, el software sometido a reingeniera vuelve a implementar la funcin del sistema existente y tambin aade nuevas funciones y/o mejora el rendimiento global.

INGENIERA INVERSALa ingeniera inversa conjura una imagen de la rendija mgica. Usted alimenta en la rendija un archivo fuente sin documentar, diseado de manera fortuita, y del otro lado sale una descripcin y documentacin completas del diseo para el programa de cmputo. Por desgracia, la rendija mgica no existe. La ingeniera inversa puede extraer informacin de diseo a partir del cdigo fuente, pero el nivel de abstraccin, la completitud de la documentacin, el grado en el que las herramientas y un analista humano trabajan en conjunto, y la direccionalidad del proceso son enormemente variables.El nivel de abstraccin de un proceso de ingeniera inversa y las herramientas usadas para efectuarla tienen que ver con la sofisticacin de la informacin de diseo que puede extraerse del cdigo fuente. De manera ideal, el nivel de abstraccin debe ser tan alto como sea posible, es decir, el proceso de ingeniera inversa debe ser capaz de inferir representaciones de diseo procedimental (una abstraccin de bajo nivel), informacin de estructura de programa y datos (un nivel de abstraccin un poco ms alto), modelos de objeto, modelos de datos y/o flujo de control (un nivel de abstraccin relativamente alto) y modelos de relacin de entidad (un nivel de abstraccin alto). Conforme aumenta el nivel de abstraccin se proporciona informacin que permitir facilitar la comprensin del programa.La completitud de un proceso de ingeniera inversa se refiere al nivel de detalle que se proporciona en un nivel de abstraccin. En la mayora de los casos, la completitud disminuye conforme aumenta el nivel de abstraccin. Por ejemplo, dada una lista de cdigo fuente, es relativamente sencillo desarrollar una representacin de diseo procedimental completa. Tambin pueden inferirse representaciones de diseo arquitectnico simples, pero es mucho ms difcil desarrollar un conjunto completo de diagramas o modelos UML.La completitud mejora en proporcin directa a la cantidad de anlisis realizado por la persona efecta la ingeniera inversa. La interactividad tiene que ver con el grado en el que el ser humano se integra con las herramientas automatizadas para crear un proceso de ingeniera inversa efectivo. En la mayora de los casos, conforme aumenta el nivel de abstraccin, la interactividad debe aumentar o decaer la completitud.Si la direccionalidad del proceso de ingeniera inversa es de una va, toda la informacin extrada del cdigo fuente se proporciona al ingeniero de software que luego puede usarla, durante cualquier actividad de mantenimiento. Si la direccionalidad es de dos vas, la informacin se alimenta a una herramienta de reingeniera que intenta reestructurar o regenerar el programa antiguo.

El proceso de ingeniera inversa se representa en la figura 29.3. Antes de poder comenzar las actividades de ingeniera inversa, el cdigo fuente no estructurado (sucio) se reestructura (seccin 29.5.1) de modo que slo contenga los constructos de programacin estructurados.5Esto hace que el cdigo fuente sea ms fcil de leer y que proporcione la base para todas las actividades de ingeniera inversa posteriores.El ncleo de la ingeniera inversa radica en una actividad llamada extraccin de abstracciones.Debe evaluar el programa antiguo y, a partir del cdigo fuente (con frecuencia no documentado), desarrollar una especificacin significativa del procesamiento que se realiza, de la interfaz de usuario que se aplica y de las estructuras de datos del programa o de la base de datos que se usa.Ingeniera inversa para comprender datosLa ingeniera inversa de datos ocurre en diferentes niveles de abstraccin y con frecuencia es la primera tarea de reingeniera. En el nivel del programa, las estructuras de datos internas del programa con frecuencia deben someterse a ingeniera inversa como parte de un esfuerzo de reingeniera global. En el nivel del sistema, las estructuras de datos globales (por ejemplo, archivos, bases de datos) con frecuencia se someten a reingeniera para acomodar nuevos paradigmas de administracin de base de datos (por ejemplo, moverse de un archivo plano a sistemas de bases de datos relacionales u orientadas a objetos). La ingeniera inversa de las estructuras de datos globales actuales monta el escenario para la introduccin de una nueva base de datos en todo el sistema.Estructuras de datos internas. Las tcnicas de ingeniera inversa para datos internos del programa se enfocan en la definicin de clases de objetos. Esto se logra al examinar el cdigo del programa con la intencin de agrupar variables del programa relacionadas. En muchos ca sos, la organizacin de datos dentro del cdigo identifica tipos de datos abstractos. Por ejemplo, el registro de estructuras, archivos, listas y otras estructuras de datos con frecuencia proporciona un indicador inicial de clases.

Estructura de la base de datos. Sin importar su organizacin lgica y su estructura fsica, una base de datos permite la definicin de objetos de datos y soporta algn mtodo para establecer relaciones entre los objetos. Por tanto, la reingeniera de un esquema de base de datos en otro nuevo requiere comprender los objetos existentes y sus relaciones.Puede usar los siguientes pasos [Pre94] para definir el modelo de extraccin de datos como precursor de la reingeniera de un nuevo modelo de base de datos: 1) construir un modelo de objeto inicial, 2) determinar claves candidatas (los atributos se examinan para determinar si se usan para apuntar hacia otro registro o tabla; los que funcionan como punteros se convierten en clases candidatas), 3) refinar las clases tentativas, 4) definir generalizaciones y 5) descubrir asociaciones usando tcnicas que sean anlogas al enfoque CRC. Una vez que se conoce la informacin definida en los pasos anteriores, puede aplicarse una serie de transformaciones[Pre94] para mapear la antigua estructura de la base de datos en una nueva estructura.

Ingeniera inversa para entender el procesamientoLa ingeniera inversa para entender el procesamiento comienza con un intento por comprender y luego extraer abstracciones procedimentales representadas mediante el cdigo fuente.Para comprender las abstracciones procedimentales se analiza el cdigo en varios niveles de abstraccin: sistema, programa, componente, patrn y enunciado.La funcionalidad global de todo el sistema de aplicacin debe entenderse antes de que ocurra trabajo de ingeniera inversa ms detallado. Esto establece el contexto para un mayor anlisis y proporciona comprensin acerca de los conflictos de interoperabilidad entre aplicaciones dentro del sistema. Cada uno de los programas que constituyen el sistema de aplicacin representa una abstraccin funcional en un nivel alto de detalle. Se crea un diagrama de bloques, que representa la interaccin entre dichas abstracciones funcionales. Cada componente realiza alguna subfuncin y representa una abstraccin procedimental definida. Se desarrolla una narrativa de procesamiento para cada componente. En algunas situaciones, ya existen especificaciones de sistema, programa y componente. Cuando ste es el caso, las especificaciones se revisan para conformarse con el cdigo existente.6Las cosas se vuelven ms complejas cuando se considera el cdigo dentro de un componente.Debe buscar secciones de cdigo que representen patrones procedimentales genricos.En casi todo componente, una seccin de cdigo prepara los datos para procesamiento (dentro del mdulo), una seccin diferente del cdigo realiza el procesamiento y otra prepara los resultados del procesamiento para exportarlos desde el componente. Dentro de cada una de esas secciones, pueden encontrarse patrones ms pequeos; por ejemplo, validacin de datos y comprobacin de enlaces que con frecuencia ocurren dentro de la seccin de cdigo que prepara los datos para procesamiento.Para sistemas grandes, la ingeniera inversa por lo general se logra usando un enfoque semiautomatizado. Es posible usar herramientas automatizadas para auxiliarse en la comprensin de la semntica del cdigo existente. La salida de este proceso pasa entonces a reestructuracin de herramientas de ingeniera hacia adelante a fin de completar el proceso de reingeniera.

Ingeniera inversa de interfaces de usuarioLas GUI (interfaces de usuario grficas) sofisticadas se han vuelto obligatorias para productos y sistemas basados en computadora de todo tipo. Por tanto, el redesarrollo de las interfaces de usuario se ha convertido en uno de los tipos ms comunes de actividad de reingeniera. Pero antes de poder reconstruir una interfaz de usuario, debe realizarse ingeniera inversa.Para comprender completamente una interfaz de usuario existente, deben especificarse la estructura y el comportamiento de la interfaz. Merlo et al. [Mer93] sugieren tres preguntas bsicas que deben responderse conforme comienza la ingeniera inversa de la UI. Cules son las acciones bsicas (por ejemplo, golpes de tecla y clics de ratn) que debe procesar la interfaz? Cul es la descripcin compacta de la respuesta de comportamiento del sistema a dichas acciones? Qu se entiende por reemplazo o, ms precisamente, qu concepto de equivalencia de interfaces es relevante aqu?La notacin de modelado de comportamiento (captulo 7) puede proporcionar un medio para desarrollar respuestas a las primeras dos preguntas. Mucha de la informacin necesaria para crear un modelo de comportamiento puede obtenerse al observar la manifestacin externa de la interfaz existente. Pero informacin adicional necesaria para crear el modelo de comportamiento debe extraerse del cdigo.Es importante observar que un reemplazo de GUI puede no reflejar con exactitud la antigua interfaz (de hecho, puede ser radicalmente diferente). Con frecuencia, vale la pena desarrollar una nueva metfora de interaccin. Por ejemplo, una antigua UI solicita que un usuario proporcione un factor de escala (que va de 1 a 10) para encoger o ampliar una imagen grfica. Una GUI sometida a reingeniera puede usar una barra de desplazamiento y ratn para lograr la misma funcin.

REESTRUCTURACINLa reestructuracin de software modifica el cdigo fuente y/o los datos con la intencin de hacerlos sensibles a cambios futuros. En general, la reestructuracin no modifica la arquitectura global del programa. Tiende a enfocarse sobre detalles de diseo de mdulos individuales y sobre estructuras de datos locales definidas dentro de mdulos. Si el esfuerzo de reestructuracin se extiende ms all de las fronteras del mdulo y abarca la arquitectura del software, la reestructuracin se convierte en ingeniera hacia adelante (seccin 29.7).La reestructuracin ocurre cuando la arquitectura bsica de una aplicacin es slida, aun cuando el interior tcnico necesite trabajarse. Se inicia cuando grandes partes del software son aprovechables y slo un subconjunto de todos los mdulos y datos necesitan modificacin extensa.

Reestructuracin de cdigoLa reestructuracin de cdigo se realiza para producir un diseo que produzca la misma funcin pero con mayor calidad que el programa original. En general, las tcnicas de reestructuracin de cdigo (por ejemplo, las tcnicas de simplificacin lgica de Warnier [War74]) modelan la lgica del programa usando lgebra booleana y luego aplican una serie de reglas de transformacin que producen lgica reestructurada. El objetivo es tomar una ensalada de cdigo y derivar un diseo procedimental que se conforme con la filosofa de programacin estructurada (captulo 10).Tambin se han propuesto otras tcnicas de reestructuracin para su uso con herramientas de reingeniera. Un diagrama de intercambio de recursos mapea cada mdulo de programa y los recursos (tipos de datos, procedimientos y variables) que se intercambiarn entre l y otros mdulos. Al crear representaciones de flujo de recursos, la arquitectura del programa puede reestructurarse para lograr un mnimo acoplamiento entre mdulos.Reestructuracin de datosAntes de que pueda comenzar la reestructuracin de datos debe realizarse una actividad de ingeniera inversa llamada anlisis de cdigo fuente. Se evalan todos los enunciados de lenguaje de programacin que contienen definiciones de datos, descripciones de archivo I/O y descripciones de interfaz. La intencin es extraer tems de datos y objetos, obtener informacin acerca del flujo de datos y entender las estructuras de datos existentes que se implementaron. Esta actividad en ocasiones se llama anlisis de datos.Una vez completado el anlisis de datos, comienza el rediseo de datos. En su forma ms simple, un paso de estandarizacin de registro de datos clarifica las definiciones de los datos para lograr consistencia entre nombres de tem de datos o formatos de registro fsico dentro de una estructura de datos existente o dentro de un formato de archivo. Otra forma de rediseo, llamada racionalizacin de nombre de datos, garantiza que todas las convenciones de nomenclatura de datos se establezcan de acuerdo con estndares locales y que los sobrenombres se eliminen conforme los datos fluyen a travs del sistema.Cuando la reestructuracin avanza ms all de la estandarizacin y la racionalizacin, se realizan modificaciones fsicas a las estructuras de datos existentes para hacer que el diseo de datos sea ms efectivo. Esto puede significar una traduccin de un formato de archivo a otro o, en algunos casos, traduccin de un tipo de base de datos a otra.

INGENIERA HACIA ADELANTEUn programa con flujo de control que sea el equivalente grfico de una olla de espagueti, conmdulos que tienen 2 000 enunciados de largo, con pocas lneas de comentarios significativos en 290 000 enunciados fuente y sin otra documentacin, debe modificarse para alojar los cambiantes requisitos de usuario. Se tienen las siguientes opciones:1. Para implementar los cambios necesarios puede luchar a travs de modificacin tras modificacin, combatir al diseo ad hoc y el cdigo fuente enredado.2. Puede intentar comprender los funcionamientos interiores ms amplios del programa con la intencin de hacer modificaciones de manera ms efectiva.3. Puede redisear, recodificar y poner a prueba aquellas porciones del software que requieran modificacin y aplicar un enfoque de ingeniera de software a todos los segmentos revisados.4. Puede redisear, recodificar y poner a prueba completamente el programa, y usar herramientas de reingeniera para ayudar a comprender el diseo actual.No hay una sola opcin correcta. Las circunstancias pueden dictar la primera opcin incluso si las otras son ms deseables.En lugar de esperar hasta recibir una solicitud de mantenimiento, la organizacin de desarrollo o soporte usa los resultados de un anlisis de inventario para seleccionar un programa: 1) que permanecer en uso durante un nmero preseleccionado de aos, 2) que en el momento se use con xito y 3) que tenga probabilidad de experimentar grandes modificaciones o aumentos en el futuro cercano. Entonces se aplican las opciones 2, 3 o 4. A primera vista, la sugerencia de que redesarrollo un programa grande cuando ya existe una versin operativa puede parecer muy extravagante. Antes de juzgar, considere los siguientes puntos:1. El costo de mantener una lnea de cdigo fuente puede ser 20 a 40 veces el costo del desarrollo inicial de dicha lnea.2. El rediseo de la arquitectura del software (programa y/o estructura de datos), con el uso de modernos conceptos de diseo, puede facilitar enormemente el mantenimiento futuro.3. Puesto que ya existe un prototipo del software, la productividad de desarrollo debe ser mucho ms alta que el promedio.4. Ahora el usuario experimenta con el software. Por tanto, pueden averiguarse con mayor facilidad los nuevos requisitos y la direccin del cambio.5. Las herramientas automatizadas para reingeniera facilitarn algunas partes de la labor.6. Existir una configuracin de software completa (documentos, programas y datos) al completar el mantenimiento preventivo.Un gran desarrollador interno de software (por ejemplo, un grupo de desarrollo de sistemas de software empresarial para una gran compaa de productos al consumidor) puede tener una produccin de 500 a 2 000 programas dentro de su dominio de responsabilidad. Dichos programas pueden clasificarse por importancia y luego revisarse como candidatos para ingeniera hacia adelante.El proceso de ingeniera hacia adelante aplica los principios, conceptos y mtodos de la ingeniera de software para volver a crear una aplicacin existente. En la mayora de los casos, la ingeniera hacia adelante no crea simplemente un equivalente moderno de un programa ms antiguo.En vez de ello, en el esfuerzo de reingeniera se integran nuevos requisitos de usuario y tecnologa. El programa redesarrollado extiende las capacidades de la aplicacin ms antigua.

Ingeniera hacia adelante para arquitecturas cliente-servidorDurante las dcadas pasadas, muchas aplicaciones de mainframe se sometieron a reingeniera para alojar arquitecturas cliente-servidor (incluidas las webapps). En esencia, los recursos de cmputo centralizados (incluido el software) se distribuyen entre muchas plataformas cliente.Aunque pueden disearse varios entornos distribuidos, la aplicacin mainframe tpica que se somete a reingeniera en una arquitectura cliente-servidor tiene las siguientes caractersticas: La funcionalidad de la aplicacin migra a cada computadora cliente. Se implementan nuevas interfaces GUI en los sitios cliente. Las funciones de base de datos se ubican en el servidor. La funcionalidad especializada (por ejemplo, anlisis con uso intenso de computadora) puede permanecer en el sitio servidor. Deben establecerse nuevos requisitos de comunicaciones, seguridad, archivado y control en los sitios cliente y servidor.Es importante observar que la migracin de mainframe a cmputo cliente-servidor requiere reingeniera tanto de la empresa como del software. Adems, debe establecerse una infraestructura de red empresarial [Jay94].La reingeniera para aplicaciones cliente-servidor comienza con un profundo anlisis del entorno empresarial que abarca el mainframe existente. Pueden identificarse tres capas de abstraccin.La base de datos que se asienta en los cimientos de una arquitectura cliente-servidor gestiona las transacciones y consultas de aplicaciones del servidor. Aunque dichas transacciones y consultas deben controlarse dentro del contexto de un conjunto de reglas empresariales (definidas por un proceso empresarial existente o de reingeniera), las aplicaciones cliente proporcionan funcionalidad dirigida a la comunidad usuaria.Las funciones del sistema de gestin de base de datos existente y la arquitectura de datos de la base de datos existente deben someterse a ingeniera inversa como precursor del rediseo de la capa cimiento de la base de datos. En algunos casos, se crea un nuevo modelo de datos (captulo 6). En todo caso, la base de datos cliente-servidor se somete a reingeniera para garantizar que las transacciones se ejecutan en forma consistente, que todas las actualizaciones se realizan slo por usuarios autorizados, que las reglas empresariales ncleo se refuerzan (por ejemplo, antes de borrar el registro de un vendedor, el servidor se asegura de que no existan cuentas por pagar, contratos o comunicaciones para dicho proveedor), que las consultas puedan acomodarse de manera eficiente y que se establece la capacidad completa de archivado.Las capas de reglas empresariales representan software residente tanto en el cliente como en el servidor. Este software realiza tareas de control y coordinacin para garantizar que las transacciones y consultas entre la aplicacin cliente y la base de datos se conforman con el proceso empresarial establecido.Las capas de aplicaciones cliente implementan funciones empresariales que requieren grupos especficos de usuarios finales. En muchas instancias, una aplicacin mainframe se segmenta en algunas aplicaciones de escritorio ms pequeas sometidas a reingeniera. La comunicacin entre aplicaciones de escritorio (cuando sea necesario) se controla mediante la capa de reglas empresariales.Un anlisis profundo del diseo y reingeniera de software cliente-servidor se deja para libros dedicados a la materia. Si tiene ms inters, consulte [Van02], [Cou00] u [Orf99].Ingeniera hacia adelante para arquitecturas orientadas a objetosLa ingeniera de software orientada a objetos se ha convertido en el paradigma de desarrollo elegido por muchas organizaciones de software. Pero, qu hay de las aplicaciones existentes que se desarrollaron usando mtodos convencionales? En algunos casos, la respuesta es dejar tales aplicaciones como estn. En otras, las aplicaciones antiguas deben someterse a reingeniera, de modo que puedan integrarse con facilidad en sistemas grandes orientados a objetos.La reingeniera de software convencional en una implementacin orientada a objeto usa muchas de las mismas tcnicas estudiadas en la parte 2 de este libro. Primero, el software existente se somete a ingeniera inversa para que puedan crearse modelos adecuados de datos, funciones y comportamientos. Si el sistema sometido a reingeniera extiende la funcionalidad o comportamiento de la aplicacin original, se crean casos de uso (captulos 5 y 6). Los modelos de datos creados durante la ingeniera inversa se usan entonces en conjuncin con el modeladoCRC (captulo 6) para establecer la base para la definicin de clases. Se definen entonces las jerarquas de clase, modelos objeto-relacional, modelos objeto- comportamiento y subsistemas, y se comienza el diseo orientado a objetos.Conforme avanza la ingeniera hacia adelante orientada a objetos desde el anlisis hacia el diseo, puede invocarse un modelo de proceso ISBC (captulo 10). Si la aplicacin existente reside dentro de un dominio que ya est poblado con muchas aplicaciones orientadas a objetos, es probable que exista una robusta librera de componentes y que pueda usarse durante la ingeniera hacia adelante.Para aquellas clases que deban someterse a ingeniera desde cero, es posible reutilizar algoritmos y estructuras de datos de la aplicacin convencional existente. No obstante, las mismas deben redisearse para estar de acuerdo con la arquitectura orientada a objetos.

ECONOMA DE LA REINGENIERAEn un mundo perfecto, todo programa no mantenible se retirara de inmediato para sustituirlo con aplicaciones sometidas a reingeniera de alta calidad desarrolladas mediante modernas prcticas de ingeniera de software. Pero se vive en un mundo de recursos limitados. La reingeniera gasta recursos que pueden usarse para otros propsitos empresariales. Por tanto, antes de que una organizacin intente someter a reingeniera una aplicacin existente, debe realizar un anlisis costo-beneficio. Sneed [Sne95] propone un modelo de anlisis costo-beneficio para reingeniera, definiendo nueve parmetros:P1 _ costo de mantenimiento anual actual para una aplicacinP2 _ costo de operaciones anuales actuales para una aplicacinP3 _ valor empresarial anual actual de una aplicacinP4 _ costo de mantenimiento anual predicho despus de reingenieraP5 _ costo de operaciones anuales predichas despus de reingenieraP6 _ valor empresarial anual predicho despus de reingenieraP7 _ costo de reingeniera estimadoP8 _ tiempo calendario de reingeniera estimadoP9 _ factor de riesgo de reingeniera (P9 _ 1.0 es nominal)L _ vida esperada del sistemaEl costo asociado con el mantenimiento continuo de una aplicacin candidata (es decir, la reingeniera no se realiza) puede definirse comoCmant _ [P3 _ (P1 _ P2)] _ L (29.1)El costo asociado con reingeniera se define usando la siguiente relacin:Creing _ P6 _ (P4 _ P5) _ (L _ P8) _ (P7 _ P9) (29.2)Con los costos presentados en las ecuaciones 29.1 y 29.2, el beneficio global de la reingeniera puede calcularse comoBeneficio en costo _ Creing _ Cmant (29.3)El anlisis costo-beneficio que se presenta en estas ecuaciones puede realizarse para todas las aplicaciones de alta prioridad identificadas durante el anlisis de inventario (seccin 29.4.2).Aquellas aplicaciones que muestren el mayor costo-beneficio pueden marcarse para reingeniera, mientras que el trabajo sobre otras puede posponerse hasta que haya recursos disponibles.

RESUMENEl mantenimiento y soporte del software son actividades en marcha que ocurren a lo largo de todo el ciclo de vida de una aplicacin. Durante dichas actividades se corrigen defectos, se adaptan aplicaciones a un entorno operativo o empresarial cambiante, se implementan mejoras a peticin de los participantes y se da soporte a los usuarios conforme integran una aplicacin en su flujo de trabajo personal o empresarial.La reingeniera ocurre en dos niveles de abstraccin diferentes. En el nivel empresarial, la reingeniera se enfoca en el proceso empresarial con la intencin de realizar cambios para mejorar la competitividad en alguna rea de la empresa. En el nivel de software, la reingeniera examina los sistemas y aplicaciones de informacin con la intencin de reestructurar o reconstruirlos de modo que muestren mayor calidad.La reingeniera de procesos empresarial define las metas de la empresa, identifica y evala los procesos empresariales existentes (en el contexto de metas definidas), especifica y disea procesos revisados y crea prototipos, los refina y ejemplifica dentro de una empresa. La RPE representa un enfoque que se extiende ms all del software. El resultado de la RPE con frecuencia es la definicin de formas en las que las tecnologas de la informacin pueden apoyar mejor a la empresa.La reingeniera de software abarca una serie de actividades que incluyen anlisis de inventario, reestructuracin de documentos, ingeniera inversa, reestructuracin de programa y datos e ingeniera hacia adelante. La intencin de dichas actividades es crear versiones de programas existentes que muestren mayor calidad y mejor mantenibilidad, mismos que sern viables bien entrado el siglo XXI.El costo-beneficio de la reingeniera puede determinarse de manera cuantitativa. El costo del status quo, es decir, el costo asociado con el soporte y mantenimiento actuales de una aplicacin existente, se compara con los costos de proyectos de la reingeniera y con la reduccin resultante en costos de mantenimiento y soporte. En casi todos los casos en los que un programa tenga una vida larga y en el momento muestre pobre mantenibilidad o soportabilidad, la reingeniera representa una estrategia empresarial efectiva en costo.CUANDO HACER REINGENIERA. Cuando los cambios del sistemas son necesarios en solo una parte. Cuando el soporte de hardware o software se hacen obsoletos. Cuando las herramientas para soportar la reestructuracin estn disponibles.

FODA.

Fortalezas

Tener informacin en la web de universidades, PDF de mucha ayuda.

Leer en los libros y encontrando informacin.

Oportunidades

Saber qu tipos de mantenimientos existe para un determinado software. Tener conocimientos sobre reingeniera de software e ingeniera inversa.

Debilidades

Tener una informacin errada y conocerla en el momento de la consulta.

Dejarnos llevar por alguna informacin que no est bien planteada.

Amenazas

Mucha informacin en la web y no saber cul sera la correcta.

No saber cul es la informacin real.

Estrategia

Redactar la informacin.

Entender los conceptos de diferentes temas a tratar.

Aprendizaje

La importancia de mantenimiento y reingeniera de software.

CONCLUSIONESEl software siempre ha sido y ser lo que le puede dar vida y plusvala a la computacin; sin el software, las computadoras seran inservibles y no podran ser utilizadas para ningn beneficio. Es el software el que realiza los procesos necesarios a los datos introducidos para as obtener nuevos datos con los que se pueden tomar decisiones, en muchos de los casos, decisiones crticas. Conforme pasa el tiempo, hemos visto que las computadoras son utilizadas en casi todos los aspectos de la vida del ser humano, hoy en da se ven computadoras en los bancos, tiendas, automviles, oficinas gubernamentales, empresas privadas, el hogar y en un futuro cercano hasta en el propio cuerpo humano. Esta simbiosis que el ser humano ha realizado con la computadora es debida en gran parte a que el software, aprovechando la velocidad con que las computadoras pueden procesar datos y arrojar resultados, facilita y agiliza las tareas del hombre.La reingeniera no es una actividad que se lleva a cabo de la noche a la maana, adems implica una gran inversin de esfuerzo, tiempo y recursos. Es por ello que es necesario planear de una manera muy cuidadosa todo el proceso. Este proceso se inicia con la justificacin del proyecto de reingeniera, en el cual se tiene que analizar cada sistema candidato para as obtener una lista de aplicaciones ordenada segn sus prioridades. Una vez obtenida la lista, se hace la estimacin de costes que sern necesarios para modificar todos los componentes. Por ltimo se comparan los costes con los beneficios esperados.En la reingeniera de software existen mtodos y modelos que permiten que esta actividad se pueda desarrollar de una manera bien direccionada para poder crear una nueva aplicacin con un alto nivel de calidad, fiabilidad y plusvala. En estos mtodos y modelos se puede observar varios puntos en comn siendo uno de los ms importantes la "reconstruccin de la arquitectura", ya que esta es la que nos va a brindar la compresin del sistema al que se le va aplicar reingeniera para poder crear una clara imagen de lo que se va a redisear y as poder planificar las actividades que se llevaran a cabo durante toda la actividad de reingeniera.

RECOMENDACIONESSe recomienda que en toda organizacin el desarrollo de software siempre este en un proceso continuo de evolucin, Esto es muy palpable en el ser humano, nadie va a llegar a este mundo sabiendo caminar, este es un proceso en el que se tienen que sufrir tropiezos y cadas, pero que al paso de los aos se logra dominar. En los primeros aos del desarrollo del software, este fue hecho sin tener absolutamente ningn tipo de conocimiento ni estrategia que permitiera el buen desarrollo, estos aos son conocidos como la "crisis de software". Los sistemas que fueron desarrollados en estos aos se fueron convirtiendo en parte vital de muchas organizaciones, por lo que se vea la constante necesidad de corregirlos, estas correcciones seguan ejecutndose de una manera no muy convenientes, generando as nuevos errores o poco a poco haciendo imposible la correccin de los sistemas.Se recomienda el mantenimiento y reingeniera de software ya que pretende terminar de una vez por todas con la vida til del sistema, no sin antes extraer de l la mayor parte del conocimiento que pueda brindar, conocimientos que sern utilizados para crear un nuevo Y por ltimo es recomendable documentar la arquitectura de un sistema. Si la documentacin existente o disponible es obsoleta, la recuperacin de la arquitectura puede ser utilizada como base para la redocumentacin de la arquitectura. La representacin de la arquitectura tambin puede ser usada como punto de partida para la reingeniera del sistema. Por ltimo, esta representacin puede ser til para identificar la funcionalidad de los componentes para reutilizarlos o establecerlos como la arquitectura base.

BIBLIOGRAFIA

Gestin de la Calidad del Softwarepg. 20