2.3 Reingeniería Del Software

Embed Size (px)

DESCRIPTION

2.3 Reingeniería Del Software

Text of 2.3 Reingeniería Del Software

2.3 Reingeniera del Software

La ingeniera se produce en dos niveles distintos de abstraccin. En elnivel de negocios, la reingeniera se concentra en el proceso de negocios con la intencin de efectuar cambios que mejoren la competitividad en algn aspecto de los negocios. En elnivel del software, la reingeniera examina los sistemas y aplicaciones de informacin con la intencin de reestructurarlos o reconstruirlos de tal modo que muestren una mayor calidad.

Qu es la Reingeniera?Tenga en consideracin cualquier producto de tecnologa que haya adquirido. Lo ve con regularidad, pero est envejeciendo. Se rompe con frecuencia, tarda enrepararse y ya no representa la ltima tecnologa.

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 opcin 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 reingeniera.

Quin lo hace?

Anivel de negocio, la reingeniera es ejercida por especialistas de negocio (frecuentemente empresas de consultora). A nivel de software, la reingeniera es ejecutada por ingenieros del software.

Por quesimportante?

Vivimos en un mundo en constante cambio.Lasdemandas de funciones de negocios y de tecnologa de informacin que las soportan estn cambiando a un ritmo que impone mucha presin competitiva en todas las organizaciones comerciales. Tanto los negocios como el software que soportan (o es) el negocio debern disearse una vez ms para mantener el ritmo

Cules son los Pasos?

1.Define las Metas comerciales.2.Identifica y evala los procesos de negocios existentes.3.Crea Procesos Comerciales revisados que mejoren las metas comerciales.

El Proceso de la Reingeniera del Software

Acompaa el anlisis de inventarios.La reestructuracin de documentos.La ingeniera Inversa.La estructuracin de Programas y datos.La ingeniera directa.

Cmo puedo estarsegurode que lo he hecho correctamente?

Utilizando las mismas prcticas que se aplican en todos los procesos de ingeniera del software: Revisiones tcnicas formales. Revisiones especializadas. La comprobacin.

Cul es el producto obtenido?

El resultado final es un proceso de reingeniera de negocios y/o el softwarede reingeniera que lo soporta.

REINGENIERIA DE PROCESOS DE NEGOCIOS.

La reingeniera constituye una recreacin y reconfiguracin 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 compaa a los efectos de lograr incrementos significativos, y en un corto perodo de tiempo, en materia de rentabilidad, productividad, tiempo de respuesta, y calidad, lo cual implica la obtencin de ventajas competitivas.Reingeniera es el rediseo rpido y radical de los procesos estratgicos de valor agregado y de los sistemas, las polticas y las estructuras organizacionales que los sustentan para optimizar los flujos de trabajo y la productividad de una organizacin.

Procesos de Negocios

Entre los ejemplos de negocio se incluyen el diseo de un nuevo producto, la adquisicin de servicios y suministros, la contratacin 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 diseo, un productoX . Adems, los procesos de negocio cruzan los lmites organizativos. Requieren que distintos grupos de la organizacin participen en las tareas lgicamente relacionadas que definen el proceso.

Todo sistema es en realidad una jerarqua de subsistemas:

Cada uno de los sistemas de negocios (tambin llamados funcinde negocios)estn compuestos por uno o ms 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 jerarqua, pero a medida que se ampla el mbito de la RPN (esto es, a medida que se asciende dentro de la jerarqua) los riesgos asociados a la RPN crecen de forma dramtica. Por esta razn, la mayor parte de los esfuerzos de la RPN se centran en procesos o subprocesos individuales.

Principios de reingeniera de procesos.

En muchos aspectos, la RPN tiene un objetivoyun mbito idntico al proceso de la ingeniera de la informacin. Lo ideal sera que la RPN se produjera de forma descendente, comenzando por la identificacin de los objetivos principales del negocio,yculminando con una especificacin mucho ms detallada de las tareas que definen un proceso especfico de negocios.Hammersugiere una serie de principios que nos guiarn por las actividades de la RPN cuando se comienza en el nivel superior (de negocios):

