domingo, 23 de febrero de 2014

Reingeniería de Software


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/



domingo, 16 de febrero de 2014

Leyes del mantenimiento de Software

Con el paso de los años se ha ido produciendo un volumen muy grande de software. En la actualidad, la mayor parte de éste software está formado por  código antiguo " heredado" (del inglés legacy code ); es decir, código de aplicaciones desarrolladas hace algún tiempo, con técnicas y herramientas en desuso y probablemente por personas que ya no pertenecen al colectivo responsable en este momento del mantenimiento del software concreto.
En muchas ocasiones, la situación se complica porque el código heredado fue objeto de múltiples actividades de mantenimiento. La opción de desechar este software y reescribirlo para adaptarlo a las nuevas necesidades tecnológicas o a los cambios en la especificación es muchas veces inadecuada por la gran carga financiera que supuso el desarrollo del software original y la necesidad económica de su amortización.

Los problemas específicos del mantenimiento de código heredado han sido  caracterizados en las llamadas  Leyes del Mantenimiento del Software,  propuestas por Lehman.

Continuidad del Cambio: Un programa utilizado en un entorno del mundo  real esta destinado a cambiar, ya que, en caso contrario, será utilizado cada  vez menos en dicho entorno (tan pronto como un programa ha sido escrito,  está ya desfasado).
– Las razones que conducen a esta afirmación son varias:
• A los usuarios se les ocurren nuevas funcionalidades cuando comienzan a  utilizar el software;
• Nuevas características en el hardware pueden permitir mejoras en el software;
• Se encuentran defectos en el software que deben ser corregidos;
• El software debe instalarse en otro sistema operativo o máquina;
• O el software necesita ser más eficiente.

Incremento de la Complejidad: A la par que los cambios transforman los programas, su estructura se hará progresivamente más compleja salvo que se haga un esfuerzo activo para evitar este fenómeno. Esto significa que al realizar cambios en un programa (excluyendo el mantenimiento preventivo), la estructura de dicho programa se hace más compleja cuando los programadores no pueden o no quieren usar técnicas de ingeniería del software.

Evolución del Programa: La evolución de un programa es un proceso autorregulado. Las medidas de determinadas propiedades (tamaño, tiempo entre versiones y número de errores) revelan estadísticamente determinadas tendencias e invariantes.

Conservación de la familiaridad: A lo largo del tiempo de vida de un programa, la carga que supone el desarrollo de dicho programa es aproximadamente constante e independiente de los recursos dedicados.

Conservación de la Familiaridad: Durante todo el tiempo de vida de un producto software, el incremento en el número de cambios incluidos con cada versión (release) es aproximadamente constante.

Crecimiento continuado: Su contenido funcional debe incrementarse continuamente para satisfacer al usuario durante el periodo de vida.

Decremento de la calidad: Su calidad parecerá disminuir a menos que se mantengan y adapten rigurosamente a los cambios en su ambiente operacional.

Realimentación del sistema: Sus procesos de evolución constituyen sistemas de retroalimentación con niveles, ciclos y agentes múltiples y deben tratarse de forma que se obtengan mejorías significativas sobre cualquier base razonable.


Estas leyes no son otra cosa que el resultado del estudio científico de experiencia acumulada en Ingeniería del Software. Como tales, nos pueden servir como base para la planificación de las actividades de mantenimiento y para la toma de decisiones al respecto.

domingo, 2 de febrero de 2014

Mantenimiento de Software

Aun cuando son las últimas en el ciclo de vida del software, las actividades  de mantenimiento no son las menos importantes. Muy al contrario demasiada importancia pues logran un mejor funcionamiento del software.

Definición de Mantenimiento
 El estándar IEEE 1219 [IEEE, 1993] define el Mantenimiento del Software como “la modificación de un producto software después de haber sido entregado [a los usuarios o clientes] con el fin de corregir defectos, mejorar el rendimiento u otros atributos, o adaptarlo a un cambio en el entorno”.
Pressman [1998] dice que “la fase mantenimiento se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software, y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente”.

En la definición de mantenimiento aparecen indicados, directa o  indirectamente, cuatro tipos de mantenimiento:
– Corregir defectos →correctivo
– Mejorar el rendimiento →preventivo/perfectivo u otras propiedades
– Adaptar a un cambio de entorno →adaptativo

