Reingeniería de Software: La transformación efectiva

Reingeniería de Software: la transformación efectiva

Jorge Ramírez

C.I. 28.219.444

01

Introducción Desde hace años el mundo se viene sumergiendo cada vez más en la tecnología, desde las empresas más grandes hasta las más pequeñas utilizan software para sus actividades diarias y gestión del negocio. Esto les permite establecer de forma óptima estrategias y desarrollar una trazabilidad en las acciones, pueden no ser las únicas y quedarme corto.

Sea cual fuere la razón de implementar software en cualquier tipo de negocio la realidad es que es para mejorar los procesos del mismo. Como es sabido el mundo del software viene desarrollándose desde hace años (aproximadamente desde la década de los 60s), al igual que sabemos que las tecnologías avanzan cada vez más rápido en fracciones más pequeñas de tiempo.

Es por ello, que hoy en día nos encontramos con una gigantesca cantidad de situaciones en las que el software que maneja una empresa, negocio pequeño o vendedor de servicio puede estar obsoleto y necesitar cambios, los cambios pueden darse por parte de un proveedor o si es un sistema heredado habrá que contratar programadores que se encarguen de realzar el trabajo.

Sin embargo, es común encontrarse con un código que parece un espagueti, documentación sumamente débil o inexistente, código que al mínimo cambio colapsa todo el sistema (es decir, funciona de milagro), y una infinidad de situaciones no son más que para el desagrado del ingeniero de software. Es por ello que el contenido a continuación trata sobre la reingeniería de software, ya que, es gracias a estar que existen métodos para hacer frente a esos problemas y poder mejorar el software heredado.

I

Contenido Procesos ........................................................................ 2 Principios .......................................................................4 Diseño ............................................................................ 5 Arquitectura .................................................................. 7 Modelos ......................................................................... 9 Mantenimiento ............................................................. 10 Ingeniería Inversa ........................................................ 11 Reconstrucción ............................................................ 12

1

Procesos

El proceso de reingeniería de software puede verse desde muchos puntos de vista, lo que hace que se le puedan aportar diversas situaciones. Básicamente es el proceso en el que se estudia un sistema existente para comprender su funcionamiento para posteriormente modificarlo, ya sea, para implementar mejoras, optimizar, adaptar a nuevas tecnologías o cualquier otra razón. El enfoque común suele ser la mantenibilidad.

Este proceso puede llegar a ser un poco complicado por carecer de información que pueda ser útil que se manejo al momento del desarrollo inicial, aquí el equipo debe descifrar analizando el resultado lo que tuvo en mente el equipo que desarrolló el sistema, es por ello que se puede dividir en las siguientes actividades o fases: Análisis de inventarios Esta actividad consiste en realizar el inventario de programas que posee la empresa en su posesión, tanto de terceros como propias.

Reestructuración de documentos La mayoría de sistemas heredados poseen una documentación débil, como documentar consume mucho tiempo se documenta en base a lo que se modifica, así hasta documentar todo lo que se necesita modificar.

Ingeniería inversa Este es el proceso que consiste en la recuperación del diseño arquitectónico y de proceso, existen herramientas que permiten ayudar con este proceso. Se puede resumir que es el proceso de abstraer el software a un nivel mucho más alto que el código fuente.

2

Procesos

Reestructuración de programas y datos Ahora es que se procede a cambiar la forma en la que el código está escrito para reescribirlo de una forma más comprensible, más fáciles de testear y mantener. Luego se analizan las estructuras de datos para optimizarlas o dejar únicamente aquellas que son necesarias.

Ingeniería directa Este proceso ocurre una vez se comprende el funcionamiento del sistema donde se le aplican procedimientos de ingeniería convencional para desarrollar mejoras en el programa.

La reingeniería es un proceso que debe estudiarse cuidadosamente previo a su aplicación, ya que, pueden surgir diversos problemas de negocio a la hora de aplicarlo, al igual que una falta de motivación por mejorar el sistema. Por lo tanto, la reingenieria debe tomar en cuenta factores de valor de negocio.

Esto último ya no formaría parte esencial del trabajo del ingeniero o grupo de ingenieros que buscarían modificar el software, ya sería parte del negocio evaluar realmente la necesidad que tienen de actualizar el sistema, mantener el sistema que ya utilizan y actualizarlo. O si por el contrario pudiesen llegar a construir un sistema totalmente nuevo que se adapte a sus necesidades nuevas.

