INGENIERIA DE SOFTWARE ASISTIDAS POR COMPUTADORAS

Ingeniería Del Software Asistida Por Computadoras

Introducción

TODO el mundo ha oído ese proverbio que habla de los hijos del zapatero: el zapatero está tan ocupado haciendo zapatos para los demás que sus hijos no tienen sus propios zapatos.

Antes de los años 90, muchos de los ingenieros de software fueron los hijos del zapatero. Aunque estos profesionales técnicos construyeron sistemas complejos y productos que automatizan los trabajos de otros, no utilizaron mucha automatización para ellos mismos.

En la actualidad, los ingenieros de software han recibido por fin su primer par de zapatos nuevos -la ingeniería del software asistida por computadora (CASE).

HERRAMIENTA CASE

¿Qué significa CASE?

El taller de ingeniería del software se denomina un entorno de apoyo integrado a proyectos, y el conjunto de herramientas que llena ese taller se denomina ingeniería del software asistida por computadora (CASE). CASE proporciona al ingeniero la posibilidad de automatizar actividades manuales y de mejorar su visión general de la ingeniería. Al igual que las herramientas de ingeniería y de diseño asistidos por computadora que utilizan los ingenieros de otras disciplinas, las herramientas CASE ayudan a garantizar que la calidad se diseñe antes de llegar a construir el producto.

Construcción de bloques  Básicos para CASE

Cada bloque de construcción forma el fundamento del siguiente, estando las herramientas situadas en la parte superior del montón. Es interesante tener en cuenta que el fundamento de los entornos CASE efectivos tiene relativamente poco que ver con las herramientas de ingeniería del software en sí. Más bien, los entornos para la ingeniería del software se construyen con éxito sobre una arquitectura de entornos que abarca un hardware y un software de sistemas adecuados. Además, la arquitectura del entorno deberá tener en cuenta los patrones de trabajo humano que se aplicarán durante el proceso de ingeniería del software.

 

Bloques  de Construcción CASE

Las arquitecturas del entorno, que constan de una plataforma hardware y de un soporte de sistema operativo (incluyendo software de red, gestión de la base de datos y servicios de gestión de objetos), establece los cimientos para un entorno CASE. Pero el entorno CASE en sí requiere otros bloques de construcción. Existe un conjunto de servicios de portabilidad que proporciona un puente entre las herramientas CASE, su marco de integración y la arquitectura del entorno. El marco de integración es un grupo de programas especializados que permiten a cada una de las herramientas comunicarse entre sí, para crear una base de datos del proyecto, y para mostrar el mismo aspecto al usuario final (el ingeniero del software). Los servicios de portabilidad permiten que las herramientas CASE y su marco de integración migren entre distintas plataformas del hardware y sistemas operativos sin un mantenimiento adaptativo significativo.

Los bloques de construcción representan un fundamento completo para la integración de herramientas CASE. Sin embargo, la mayor parte de las herramientas CASE que se utilizan en la actualidad no han sido construidas empleando todos los bloques de construcción anteriormente descritos. De hecho, algunas herramientas siguen siendo las «soluciones puntuales». Esto es, una herramienta se utiliza para prestar apoyo en una actividad de ingeniería del software concreta (por ejemplo, modelado de análisis), pero esta herramienta no se comunica directamente con otras, no está unida a una base de datos del proyecto, y no forma parte de un entorno integrado CASE. Aunque esta situación no es la ideal, se puede utilizar una herramienta CASE bastante eficiente, aunque se trate de una solicitud puntual.

 

En el extremo inferior del espectro de integración se encuentra la herramienta individual (solución puntual). Cuando las herramientas individuales proporcionan servicios para el intercambio de datos (como lo hacen la mayoría), el nivel de integración mejora ligeramente. Estas herramientas producen su salida en un formato estándar que deberá ser compatible con otras herramientas que sean capaces de leer ese formato.

La integración de fuente única se produce cuando un único vendedor de herramientas CASE integra una cierta cantidad de herramientas distintas y las vende en forma de paquete. Aunque este enfoque es bastante eficiente, la arquitectura cerrada de la mayoría de los entornos de fuente Única evita añadir fácilmente herramientas procedentes de otros fabricantes.

En el extremo superior del espectro de integración se encuentra el entorno de apoyo integrado a proyectos integrado (EAIP). Se han creado estándares en cada uno de los bloques de construcción descritos anteriormente. Los fabricantes de herramientas CASE utilizan los estándares EAIP para construir herramientas que sean compatibles con el EAIP, y que por tanto sean compatibles entre sí.

Las herramientas CASE se pueden clasificar por su función, por su papel como instrumentos para administradores o personal técnico, por su utilización en los distintos pasos del proceso de ingeniería del software, por la arquitectura del entorno (hardware y software) que les presta su apoyo, o incluso por su origen o coste. La taxonomía que se presenta a continuación utiliza como criterio principal la función.

Ø  Herramienta de ingeniería de procesos de  negocio

Ø  Modelado de procesos y herramientas de gestión

Ø  Herramientas de planificación de proyectos

Ø  Herramientas de análisis de riesgo

Ø  Herramientas de gestión de proyectos

Ø  herramientas de seguimiento de requisitos

Ø  Herramientas de métricas y de gestión

Ø  Herramientas de documentación

