Reingeniería de Procesos

El proceso de reingeniería del Software: Acompaña el análisis de inventarios.

•         La estructuración de documentos.

•         La ingeniería inversa.

•         La estructuración de datos.

•         La ingeniería avanzada.

Utilizando las mismas prácticas que se aplican en todos los procesos de ingeniería del software -las revisiones técnicas formales evalúan los modelos de análisis y de diseños, las revisiones especializadas tienen en consideración la capacidad de aplicación comercial y la compatibilidad, y la comprobación se aplica para descubrir los errores en el contenido, en la funcionalidad y en la interoperabilidad.

El negocio global se puede segmentar de la siguiente manera:

   §  El negocio

   §  sistemas de negocio

   §  proceso de negocio

   §  subprocesos de negocio

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

Un proceso de negocio es «un conjunto de tareas lógicamente relacionadas que se llevan a cabo para obtener un determinado resultado de negocio». Dentro del proceso de negocio, se combinan las personas, los equipos, los recursos materiales y los procedimientos de negocio con objeto de producir un resultado concreto. Entre los ejemplos de negocio se incluyen el diseño de un nuevo producto, la adquisición de servicios y suministros, la contratación de nuevos empleados o el pago a proveedores. Cada una requiere un conjunto de tareas y se basa en diversos recursos dentro del 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 t. 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.

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.

 

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.

Definición del negocio. Los objetivos de negocios se identifican en un contexto de cuatro controladores principales: reducción de costes, reducción de tiempos, mejora de calidad y desarrollo y potenciación del personal. Los objetivos se pueden definir en el nivel de negocios o para un componente específico del negocio.

Identificación de procesos. En esta actividad se identifican los procesos críticos para alcanzar los objetivos definidos en la definición del negocio, A continuación, pueden recibir prioridades en función de su importancia, necesidad de cambio, o cualquier otra forma que resulte adecuada para la actividad de reingeniería.

Evaluación de procesos. Los procesos existentes deberán analizarse y medirse  exhaustivamente. Las tareas de procesos se identificarán; los costes y los tiempos consumidos por las tareas de proceso se anotarán cuidadosamente, y se aislarán los problemas de calidad y rendimiento.

Especificación y diseño de procesos. Basándose en la información obtenida durante las tres primeras actividades de la RPN, se prepararán casos prácticos  para cada uno de los procesos que se tengan que rediseñar. Dentro del contexto de la RPN, los casos prácticos identifican un escenario que proporciona resultados a un cliente. Con el uso de casos prácticos como especificación del proceso, se diseña un nuevo conjunto de tareas  para el proceso.

Creación de prototipos. Es preciso construir un prototipo del proceso de negocios  rediseñado antes de integrarlo por completo en el negocio. Esta actividad «comprueba» el proceso para que sea posible efectuar refinamientos.

 

Refinamiento e instanciación. Basándose en la realimentación procedente del prototipo, se refina el proceso de negocio y después se instancia en el seno de un sistema de negocio.

En algunas ocasiones las actividades de RPN descritas anteriormente se utilizan junto con herramientas de análisis del flujo de trabajo. El objetivo de estas herramientas es construir un modelo del flujo de trabajo existente, en un esfuerzo por analizar mejor los procesos existentes. Además, para implementar las cuatro primeras actividades descritas en el modelo de procesos se pueden utilizar las técnicas de modelado que se asocian normalmente a las actividades de ingeniería de la información tales como la planificación de estrategias de información y el análisis de áreas de negócios.

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.

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

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.

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.

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.

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

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.

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.

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 se 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).

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 Descompiladores.

Ø  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 insertará 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 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.