RESUMEN
Este trabajo tiene como objetivo
proponer un enfoque para el desarrollo de software en el que se incluyan
atributos, etapas y herramientas del proceso de reingeniería en la mayoría de
las fases del desarrollo de software. Mediante esta propuesta, se espera que al incorporar métodos de
reingeniería y refactoring como paso previo a la finalización de cada fase de
desarrollo, permita prever y disminuir el impacto que genera en las
organizaciones en términos de costos de tiempo, recurso humano y dinero las múltiples
correcciones, adaptaciones o mejoras no planificadas que puedan surgir a lo
largo del tiempo.
Este enfoque pretende ser aplicable
durante el diseño de nuevos sistemas de software y no para adaptación y
rediseño de aplicaciones existentes, en la cual el uso de las técnicas de
re-ingeniería es indispensable. Se espera que la aplicación de este enfoque
permita la creación de sistemas de software más fiables, eficientes, y con
poca necesidad de mantenimiento.
INTRODUCCIÓN
Ciertas aplicaciones de software pueden
haber sido desarrolladas con un diseño particular, pero las diferentes
modificaciones (debido a nuevos requerimientos) y actividades de mantenimiento
(debido a cambios en los procesos y/o errores) terminan afectando el diseño
original. Estas aplicaciones son difíciles y costosas de mantener. Es posible
rediseñar estos sistemas de software y desarrollarlos de nuevo, pudiendo partir
de la versión actual del software y aplicando las lecciones aprendidas. Esto se llama reingeniería de
la aplicación de software [1].
Las organizaciones que usan los sistemas
de información tienen que lidiar con el problema de que el software se vuelve
antiguo y redundante. Aunque mantener programas de software antiguos es costoso
la mayoría de las organizaciones dudan en hacerles una reingeniería, ya que
piensan que la reingeniería será más costosa que mantener los programas de
software antiguos. Pero la reingeniería de software es usualmente una opción de
bajo costo en comparación al mantenimiento de software. Las compañías de
software deben escoger programas que se van a usar por 5 años o una década.
La reingeniería de software presenta una
serie de dificultades, como: falta de
planificación exhaustiva para la reutilización del software, no utilización por
parte de los desarrolladores de software de herramientas o componentes
diseñados específicamente para ayudar e
impulsar la reutilización, falta de entrenamiento para ayudar a ingenieros de
software y administradores a comprender y explicar la reutilización,
resistencia del personal especializado
contra el concepto de reutilización, propugnar metodologías que no
facilitan la reutilización, como puede ser la descomposición funcional en detrimento de enfoques orientados a
objetos, falta de incentivos en las
compañías para producir componentes
reutilizables[2].
Se pueden definir diez elementos del
software que pueden reutilizarse: planes de proyecto, estimaciones de coste,
arquitectura, especificaciones y modelos de requisitos, diseños, código fuente,
documentación de usuario y técnica, interfaces de usuario, datos, y casos de
prueba [3].
Regularmente la utilización de la
reingeniería se efectúa tiempo después de la terminación del software, cuando
nuevos requerimientos son solicitados, así como también, cuando características
de calidad como rendimiento, eficiencia y usabilidad tienden afectar el
desempeño del software y el cumplimiento de los requerimientos de los usuarios.
Con la finalidad de disminuir los costos que se generan durante el proceso de
reingeniería, se plantea el uso de ciertas fases, procesos y técnicas para que
sean aplicadas durante el desarrollo de un sistema de software.
FASES
DE LA REINGENIERÍA DE SOFTWARE
A pesar de que no hay una definición de
proceso de reingeniería, sí que hay trabajos importantes en esta área, como el
de Rugaber y Wills [4], en el que proponen una serie de pasos para fomentar y
avanzar en la investigación en el área de la reingeniería.
En el proceso de reingeniería se podrían
distinguir las siguientes fases:
Traducción del código fuente.
El programa se convierte a una versión más moderna del lenguaje en que estaba
codificado o a un lenguaje diferente. Los motivos que llevan a una traducción pueden ser muy diversos:
falta de conocimientos del personal en ese lenguaje, falta de soporte en los
compiladores, actualización de la plataforma de hardware o de software,
políticas de empresa, necesidad de cambio en las interfaces de usuario, etc.
Ingeniería inversa.
Se analiza el programa y se extrae información de él, la cual ayuda a
documentar su organización y funcionalidad. Es el proceso de analizar el
software con el objetivo de recuperar su diseño y especificación. Lo normal es
que la entrada a este proceso sea el código fuente si se dispone de él.
Mejora de la estructura del programa.
Se analiza y modifica la estructura de control
del programa para hacerlo más fácil de
leer y comprender. Los programas pueden presentar lógica de control no
intuitiva lo que puede hacer que no se
entiendan fácilmente.
Modularización del programa.
Es el proceso de reorganizar un programa de forma que partes relacionadas se
integren de forma conjunta. Esto facilita eliminar componentes y mejorar la
comprensión. Se pueden considerar
diferentes tipos de módulos: abstracciones de datos, módulos de hardware,
módulos funcionales, módulos de apoyo al proceso, etc.
Reingeniería de datos.
Se trata de analizar y reorganizar las estructuras, e incluso a veces, los valores de los datos de un sistema
para hacerlos más comprensibles. Si la funcionalidad del sistema no cambia, la
reingeniería de datos no es necesaria.
No son fases que tengan que
desarrollarse todas necesariamente, sino que dependiendo de los casos podrán
figurar unas u otras.
Otros autores [5] desarrollan un modelo
de reingeniería del Software que sitúa al usuario como colaborador principal en
la tarea de especificar los requisitos del sistema. Las fases, en este caso
serían:
Definición del problema.
Se identifican objetivos, límites, beneficios, riesgos, estimaciones de
tiempos, etc., estableciendo una imagen real de lo que existe realmente ahora y
lo que se quiere obtener en el futuro.
Estudio del código antiguo.
Partiendo del código fuente en un lenguaje de tercera generación, se obtiene un
conjunto de documentos que ayudan a posteriores fases de la metodología.
Viabilidad del proyecto.
Consiste en detectar posibles errores en las especificaciones.
Rediseño de especificaciones.
Se busca conseguir, que las especificaciones representen de forma real la
visión futura deseada del sistema.
Creación de prototipos.
De aquellas partes que puedan dar problemas, o solamente de aquellas que vayan
a cambiar sustancialmente de la original.
Planificación de la implementación.
Consiste en diseñar la forma y modo en que se va a migrar de una herramienta a
otra.
Perfeccionamiento.
Realizar cambios en la nueva aplicación que aumenten la calidad del sistema.
ENFOQUE.
Para el enfoque planteado se propone
utilizar algunas de las fases anteriormente descritas de la reingeniería
integradas estrechamente como pasos previos a la finalización de cada etapa de
desarrollo de un software. A pesar de utilizar fases o procesos adicionales
durante el desarrollo de software se desea mantener un modelo de desarrollo lo
más ágil posible, siempre teniendo como objetivo el aseguramiento de la calidad
y garantizando |que las etapas de desarrollo tengan un nivel importante de
refinamiento y pruebas que permita poder prescindir de futuros procesos de reingeniería
y de refactoring que pudiesen generar altos costos a las organizaciones.
Pese a que uno de los objetivos
principales planteados con la utilización de este enfoque es poder prescindir de
futuros procesos de reingeniería, existe la posibilidad de que este proceso de
reingeniería sea inevitable, esto debido al constante crecimiento y evolución
de los requerimientos y necesidades de las organizaciones. En este escenario,
el desarrollo de software apoyado en este enfoque permitiría que el proceso de
reingeniería sea más ligero y genere menores costos de tiempo, dinero y
recursos que los que normalmente se requerirían.
En este sentido, se pretende aplicar el
enfoque de reingeniería como apoyo a los procesos de desarrollo, específicamente
como un modelo de cascada con fases iterativas, que agrega al modelo
originalmente propuesto por Winston Royce en 1970, una etapa de creación de
prototipo que permita validar con los usuarios el software el cumplimiento de
los requerimientos específicamente durante la etapa de diseño y de esta manera
aplicar las etapas de reingeniería correspondientes.
MODELO
DE DESARROLLO APOYADO EN LA REINGENIERÍA.
Se propone a continuación un modelo
basado en un estilo de desarrollo en cascada integrado con técnicas como la
creación de prototipos, procesos de revisión, validación y refinamiento
constante junto a los usuarios/clientes, y el uso de métodos propios de la
reingeniería de software. Con este modelo se pretende aprovechar las características
y fortalezas del estilo de desarrollo en cascada; estilo que ha probado a
través de los años tener gran efectividad promoviendo una máxima organización
en el proceso de implementación. Sin embargo, como cualquier estilo de
desarrollo tiene sus desventajas y con la integración con técnicas de
reingeniería se espera entre otras cosas eliminar los puntos débiles y
desventajas del uso de este estilo de desarrollo.
Las primeras 5 etapas del modelo pasarán
por un proceso de refinamiento, en el cual se definirán que método(s) de
reingeniería específico(s) se utilizará(n) para garantizar que los
requerimientos de los usuarios y los requerimientos de calidad sean cumplidos.
Un punto clave en el proceso de refinamiento lo establecería el uso de la
ingeniería inversa permitiendo analizar y extraer información, de cada fase de
desarrollo.
Como primer paso, durante la fase de
análisis de requerimientos se analizan y entienden los requerimientos buscando
evitar ambigüedades, luego de definir y especificar los requerimientos se
validan junto a los usuarios/clientes, si los requerimientos son aprobados y
validados por los usuarios se continua con las próxima fase, en caso contrario
se activa un proceso refinamiento en el cual se establece que técnica(s) de
reingeniería se utilizara(n), entre las cuales se proponen redefinición del
problema o redefinición de especificaciones para garantizar futuros errores y
ambigüedades en los requerimientos del sistema de software.
Durante la fase de diseño se planifica
una solución para el problema especificado en la fase previa. Este es el primer
paso para moverse del dominio del problema al dominio de la solución [1]. Antes
de continuar a la fase siguiente, se validan junto a los usuarios/clientes los
puntos que se consideren prioritarios, con especial atención a las
características arquitecturales y necesidades de recursos de software y
hardware. Dependiendo de la respuesta de los usuarios/clientes se refinará
mediante la reingeniería de datos y/o modularización del problema, o pasará a
la fase de codificación.
La creación de prototipos es una etapa
que se agrega en esta propuesta en búsqueda de mantener una comunicación
constante con los usuarios y que la versión de lo que será el sistema de
software no pueda solo verse en la etapa final, atacando una de las más
importantes desventaja del estilo de cascada. Esta fase se apoya en el proceso
de perfeccionamiento en búsqueda de asegurar cualidades como usabilidad y
facilidad de uso para los usuarios del software. Posteriormente cuando los
prototipos son validados por los usuarios se comienza la fase de codificación.
La fase de codificación se plantea la
revisión y el uso de pruebas unitarias de las funciones y módulos que conforman
el software. En esta fase se recomienda una considerable inversión de tiempo.
El rendimiento del software depende en gran medida de la búsqueda de la
optimización de las unidades de software, es por ello que se plantea la
revisión y prueba constante usando el perfeccionamiento, la mejora de la
estructura y el estudio del código antiguo. La utilización de este modelo
pretende disminuir el impacto que genera el estudio del código antiguo en
cuanto al tiempo invertido, debido a que la constante revisión y optimización
de las unidades de software hacen que la antigüedad del código no sea muy alta.
Fase de prueba, la principal medida de
control de calidad empleada durante el desarrollo de software. Es el paso final
de verificación y validación del proceso de desarrollo. Se realiza contrastando
los requerimientos originales. Con la ayuda de este enfoque se prevé evitar que
haya grandes cantidades de errores en las fases previas, especialmente la de
codificación. Esto debido al mejoramiento continuo y la ejecución pequeños
procesos de refinación, reingeniería y refactoring en todas fases anteiores.
Por último, la fase de mantenimiento
incluye todas las actividades realizadas para mantener el sistema operacional
después de la instalación de software [1]. Mediante este enfoque se propone
mantener una fase de mantenimiento que resulte mucho más liger-a que las
tradicionales, pues de cierta manera muchas de las actividades de mantenimiento
correctivo, adaptativo, mejorativo y preventivo se han desarrollado en las
fases anteriores.
CONCLUSIÓN
Este trabajo
presentó un enfoque que puede ser desarrollado a profundidad, creando
documentos de control específicos para cada técnica de reingeniería utilizada
durante las fases que componen el estilo planteado. Bajo este enfoque, se hace
necesario que desarrolladores, arquitectos,
líderes y miembros que integran el proceso de desarrollo de software
apliquen y perfeccionen las técnicas de reingeniería durante el análisis,
diseño, implementación, prueba y mantenimiento de los sistemas de software, en
busca de disminuir el alto impacto generado por entre otros, los altos costos
de los procesos de reingeniería durante la búsqueda de la adaptación de las
organizaciones a un mundo en constante evolución.
Por último se
recomienda a los miembros que forman parte del desarrollo de software realizar
una planificación exhaustiva para la verificación y validación del software, el
uso de herramientas o componentes diseñados específicamente para ayudar e impulsar la reutilización y el
aseguramiento de la calidad del software.
REFERENCIAS.
[1]
IBM. “Ingeniería de Software”. IBM Learning Services. Versión 4.2. Pp 89-91. Julio 2006.
[2]
Pressman, R.S.: Software Engineering: A Practitioner’s Approach. Fifth Edition.
McGraw-Hill. 2001.
[3] Jones,
C.: The economics of Object-Oriented Software, American Programmer, vol. 7, nº
10, October 1994, 28–35
[4]
Rugaber, S. and Will L.M.: Creating a research infrastructure for
reengineering. In 3 Rd Working Conference on Reverse Engineering. IEEE Computer Society Press, September 1996, 120-130.
[5] SICUMA, Grupo.
Leiva, J.: Construcción de especificaciones de interfaces en un proceso de
reingeniería, en: 2da. Conferencia Iberoamericana en Sistemas, Cibernética
e Informática CISCI 2003, Orlando
(Florida)-EEUU.