Ø  Herramientas de software de sistema

Ø  herramientas de control de calidad

Ø  Herramientas de gestión de bases de datos

Ø  Herramientas de gestión de configuración de software

Ø  Herramientas de análisis y diseño

Ø  Herramientas PROISIM

Ø  Herramientas de desarrollo y diseño de interfaz

Ø  Herramientas de construcción de prototipos

Ø  Herramientas de programación

Ø  Herramientas de desarrollo de Webs

Ø  Herramientas de integración y pruebas

Ø  Herramientas de análisis estáticos

Ø  Herramientas de análisis dinámico

Ø  Herramientas de gestión de pruebas

Ø  Herramientas de pruebas cliente/servidor

Ø  Herramientas de reingeniería

Entornos CASE Integrados

Requisitos de un entorno CASE integrado:

v  Proporcionar un mecanismo para compartir la información de la ingeniería del software entre todas las herramientas dentro del entorno.

v  Hacer posible que un cambio de un elemento de información se siga hasta los demás elementos de información relacionados.

v  Proporcionar un control de versiones y una gestión de configuración general para toda la información de la ingeniería del software.

v  Permitir un acceso directo y no secuencial a cualquier herramienta del entorno.

v  Establecer un apoyo automatizado para el modelo de procesos de software que se haya seleccionado, integrando herramientas CASE y elementos de configuración del software en una estructura estándar de desglose de trabajo.

v  Permitir que los usuarios de cada una de las herramientas puedan experimentar con el aspecto e interacción de la interfaz hombre-máquina.

v  Dar soporte a la comunicación entre ingenieros del software.

v  Recoger métricas tanto técnicas como de gestión que se puedan utilizar para mejorar el proceso y el producto.

Arquitectura de Integración

La capa de interfaz del usuario incorpora un conjunto de herramientas de interfaz estandarizado, con un protocolo de presentación común. El kit de herramientas de interfaz contiene software para la gestión de la interfaz hombre-máquina, y una biblioteca de objetos de visualización. Ambos proporcionan un mecanismo consecuente para la comunicación entre la interfaz y las herramientas CASE individuales.

El protocolo de presentación es el conjunto de líneas generales que proporciona un mismo aspecto a todas las herramientas CASE. Las convenciones del diseño de pantalla, nombres y organización del menú, iconos, nombres de los objetos, utilización del teclado y del ratón, y el mecanismo para acceder a las herramientas se definen todos ellos como parte del protocolo de presentación.

 

La capa de herramientas incorpora un conjunto de servicios de gestión de herramientas con las herramientas CASE en sí. Los servicios de gestión de herramientas (SGH) controlan el comportamiento de las herramientas dentro del entorno. Si durante la ejecución de una o más herramientas se emplea la multitarea, SGH efectúa la sincronización y comunicación multitarea, coordina el flujo de información desde el repositorio y el sistema de gestión de objetos a las herramientas, realiza las funciones de seguridad y auditoría y recoge métricas acerca de la utilización de herramientas.

La capa de gestión de objetos (CGO) lleva a cabo las funciones de gestión de configuración. En esencia, el software de esta capa de la arquitectura de marco de referencia proporciona el mecanismo para la integración de herramientas. Cada herramienta CASE «se enchufa» en la capa de gestión de objetos. Al funcionar en conjunto con el repositorio CASE, la CGO proporciona los servicios de integración un conjunto de módulos estándar que acoplan las herramientas con el repositorio. Además, la OML proporciona los servicios de gestión de configuración haciendo posible la identificación de todos los objetos de configuración, llevando a cabo el control de versiones y proporcionando apoyo para el control de cambios, auditorías y contabilidad de estados.

La capa de repositorio compartido es la base de datos CASE y las funciones de control de acceso que hacen posible que la capa de gestión de objetos interactúe con la base de datos. La integración de datos se logra mediante las capas de gestión de objetos y de repositorio compartido.

El Repositorio CASE

El Diccionario Webster define la palabra repositorio como  «todo objeto o persona considerado centro de acumulación o almacenamiento». Durante las primeras fases de la historia del desarrollo del software, el repositorio era en realidad una persona el programador que tenía que recordar la ubicación de toda la información relevante para un determinado proyecto de software, que tenía que recordar información que nunca se había escrito y que tenía que reconstruir la información que se había perdido. Tristemente, la utilización de una persona como «centro de acumulación y almacenamiento» (aunque corresponda con la definición del diccionario) no funciona demasiado bien. En la actualidad, el repositorio es una «cosa» una base de datos que actúa como centro tanto para la acumulación como para el almacenamiento de información de ingeniería del software.

EL papel del repositorio En CASE

El repositorio de un entorno CASE es el conjunto de mecanismos y de estructuras de datos que consiguen la integración entre datos y herramientas, y entre datos y datos. Proporciona las funciones obvias de un sistema de gestión de bases de datos

Funciones

Integridad de datos: incluye funciones para validar las entradas efectuadas en el repositorio, para asegurar la consistencia entre objetos relacionados, y para efectuar automáticamente modificaciones «en cascada» cuando un cambio efectuado en un objeto exige algún cambio en otros objetos relacionados con él

 Información compartida: proporciona un mecanismo para compartir información entre múltiples desarrolladores y entre múltiples herramientas; gestiona y controla el acceso multiusuario a los datos, y bloquea/desbloquea objetos para que los cambios no se superpongan inadvertidamente