Mantenimiento Correctivo
A pesar de las pruebas y verificaciones que aparecen en etapas anteriores del  ciclo de vida del software, los programas pueden tener defectos. El  mantenimiento correctivo tiene por objetivo  localizar y eliminar los posibles  defectos de los programas.
• Un defecto en un sistema es una característica del sistema con el potencial de  causar un fallo.
• Un  fallo ocurre cuando el comportamiento de un sistema es diferente del  establecido en la especificación. Entre otros, los fallos en el software pueden  ser de:
- Procesamiento, por ejemplo, salidas incorrectas de un programa.
- Rendimiento, por ejemplo, tiempo de respuesta demasiado alto en una búsqueda  de información.
- Programación, por ejemplo, inconsistencias en el diseño de un programa.
- Documentación, por ejemplo, inconsistencias entre la funcionalidad de un  programa y el manual de usuario.

Mantenimiento Adaptativo
Este tipo de mantenimiento consiste en la modificación de un programa  debido a  cambios en el entorno (hardware o software) en el cual se ejecuta.
• Los cambios pueden afectar a:
– el sistema operativo (cambio a uno más moderno),
– la arquitectura física del sistema informático (paso de una arquitectura de red de  área local a Internet/Intranet),
– o al entorno de desarrollo del software (incorporación de nuevos elementos o  herramientas como ODBC).
• La envergadura del cambio necesario puede ser muy diferente: desde un  pequeño retoque en la estructura de un módulo hasta tener que reescribir prácticamente todo el programa para su ejecución en un ambiente distribuido  en una red.
Los cambios en el entorno software pueden ser de dos clases:
– En el entorno de los datos, por ejemplo, al dejar de trabajar con un sistema de  ficheros clásico y sustituirlo por un sistema de gestión de bases de datos relacionales.
– En el entorno de los  procesos, por ejemplo, migrando a una nueva plataforma de  desarrollo con componentes distribuidos, Java, ActiveX, etc.
• Este tipo de mantenimiento es cada vez más frecuente debido principalmente  al cambio, cada vez más rápido, en los diversos aspectos de la informática:  nuevas generaciones de hardware, nuevos sistemas operativos -o versiones de  los antiguos-, y mejoras en los periféricos o en otros elementos del sistema  (frente a esto, la vida útil de un sistema software puede superar fácilmente los  diez años).


 Mantenimiento perfectivo:
Cambios en la especificación, normalmente debidos a cambios en los requerimientos de un producto software, implican un nuevo tipo de  mantenimiento llamado perfectivo. La casuística es muy variada. Desde algo tan simple como cambiar el formato de impresión de un informe, hasta la incorporación de un nuevo módulo funcional. Podemos definir el mantenimiento perfectivo como el conjunto de actividades para mejorar o añadir nuevas funcionalidades requeridas por el usuario. Se divide en dos:
 - Mantenimiento de Ampliación: incorporación de nuevas funcionalidades.
- Mantenimiento de Eficiencia: mejora de la eficiencia de ejecución.

Mantenimiento preventivo:
 Modificación del software para mejorar las propiedades de dicho software  (calidad y mantenibilidad) sin alterar sus especificaciones funcionales. Incluir  sentencias que comprueben la validez de los datos de entrada, reestructuración de los  programas para aumentar su legibilidad o incluir nuevos comentarios. Este tipo de  mantenimiento utiliza las técnicas de ingeniería inversa y reingeniería. El  mantenimiento para la reutilización especializado en mejorar la reusabilidad del software se incluye en este tipo.


El mantenimiento tiene una importancia muy grande debido a que si queremos  tener un  software libre de fallos o con fallos mínimos debemos darle mantenimiento para que tenga buena funcionabilidad y así satisfaga las necesidades del usuario.

Trabajos citados

ESCUELA SUPERIOR DE INFORMÁTICA, U. D.-L. (2010). Grupo Alarcos. Recuperado el 31 de Enero de 2014, de Grupo Alarcos: http://alarcos.inf-cr.uclm.es/doc/mso/slides/S1.pdf
Facultad de Estadística e Informática, U. V. (2000). http://www.uv.mx/fei/. Recuperado el 31 de Enero de 2014, de http://www.uv.mx/fei/: http://informatica.uv.es/iiguia/2000/IPI/material/tema7.pdf
Tlaxcala, U. A. (Agosto de 2011). http://ingenieria.uatx.mx/. Recuperado el 30 de Enero de 2014, de http://ingenieria.uatx.mx/: http://ingenieria.uatx.mx/