3

Principios La reingeniería de software como cualquier otra disciplina posee sus principios sobre los que basa todos sus procesos, entre estos podemos encontrar: Revisión integral: el análisis del sistema se realiza de forma sistemática, desde el código fuente hasta el paradigma de programación.

Enfoque global: la visión que tiene el análisis es de forma completa, no de partes individuales del sistema.

Rediseño radical: la reingeniería no se enfoca solo en cambios pequeños, si no en un cambio completo al sistema.

Orientación a resultados: el enfoque está en los resultados que se desean obtener.

Mejora continua: el sistema busca adaptarse para que las mejoras en el futuro se implementen más fácil.

Reutilización: se busca desarrollar código que pueda ser utilizado más de una vez en todo el sistema.

Estos principios son fundamentales en todo proceso de reingeniería, plantean la base sobre la cual se desarrollará todo el proceso. El objetivo de la reingeniería de software es desarrollar un sistema capaz de satisfacer tanto las necesidades actuales del cliente como los requisitos de calidad actuales y estar alineado con las nuevas tecnologías

4

Diseño El diseño en la reingeniería es como si hablaramos de la columna vertebral de todo el proceso, este aspecto es el que establece los fundamentos de trabajo para tener una forma de trabajo definida. Definir adecuadamente el diseño en el proceso de reingeniería es vital.

Este aspecto debe tener orientaciones claras, principalmente debe estar basado en los principios anteriormente expuestos, es decir: Debe tener un enfoque global en el que se proyecte al sistema de forma integral.

Debe establecer cambios contundentes, si se tiene un sistema heredado muy antiguo, es normal necesitar hacer un cambio prácticamente completo.

El objetivo esta en los resultados que se desean obtener, y el trabajo debe estar enfocado y organizado para obtener dichos resultados.

La idea de refactorizar un sistema es poder mejorarlo, su mejora no solo implica en aspectos de funcionamiento, visualización y/o buenas prácticas; también debe ver un poco más allá para que la próxima vez que necesite modificarse no sea una dificultad tan grande La reutilización del código es una buena forma de organizarlo permitiendo tener un código optimizado y fácil de entender, por lo tanto evitamos la existencia de un código espagueti.

Antes de toda transformación de un sistema debe haber una análisis previo y previsualización del trabajo que se va a realizar, ahí es cuando sabemos que debemos establecer el diseño de nuestro proceso.

5

Diseño

El diseño puede apoyarse en factores como la arquitectura para establecer un marco de trabajo fuerte, también existen los patrones de diseño, lo que le permite al ingeniero poder resolver diversos tipos de problemas mediante una lógica abstracta y reutilizable (es decir, que podemos verlos como plantillas sobre las cuales planear nuestro diseño).

También el diseño puede buscar modelos sobre los que organizar el trabajo que se debe realizar, con estos modelos me refiero a los existentes como el modelo de cascada, modelo en espiral, y muchos otros. Por lo que, el diseño del proceso de reingeniería no se enfoca únicamente en los aspectos técnicos, si no que también busca establecer una forma organizada de trabajar.

Aquí los procesos de negocios también cobran relevancia, el diseño del proceso de reingeniería debe estar alineado con los procesos de negocio porque el objetivo de hacer cambios en el sistema debe estar alineado con el objetivo de negocio. Aquí también llega a suceder que se cuestionan los procesos de negocios y esto (dependiendo del caso) puede llegar a redirigir al negocio con sus objetivos.

De forma resumida, podemos decir que el diseño involucra aspectos técnicos, de organización y de negocio; dentro del diseño se debe trabajar en todos estos para alinearse con los objetivos del negocio y crear una plantilla de trabajo óptima.

6

Arquitectura La arquitectura ya es el marco de trabajo en sí mismo que se va a implementar durante todo el proceso de reingeniería para comprender el sistema actual, al igual que la arquitectura que se va a implementar. Lo podemos ver como la serie de pasos que se deben seguir para llevar a cabo la transformación del sistema.

Todo el proceso de reingeniería tiene sus fundamentos en el diseño y la arquitectura, aquí ya no estamos hablando únicamente del código a escribir o corregir, estamos hablando de comprender realmente los requisitos del negocio, lo que desea conseguir por medio del uso del sistema en sus procesos de negocio y el objetivo general que tiene el negocio.