Integración datos-herramientas: establece un modelo de datos al que pueden acceder todas las herramientas del entorno 1-CASE; controla el acceso a los datos, y lleva a cabo las funciones de gestión de configuración adecuadas

Integración duros-datos: el sistema de gestión de bases de datos relaciona los objetos de datos de tal manera que se puedan alcanzar las demás funciones

Imposición de la metodología: el modelo E-R de datos almacenado en el repositorio puede implicar un paradigma específico de ingeniería del software; como mínimo, las relaciones y los objetos definen un conjunto de pasos que se llevará a cabo para construir el contenido del repositorio

 Estandarización de documentos: la definición de objetos de la base de datos da lugar directamente a un enfoque estándar para la creación de documentos de ingeniería del software.

Para conseguir estas funciones, se define el repositorio en función de un metamodelo. El metamodelo determina la forma en que se almacena la información en el repositorio, la forma en que las herramientas pueden acceder a los datos y estos datos pueden ser visualizados por los ingenieros de software, el grado hasta el cual se puede mantener la seguridad e integridad de los datos, y la facilidad con que se puede ampliar el modelo ya existente para admitir nuevas necesidades. El metamodelo es la plantilla en la cual se sitúa la información de ingeniería del software.

Características y contenido

Las características y contenido del repositorio se entienden especialmente bien examinándolo desde dos perspectivas: ¿Qué es lo que hay que almacenar en el repositorio, y qué servicios específicos son los que proporciona el repositorio? En general, los tipos de cosas que habrá que almacenar en el repositorio incluyen

Ø  El problema que hay que resolver.

Ø  Información acerca del dominio del problema.

Ø  La solución del sistema a medida que va surgiendo.

Ø  Las reglas e instrucciones relativas al proceso de software (metodología) que se está siguiendo.

Ø  El plan del proyecto, sus recursos y su historia.

Ø  Información acerca del contexto organizativo.

Muchos requisitos del repositorio son iguales a los de las aplicaciones típicas que se construyen tomando como base un sistema de gestión de bases de datos de comercial (SGBD). De hecho, muchos de los repositorios CASE actuales hacen uso de un SGBD (normalmente relacional u orientado a objetos) como la tecnología de gestión de datos básica. Entre las características de un SGBD que dan soporte a la gestión de información de desarrollo del software se incluyen las siguientes:

Almacenamiento de datos no redundante. Cada objeto es almacenado sólo una vez, aunque es accesible por todas las herramientas CASE siempre y cuando estas lo necesiten.

Acceso de alto nivel. Se implementa un mecanismo común de acceso a los datos de tal modo que no sea preciso duplicar las funciones de gestión de datos en todas las herramientas CASE.

Independencia de datos. Las herramientas CASE y las aplicaciones destino se aíslan del almacenamiento físico para que no se vean afectadas cuando la configuración del hardware se cambie.

Control de transacciones. El repositorio implementa bloqueo de registros, admisiones de dos fases, registros de transacciones y procedimientos de recuperación para mantener la integridad de los datos cuando existen usuarios concurrentes.

Seguridad. El repositorio proporciona mecanismos para controlar quién puede visualizar y modificar la información contenida en él.

 Consultas e informes de datos ad hoc. El repositorio permite acceder directamente a su contenido mediante una interfaz de usuario cómoda tal como SQL, o mediante un «navegador» (browser) orientado a formularios, haciendo posible un análisis definido por el usuario que va más allá de los informes estándar proporcionados por el conjunto de herramientas CASE.

 Apertura. Los repositorios suelen proporcionar un mecanismo de importación/exportación sencillo que hace posible las cargas o transferencias de información al por mayor.

 Soporte multiusuario. Un repositorio robusto deberá permitir que múltiples desarrolladores trabajen en una aplicación al mismo tiempo. Deberá gestionar el acceso concurrente a la base de datos mediante múltiples herramientas y por parte de múltiples usuarios, con arbitraje de accesos y con bloqueos en el nivel de archivos o registros. Para los entornos basados en redes, el soporte multiusuario implica también que el repositorio se podrá comunicar mediante interfaz con protocolos (agentes de solicitud de objetos) y servicios comunes de red.

El entorno CASE también efectúa demandas especiales con respecto al repositorio que van más allá de lo que está disponible directamente en un SGBD comercial. Entre las características especiales de los repositorios CASE se incluyen las siguientes:

 Almacenamiento de estructuras de datos sofisticadas. El repositorio debe admitir tipos de datos complejos tales como diagramas, documentos y archivos, así como sencillos elementos de datos. Un repositorio también incluye un modelo de información (o metamodelo) que describe la estructura, relaciones y semántica de los datos almacenados en él. El metamodelo deberá poder ampliarse para dar cabida a representaciones nuevas y a una información organizativa única. El repositorio no solamente almacena modelos y descripciones de los sistemas en desarrollo, sino que los metamodelos asociados (esto es, una información adicional que describe la información de ingeniería del software en sí, tal como el momento en que se ha creado un componente de diseño concreto, su estado actual y la lista de componentes de los cuales depende).