Organizacin en torno a los resultados, no en torno a las tareas:Hay muchas compaas que poseen actividades de negocio compartimentadas, de tal modo que no existe una nica persona (u organizacin) que tenga la responsabilidad (o el control) de un cierto resultado de negocio. En tales casos, resulta difcil determinar el estado del trabajo e incluso ms difcil depurar los problemas de proceso cuando esto sucede. La RPN deber disear procesos que eviten este problema.Hay que hacer que quienes utilicen la salida del proceso lleven a cabo el proceso:El objetivo de esta recomendacin 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 nmero de personas distintas implicadas en el proceso, ms fcil ser el camino hacia un resultado rpido.Hay que incorporar el trabajo de procesamiento de informacin al trabajo real que produce la informacin pura. A medida que la TI se distribuye, es posible localizar la mayor parte del procesamiento de informacin en el seno de la organizacin que producelosdatos. Esto localiza el control, reduce el tiempo de comunicacin y la potencia de computacin se pone en manos de quienes tienen fuertes intereses en la informacin producida.

Hay que manipular recursos geogrficamente dispersos como si estuviesen centralizados. Las comunicaciones basadas en computadoras se han sofisticado tanto que es posible situar grupos geogrficamente dispersos en una misma oficina virtual. Por ejemplo, en lugar de emplear tres turnos de ingeniera en una nica localizacin, toda la compaa podr tener un turno en Europa, un segundo turno en Norteamrica y un tercer turno en Asia. En todos los casos, los ingenieros trabajarn durante el da y se comunicarn 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 disear un proceso que exija una continuacin en la comunicacin y coordinacin. En caso contrario, es seguro que se producirn problemas de integracin.

Hay que poner e1 punto de decisin en el lugar donde se efecta el trabajo, e incorporar el control al proceso. Dentro de la jerga del diseo del software, esto sugiere una estructura organizativa ms uniforme y con menos factorizacin.

Hay que capturar los datos una sola vez, en el lugar donde se producen. Los datos se debern 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 visin dotalmente general de la RPN. Una vez informados por estos principios, los planificadores denegocios y los diseadores de procesos debern empezar a procesar el nuevo diseo. En la seccin siguiente, se examinar el proceso de RPN ms detalladamente.

Un modelo de RPN

Al igual que la mayora de las actividades de ingeniera, la reingeniera de procesos de negocio es iterativa. Los objetivos de negocio,ylos procesos que los logran, debern adaptarse a un entorno de negocio cambiante. Por esta razn, no existe ni principio ni fin en la RPN -se trata de un proceso evolutivo.

Reingeniera del Software:

Este escenario resulta sumamente conocido: Una aplicacin ha dado servicio y ha cubierto las necesidades del negocio de una compaa durante diez o quince aos. A lo largo de este tiempo, ha sido corregida, adaptadaymejorada muchas veces. Las personas se dedicaban a esta tarea con la mejor de sus intenciones, pero las prcticas de ingeniera del software buenas siempre se echaban a un lado (por la urgencia de otros problemas). Ahora la aplicacin se ha vuelto inestable. Sigue funcionando, pero cada vez que intenta efectuar un cambio se producen efectos colaterales graves e inesperados.

Qu se puede hacer?

La imposibilidad de mantener el software no es unproblema nuevo. De hecho, el gran inters por la reingeniera del software ha sido generado por un iceberg de mantenimiento de software que lleva creciendo desde hace ms de treinta aos.

Mantenimiento del software:

Hace casi treinta aos, el mantenimiento del softwaresecaracterizabapor ser como un iceberg.Esperbamos que lo que era inmediatamente visible fuera de verdad lo que haba, pero sabamos que una enormemasa de posibles problemas y costes yaca pordebajo de la superficie.Aprincipios de los aos 70, el iceberg demantenimiento era lo suficientemente grande como para hundir un portaaviones. En la actualidad podra hundir toda la Armada.

El mantenimiento del software existente puede dar cuenta de ms del 60 por 100 de las inversiones efectuadas por una organizacin de desarrollo, y ese porcentaje sigue ascendiendo a medida que se produce ms software. Los lectores que tengan menos conocimientos en estos temas podran preguntarse por qu se necesita tanto mantenimiento, y por qu se inviertetanto esfuerzo.Gran parte del softwa