domingo, 2 de diciembre de 2012

Reingeniería




Reingeniería del 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.
Entre los beneficios de aplicar reingeniería a un producto existente se puede incluir:
·         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
La reingeniería del software involucra diferentes actividades como son:
·         análisis de inventarios
·         reestructuración de documentos
·         ingeniería inversa
·         reestructuración de programas y datos
·         ingeniería directa
con la finalidad de crear versiones de programas ya existentes que sean de mejor calidad y los mismos tengan una mayor facilidad de mantenimiento.

Figure 1
Figura 1. Pasos de la Reingeniería del 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 de código
El tipo más común de reingeniería es la reestructuración de código, se puede hacer con módulos individuales que se codifican de una manera que dificultan comprenderlos, probarlos y mantenerlos.
Llevar a cabo esta actividad requiere analizar el código fuente empleando 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
La reestructuració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 con una actividad de ingeniería inversa. La arquitectura de datos actual se analiza con minuciosidad y se define los modelos de datos necesarios, se identifican los objetivos de datos y los atributos, y después se revisa la calidad de las estructuras de datos existentes.
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 lo pueblan, los cambios en datos darán lugar invariablemente a cambios o bien de arquitectura o bien de código.
Ingeniería directa
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. Lo que es más importante, estas herramientas de reingeniería cada vez son más sofisticadas.
La ingeniería directa no solo recupera la información de diseño a partir del software existente, también utiliza esta información para alterar o reconstruir el sistema existente con la finalidad de mejorar su calidad global. En la mayoría de los casos el software sometido a reingeniería vuelve a implementar la función del sistema existente y también añade nuevas funciones o mejoras.

CASE



Herramientas CASE

Introducción

CASE, o Computer-Aided Software Engineering es un termino que ha estado por décadas. Este puede ser generalmente aplicado a cualquier sistema o colección de herramientas que ayuda a automatizar el proceso de diseño y desarrollo de software. Compiladores, editores estructurados, sistemas de control de código fuente, y herramientas de modelado son todas, estrictamente hablando herramientas CASE. Ellas impiden a los programadores tratar tan directamente con el hardware y les permiten trabajar en un alto nivel de abstracción en la definición de un sistema de software que entonces será construido.

Sistemas CASE

Hay generalmente tres tipos de sistemas CASE: Herramientas de Diseño, Ambientes de Construcción e Híbridos. Algunas de estas herramientas vienen por default en ambientes UNIX, como aquellas herramientas y utilidades que sirven para editar y compilar software.

Este tipo de herramientas (make, cvs/rcs, gcc, Text/groff) que vienen con UNIX son herramientas de desarrollo base, pero los sistemas CASE generalmente no se enfocan en el codificado/escritura/compilado, en vez de esto se encargan del proceso de diseño, refinamiento, documentación, construcción y administración de versiones necesarias para desarrollar y administrar un sistema o paquete de software. En un ambiente de un gran equipo o un gran paquete donde usted puede tener cinco versiones de este paquete en varios estados de desarrollo y/o desplegándose en cinco arquitecturas de hardware diferentes, suportando de tres a cuatro versiones de sistemas operativos, los procesos de trabajo son complejos.
Herramientas de diseño CASE auxilian grandes equipos de ingenieros en la especificación de sistemas de software y ayudan a automatizar la escritura de arquitecturas, documentación, y además integrar automáticamente esas piezas generadas en el IDE del desarrollador
Muchas herramientas CASE utilizan el Lenguaje de Modelado Unificado (UML) desarrollador por Grady Booch, Jim Rumbaugh, e Ivar Jacobsen. Su compañia, Rational Software es una de la más conocidas en sistemas CASE. La disponibilidad de UML ha revolucionado la habilidad de los ingenieros de software para crear especificaciones de sistemas que pueden ser relativamente fácil de traducir en código mantenible y que funcione.
Hay herramientas CASE para casi todo tipo de especialización que uno puede pensar, de diseño de base de datos a data warehousing, de generación de documentación a desarrollo de sistemas embedidos como teléfonos celulares.
Herramientas de construcción auxilian equipos grandes en la construcción y administración de liberación de paquetes de software.
Herramientas híbridas son un nuevo fenómeno, aplicación Servicios Web para crear un sistema distribuido que puede manejar múltiples estilos de desarrollo y la flexibilidad de agregar nuevas herramientas y servicios sin mucho trabajo. Buenos ejemplos incluyen Sourceforge, Collab.NET, y todas sus variantes.