Imposición de una integridad. El modelo de información del repositorio contiene también reglas, o políticas, que describen reglas de negocios válidas y otras restricciones y requisitos acerca de la información que se inserta en el repositorio (directamente o a través de una herramienta CASE). Es posible emplear un servicio llamado disparador para activar las reglas asociadas a un objeto siempre que este sea modificado, lo cual hace posible verificar la validez de los modelos de diseño en tiempo real.

 Interfaz de herramientas ricas en términos semánticos. El modelo de información del repositorio (el metamodelo) contiene una semántica que hace posible que toda una gama de herramientas interpreten el significado de los datos almacenados en el repositorio. Por ejemplo, un diagrama de flujo de datos creado mediante una herramienta CASE se almacena en el repositorio en un formulario basado en el modelo de información e independiente de toda representación interna que pueda utilizar la herramientas en sí. Entonces otra herramienta CASE puede interpretar el contenido del repositorio y utilizar la información cuando la necesite para su tarea. De este modo, la semántica almacenada en un repositorio permite compartir datos entre una gran variedad de herramientas, a diferencia de las conversiones específicas entre herramientas, o entre «puentes».

Gestión de proceso y proyectos. Un repositorio contiene información no sólo acerca de la aplicación de software en sí, sino también acerca de las características de cada proyecto en particular, y del proceso general de la organización para el desarrollo del software (fases, tareas y productos). Esto abre posibilidades para la coordinación automatizada de la actividad de desarrollo técnico con la actividad de gestión del proyecto. Por ejemplo, la actualización del estado de las tareas de proyectos se podría efectuar de forma automática o bien como un producto derivado de la utilización de herramientas CASE. La actualización de estado resultará muy fácil para los desarrolladores, sin tener que abandonar el entorno de desarrollo normal. La asignación de tareas y consultas también se puede gestionar por correo electrónico. Los informes de problemas, las tareas de mantenimiento, las autorizaciones de cambios, y los estados de reparación se pueden coordinar y monitorizar mediante herramientas que acceden al repositorio.

Las siguientes características del repositorio son abarcadas todas ellas por la gestión de configuración del software. Se vuelven a examinar aquí para hacer hincapié en su interrelación con los entornos CASE.

 Versiones. A medida que avanza un proyecto, se irán creando muchas versiones de productos individuales. El repositorio deberá ser capaz de guardar todas estas versiones para hacer posible una gestión efectiva de las versiones de los productos y para permitir que los desarrolladores vuelvan a las versiones anteriores durante la comprobación y depuración. El repositorio CASE deberá ser capaz de controlar una amplia variedad de tipos de objetos entre los que se incluyen texto, gráficos, mapas de bits, documentos complejos y objetos Únicos como definiciones de pantalla y de informes, archivos de objetos, datos de comprobación y resultados. Un repositorio maduro rastrea las versiones de objetos con niveles arbitrarios de granularidad, por ejemplo, se puede rastrear cada definición de datos o agrupamiento de módulos. Para dar apoyo al desarrollo paralelo, el mecanismo de control de versiones deberá permitir múltiples derivados (variantes) a partir de un solo predecesor. Así pues, un desarrollador podrá estar trabajando al mismo tiempo, en dos soluciones posibles para un problema de diseño generadas las dos desde el punto de partida.

Seguimiento de dependencias y gestión de cambios. El repositorio gestiona una amplia variedad de relaciones entre los elementos de datos almacenados en él. Entre estas se cuentan las relaciones entre entidades y procesos de la empresa, entre las partes de un diseño de aplicación, entre componentes del diseño y la arquitectura de la información de la empresa, entre elementos de diseño y productos, etc. Algunas de las relaciones son meramente asociaciones, y algunas son dependencias o relaciones obligatorias. El mantenimiento de estas relaciones entre objetos de desarrollo se denomina administración de enlaces.

Seguimiento de requisitos. Esta función especial depende de la gestión de enlaces y proporciona la capacidad de hacer seguimiento de los componentes de diseño y de los productos derivados que proceden de una especificación de requisitos específica (seguimiento progresivo). Además, proporciona la capacidad de identificar cuáles son los requisitos que generaron cualquier producto derivado (seguimiento regresivo).

Gestión de configuración. Una función de gestión de configuración que trabaja muy cerca de las funciones de versiones y gestión de enlaces para hacer seguimiento de una serie de configuraciones que representarán hitos específicos del proyecto o de versiones de producción. La gestión de versiones proporciona las versiones necesarias, y la gestión de enlaces hace seguimiento de las interdependencias.

 Seguimiento de auditoría. El seguimiento de auditoría establece información extra acerca de cuándo, por qué, y por quién son efectuados los cambios. La información acerca de las fuentes de las modificaciones se pueden introducir en forma de atributos de objetos específicos del repositorio. Un mecanismo disparador del repositorio resultará útil para solicitar al desarrollador o a la herramienta que esté utilizando que inicie la introducción de información de auditoría. (tal como la razón del cambio) siempre que se modifique un elemento de diseño.

Ejemplo para el uso de la herramienta CASE "Power Designer", en el cual se diseña el modelo conceptual de una base de datos y luego se generan ...

REINGENIERIA

REINGENIERIA

INTRODUCCIÓN.

