Informe reing

S.E.P. D.G.E.S.T. S.N.E.S.T.

INSTITUTO TECNOLÓGICO
de Tuxtepec
INFORMES SOBRE LAS DIFERENTES METODOLOGIAS DE
LA REINGENIERIA DEL SOFTWARE
UNIDAD III
Métodos y modelos de la reingeniería del software

CARRERA:
Ingeniería en Sistemas Computacionales

MATERIA:
Reingeniería de Software
PRESENTAN:
Bolaños Duran Juan Carlos
Pérez Antonio Julio Cesar
Vázquez Gómez Guadalupe
Vicente Azamar Timoteo
Zarate Castillo Celeste Yamín

CATEDRÁTICO:
L. I. María de los Ángeles Martínez Morales

ISC – 2010/01 Marzo de 2012

NOMBRE DEL
CORREO ELECTRONICO N° DE CONTROL
ALUMNO
Bolaños Duran Juan
scorpion_03k@hotmail.com
Carlos 08350634

Pérez Antonio Julio
jcpat_10@hotmail.com
Cesar 08350355

Vázquez Gómez
Guadalupe lupev_g@hotmail.com 08350380

Vicente Azamar
Timoteo alkon_1_15@hotmail.com 08350384

Zarate Castillo Celeste
Yamín celeste_tux@hotmail.com 08350385

2

INDÍCE

INTRODUCCIÓN .............................................................................................................................. 4
MÉTODOS Y MODELOS DE LA REINGENIERIA DE SOFTWARE DE SOFTWARE ......... 5
EL MÉTODO ANÁLISIS DE OPCIONES PARA REINGENIERÍA ............................................ 5
EL MODELO HERRADURA ........................................................................................................... 8
EL MODELO CÍCLICO .................................................................................................................. 11
CONCLUSION ................................................................................................................................ 14
REFERENCIA ................................................................................................................................. 15

3

INTRODUCCIÓN

En este apartado se explican losmétodos y los modelos de la reingeniería del
software. Organizado con puntos importantes para el mayor entendimiento de los
lectores.

Tratamos de dar una visión general de lo que es la reingeniería de software y
cuáles sus métodos y modelos para saber en que momento podemos adquirirlo en
una operación del cual se ejecuta y saber si es de eficiencia y conocer su
disponibilidad.Los métodos y los modelos surgen como una consecuencia de la
aplicación de los procesos dentro de la reingeniería del software, su aplicación
consiste en las técnicas para verificar la aprobación del caso de estudio.

La reingeniería de software debe ser entendida como un proceso mediante el cual
se mejora un software existente haciendo uso de técnicas de ingeniería inversa y
restructuración de código. Para llevar a cabo la reingeniería del Software se puede
realizar a través del: (1) método de análisis de opción para reingeniería, (2) el
modelo herradura y (3) el modelo cíclico.

Donde el método de análisis de opción para reingeniería es el encargado de tomar
las decisiones para la identificación y la extracción de componentes del sistema,
mientras que el modelo herradura se basa del análisis, transformación y desarrollo
del sistema, y por ultimo el modelo cíclico consta de seis actividades la cual
explicaremos en este apartado.

Este documento cuenta con principales características de los modelos y los
métodos, esperando que sea entendible cada punto y así poder tener mayor
conocimiento del tema.

4

MÉTODOS Y MODELOS DE LA REINGENIERIA DE SOFTWAREDE
SOFTWARE

EL MÉTODO ANÁLISIS DE OPCIONES PARA REINGENIERÍA

Sus siglas en ingles, Options analysis for reengineering, es un método sistemático,
de arquitectura central y de toma de decisiones para la identificación y extracción
de componentes dentro de grandes y complejos sistemas de software. La
extracción envuelve rehabilitación de partes de un sistema anterior para su re-uso.
El análisis de opciones para reingeniería (OAR) identifica componentes de
arquitectura potencial relevantes y analiza los cambios requeridos para usarlos en
una line de producción de software o nuevas arquitecturas de software. OAR
proporciona un conjunto de opciones de extracción junto con estimación de
costos, esfuerzos y riesgos asociados con estas opciones.

La extracción de componentes casi siempre había sido discutido como una
alternativa, pero requería el entendimiento de que tipos de componentes valían la
pena extraer y como se debería extraer. Estos puntos son importantes para la
realización de la extracción:

Componentes existentes casi siempre eran pobremente
estructurados y documentados.
Componentes existentes diferían en niveles de granuralidad.
Ho había una guía clara sobre cómo salvar componentes.

Este tipo de método consiste de cinco actividades principales con tareas
escalables.

Establecimiento Del Contexto De Extracción (ECE): Es importante para el equipo
de OAR entender el contexto para la extracción. Cómo un resultado, la primer
actividad de OAR consiste en entrevistar a los accionistas y estudiar la línea de
producción de la organización o nuevos requerimientos de sistema, base
heredada y expectativas para la extracción de componentes heredados.