Aquí buscamos comprender la visión y objetivo del negocio como una entidad para adoptar o desarrollar una arquitectura de trabajo que se encuentre alineada con ello. Esto es de suma importancia porque es donde encontramos ese punto medio de fusión entre el código que se escribe y el negocio, aquí la visión tiene que ser de una herramienta que es utilizada por una entidad.

Lo primero que se debe hacer es intentar extraer la arquitectura que ya existe en el sistema, claro está que la información que se tiene del mismo podría ser prácticamente nula. Sin embargo mediante un cuidadoso análisis el equipo puede ser capaz de detectar ciertos elementos, componentes y/o estructuras que sean características de alguna arquitectura de conocimiento.

Por otro lado, podemos tener un caso en el que no haya sido desarrollada una arquitectura estable, si no, que el sistema pudo irse desarrollando sobre la marcha o simplemente se desarrollaba sin organización clara.

7

Arquitectura

Lo ideal y más fácil de realizar en cualquier caso es buscar una arquitectura existente que funcione como plantilla para resolver el problema que se tiene en frente, esto debe ser estudiado con pinzas, porque puede que no todas las arquitecturas sean óptimas para todos los problemas, a pesar que igualmente puedan aplicarse.

Para poder implementar una arquitectura en un código que parece no tenerla es cuando se comienza un proceso de reestructuración o refactorización del mismo, para conseguir que este aparte de ser comprensible más fácilmente, cumpla con requisitos de arquitectura.

Es importante que la arquitectura tenga la capacidad de adaptarse al proceso de transformación, no que solo sea capaz de crear. Porque pareciera que al ver un problema que involucre transformación pareciera tener las mismas características que uno de construir desde cero, cuando no exactamente igual. Cada uno posee características especiales y pueden coincidir en algunas que hacer que algunas arquitecturas sean aplicables a ambos, como pueden suceder todo lo contrario.

Visto de una forma objetiva, ya que se está tomando el tiempo y recursos para reconstruir un programa ¿Por qué no hacerlo flexible y escalable? Este es un punto de vista importante porque si no se toman factores de ese estilo, estamos cometiendo los mismos errores que cuando se desarrolló por primera vez. Cobra mucha importancia factores como los mencionados, documentar, integrar nuevas tecnologías y buscar dejar un trabajo amigable para el mantenimiento o posibles actualizaciones futuras de las que se encargue el mismo equipo, o incluso un equipo totalmente diferente.

8

Modelos El enfoque en los modelos que se implementen en la reingeniería deben ser compatibles con la ingeniería inversa, hablando específicamente de los modelos de desarrollo de software. El ingeniero de software debe ser capaz de adaptar algún modelo e incluir a la ingeniería inversa en su proceso. ¿Por qué dar tanta importancia a la ingeniería inversa?

Porque ésta disciplina es la que permitirá comprender el comportamiento del sistema y, posteriormente, lograr realizar los cambios de forma adecuada. Toda la reingeniería tiene su núcleo en la ingeniería inversa para poder analizar el comportamiento de un sistema.

Es por ello que en el modelo de desarrollo debe incluirse, y por lo tanto, el modelo debe aceptar este proceso. Por ejemplo, ya que estamos buscando un proceso de transformación en la fase de análisis de los requerimientos queremos poder incluir la ingeniería inversa para comprender el funcionamiento del sistema y luego poder implementar los cambios deseados.

Básicamente, debemos comprender primero como funciona el sistema para poder modificarlo, y la ingeniería inversa es la herramienta que permite esto último.

Durante este proceso, no se puede hacer uso de herramientas como las CASE (Computer Aided Software Engineer) porque de momento no se ha desarrollado ningún software que sea capaz de entender del todo los pensamientos que tuvo un ser humano en algún momento.

9

Mantenimiento El mantenimiento es una parte vital del software, esto ya refiriéndonos de una forma general fuera de cualquier contexto. La mantenibilidad de un sistema es lo que permite prolongar su tiempo de vida, o que este se pueda adaptar a nuevas tecnologías, o que permita integrar nuevas funciones con mayor facilidad, o que permita la corrección de errores sin una gran cantidad de problemas al modificar el sistema.