La ingeniería se produce en dos niveles distintos de abstracción. En el nivel de 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. En el 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 ?

 Tenga en consideración cualquier producto de tecnología que haya adquirido. Lo ve con regularidad, pero está envejeciendo. Se rompe con frecuencia, tarda en  repararse y ya no representa la última tecnología. 

Qué se puede hacer?

Si el producto es de hardware, probablemente lo tirará y se comprará uno nuevo. Pero si es un software personalizado, no dispondrá la opción de tirarlo. Necesitará reconstruirlo. Creará un producto con una funcionalidad nueva, un mejor rendimiento y fiabilidad, y un mantenimiento mejorado. Eso es lo que llamamos reingeniería.

¿Quién lo hace?

A nivel de negocio, la reingeniería es ejercida por especialistas de negocio (frecuentemente empresas de consultoría). A nivel de software, la reingeniería es ejecutada por ingenieros del software.

¿Por qué es importante?

Vivimos en un mundo en constante cambio. Las demandas de funciones de negocios y de tecnología de información que las soportan están cambiando a un ritmo que impone mucha presión competitiva en todas las organizaciones comerciales. Tanto los negocios como el software que soportan (o es) el negocio deberán diseñarse una vez más para mantener el ritmo.

 

 

REINGENIERIA DE PROCESOS DE NEGOCIOS.

La reingeniería constituye una recreación y reconfiguración de las actividades y procesos de la empresa, lo cual implica volver a crear y configurar de manera radical él o los sistemas de la compañía a los efectos de lograr incrementos significativos, y en un corto período de tiempo, en materia de rentabilidad, productividad, tiempo de respuesta, y calidad, lo cual implica la obtención de ventajas competitivas.

Reingeniería es el rediseño rápido y radical de los procesos estratégicos de valor agregado y de los sistemas, las políticas y las estructuras organizacionales que los sustentan para optimizar los flujos de trabajo y la productividad de una organización.

Procesos de negocios

Qué es un Proceso de  Negocios?

Un proceso de negocio es un conjunto de tareas lógicamente relacionadas que se llevan a cabo para obtener  un determinado resultado de negocio

 

