Vous êtes sur la page 1sur 15

INSTITUTO TECNOLOGICO DE TUXTEPEC

INFORME SOBRE LAS DIFERENTES METODOLOGIAS DE LA REINGENIERIA DEL SOFTWARE CARRERA: ING. SISTEMAS COMPUTACIONALES MATERIA: REINGENIERIA DEL SOFTWARE

PRESENTA: 08350619 08350626 RAMON DOMINGUEZ iris_bella_31@hotmail.com IRIS DEL CARMEN JUAREZ AGUSTIN eli03_jan@hotmail.com ELIZABETH DOMINGUEZ MOJICA XOCHILT MONSERRAT JARQUIN ABDIEL GONZALEZ zero_jga@hotmail.com

08350635

083506

Marzo 2012

INDICE

INDICE.2 INTRODUCCION...3 ANALISIS DE OPCIONES PARA REINGENIERIA (OAR)..4 MODELO HERRADURA.. 7 MODELO CICLICO..... 11 CONCLUSION......... 14 BIBLIOGRAFIA.... 15

INTRODUCCION

Existen varios mtodos y modelos que son utilizados para llevar a cabo de manera satisfactoria la actividad de reingeniera. La metodologa surge como consecuencia de la aplicacin de procesos de reingeniera del software tradicionales, sobre una aplicacin cientfica de considerables dimensiones y por la no consecucin de buenos resultados mediante esas tcnicas, que en la mayora de los casos cuenta con una probada validez, pero que aplicadas al tipo de aplicacin del caso de estudio no fueron satisfactorias

Este texto explica de una forma muy breve los mtodos y modelos que son utilizados para llevar a cabo de manera satisfactoria la actividad de reingeniera. Al comienzo del texto se alude al mtodo de anlisis de opciones para reingeniera (OAR por sus siglas en ingles de Options Analysis for Reingeneering) dando su definicin y explicando la necesidad de aplicarlo, se menciona de forma breve las actividades principales y especializadas de este mtodo as como la estructura de ellas. En los siguientes dos subtemas se trata a dos modelos utilizados para la reingeniera: El modelo herradura y el modelo cclico, explicando brevemente los niveles o actividades de cada uno.

ANLISIS DE OPCIONES PARA REINGENIERA (OAR)


OAR es un mtodo sistemtico, de arquitectura central y de toma de decisiones para la identificacin y extraccin de componentes dentro de grandes y complejos sistemas de software. La extraccin envuelve rehabilitacin de partes de un sistema viejo para su reso. OAR identifica componentes de arquitectura potencialmente relevantes y analiza los cambios requeridos para usarlos en una lnea de produccin de software o nuevas arquitecturas de software. En esencia, OAR proporciona un conjunto de opciones de extraccin junto con estimacin de costos, esfuerzo y riesgos asociados con estas opciones. El mtodo OAR consiste de cinco actividades principales con tareas escalables. Esas tareas son representadas en la Figura 1.

Anlisis de las opciones de reingeniera (OAR) es un proceso sistemtico, centrado en la arquitectura. Cinco OAR las actividades de identificar los componentes potenciales, estimar el costo de la minera, y evaluar el esfuerzo necesario para reutilizar los componentes existentes. OAR revela implcita

supuestos interesados, restricciones y otros conductores principales que afectan a la minera de los componentes, sobre esta compleja tarea. dando as a los administradores informacin

Las cinco principales actividades se describen a continuacin: 1.- Establecimiento del contexto de extraccin (ECE). Es importante para el equipo de OAR entender el contexto para la extraccin. Cmo un resultado, la primer actividad de OAR consiste en entrevistar a los accionistas y estudiar la lnea de produccin de la organizacin o nuevos requerimientos de sistema, base heredada y expectativas para la extraccin de componentes heredados. Estos esfuerzos establecen una lnea base de un conjunto de metas, expectaciones y necesidades de componentes. Esto tambin descubre los controladores de programa y tcnicos para la toma de decisiones. 2.- Inventario De Componentes (IC). Despus del ECE, el equipo OAR identifica los componentes del sistema heredado que potencialmente pueden ser extrados para usarlos en una lnea de produccin o en una nueva arquitectura de software. Durante esta actividad, los miembros del equipo identifican componentes de lneas de produccin necesarios y evalan los componentes heredados basados en esos criterios. Aquellos que no descubran los criterios estn incapacitados para continuar con el proceso de reingeiera. Esta actividad resulta en un inventario de los componentes heredados candidatos. La actividad de IC tiene seis tareas: 1. Identificar caractersticas de los componentes necesarios 2. Identifica las caractersticas satisfactorias de los componentes: 3. Compara las necesidades de componentes: 4. Inventario de componentes candidatos: 5. Produce tpicos de extraccin 6. Revisin del calendario OAR:

