Reingeniería del software
se puede definir como: “modificación de un producto software, o de ciertos
componentes, usando para el análisis del sistema existente técnicas de
Ingeniería Inversa y, para la etapa de reconstrucción, herramientas de
Ingeniería Directa, de tal manera que se oriente este cambio hacia mayores
niveles de facilidad en cuanto a mantenimiento, reutilización, comprensión o
evaluación.”
Cuando una aplicación
lleva siendo usada años, es fácil que esta aplicación se vuelva inestable como
fruto de las múltiples correcciones, adaptaciones o mejoras que han podido
surgir a lo largo del tiempo. Esto deriva en que cada vez que se pretende realizar
un cambio se producen efectos colaterales inesperados y hasta de gravedad, por
lo que se hace necesario, si se prevé que la aplicación seguirá siendo de
utilidad, aplicar reingeniería a la misma.
Beneficios de aplicar reingeniería
·
Pueden reducir
los riegos evolutivos de una organización.
·
Puede ayudar a
las organizaciones a recuperar sus inversiones en software.
·
Puede hacer el
software más fácilmente modificable
·
Amplía las
capacidades de las herramientas CASE
·
Es un catalizador
para la automatización del mantenimiento del software
·
Puede actuar
como catalizador para la aplicación de técnicas de inteligencia artificial para
resolver problemas de reingeniería
Etapas de la reingeniería de Software
Análisis de Inventarios
Todas las organizaciones
de software deberían tener un inventario de todas sus aplicaciones. El
inventario tal vez no sea más que un modelo en una hoja de cálculo que contenga
información que proporcione una descripción detallada (tamaño, edad, importancia
para el negocio) de 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 señalar que el inventario deberá visitarse con regularidad, el
estado de las aplicaciones puede cambiar en función del tiempo y, como
resultado, cambiarán las prioridades para la reingeniería.
Reestructuración de documentos
La documentación débil es
la marca de muchos sistemas heredados. ¿Pero que se hace acerca de ellos?
¿Cuáles son las opciones? Crear documentación consume mucho tiempo, si el sistema
funciona vivirá con lo que tenga. La documentación debe actualizarse pero se
tiene recursos limitados. Se utiliza un enfoque de “documentar cuando se
toque”. El sistema es crucial para el negocio y debe volver a documentarse por
completo incluso en este caso un enfoque inteligente es recortar la
documentación a un mínimo esencial. Cada una de estas opciones es viable. Una
organización de software debe elegir la más apropiada para cada caso.
Ingeniería Inversa
Este término tiene sus
orígenes en el mundo del hardware. Una cierta compañía desensambla 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. En esencia, una ingeniería inversa
con éxito precede de una o más especificaciones de diseño y fabricación para el
producto, mediante el examen de ejemplos reales de ese producto.
La
ingeniería inversa del software es algo similar. 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. Los “secretos” que hay que
comprender resultan incomprensibles porque nunca se llegó a desarrollar una
especificación. Consiguientemente, 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.
La
Ingeniería inversa es un proceso de recuperación de diseño. Con las
herramientas de la ingeniería inversa se extraerá del programa existente
información del diseño arquitectónico y de proceso, e información de los datos.
Reestructuración
del código.
El tipo más común de
reingeniería es la reestructuración del código. Algunos sistemas heredados
tienen una arquitectura de programa relativamente sólida, pero los módulos individuales
han sido codificados de una forma que hace difícil comprenderlos, comprobarlos
y mantenerlos. En estos casos, se puede reestructurar 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
reestructuración, se indican las violaciones de las estructuras de programación
estructurada, y entonces se reestructura el código (esto se puede hacer
automáticamente). El código reestructurado resultante se revisa y se comprueba
para asegurar que no se hayan introducido anomalías. Se actualiza la
documentación interna del código.
Reestructuració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.
A diferencia de la
reestructuración de código, que se produce en un nivel relativamente bajo de
abstracción, la estructuración de datos es una actividad de reingeniería a gran
escala. En la mayoria de los casos, la reestructuración de datos comienza por
una actividad de ingeniería 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 continuación, se revisan las estructuras de
datos a efectos de calidad.
Cuando la estructura de
datos es débil (por ejemplo, actualmente se implementan archivos planos, cuando
un enfoque relacional simplificaría muchísimo el procesamiento), 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 (foward engineering).
En un mundo ideal, las
aplicaciones se reconstruyen utilizando un “motor de reingeniería”
automatizado. En el motor se insertaría el programa viejo, que lo analizaría, reestructuraría
y después regeneraría la forma de exhibir los mejores aspectos de la calidad del
software. Después de un espacio de tiempo corto, es probable que llegue a
aparecer este “motor”, pero los fabricantes de CASE han presentado herramientas
que proporcionan un subconjunto limitado de estas capacidades y que se
enfrentan con dominios de aplicaciones específicos (por ejemplo, aplicaciones
que han sido implementadas empleando un sistema de bases de datos específico).
Lo que es más importante, estas herramientas de reingeniería cada vez son más
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, sino que, además, utiliza
esta información en un esfuerzo por mejorar su calidad global. En la mayoría de
los casos, el software procedente de una reingeniería vuelve a implementar la
funcionalidad del sistema existente, y añade además nuevas funciones y/o mejora
el rendimiento global.
Como conclusión diremos
que la reingeniería de sistemas heredados tiene por finalidad reestructurar o
transformar viejos sistemas en aplicaciones más fáciles de mantener, con
entornos más agradables e integradas en nuevas plataformas de hardware/software.
Trabajos citados
Dana, G. (28 de Junio de 2010). UTN-Buenos Aires.
Recuperado el 22 de Febrero de 2014, de UTN-Buenos Aires:
http://epetushuaia.files.wordpress.com/2011/06/reingenieria-de-soft.pdf
Norsoft. (2010). Norsoft
Information Technologies. Recuperado el 22 de Febrero de 2014, de Norsoft
Information Technologies:
http://www.norsoft.com.ar/servicios/servicios-reingenieria.html
Silicia, M. A. (09 de
Enero de 2014). Connexions. Recuperado el 22 de Febrero de 2014, de
Connexions: http://cnx.org/content/m17438/latest/