Ejemplos de Herramientas CASE

Herramientas Case 


De acuerdo con Kendall y Kendall la ingeniería de sistemas asistida por ordenador es la aplicación de tecnología informática a las actividades, las técnicas y las metodologías propias de desarrollo, su objetivo es acelerar el proceso para el que han sido diseñadas, en el caso de CASE para automatizar o apoyar una o mas fases del ciclo de vida del desarrollo de sistemas. 

Cuando se hace la planificación de la base de datos, la primera etapa del ciclo de vida de las aplicaciones de bases de datos, también se puede escoger una herramienta CASE (Computer-Aided Software Engineering) que permita llevar a cabo el resto de tareas del modo más eficiente y efectivo posible. Una herramienta CASE suele incluir: 

Un diccionario de datos para almacenar información sobre los datos de la aplicación de bases de datos. 
Herramientas de diseño para dar apoyo al análisis de datos. 
Herramientas que permitan desarrollar el modelo de datos corporativo, así como los esquemas conceptual y lógico. 
Herramientas para desarrollar los prototipos de las aplicaciones. 
El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de una aplicación de bases de datos. 

Historia


En la década de los setenta el proyecto ISDOS desarrolló un lenguaje llamado "Problem Statement Language" (PSL) para la descripción de los problemas de usuarios y las necesidades de solución de un sistema de información en un diccionario computarizado. Problem Statement Analyzer (PSA) era un producto asociado que analizaba la relación de problemas y necesidades. 
Pero la primera herramienta CASE como hoy la conocemos fue "Excelerator" en 1984, era para PC. Actualmente la oferta de herramientas CASE es muy amplia y tenemos por ejemplo el EASYCASE o WINPROJECT. (Monografías.com)

Tecnología Case 


La tecnología CASE supone la automatización del desarrollo del software, contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de información y se plantean los siguientes objetivos: 

Permitir la aplicación práctica de metodologías estructuradas, las cuales al ser realizadas con una herramienta se consigue agilizar el trabajo. 
Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones. 
Simplificar el mantenimiento de los programas. 
Mejorar y estandarizar la documentación. 
Aumentar la portabilidad de las aplicaciones. 
Facilitar la reutilización de componentes software. 
Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilización de gráficos. 
Automatizar: 

Ø El desarrollo del software 
Ø La documentación 
Ø La generación del código 
Ø El chequeo de errores 
Ø La gestión del proyecto

Permitir: 
Ø La reutilización del software 
Ø La portabilidad del software 
Ø La estandarización de la documentación

Componentes de una herramienta case 


De una forma esquemática podemos decir que una herramienta CASE se compone de los siguientes elementos: 

Repositorio (diccionario) donde se almacenan los elementos definidos o creados por la herramienta, y cuya gestión se realiza mediante el apoyo de un Sistema de Gestión de Base de Datos (SGBD) o de un sistema de gestión de ficheros. 
Meta modelo (no siempre visible), que constituye el marco para la definición de las técnicas y metodologías soportadas por la herramienta. 
Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez, alimentar otros sistemas. Este elemento proporciona así un medio de comunicación con otras herramientas. 
Comprobación de errores, facilidades que permiten llevar a cabo un análisis de la exactitud, integridad y consistencia de los esquemas generados por la herramienta. 
Interfaz de usuario, que constará de editores de texto y herramientas de diseño gráfico que permitan, mediante la utilización de un sistema de ventanas, iconos y menús, con la ayuda del ratón, definir los diagramas, matrices, etc. que incluyen las distintas metodologías. 

Estructura general de una herramienta case 


La estructura CASE se basa en la siguiente terminología: 

CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases finales o superiores del ciclo de vida del desarrollo de sistemas como la planificación de sistemas, el análisis de sistemas y el diseño de sistemas. 
CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida como el diseño detallado de sistemas, la implantación de sistemas y el soporte de sistemas. 
CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen actividades como la gestión de proyectos y la estimación. 

Estado Actual

En las últimas décadas se ha trabajado en el área de desarrollo de sistemas para encontrar técnicas que permitan incrementar la productividad y el control de calidad en cualquier proceso de elaboración de software, y hoy en día la tecnología CASE (Computer Aided Software Engineering) reemplaza al papel y al lápiz por el ordenador para transformar la actividad de desarrollar software en un proceso automatizado. 