3.- Anlisis de componentes candidatos (ACC). El siguiente paso de los miembros del equipo es analizar el conjunto de candidatos de componentes heredados para extraer los tipos de cambios que son requeridos. Esta actividad tiene seis tareas: 1. Seleccin de componentes deseables. 2. Identifica los componentes "Tal como estn y de caja negra" 3. Identifica componentes de caja blanca. 4. Determina cambios requeridos: 5. Produccin de tpicos de extraccin: 6. Revisa el calendario OAR: 4 Plan de opciones de extraccin (POE). Dado el conjunto de componentes candidatos analizados, el equipo desarrollar alternativas para la extraccin basada en consideraciones de calendario, costo, esfuerzo, riesgo y recursos. El equipo OAR tambin filtra una vez ms los componentes candidatos y analiza el impacto de agregacin de diferentes componentes. El POE tiene siete tareas: 1. Selecciona componentes favorables: 2. Ejecucin de intercambio de componentes: 3. Forma opciones de componentes: 4. Determina costos comparativos y esfuerzos: 5. Analiza dificultad o riesgo: 6. Produccin de tpicos de extraccin: 7. Revisa el calendario OAR: 5 Seleccin de opciones de extraccin (SOE). Finalmente, los miembros del equipo seleccionan la mejor opcin de extraccin o combinacin de opciones para programas y consideraciones tcnicas. Despus de

evaluar cada opcin de extraccin, ellos preparan un resumen que presenta y justifica sus elecciones. La actividad SOE tiene cinco tareas: 1. Elegir la mejor opcin: 2. Verificacin de opcin: 3. Identifica componentes necesarios satisfechos. 4. Presentacin de descubrimientos. 5. Produccin de resumen.

EL MODELO HERRADURA
Los tres procesos bsicos: anlisis de un sistema existente, transformacin lgica y desarrollo de un nuevo sistema, forman la base del modelo de herradura. Como puede observarse en la Figura 2, el primer proceso sube el extremo izquierdo de la herradura, el segundo cruza la parte superior y el tercero baja por el extremo derecho de la herradura. La riqueza del modelo de herradura son los tres niveles de abstraccin que pueden ser dotados para las descripciones lgicas. Conceptualmente, este puede ser a travs de un conjunto de herraduras anidadas. Las descripciones lgicas pueden ser artefactos tan concretos y simples como el cdigo fuente del sistema o tan complejos y abstractos como la arquitectura del sistema. El propsito de la metfora visual es para integrar las vistas de reingeniera a nivel de cdigo y arquitectnico del mundo

En su ms pura y completa forma, el primer proceso recupera la arquitectura por medio de la extraccin de artefactos desde el cdigo fuente. Esta estructura recuperada es analizada para determinar si esta se adapta a la arquitectura antes diseada. La arquitectura descubierta tambin es evaluada con respecto a un nmero de calidad de atributos tales como rendimiento, modificabilidad, seguridad o confiabilidad. El segundo proceso es la transformacin de arquitectura. En este caso, la arquitectura antes construida es recuperada y es reingeniera para hacerla una nueva arquitectura deseable. Esta es reevaluada contra las metas de calidad del sistema y sujetas a otras restricciones organizacionales y econmicas. El tercer proceso del modelo de herradura usa el "Architecture-Based Development (ABD)" [Bass99] para ejemplificar la arquitectura deseable. En este proceso, ya empaquetados los tpicos son decididas e interconectadas las estrategias elegidas. Los artefactos a nivel de cdigo del sistema de informacin heredado son normalmente tapados o reescritos para adaptarlos dentro de la nueva arquitectura.

