Ventajas y desventajas de la ingenieria inversa

Share Button

REINGENIERÍA DEL SOFTWARE
1. INTRODUCCIÓN Y DEFINICIONES


La reingeniería nace de la necesidad de que con el paso del tiempo, el sw se deteriora dado que sifre constantes adaptaciones y cambios durante el mantenimiento.
Llega un momento en que ese software se hace insostenible. Si hacemos la similitud con una vivienda: en una casa vieja tendríamos que tomar la decisión de si tirarla abajo y volver a construir o rehabilitarla.
El proceso de reingeniería se realiza en dos niveles distintos de abstracción: Negocio y Software.

? Negocio: se aplica con la intención de efectuar cambios que mejoren la competitividad en algún aspecto de los negocios, los pasos a seguir son:
o Definir negocios y metas comerciales.
o Identificar y evaluar los procesos de negocios existentes.
? Software: la reingeniería examina los sistemas y aplicaciones de información con intención de reestructurarlos o reconstruirlos de tal modo que muestren una mayor calidad, los pasos a seguir son:
o Análisis de inventario.
o Reestructuración de documentos.
o Ingeniería inversa.

o Reestructuración de códigos.
o Reestructuración de datos.
o Ingeniería directa.

2. REINGENIERÍA EN EL SOFTWARE


Implica la modificación de un producto sw o de ciertos componentes, usando para el análisis de sistema existente técnicas de ingeniería inversa y para la etapa de reconstrucción, herramientas de ingeniería directa.
Objetivos métodos para reconstruir el sw de la siguiente forma:
? Reprogramarlo
? Redocumentarlo
? Rediseñarlo
? Rehacer alguna/ característica/s del producto.

Actividades que implica la reingeniería en el software:

2.1. Análisis de inventarios


Toda organización debe tener un inventario del software que tiene. Debe reflejar las características de cada aplicación software. El inventario debe consultarse y modificarse con regularidad, según varíe el estado de dicho software ya que dicho estado podría variar a lo largo del tiempo y esto puede implicar que varíen las prioridades del mismo, haciendo que cambien las prioridades para el proceso de reingeniería.

2.2. Reestructuración de documentos


Si el sistema funciona y la redocumentación consume muchos recursos, mejor no redocumentar.
Si es preciso actualizar la documentación, pero se tienen recursos limitados, puede ser útil documentar cuando se modifica, con el tiempo se formará una colección de información interesante.
Si el sistema es fundamental para la organización, redocumentar por completo. Se puede reducir la documentación al mínimo.

2.3. Ingeniería inversa


La ingeniería inversa se define como el proceso de construir especificaciones abstractas del código fuente de un sistema sw o cualquier otro producto sw, con el objetivo de que estas especificaciones pueden ser utilizadas para construir una nueva implementación hacia delante.
Beneficios:
? Reducir la complejidad del sistema.
? Generar vistas alternativas.
? Recuperar información perdida.
? Detectar efectos laterales.
? Facilitar la reutilización.

El punto de partida no tiene que ser necesariamente el código fuente.
Existen diferentes tipos de ingeniería inversa:
? Ingeniería inversa de lógica o de proceso

Se aplica sobre código de un programa para averiguar su lógica o cualquier documento de diseño para obtener documentos de análisis o de requisitos.
Proceso a seguir:
o Identificación: recopilación de los componentes fundamentales del sistema
o Asignar significado: a los componentes anteriores (no se realizan secuencialmente). Recorrer las sentencias del componente, para confirmar su calidad de componente funcional (análisis estático). Detectar y registrar errores (bucles infinitos, código inalcanzable,…)

La funcionalidad general debe ser algo perfectamente comprendido antes de comenzar un trabajo de ingeniería inversa detallado. Esto establece un contexto para un análisis posterior, que proporciona ideas generales acerca de los problemas de interoperabilidad entre módulos del sistema.
? Ingeniería inversa de datos (base de datos):


? Ingeniería inversa de datos (ficheros):

Considerar cada fichero como una posible tabla y cada campo como un campo de la tabla.
Determinar un conjunto de campos que pueden ser clave primaria de sus respectivos ficheros (buscar ID, #).
Determiar las claves ajenas.
Determinar los ficheros que no pueden tratarse como tablas (aquellos sin claves).
Buscar generalizaciones: grandes grupos de claves ajenas, valores repetidos de atributos en una tabla, datos con valores mutuamente excluyentes.
? Ingeniería inversa interfaces de usuario

Adaptar aplicaciones a las necesidades de los usuarios, respectando su lógica anterior:
1. Recopilar la documentación, manuales de usuario,…
2. Entrevistas a distintos grupos de usuario y observación de sus métodos de trabajo.
3. Uso del sistema por el propio equipo de mantenimiento.
4. Reconstrucción y redocumentación de la interfaz.

2.4. Reestructuración de …


Código:

a partir de los productos de ingeniería inversa se construye el programa mediante técnicas de ingeniería directa.
?

Datos:

eliminar sinonimias y polisemias.
?

Procesos:

transformar el código no estructurado en código estructurado u orientado a objetos.

En un diagrama de flujo estructurado es posible hacer transformaciones sucesivas hasta que su complejidad ciclomática se iguale a 1.

Share Button

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>