Cada proceso de negocio posee un cliente bien definido -una persona o grupo que recibe el resultado (por ejemplo: una idea, un informe, un diseño, un producto  X . Además, los procesos de negocio cruzan los límites organizativos. Requieren que distintos grupos de la organización participen en las «tareas lógicamente relacionadas » que definen el proceso.

Todo sistema es en realidad una jerarquía de subsistemas

Cada uno de los sistemas de negocios (también llamados función  de negocios) están compuestos por uno o más procesos de negocio, y cada proceso de negocio está definido por un conjunto de subprocesos.

La RPN se puede aplicar a cualquier nivel de la jerarquía, pero a medida que se amplía el ámbito de la RPN (esto es, a medida que se asciende dentro de la jerarquía) los riesgos asociados a la RPN crecen de forma dramática. Por esta razón, la mayor parte de los esfuerzos de la RPN se centran en procesos o subprocesos individuales.

Principios de reingeniería de procesos.

En muchos aspectos, la RPN tiene un objetivo y un ámbito idéntico al proceso de la ingeniería de la información . Lo ideal sería que la RPN se produjera de forma descendente, comenzando por la identificación de los objetivos principales del negocio, y culminando con una especificación mucho más detallada de las tareas que definen un proceso específico de negocios.

Hammer  sugiere una serie de principios que nos guiarán por las actividades de la RPN cuando se comienza en el nivel superior (de negocios):

Organización en torno a los resultados, no en torno a las tareas:

Hay muchas compañías que poseen actividades de negocio compartimentadas, de tal modo que no existe una Única persona (u organización) que tenga la responsabilidad (o el control) de un cierto resultado de negocio. En tales casos, resulta difícil determinar el estado del trabajo e incluso más difícil depurar los problemas de proceso cuando esto sucede. La RPN deberá diseñar procesos que eviten este problema.

Hay que hacer que quienes utilicen la salida del proceso lleven a cabo el proceso:

El objetivo de esta recomendación es permitir que quienes necesiten las salidas del negocio controlen todas las variables que les permitan obtener esa salida de forma temporalmente adecuada. Cuanto menor sea el número de personas distintas implicadas en el proceso, más fácil será el camino hacia un resultado rápido.

Hay que incorporar el trabajo de procesamiento de información al trabajo real que produce la información pura. A medida que la TI se distribuye, es posible localizar la mayor parte del procesamiento de información en el seno de la organización que produce los datos. Esto localiza el control, reduce el tiempo de comunicación y la potencia de computación se pone en manos de quienes tienen fuertes intereses en la información producida.

Hay que manipular recursos geográficamente dispersos como si estuviesen centralizados. Las comunicaciones basadas en computadoras se han sofisticado tanto que es posible situar grupos geográficamente dispersos en una misma «oficina virtual». Por ejemplo, en lugar de emplear tres turnos de ingeniería en una única localización, toda la compañía podrá tener un turno en Europa, un segundo turno en Norteamérica y un tercer turno en Asia. En todos los casos, los ingenieros trabajarán durante el día y se comunicarán empleando redes de un elevado ancho de banda.

Hay que enlazar las actividades paralelas en lugar de integrar sus resultados. Cuando se utilizan diferentes grupos de empleados para realizar tareas en paralelo, es esencial diseñar un proceso que exija una continuación en la comunicación y coordinación. En caso contrario, es seguro que se producirán problemas de integración.

Hay que poner e1 punto de decisión en el lugar donde se efectúa el trabajo, e incorporar el control al proceso. Dentro de la jerga del diseño del software, esto sugiere una estructura organizativa más uniforme y con menos factorización.

Hay que capturar los datos una sola vez, en el lugar donde se producen. Los datos se deberán almacenar en computadoras, de tal modo que una vez recopilados no sea necesario volver a introducirlos nunca.

Todos y cada uno de los principios anteriores representan una visión dotalmente general» de la RPN. Una vez informados por estos principios, los planificadores de

negocios y los diseñadores de procesos deberán empezar a procesar el nuevo diseño. En la sección siguiente, se examinará el proceso de RPN más detalladamente.

Un modelo de RPN

Al igual que la mayoría de las actividades de ingeniería, la reingeniería de procesos de negocio es iterativa. Los objetivos de negocio, y los procesos que los logran, deberán adaptarse a un entorno de negocio cambiante. Por esta razón, no existe ni principio ni fin en la RPN -se trata de un proceso evolutivo.

 

Advertencias:

Es muy frecuente que se exagere la importancia de un nuevo enfoque de negocio - e n este caso, la RPN como si fuese la panacea, para después criticarla con tanta severidad que pase a ser un desecho. A lo largo de los Últimos años, se ha debatido de forma exagerada acerca de la eficacia de la RPN. En un resumen excelente del caso a favor  y en contra de la RPN, Weisz  expone su argumento de la manera siguiente:

Resulta tentador atacar a la RPN como si se tratase de otra reencarnación de la famosa bala de plata. Desde varios puntos de vista -pensamiento de sistemas, tratamiento de personal, simple historia- habría que predecir unos índices de fallos elevados para el concepto, índices que parecen ser confirmados por la evidencia empírica. Para muchas compañías parece  que la bala de plata no da en el blanco.

Para otras, sin embargo, el nuevo esfuerzo de la reingeniería ha tenido evidentemente su fruto ...

La RPN puede funcionar, si es aplicada por personas motivadas y formadas, que reconozcan que el proceso de reingeniería es una actividad continua. Si la RPN se lleva a cabo de forma efectiva, los sistemas de información se integran mejor con los procesos de negocios..

Dentro  del contexto de una estrategia más amplia de negocios se puede examinar la reingeniería de aplicaciones más antiguas, y también se pueden establecer de forma inteligente las prioridades de reingeniería del software

Aunque la reingeniería de negocio sea una estrategia rechazada por una compañía, la reingeniería del software es algo que debe hacerse. Existen decenas de millares de sistemas heredados -aplicaciones cruciales para el éxito de negocios grandes y pequeños- que se ven afectados por una enorme necesidad de ser reconstruidos o rehechos en su totalidad.

Reingeniería del Software

Este escenario resulta sumamente conocido: Una aplicación ha dado servicio y ha cubierto las necesidades del negocio de una compañía durante diez o quince años. A lo largo de este tiempo, ha sido corregida, adaptada y mejorada muchas veces. Las personas se dedicaban a esta tarea con la mejor de sus intenciones, pero las prácticas de ingeniería del software buenas siempre se echaban a un lado (por la urgencia de otros problemas). Ahora la aplicación se ha vuelto inestable. Sigue funcionando, pero cada vez que intenta efectuar un cambio se producen efectos colaterales graves e inesperados.

La imposibilidad de mantener el software no es un problema nuevo. De hecho, el gran interés por la reingeniería del software ha sido generado por un «iceberg» de mantenimiento de software que lleva creciendo desde hace más de treinta años.

Mantenimiento del software

Hace casi treinta años, el mantenimiento del software  se  caracterizaba  por ser como un «iceberg».  Esperábamos que lo que era inmediatamente visible fuera de verdad lo que había, pero sabíamos que una enorme  masa de posibles problemas y costes yacía por  debajo de la superficie. A principios de los años 70, el iceberg de  mantenimiento era lo suficientemente grande como para hundir un portaaviones. En la actualidad podría hundir toda la Armada.

El mantenimiento del software existente puede dar cuenta de más del 60 por 100 de las inversiones efectuadas por una organización de desarrollo, y ese porcentaje sigue ascendiendo a medida que se produce más software. Los lectores que tengan menos conocimientos en estos temas podrían preguntarse por qué se necesita tanto mantenimiento, y por qué se invierte  tanto esfuerzo.

Gran parte del software del que dependemos en la actualidad tiene por término medio entre diez y quince años de antigüedad. Aun cuando estos programas se crearon empleando las mejores técnicas de diseño y codificación conocidas en su época (y la mayoría no lo fueron), se crearon cuando el tamaño de los programas y el espacio de almacenamiento eran las preocupaciones principales. A continuación, se trasladaron a las nuevas plataformas, se ajustaron para adecuarlos a cambios de máquina y de sistemas operativos y se mejoraron para satisfacer nuevas necesidades del usuario; y todo esto se hizo sin tener en cuenta la arquitectura global.

El resultado son unas estructuras muy mal diseñadas, una mala codificación, una lógica inadecuada, y una escasa documentación de los sistemas de software que ahora nos piden que mantengamos en marcha ...

La naturaleza ubicua del cambio subyace en todos los tipos de trabajo del software. El cambio es algo inevitable cuando se construyen sistemas basados en computadoras; por tanto debemos desarrollar mecanismos para evaluar, controlar y realizar modificaciones.

Un modelo de procesos de reingeniería del  software

La reingeniería requiere tiempo; conlleva un coste de dinero enorme 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. La reingeniería de sistemas de información es una actividad que absorberá recursos de las tecnologías de la información durante muchos 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. Más adelante, en esta misma sección, se describirá este modelo, pero veamos en primer lugar algunos de los principios básicos. La reingeniería es una tarea de reconstrucción, y se podrá comprender mejor la reingeniería de sistemas de  información si tomamos en consideración una actividad análoga: la reconstrucción de una casa. Consideremos la situación siguiente:

Suponga que ha adquirido una casa en otro lugar. Nunca ha llegado a ver la finca realmente, pero la consiguió por un precio sorprendentemente reducido, advirtiéndosele que quizá fuera preciso reconstruirla en su totalidad. ¿Cómo se las arreglaría?

Antes de empezar a construir, sería razonable inspeccionar la casa. Para determinar si necesita una reconstrucción, usted (o un inspector profesional) creará una lista de criterios para que la inspección sea sistemática.

Antes de derribar y de construir toda la casa, asegúrese de que la estructura está en mal estado. Si la casa tiene una buena estructura, quizá sea posible remodelarla sin reconstruirla (con un coste muy inferior y en mucho menos tiempo).

Antes de empezar a reconstruir, asegúrese de que entiende la forma en que se construyó el original. Eche una ojeada por detrás de las paredes. Comprenda el cableado, la fontanería y los detalles internos de la estructura. Aunque vaya a eliminarlos todos, la idea que haya adquirido de ellos le servirán de mucho cuando empiece a construirla.

Si empieza a reconstruir, utilice tan solo los materiales más modernos y de mayor duración. Quizá ahora le cuesten un poquito más, pero le ayudarán a evitar un mantenimiento costoso y lento en fecha posterior.

Si ha decidido reconstruir, tenga una actitud disciplinada.  Utilice prácticas que den como resultado una gran calidad -tanto hoy como en el futuro.

Aunque los principios anteriores se centran en la reconstrucción de una casa, son aplicables igualmente a la reingeniería de sistemas y aplicaciones basados en computadoras.

estas actividades se producen de forma secuencial y lineal, pero esto no siempre es así. Por ejemplo, puede ser que la ingeniería inversa (la comprensión del funcionamiento interno de un programa) tenga que producirse antes de que pueda comenzar la reestructuración de documentos.

El paradigma de la reingeniería mostrado en la figura es un modelo cíclico. Esto significa que cada una de las actividades presentadas como parte del paradigma pueden repetirse en otras ocasiones. Para un ciclo en particular, el proceso puede terminar después de cualquiera de estas actividades.

Análisis de inventario. Todas las organizaciones de software deberán disponer de 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.

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 destacar que el inventario deberá revisarse con regularidad. El estado de las aplicaciones (por ejemplo, la importancia con respecto al negocio) puede cambiar en función del tiempo y, como resultado, cambiarán también las prioridades para la reingeniería.

 

Reestructuración de documentos. Una documentación escasa es la marca de muchos sistemas heredados.

Qué se puede hacer al respecto?

Opción  1: 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: dejémoslo así!

Opción 2: Es preciso actualizar la documentación, pero se dispone de recursos limitados. Se utilizará un enfoque «del tipo documentar si se modifica». Quizá no sea necesario volver a documentar por completo la aplicación. Más bien se documentarán por completo aquellas partes del sistema que estén experimentando cambios en ese momento. La colección de documentos Útil y relevante irá evolucionando con el tiempo.

Opción 3: El sistema es fundamental para el negocio, y  es preciso volver a documentarlo por completo. En este caso, un enfoque inteligente consiste en reducir la documentación al mínimo necesario.

Ingeniería inversa: Es el proceso de construir especificaciones de un mayor nivel de abstracción partiendo del código fuente de un sistema software o cualquier otro producto (se puede utilizar como punto de partida cualquier otro elemento de diseño, etc.).

Estas especificaciones pueden volver ser utilizadas para construir una nueva implementación del sistema utilizando, por ejemplo, técnicas de ingeniería directa.

Ventajas de la Ingeniería Inversa:

Reducir la complejidad del sistema: al intentar comprender el software se facilita su mantenimiento y la complejidad existente disminuye.

Generar diferentes alternativas: del punto de partida del proceso, principalmente código fuente, se generan representaciones gráficas lo que facilita su comprensión.

Recuperar y/o actualizar la información perdida (cambios que no se documentaron en su momento).

Detectar efectos laterales: los cambios que se puedan realizar en un sistema puede conducirnos a que surjan efectos no deseados, esta serie de anomalías puede ser detectados por la ingeniería inversa.

Facilitar la reutilización: por medio de la ingeniería inversa se pueden detectar componentes de posible reutilización de sistemas existentes, pudiendo aumentar la productividad, reducir los costes y los riesgos de mantenimiento.

La finalidad de la ingeniería inversa es la de desentrañar los misterios y secretos de los sistemas en uso a partir del código. Para ello, se emplean una serie de herramientas que extraen información de los datos, procedimientos y arquitectura del sistema existente.

TIPOS DE INGENIERIA INVERSA.

Ingeniería inversa de datos: Se aplica sobre algún código de bases datos (aplicación, código SQL, etc) para obtener los modelos relacionales o sobre el modelo relacional para obtener el diagrama entidad-relación.

Ingeniería inversa de lógica o de proceso: Cuando la ingeniería inversa se aplica sobre código de un programa para averiguar su lógica o sobre cualquier documento de diseño para obtener documentos de análisis o de requisitos.

Ingeniería inversa de interfaces de usuario: Se aplica con objeto de mantener la lógica interna del programa para obtener los modelos y especificaciones que sirvieron de base para la construcción de la misma, con objeto de tomarlas como punto de partida en procesos de ingeniería directa que permitan modificar dicha interfaz.

HERRAMIENTAS PARA LA INGENIERIA INVERSA.

Ø  Los Depuradores.

Ø  Las Herramientas de Inyección de Fallos.

Ø  Los Desensambladores.

Ø  Los compiladores Inversos o Decompiladores.

Las Herramientas CASE.

REESTRUCTURACION DEL SOFTWARE.

La reestructuración del software modifica el código fuente y/o los datos en un intento de adecuarlo a futuros cambios. Tiende a centrarse en los detalles de diseño de módulos individuales y en estructuras de datos locales definidas dentro de los módulos. Los beneficios de de la reestructuración son:

Programas de mayor calidad con mejor documentación y menos complejidad, y ajustados a las prácticas y estándares de la ingeniería del software moderno.

Reduce la frustración entre ingenieros del software que deban trabajar con el programa, mejorando por tanto la productividad y haciendo más sencillo el aprendizaje.

Reduce el esfuerzo requerido para llevar a cabo las actividades de mantenimiento.

Hace que el software se mas sencillo de comprobar y depurar.

La reestructuración se produce cuando la arquitectura básica de la aplicación es sólida, aún cuando sus interioridades técnicas necesiten un retoque. Comienza cuando existen partes considerables del software que son útiles todavía y solamente existe un subconjunto de todos los módulos y datos que requieren una extensa modificación.

Los tipos de reestructuración, básicamente son 2: del código y de datos.

Reestructuración del código.

La reestructuración del código se lleva a cabo para conseguir un diseño que produzca la misma función pero con mayor calidad que el programa original.

Reestructuración de datos.

Primero se realiza el ANALISIS del código.

Se evalúan las definiciones de los datos, archivos, O/I e Interfaces.

Extraer elementos y objetos de datos para obtener información del flujo de datos y comprender la estructura.

Ingeniería directa (forward engineering):

En un mundo ideal, las aplicaciones se  reconstruyen utilizan utilizando un «motor de reingeniería» automatizado. En el motor se insertm’a el programa viejo, que lo analizaría, reestructurm’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 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.

LA ECONOMIA DE LA REINGENIERIA

En un mundo perfecto, todo programa que no se pudiera mantener se retiraría inmediatamente, para ser sustituido por unas aplicaciones de alta calidad, fabricadas mediante reingeniería y desarrolladas empleando las prácticas de la ingeniería del software modernas. Sin embargo, vivimos en un mundo de recursos limitados. La reingeniería consume recursos que se pueden utilizar para otros propósitos de negocio. Consiguientemente, antes de que una organización intente efectuar una reingeniería de la aplicación existente, deberá llevar a cabo un análisis de costes y beneficios.

Se ha propuesto un modelo de análisis de costes y beneficios para la reingeniería. Se definen nueve parámetros:

P, = coste de mantenimiento anual actual para una aplicación;

P, = coste de operación anual de una aplicación;

P, = valor de negocios anual actual de una aplicación;

P, = coste de mantenimiento anual predicho después

P, = coste de operaciones anual predicho después de

P, = valor de negocio actual predicho después de la

P, = costes de reingeniería estimados;

P, = fecha estimada de reingeniería;

P, = factor de riesgo de la reingeniería (P, = 1 ,O es

L = vida esperada del sistema.

El coste asociado al mantenimiento continuado de una aplicación candidata (esto es, si no se realiza la reingeniería) se puede definir como:

Cmant=  [P₃-(P₁+P₂)] *L

Los costes asociados con la reingeniería se definen empleando la relación siguiente:

Creing=[P₆ - (P₄+P₅)] * (L –P₈) – (P₇ * P₉)]

Empleando los costes presentados en la ecuaciones (30.1) y (30.2), los beneficios globales de la reingeniería se pueden calcular en la forma siguiente>

Beneficio y coste = Creing- Cmant  El análisis de costes y beneficios presentados en las ecuaciones anteriores se puede llevar a cabo para todas aquellas aplicaciones de alta prioridad que se hayan identificado durante un análisis de inventario (Sección 30.2.2). Aquellas aplicaciones que muestren el mayor beneficio en relación con los costes podrán

destinarse a la reingeniería, mientras que las demás podrán ser propuestas hasta que se disponga de más recursos.

Descripcion de esta herramienta del mejoramiento que nos da la reingenieria