Hay tres niveles de la herradura: 1. "Code-estructura de la representacin", que incluye el cdigo fuente y los artefactos tales como rboles de sintaxis abstracta (AST) y grficos de flujo

obtenida a travs de anlisis y memoria operaciones analticas. En el nivel de cdigo existen dos sub-niveles, transformacin textual (o basado en cadena) y transformacin basado en el rbol de sintaxis. Mientras algunos mtodos hacen distinciones entre transformaciones "1A" textual (sintctico) y "1B" AST-based (semntico), el modelo herradura los considera a ambos dentro del contexto de estructura de cdigo. 2. "La funcin de nivel de representacin", que describe la relacin entre el

programas de funciones (llamadas, por ejemplo), los datos (la funcin y las relaciones de datos) y los archivos (Agrupaciones de funciones y datos). Transformaciones a nivel funcional (nivel "2") tiene que ver con el re-empaquetado de funcionalidad (por ejemplo, migrar desde un diseo funcional a un diseo orientado a objeto o migrar desde un modelo de base de datos relacional a un modelo orientado objeto). La encapsulacin de un modulo de funcionalidad por un diferente ambiente, es un ejemplo de transformacin a nivel funcional. Transformaciones a nivel funcional va ms all de simples transformaciones a la estructura del cdigo, pero no va ms all que una transformacin de arquitectura. Ellos son elegidos cuando grandes unidades de funcionalidad pueden ser salvados ponindolos dentro de un nuevo contexto. 3. "Concepto" de nivel, lo que representa grupos de la funcin y artefactos de cdigo de alto nivel que se montan en los subsistemas de componentes

relacionados con la arquitectura o los conceptos. Las transformaciones a nivel de arquitectura (nivel "3") involucran cambios a los bloques bsicos de la arquitectura. Estos incluyen los modelos bsicos de interaccin incluyendo los tipos de componentes, los conectores usados, la asignacin de funcionalidad y el modelo en tiempo de ejecucin de control y datos. El nivel de arquitectura es el ms abstracto y lejos del alcance de las transformaciones. Las transformaciones a nivel de arquitectura son hechas
9

cuando es necesario un cambio a la estructura principal debido a las principales modificaciones o deficiencias en los sistemas de informacin heredados. Las transformaciones generalmente traen mayores compromisos de tiempo y recursos, pero tambin trae consigo grandes beneficios.

Interaccin entre niveles. Las transformaciones a la estructura del cdigo se pueden dar sin hacer cambios de nivel funcional o cambios a la arquitectura. Las transformaciones del nivel ms bajo soportan las transformaciones de niveles ms altos. Con esta vista multi-nivel de transformaciones, las transformaciones a la arquitectura son normalmente el contexto en los cuales toman parte niveles ms bajos. Sin embargo, las transformaciones de nivel superior no soportan transformaciones de nivel bajos porque esas transformaciones se pueden dar independientemente de las transformaciones de niveles superiores. De hecho, uno de los principales propsitos del modelo herradura es elevar el nivel de abstraccin y brindar noticiones de la arquitectura para las tareas de reingeniera.

10

MODELO CCLICO
Este modelo propuesto en define seis actividades, las cuales se muestran en la Figura 4. En algunas ocasiones, estas actividades se producen de forma secuencial y lineal, pero esto no siempre es as. Por ejemplo, puede ser que la ingeniera inversa (la comprensin del funcionamiento interno de un programa) tenga que producirse antes de que pueda comenzar la reestructuracin de documentos.