La tecnología CASE supone la –informatización de la informática—es decir –la automatización del desarrollo del software--, contribuyendo así a elevar la productividad y la calidad de en el desarrollo de los sistemas de información de forma análoga a lo que suponen las técnicas CAD/CAM en el área de fabricación. 
En este nuevo enfoque que persigue mejorar la calidad del software e incrementar la productividad en el proceso de desarrollo del mismo, se plantean los siguientes objetivos:
< Permitir la aplicación práctica de metodologías, lo que resulta muy difícil sin emplear herramientas.
< Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones.
< Simplificar el mantenimiento del software.

Mejorar y estandarizar la documentación. 
Aumentar la portabilidad de las aplicaciones. 
Facilitar la reutilización de componentes de software 
Permitir un desarrollo y un refinamiento (visual) de las aplicaciones, mediante la utilización de controles gráficos (piezas de código reutilizables).

Integración de las herramientas case en el futuro 


Las herramientas CASE evolucionan hacia tres tipos de integración: 

La integración de datos permite disponer de herramientas CASE con diferentes estructuras de diccionarios locales para el intercambio de datos. 
La integración de presentación confiere a todas las herramientas CASE el mismo aspecto. 
La integración de herramientas permite disponer de herramientas CASE capaces de invocar a otras CASE de forma automática. 

 Clasificación de las herramientas case 

No existe una única clasificación de herramientas CASE y, en ocasiones, es difícil incluirlas en una clase determinada. Podrían clasificarse atendiendo a: 
- Las plataformas que soportan.
- Las fases del ciclo de vida del desarrollo de sistemas que cubren.
- La arquitectura de las aplicaciones que producen.
- Su funcionalidad.
CASE es una combinación de herramientas software (aplicaciones) y de metodologías de desarrollo : 
1. Las herramientas permiten automatizar el proceso de desarrollo del software. 
2. Las metodologías definen los procesos automatizar.
Una primera clasificación del CASE es considerando su amplitud : 
TOOLKIT: es una colección de herramientas integradas que permiten automatizar un conjunto de tareas de algunas de las fases del ciclo de vida del sistema informático: Planificación estratégica, Análisis, Diseño, Generación de programas. 
WORKBENCH: Son conjuntos integrados de herramientas que dan soporte a la automatización del proceso completo de desarrollo del sistema informático. Permiten cubrir el ciclo de vida completo. El producto final aportado por ellas es un sistema en código ejecutable y su documentación.
Una segunda clasificación es teniendo en cuenta las fases (y/o tareas) del ciclo de vida que automatizan: 
UPPER CASE: Planificación estratégica, Requerimientos de Desarrollo Funcional de Planes Corporativos. 
MIDDLE CASE: Análisis y Diseño. 
LOWER CASE: Generación de código, test e implantación

Características Deseables De Una Case

