Reingeniería es comenzar de cero, es un cambio de todo o nada, además ordena la
empresa alrededor de los procesos. La Reingeniería se puede dividir en dos
grandes ramas, la reingeniería de negocios y la de software. En negocios, la
reingeniería se concentra en el proceso de negocios con la intención de
efectuar cambios que mejoren la competitividad en algún aspecto de los
negocios. A nivel del software, la reingeniería examina los sistemas y
aplicaciones de información con la intención de reestructurarlos o
reconstruirlos de tal modo que muestren una mayor calidad.
¿Qué es?
La reingeniería es un proceso mediante el cual se mejora un software
existente haciendo uso de técnicas de ingeniería inversa
y reestructuración de código. También 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 es usada por años, es fácil que esta aplicación se vuelva
inestable a causa de las múltiples correcciones, adaptaciones o mejoras que han
podido surgir a lo largo del tiempo. Por lo 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.
La reingeniería en algunos casos requiere tiempo; conlleva un gran coste de
dinero y absorbe recursos que de otro modo podrían emplearse en preocupaciones
más inmediatas. Por todas estas razones, la reingeniería no se lleva a cabo en
unos pocos meses, ni siquiera en unos pocos años. Esta es la razón por la cual
toda organización necesita una estrategia pragmática para la reingeniería del
software.
Una estrategia de trabajo también acompaña al modelo de procesos de
reingeniería. El Proceso de la Reingeniería del Software:
- Análisis de inventarios
- Reestructuración de
documentos
- Ingeniería inversa
- Reestructuración de
programas y datos
- Ingeniería directa
Análisis de inventario: Todas las organizaciones de
software deberían tener un inventario de todas sus aplicaciones. El
inventario puede que no sea más que una hoja de cálculo con la información que
proporciona una descripción detallada (por ejemplo: tamaño, edad, importancia
para el negocio) de todas las aplicaciones activas. 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.
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.
Reestructuración de documentos: 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. Una documentación escasa es la marca de muchos sistemas
heredados.
La creación de documentación consume muchísimo tiempo. El sistema
funciona, y ya nos apañaremos con lo que tengamos. En algunos casos, éste es el
enfoque correcto. No es posible volver a crear la documentación para cientos de
programas de computadoras. Si un programa es relativamente estático está
llegando al final de vida útil, y no es probable que experimente muchos
cambios.
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.
Ingeniería inversa: La ingeniería inversa puede extraer
información de diseño del código fuente, pero el nivel de abstracción, la completitud
de la documentación, el grado con el cual trabajan al mismo tiempo las
herramientas y el analista humano, y la direccionalidad del proceso son
sumamente variables.
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 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 (con frecuencia efectuado hace muchos años). 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: 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. 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 mayoría 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, 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 lo pueblan, los
cambios en datos darán lugar invariablemente a cambios o bien de arquitectura o
bien de código.
Ingeniería directa: 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
para alterar o reconstruir el sistema existente 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.
Conclusiones:
El Proceso de Reingeniería de Software es muy importante para los
sistemas software ya que es una actividad de reconstrucción, la cual es
preferible de realizar antes de que se “derrumbe” la obra. Aunque a veces puede
llegar a ser costosa y consumidora de tiempo, puede ser una mejor opción
que construir un software desde cero porque esto implicaría aún más tiempo,
personal y dinero.
En otras ocasiones no es una buena opción, un ejemplo sería si el
sistema al que se le desea hacer la reingeniería está en muy malas condiciones
y sea muy difícil el aplicar los pasos.
Bibliografía
isoftwareunesum. (28 de Abril de 2011). INGENIERÍA
DEL SOFTWARE. Obtenido de
https://isoftwareunesum.wordpress.com/2011/04/28/reingenieria-de-la-ingenieria-del-software/
Mendoza, E. E. (08 de Octubre de
2007). Reingenieria UCV. Obtenido de
http://reingenieriaucv2007.blogspot.mx/2007/10/qu-es-reingeniera.html
NORSOFT. (25 de Marzo de 2015). NORSOFT
Information Tecnologies. Obtenido de
http://www.norsoft.com.ar/servicios/servicios-reingenieria.html
Solís, F. (12 de Octubre de 2012). Reingenieria
de software. Obtenido de
https://prezi.com/z4yorwp-ho2x/pasos-para-la-reingenieria-de-software/