5

Inventario De Componentes (IC): En esta actividad los miembros del equipo
identifican componentes de líneas de producción necesarios y evalúan los
componentes heredados basados en esos criterios. Aquellos que no descubran
los criterios están incapacitados para continuar con el proceso de reingeniería.
Esta actividad resulta en un inventario de los componentes heredados candidatos.

La IC consta de las siguientes tareas:

 Identificar características de los componentes necesarios.
 Identifica las características satisfactorias de los componentes.
 Compara las necesidades de componentes.
 Inventario de componentes candidatos.
 Produce tópicos de extracción.
 Revisión del calendario OAR.

Análisis De Componentes Candidatos (ACC): En este paso es analizar el conjunto
de candidatos de componentes heredados para extraer los tipos de cambios que
son requeridos. Sus tareas principales son:

 Selección de componentes deseables.
 Identifica los componentes Tal como están y de caja negra.
 Identifica componentes de caja blanca.
 Determina cambios requeridos.
 Producción de tópicos de extracción.
 Revisa el calendario OAR.

Plan De Opciones De Extracción (POE): Dado el conjunto de componentes
candidatos analizados, el equipo desarrollar alternativas para la extracción
basada en consideraciones de calendario, costo, esfuerzo, riesgo y recursos. El
POE consta de las siguientes tareas:

 Selecciona componentes favorables.
 Ejecución de intercambio de componentes.
 Forma opciones de componentes.

6

 Determina costos comparativos y esfuerzos.
 Analiza dificultad o riesgo.
 Producción de tópicos de extracción.
 Revisa el calendario OAR.

Selección De Opciones De Extracción (SOE): Al final de seleccionan la mejor
opción de extracción o combinación de opciones para programas y
consideraciones técnicas. Después de evaluar cada opción de extracción, ellos
preparan un resumen que presenta y justifica sus elecciones. SOE tiene cinco
tareas que son:

 Elegir la mejor opción.
 Verificación de opción
 Identificar componentes necesarios satisfechos
 Presentación de descubrimientos.
 Producción de resumen.

Cada actividad tiene un potencial de conjunto de actividades especializadas para
direccionar circunstancias que pueden de otro modo imposibilitar la cumplimiento
de la actividad.

Cada actividad esta compuesta de tareas y sub-tareas diseñadas para contestar
un conjunto de preguntas de actividades especificadas. Las actividades están
estructuradas de acuerdo a un formato “EITVOX”.

Los criterios de entrada se analizan para determinar si hay suficiente datos y
tecnológica disponible para ejecutar la actividad exitosamente. Si no es satisfecho
el criterio la tarea especializada debe ser desarrollada.

Los criterios de validación son dadas después de que las tareas fueron
complementadas. Los criterios de salida son sugeridos antes de complementar el
establecimiento del contexto de extracción.

7

EL MODELO HERRADURA

Análisis de un sistema existente, transformación lógica y desarrollo de un sistema,
son los tres procesos básicos para formar la base del modelo de herradura. 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.

Los tres niveles de abstracción que pueden ser adoptados para las descripciones
lógicas es la riqueza del modelo de herradura. Las descripciones lógicas pueden
ser artefactos tan concretos y simples como el código fuente del sistema o tan
complejos y abstractos como la arquitectura del sistema.

El propósito de la metáfora visual es para integrar las vistas de reingeniería a nivel
de código y arquitectónico del mundo.

El primer proceso recupera la arquitectura por medio de la extracción de artefactos
desde el código fuente. Esta estructura recuperada es analizada para determinar
si esta se adapta a la arquitectura antes diseñada. La arquitectura descubierta
también es evaluada con respecto a un número de calidad de atributos tales como
rendimiento, modificabilidad, seguridad o confiabilidad.

El segundo proceso es la transformación de arquitectura. En este caso, la
arquitectura antes construida es recuperada y es reingeniería para hacerla una
nueva arquitectura deseable. Esta es revaluada contra las metas de calidad del
sistema y sujetas a otras restricciones organizadas y económicas.

El tercer proceso usa el “Architectura-Based DEvelopment (ABD), para ejemplificar
la arquitectura deseable. En este proceso, ya empaquetados los tópicos son
decididas e interconectadas las estrategias elegidas. Los artefactos a nivel de
código del sistema de información heredado son normalmente tapados o rescritos
para adaptarlos dentro de la nueva arquitectura.

El modelo de herradura consta de tres niveles que son:

8

 Representación de la estructura de código: este incluye el código fuente y
artefactos tales como arboles de sintaxis abstractas y diagramas de flujo
obtenidos a través del análisis gramatical y operaciones analíticas de rutina.
 Representación del nivel funcional: es el cual describe la relación entre las