Todo desarrollo debe tomar en cuenta este aspecto, de no hacerlo lo único que hacemos es generar un efecto bola de nieve que en el futuro es donde se verá la magnitud de los problemas. Ya sea que en el futuro lo trate un tercero o nosotros mismos, lo que es seguro es que la dificultad será grande.

Si durante el desarrollo se toma el tiempo de dejar una documentación explicita, dejar un código limpio y entendible (esto no quiere decir que estén prohibidos los comentarios en el mismo). Cuando nos enfrentamos a un proceso de reingeniería tenemos que tomar en cuenta este factor cuando ya se está aplicando la ingeniería directa, la idea de esto es mejorar lo que se hizo en un pasado y no cometer los mismos errores.

Si el sistema termina siendo reconstruido y no se tomo en cuenta la mantenibilidad dejando un código comprensible, una documentación clara, ni se establecieron arquitecturas ni diseños claros. Lo único que hacemos es tropezar la misma piedra cuando la idea de reconstrucción implica mejora, pero no sola mejora en funcionamiento o cantidad de funciones, mejorar a nivel técnico también es importante.

10

Ingeniería Inversa Como mencionamos previamente, este es el núcleo del proceso de reingeniería. Su concepción tiene inicios en el mundo del hardware cuando los circuitos eran todos propietarios y cuando un competidor lanzaba un mejor dispositivo, las otras empresas del mercado se dedicaban al estudio del dispositivo para comprender su funcionamiento. Si la empresa que lanzó el dispositivo compartía información sería perjudicar su posicionamiento en el mercado.

El concepto terminó llegando al mundo del software, pero sería oportuno primero entender el concepto de forma general de la ingeniería inversa y esta no es más que el proceso de obtener información, diseño o arquitectura en función de un objeto en su resultado final. Llevado al mundo del software es el proceso de estudiar un programa para obtener información de su diseño o arquitectura por medio de los resultados que otorga y el estudio de su código fuente.

Este es un proceso principalmente de observación y análisis, en este no se implementan cambios reales. El objetivo es conocer como funciona un programa, esto se puede hacer probando algún programa ingresando datos ficticios y viendo su comportamiento, luego dirigirse al código fuente para analizar un poco lo que se realizó; teniendo conocimiento del lenguaje de programación en uso se puede detectar en la parte del código donde se recogen datos y luego de allí realizar un recorrido secuencial para ver las transformaciones de la variable y ver como se obtuvo el resultado visualizado.

11

Reestructuración

Esta es la parte en la que ya se aplica ingeniería directa, luego del largo y complejo proceso que puede ser llegar a conocer el funcionamiento del programa por medio del estudio de su comportamiento y código fuente, es cuando se puede finalmente comenzar a reescribir. Se puede inicial estableciendo estructuras de código que, inicialmente, sean más fáciles de comprender eliminando complejidad innecesaria.

Cabe destacar que esta el oportunidad de actualizarlo incluso en el lenguaje de programación, ya que, cabe la posibilidad que el que utiliza sea de bajo nivel (común en sistemas heredados antiguos) haciéndolo más difícil de implementar cualquier modificación. Durante este proceso, como previamente se cuestionaron los procesos de negocio, puede darse el caso que toque eliminar alguna función del sistema.

Luego se puede reestructurar un poco más el código para que este cumpla con alguna arquitectura que se definió en la fase de diseño y arquitectura, mejorando un poco más el código, e incluso llegando a optimizarlo. Luego que ya se tiene un código robusto, comprensible y sólido es ideal generar la documentación del mismo mediante la estrategia de documentar a la par que se modifica, esto permite que el proceso sea más fácil de llevar a cabo.

Esta es una fase mucho más técnica, los procesos de negocios se vieron involucrados previamente al momento de cuestionarlos y adaptar el proceso con ellos. Sin embargo, si se desean implementar funciones nuevas se tiene que volver a pasar por el proceso de diseño, y en éste se involucra de forma cercana los procesos de negocio.

12

Conclusión

Considero que durante el recorrido de este libro no solo se hablo de la reingeniería de software, sino que también fue la oportunidad ideal para recordar un poco los aspectos importantes del desarrollo de software que suelen ser dejados de lado. Un programa no se construye únicamente con código, el código debe estar organizado.

El tiempo pasó y nos encontramos a día de hoy con la ingeniería de software y un montón de metodologías que se adaptan a necesidades, problemas e incluso comodidades. La reingeniería nace porque el mundo de software moderno tiene la necesidad de comprender el complejo y desorganizado mundo de software de antes.