Una herramienta CASE cliente / servidor provee modelo de datos, generación de código, registro del ciclo de vida de los proyectos, comunicación entre distintos ingenieros. Las principales herramientas son KnowledgeWare’s Application Development Workbench, TI’s, Information Engineering Facility (IEF), y Andersen Consulting’s Foundation for Cooperative Processing. 
Deberes de una herramienta CASE Cliente / servidor:
Ø Proporcionar topologías de aplicación flexibles. La herramienta debe proporcionar facilidades de construcción que permita separar la aplicación (en muchos puntos diferentes) entre el cliente, el servidor y más importante, entre servidores. 
Ø Proporcionar aplicaciones portátiles. La herramienta debe generar código para Windows, OS/ 2, Macintosh, Unix y todas las plataformas de servidores conocidas. Debe ser capaz, a tiempo de corrida, desplegar la versión correcta del código en la máquina apropiada. 
Ø Control de Versión. La herramienta debe reconocer las versiones de códigos que se ejecutan en los clientes y servidores, y asegurarse que sean consistentes. También, la herramienta debe ser capaz de controlar un gran número de tipos de objetos incluyendo texto, gráficos, mapas de bits, documentos complejos y objetos únicos, tales como definiciones de pantallas y de informes, archivos de objetos y datos de prueba y resultados. Debe mantener versiones de objetos con niveles arbitrarios de granularidad; por ejemplo, una única definición de datos o una agrupación de módulos. 
Ø Crear código compilado en el servidor. La herramienta debe ser capaz de compilar automáticamente código 4GL en el servidor para obtener el máximo performance. 
Ø Trabajar con una variedad de administradores de recurso. La herramienta debe adaptarse ella misma a los administradores de recurso que existen en varios servidores de la red; su interacción con los administradores de recurso debería ser negociable a tiempo de ejecución. 
Ø Trabajar con una variedad de software intermedios. La herramienta debe adaptar sus comunicaciones cliente / servidor al software intermedio existente. Como mínimo la herramienta debería ajustar los temporizadores basándose en, si el tráfico se está moviendo en una LAN o WAN. 
Ø Soporte multiusuarios. La herramienta debe permitir que varios diseñadores trabajen en una aplicación simultáneamente. Debe gestionarse los accesos concurrentes a la base de datos por diferentes usuarios, mediante el arbitrio y bloqueos de accesos a nivel de archivo o de registro. 
Ø Seguridad. La herramienta debe proporcionar mecanismos para controlar el acceso y las modificaciones a los que contiene. La herramienta debe, al menos, mantener contraseñas y permisos de acceso en distintos niveles para cada usuario. También debe facilitar la realización automática de copias de seguridad y recuperaciones de las mismas, así como el almacenamiento de grupos de información determinados, por ejemplo, por proyecto o aplicaciones. 
Ø Desarrollo en equipo, repositorio de librerías compartidas. Debe permitir que grupos de programadores trabajen en un proyecto común; debe proveer facilidades de check-in/ check-out registrar formas, widgets, controles, campos, objetos de negocio, DLL, etc.; debe proporcionar un mecanismo para compartir las librerías entre distintos realizadores y múltiples herramientas; Gestiona y controla el acceso multiusuario a los datos y bloquea los objetos para evitar que se pierdan modificaciones inadvertidamente cuando se realizan simultáneamente.

 Factores asociados a la implantación de las herramientas case

La difusión de las innovaciones en esta área ha comenzado a estudiarse a partir de los años 1940. Por ello, existen estudios teóricos al respecto, realizándose evaluaciones, adopción e implementación tecnológica.

Existe un amplio cuerpo de investigaciones disponibles sobre la adopción de innovaciones. Muchos de los estudios sobre innovación se han analizado bajo dos perspectivas: adopción y difusión (Kimberly, 1981). Mientras unos estudios usan la perspectiva de la adopción para evaluar la receptividad y los cambios de la organización o sociedad por la innovación, otros usan la perspectiva de la difusión para intentar entender por qué y cómo se difunde y qué características generales o principales de la innovación son aceptadas.


Conclusión


Sin lugar a dudas las herramientas CASE han venido a revolucionar la forma de automatizar los aspectos clave en el desarrollo de los sistemas de información, debido a la gran plataforma de seguridad que ofrecen a los sistemas que las usan y es que éstas, brindan toda una gama de componentes que incluyen todas o la mayoría de los requisitos necesarios para el desarrollo de los sistemas, han sido creadas con una gran exactitud en torno a las necesidades de los desarrolladores de sistemas para la automatización de procesos incluyendo el análisis, diseño e implantación.

Las Herramientas CASE se clasifican por su amplitud en: TOOLKIT, WORKBENCH además también se pueden dividir teniendo en cuenta las fases del ciclo de vida que automatizan: UPPER CASE, MIDDLE CASE, LOWER CASE.

Debido a la gran demanda que tienen las CASE su exigencia en cuanto a su uso ha ido aumentando, por lo que toda CASE debe entre otras cosas:

Proporcionar topologías de aplicación flexibles 
Proporcionar aplicaciones portátiles 
Brindar un Control de versión 
Crear código compilado en el servidor 
Dar un Soporte multiusuario 
Ofrecer Seguridad
Desde que se crearon éstas herramientas (1984) hasta la actualidad, las CASE cuentan con una credibilidad y exactitud que tienen un reconocimiento universal, siendo usadas por cualquier desarrollador y / o programador que busca un resultado óptimo y eficiente, pero sobre todo que busca esa minuciosidad necesaria de los procesos y entre los procesos.

13. Bibliografía

Analisis Y Diseño De Sistemas
3ª. Edición
Kendall & Kendall 
Páginas 15.16.17.18