funciones del programa, datos y archivos.
 Nivel conceptual: aquí se representa grupo tanto de funciones y artefactos
de nivel de código que son ensamblados dentro de subsistemas de
componentes relacionados o conceptos.

El modelo completo no solo hace transformaciones en el nivel de arquitectura,
también lo hace en los niveles subsidiarios. Los ejemplos simples de
transformaciones a cada nivel se mencionan a continuación:

Nivel De Código: Existen dos sub-niveles, transformación textual y transformación
basado en el árbol de sintaxis. Mientras algunos métodos hacen distinciones entre
transformaciones “1A” textual y “1B” AST-based, el modelo herradura los
considera a ambos dentro del contexto de estructura de código.

 Transformación Textual: En el nivel 1A, las transformaciones textuales son
realizadas a través de varias comparaciones de cadenas simples y
remplaza métodos. Las transformaciones son elegidas por las
organizaciones cuando el problema es suficientemente simple o cuando se
requiere un resultado rápido y sucio.
 Transformación al árbol de sintaxis: En el nivel 1B, las transformaciones a
la estructuras de código basada en arboles de sintaxis soportan cambios
que son inmunes a las variaciones superficiales de sintaxis. La
representación del código fuente es independiente de las expresiones o la
forma en que los lenguajes de programación representan números.

Transformaciones A Nivel funcional: Tiene que ver con el re-empaquetado de
funcionalidad. La encapsulación de un modulo de funcionalidad por un diferente
ambiente. Transformaciones a nivel funcional va másallá de simples

9

transformación de arquitectura. Ellos son elegidos cuando grades unidades de
funcionalidad pueden ser salvados poniéndolos dentro de un nuevo contexto.

Transformaciones A Nivel De Arquitectura: Involucran cambios a los bloques
básicos de la arquitectura. Estos modelos básicos de interacción incluyen los tipos
de componentes, los conectores usados, la asignación de funcionalidad y el
modelo en tiempo de ejecución de control y datos. A este nivel es el mas abstracto
y lejos de alcance de las transformaciones.

Las trasformaciones son hechas cuando es necesario un cambio a la estructura
principal debido a las principales modificaciones o deficiencias en los sistemas de
información heredados.

Interacción Entre Niveles: Las transformaciones a la estructura del código se
pueden dar sin hacer cambios de nivel funcional o cambios a la arquitectura. Las
transformaciones del nivel mas bajo soportan las transformaciones de niveles más
altos.

Las transformaciones a la arquitectura son normalmente el contexto en los cuales
toman parte niveles más bajos. Las transformaciones se pueden dar
independientemente de las transformaciones de niveles superiores.

10

EL MODELO CÍCLICO

Este modelo define seis actividades, estas actividades se producen de forma
secuencial y lineal, pero esto no siempre es así.

El paradigma de la reingeniería es un modelo cíclico, esto es que cada una de las
actividades es parte del paradigma que pueden repetirse en otras ocasiones. Para
un ciclo en particular, el proceso puede terminar después de cualquier actividad.

Las actividades del modelo cíclico son:

Análisis de inventario, Restructuración de documentos, Ingeniería Inversa,
Restructuración de código, Restructuración de datos e Ingeniería directa.

El análisis de inventario: todas las organizaciones de software deberán disponer
de un inventario de todas sus aplicaciones. El inventario pueden que no sea mas
que una hoja de calculo con la información que proporciona una descripción
detallada de todas las aplicaciones activas.

Los candidatos a la reingeniería aparecen cuando se ordena esta información en
función de su importancia para el negocio, longevidad, mantenibilidad actual y
otros criterios localmente importantes. Es entonces cuando es posible asignar
recursos a las aplicaciones candidatas para el trabajo de reingeniería.

Es importante destacar que el inventario deberá revisarse con regularidad. El
estado de las aplicaciones puede cambiar en función del tiempo y, como
resultado, cambiaran también las prioridades para la reingeniería.

Restructuración de documentos: Una documentación escasa es la marca de
muchos sistemas de información heredados. Para esto se tiene que hacer:

 La creación de documentación consume muchísimo tiempo. El sistema
funciona, y ya nos ajustaremos con lo que se tiene. En algunos casos, este
es el enfoque correcto. No es posible volver a crear la documentación para
cientos de programas de computadoras. Si un programa es relativamente

11

estático esta llegando la final de vida útil, y no es probable que experimente
muchos cambios.
 Es preciso actualizar la documentación, pero se dispone de recursos
limitados. Quizá no es necesario volver a documentar por completo la
aplicación. Más bien se documentan por completo aquellas partes del
sistema que están experimentando cambios en ese momento. La colección
de documentos útil y relevante ira evolucionada con el tiempo.
 El sistema es fundamental para el negocio, y es preciso volver a