Actividades que se definen en el modelo cclico: Anlisis de inventario, Reestructuracin de documentos, Ingeniera inversa, Reestructuracin de cdigo, Reestructuracin de datos e Ingeniera directa. 1 Anlisis de inventario. Todas las organizaciones de software debern disponer de un inventario de todas sus aplicaciones. El inventario puede que no sea ms que una hoja de clculo con la informacin que proporciona una descripcin detallada (de todas las aplicaciones activas.

11

Es importante destacar que el inventario deber revisarse con regularidad. El estado de las aplicaciones puede cambiar en funcin del tiempo y, como resultado, cambiarn tambin las prioridades para la reingeniera. 2 Reestructuracin de documentos. Una documentacin escasa es la marca de muchos sistemas de informacin heredados. Qu se puede hacer al respecto?

Opcin 1: La creacin de documentacin consume muchsimo tiempo. El sistema funciona, y ya nos ajustaremos con lo que se tiene.

Opcin 2: Es preciso actualizar la documentacin, pero se dispone de recursos limitados. Se utilizar un enfoque "del tipo documentar si se modifica Ms bien se documentarn por completo aquellas partes del sistema que estn experimentando cambios en ese momento. La coleccin de documentos til y relevante ir evolucionando con el tiempo.

Opcin 3: El sistema es fundamental para el negocio, y es preciso volver a documentarlo por completo. En este caso, un enfoque inteligente consiste en reducir la documentacin al mnimo necesario. 3 Ingeniera inversa. En esencia, una ingeniera inversa con xito precede de una o ms especificaciones de diseo y fabricacin para el producto, mediante el examen de ejemplos reales de ese producto. La ingeniera inversa del software es el proceso de anlisis de un programa con el fin de crear una representacin de programa con un nivel de abstraccin ms elevado que el cdigo fuente. La ingeniera inversa se extraer del programa existente informacin del diseo arquitectnico y de proceso, e informacin de los datos. 4 Reestructuracin del cdigo. El tipo ms comn de reingeniera es la reestructuracin del cdigo. Para llevar a cabo esta actividad, se analiza el cdigo fuente mediante una herramienta de reestructuracin, se indican las violaciones de las estructuras de programacin estructurada, y entonces se reestructura el cdigo (esto se puede hacer
12

automticamente). El cdigo reestructurado resultante se revisa y se comprueba para asegurar que no se hayan introducido anomalas. Se actualiza la documentacin interna del cdigo. 5 Reestructuracin de datos. Un programa que posea una estructura de datos dbil ser difcil de adaptar y de mejorar. A diferencia de la reestructuracin de cdigo, que se produce en un nivel relativamente bajo de abstraccin, la estructuracin de datos es una actividad de reingeniera a gran escala. En la mayora de los casos, la reestructuracin de datos comienza por una actividad de ingeniera inversa. La arquitectura de datos actual se analiza minuciosamente y se definen los modelos de datos necesarios. Se identifican los objetos de datos y atributos y, a continuacin, se revisan las estructuras de datos a efectos de calidad. Cuando la estructura de datos es dbil se aplica una reingeniera a los datos. Dado que la arquitectura de datos tiene una gran influencia sobre la arquitectura del programa, y tambin sobre los algoritmos que los pueblan, los cambios en datos darn lugar invariablemente a cambios o bien de arquitectura o bien de cdigo. 6 Ingeniera directa (foward engineering). En un mundo ideal, las aplicaciones se reconstruyen utilizando un "motor de reingeniera" automatizado. En el motor se insertara el programa viejo, que lo analizara, reestructurara y despus regenerara la forma de exhibir los mejores aspectos de la calidad del software. La ingeniera directa, que se denomina tambin renovacin o reclamacin, no solamente recupera la informacin de diseo de un software ya existente, sino que, adems, utiliza esta informacin en un esfuerzo por mejorar su calidad global. En la mayora de los casos, el software procedente de una reingeniera vuelve a implementar la funcionalidad del sistema existente, y aade adems nuevas funciones y/o mejora el rendimiento global.

13

CONCLUSION
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. Ninguna de las actividades llevadas a cabo durante la reingeniera de un sistema es fcil, es por ellos que cada una debe de estar muy bien planeadas antes de emprenderse y la reconstruccin de la arquitectura no es la excepcin. Es por ello que para realizar la reconstruccin de la arquitectura de un sistema de informacin heredado se recomienda tener bien definidas las metas y objetivos, obtener una visin general de la arquitectura, identificar y usar la documentacin existente, e involucrar a personas familiarizadas con el sistema.

14

BIBLIOGRAFIA
http://ri.biblioteca.udo.edu.ve/bitstream/123456789/1810/1/TESIS_YG.pdf http://repository.cmu.edu/cgi/viewcontent.cgi?article=1573&context=sei http://www.monografias.com/trabajos17/reingenieria-software/reingenieriasoftware.shtml

15