Si se quiere reconstruir un sistema de forma adecuada es importante tomar nota de aquellos errores que se cometieron en el pasado para no caer igual en ellos, por eso la importancia de aspectos como diseño, estructura, documentación y mantenibilidad.

Creo firmemente que al desarrollar el software debemos pensar un poco más allá, ver el futuro del mismo y nos solo estar estar estancados en la actualidad y futuro cercano. Si es cierto que al futuro lejano puede ser reemplazado o mejorado con mejores tecnologías pero si facilitamos ese trabajo, como nosotros hubiésemos querido que hicieran en el pasado cuando desarrollaron el programa que estemos reestructurando, hacemos que el desarrollo del software sea más amigable tanto en presente como a futuro.

Siempre hay que ver más allá.

II

Referencias Bibliográficas

III

Anónimo (2023). Reingeniería: conceptos y etapas. INESDI Business TechSchool. Recuperado el 19 de noviembre de 2023 en: https://www.inesdi.com/blog/reingenieria-concepto-y-etapas/ Benito, J (s/f). Reingeniería del Software. WordPress. Recuperado el 19 de noviembre de 2023 en: https://juanantoniomb.wordpress.com/reingenieria-del-software-2/ Torreblanca, J (2014). Reingeniería de Software. Sistemas Distribuidos. Recuperado el 19 de noviembre de 2023 en: https://alexistorreblanca.blogspot.com/?view=classic García, J; et al (2004). Metodología De Reingeniería Del Software Para La Remodelación De Aplicaciones Científicas Heredadas. Universidad de Salamanca. Recuperado el 20 de noviembre de 2023 en: https://gredos.usal.es/bitstream/handle/10366/21762/DPTOIA-IT-2004003.pdf;jsessionid=A6DDFBA73FB21722812CC710DB3F2537?sequence=1 Canelo, M (2020). ¿Qué son los patrones de diseño de software?. profile. Recuperado el 20 de noviembre de 2023 en: https://profile.es/blog/patrones-de-diseno-de-software/ Sharma, P (2022). Los 9 mejores modelos de desarrollo de software para elegir: fases y aplicaciones.

Cynoteck. Recuperado el 20 de noviembre de 2023 en: https://cynoteck.com/es/blog-post/top-softwaredevelopment-models-to-choose-from/ Huet, P (2022). Arquitectura de software: Qué es y qué tipos existen. OpenWebinars. Recuperado el 20 de noviembre de 2023 en: https://openwebinars.net/blog/arquitectura-de-software-que-es-y-que-tiposexisten/ Ruiz, J (2021). Ingeniería inversa: qué es, herramientas y técnicas. Universitat Oberta de Catalunya.

Recuperado el 21 de noviembre de 2023 en: https://blogs.uoc.edu/informatica/ingenieria-inversa-que-esherramientas-ytecnicas/#:~:text=La%20ingenier%C3%ADa%20inversa%20es%20el,fue%20el%20proceso%20de%20fabric aci%C3%B3n.

Anónimo (2022). Ingeniería inversa: concepto y aplicaciones. Ingenieros Asesores. Recuperado el 21 de noviembre de 2023 en: https://ingenierosasesores.com/actualidad/ingenieria-inversa-conceptoaplicaciones/ Anónimo (s/f). Reingeniería de Programación. Universidad Nacional Autónoma de México. Recuperado el 22 de noviembre de 2023 en: http://profesores.fi-b.unam.mx/heriolg/Reipro10.pdf

Universidad Bicentenaria de Aragua / La reingeniería de software es una disciplina que cobra una relevancia muy alta en el mundo de hoy en día porque nos encontramos muchas situaciones en las que debemos encontrar una forma de comprender el desorganizado mundo del software que existía previamente (decir que dejo de existir sería una gran mentira, todavía en parte sigue siendo desorganizado).

Es por ello el desarollo de este libro, donde se realiza una exploración por la disciplina de la reingeniería llegando a comprenderla un poco más para hacer frente a aquellos sistemas heredados que presentan miles de problemas, o incluso software actual pero falto de documentación y mal estructurado.

Al igual que se hace un repaso por aspectos fundamentales en el desarrollo de software que suelen ser dejados de lado.