documentar por completo. Un enfoque inteligente consiste en reducir la
documentación al mínimo necesario.

Todas y cada una de estas opciones son viables. Las organizaciones del software
deberán seleccionar aquella que resulte más adecuada para cada caso.

Ingeniería Inversa: tiene sus orígenes en el mundo del hardware. Una cierta
compaña desensambla un producto de hardware un producto de hardware
competitivo en un esfuerzo por comprender los secretos del diseño y fabricación
de su competidor. Estos secretos se podrán comprender más fácilmente si se
obtuvieran las especificaciones de diseño y fabricación del mismo. Pero estos
documentos son privados y no están disponibles para la compañía que efectúa la
ingeniería inversa.

La ingeniería inversa del software es algo bastante similar. Sin embargo, en la
mayoría de los casos, el programa del cual hay que hacer una ingeniería inversa
no es el de un rival, sino, más bien, el propio trabajo de la compañía.

La ingeniería inversa del software es el proceso de análisis de un programa con el
fin de crear una representación de programa con un nivel de abstracción más
elevado que el código fuente. Esta se extraerá del programa existente información
del diseño arquitectónico y de proceso, e información de los datos.

Restructuración del Código: este es el tipo más común. Algunos sistemas
heredados tiene una arquitectura de programa relativamente solida, pero los
módulos individuales han sido codificados de una forma que hace comprenderlos,

12

comprobarlos y mantenerlos. En este caso, se puede restructurar el código
ubicado dentro de los módulos sospechosos.

Para llevar a cabo esta actividad, se analiza el código fuente mediante una
herramienta de restructuración, se indican las violaciones de las estructuras de
programación estructurada, y entonces se restructurar el código. El código
restructurado resultante se revisa u se comprueba para asegurar que no se hayan
introducido anomalías. Se actualiza la documentación interna del código.

Restructuración de Datos: Un programa que posea una estructura de datos débil
será difícil de adaptar y de mejorar. De hecho, para muchas aplicaciones, la
arquitectura de datos tiene más que ver con la viabilidad a largo plazo del
programa que el propio código fuente. Cuando la estructura de datos es débil, se
aplica una reingeniería a los datos.

Dado que la arquitectura de datos tiene una gran influencia sobre la arquitectura
del programa, y también sobre los algoritmos que los pueblan, los cambios en
datos darán lugar invariablemente a cambios o bien de arquitectura o bien de
código.

Ingeniería Directa: las aplicaciones se reconstruyen utilizando un motor de
reingeniería automatizado. En el motor se insertaría el programa viejo, que lo
analizaría, restructuraría y después regeneraría la forma de exhibir los mejores
aspectos de la calidad del software.

Lo que es mas importante, estas herramientas de reingeniería cada vez son mas
sofisticadas.

La ingeniería directa, que se denomina también renovación o reclamación, no
solamente recupera la información de diseño de un software ya existente, si no
que, además, utiliza esta información en un esfuerzo por mejorar su calidad global.

13

CONCLUSION

La reingeniería del software es un tema muy importante para muchas empresas
yorganismos que tienen que seguir manteniendo sus aplicaciones porque sus
desarrollos han sidocostosos y adaptados a sus necesidades, lo que en muchos
casos hace que no existanaplicaciones comerciales similares. En muchos casos
no pueden adaptarse a los avances del hardware, porque estos nuevos
equiposincorporan sistemas operativos para los que no fueron pensados los
sistemas legados.

Existen los modelos y métodos de desarrollo que abordan esta problemática,
algunas de ellas específicas para determinados aspectos, como recuperar el
diseño, desarrollar la documentación pérdida, o convertir un código. Nuestro
proceso de desarrollo trata de mantener la funcionalidad del sistema, manteniendo
los datos, pero utilizando un nuevo código en un lenguaje orientado a objetos,
portanto, ya estructurado, con una interfaz de usuario totalmente nueva, que dote
a las aplicaciones de un aire de modernidad y que, por tanto, facilite su utilización
por parte del usuario final. Además, añade nuevas especificaciones con su
correspondiente documentación, lo que permitirá la ampliación del sistema.

Una ventaja de esta los modelos y métodos que explicamos es que algunas de
sus fases pueden llevarse a cabo sin complicaciones. Otra ventaja es que se
adapta a dominios científicos, en los que el tiempo de procesamiento es
importante y está claramente diferenciada la interfaz de usuario del procesamiento
y la obtención de resultados.

Esperando que este informe haya sido explicado de una manera entendible y así
puedan los lectores utilizar este documento para la realización de reingeniería

14

Informe reing

Más contenido relacionado

Similar a Informe reing (20)

Más de Blue ... (20)

Informe reing