INSTITUTO TECNOLGICO SUPERIOR DE TEPOSCOLULA

Nombre de la carrera: Ingeniera en sistemas computacionales

Nombre de la materia: Ingeniera de Software

Temas: Reingeniera

Integrantes: Doris Lzaro Chan vez Ana Castro Lpez Antonio de Jess Santiago Valentin Nombre del catedrtico: Ing. Eloy Snchez Salmorn

San Pedro y San Pablo Teposcolula a 20 de Marzo del 2013

REINGENIERA DE PROCESOS DE NEGOCIO

La reingeniera de procesos de negocio (RPN) rebasa el mbito de las

tecnologas de informacin y de la ingeniera de software. La RPN publicada en la revista Fortune: Es la bsqueda e implementacin de un cambio radical en el proceso de negocios para lograr resultados de vanguardia.

PROCESO DE NEGOCIOS Un proceso de negocios es un conjunto de tareas lgicamente relacionadas que se ejecutan para lograr un resultado de negocios especifico en el cual trabaja la gente, el equipo, los recursos materiales y los procedimientos del negocio en combinacin. Estos incluyen el diseo de un nuevo producto, la compra de servicios y suministros, la contratacin de un nuevo empleado y el pago a proveedores, donde cada uno demanda un conjunto de tareas empleando diversos recursos dentro del negocio. Cada proceso de negocio consta de un cliente definido, es decir, una persona o grupo que recibe el resultado.

Los procesos de negocio traspasan fronteras de organizacin, para ello se necesita que dichas organizaciones se involucren en las tareas lgicamente relacionadas que definen el proceso. Cada sistema de negocio llamado tambin funcin negocio, est compuesto de uno o ms procesos de negocio donde cada proceso define un subconjunto de subprocesos. La RPN se puede aplicar en cualquier nivel de jerarqua est conforme se ampla su mbito tomando en cuenta riesgos asociados. La RPN se enfoca ms a procesos individuales o subprocesos.

UN MODELO DE RPN La reingeniera de procesos de negocio es iterativa. Las metas y procesos de negocios deben adaptarse a un entorno de negocios cambiante, por lo que no existe principio ni fin, se trata de un proceso evolutivo. El modelo de la RPN define 6 actividades: Definicin del negocio: las metas del negocio se identifican con 4 controladores clave: reduccin de costo, de tiempo, mejora de calidad y desarrollo y fortalecimiento del personal. Identificacin del proceso: Se identifican los procesos cruciales para lograr las metas precisadas en la definicin del negocio. Evaluacin del proceso: Se analiza el proceso. Se identifican tareas del proceso. Especificacin y diseo del proceso: Con una retroalimentacin obtenida de las actividades anteriores, se preparan casos de uso para cada proceso que ser diseado. Elaboracin de prototipos: Una vez rediseado el proceso de negocios se convierte en prototipo antes de ser integrado completamente en el negocio. Refinamiento y particularizacin: con base a la retroalimentacin de prototipos, el proceso se refina y luego se particulariza dentro de un sistema de negocio.

REINGENERIA EN DESARROLLO DE SOFTWARE

MANTENIMIENTO DEL SOFTWARE:

Durante dcadas pasadas el mantenimiento de software se caracteriz como un iceberg. Durante los principios del decenio de 1970, el mantenimiento de iceberg era suficientemente grande como para hundir un portaaviones. El mantenimiento del software existente explica el 60 por ciento del esfuerzo que emplea una organizacin de desarrollo y dicho porcentaje continua elevndose conforme se produce ms software. Osborme y Chikofsky mencionan que en gran parte del software del que dependemos en la actualidad tiene en promedio de 10 a 15 aos de antigedad, aun cuando dichos programas se crearon empleado las mejores tcnicas de diseo y codificacin conocida en la poca, se crearon cuando el tamao de los programas y el espacio de almacenamiento eran las principales preocupaciones. Y esto llevo a que emigraran hacia nuevas plataformas, se ajustaron para adecuarlos a los cambios en las mquinas y a la tecnologa de los sistemas operativos y aumentaron para satisfacer las necesidades de los nuevos usuarios. Otra gran razn respecto del problema del mantenimiento del software es la movilidad del personal. Esto quiere decir que probamente la persona o equipo que realizo el trabajo original ya no este. El mantenimiento del software se define identificando cuatro actividades diferentes: Mantenimiento correctivo. Mantenimiento adaptativo. Mejora o mantenimiento de perfeccionamiento. Mantenimiento preventivo o reingeniera.

UN MODELO DE PROCESOS DE REINGENIERA DEL SOFTWARE:

La reingeniera requiere tiempo, cuesta cantidades significativas de dinero y absorbe recursos que de otro modo se ocuparan en problemas inmediatos, por estas razones la reingeniera no se logra en cuestin de meses, ni siquiera en unos cuantos aos. Por tanto, toda organizacin necesita una estrategia pragmtica respecto de la reingeniera del software. La reingeniera es una actividad de reconstruccin, y la reingeniera de los sistemas de informacin se comprende mejor si se considera una actividad anloga. Un ejemplo claro de la reingeniera es cuando una persona compra una casa en otro estado a un buen precio, pero con la advertencia de que tenga que reconstruirla. As que se procedera lo siguiente: Antes de que se pueda iniciar la reconstruccin sera razonable inspeccionar la casa. Antes de tirar y reconstruir toda la casa se debe tener la certeza que la estructura es dbil. Antes de iniciar la reconstruccin se debe tener la certeza de que se entiende como se construy anteriormente. Si se comienza a reconstruir solo se utilizaran materiales ms modernos y de larga duracin. Si se decide reconstruir es preciso disciplinarse en cuanto a ello. Utilcense prcticas que redundaran en alta calidad, hoy y maana. Aunque estos principios se enfocan en la reconstruccin de una casa. Tambin se aplican igualmente bien a la reingeniera de sistemas y aplicaciones basadas en computadoras

Estos procesos requieren aplicar un modelo de proceso de reingeniera del software que define seis actividades: Figura 2.1

Ingeniera Avanzada

Anlisis de Inventarios

Reestructuracin de los datos

Reestructuracin de documentos

Reestructuracin del cdigo Figura 2.1

Ingeniera Inversa

Anlisis de inventarios: Las organizaciones de software debera tener un inventario de todas sus aplicaciones. El inventario tal vez no sea ms que un modelo en una hoja de clculo que contenga informacin que proporciones una descripcin detallada de aplicaciones activas.

Reestructuracin de documentos: La documentacin dbil es la marca de muchos sistemas heredados: Crear documentacin consume demasiado tiempo: Si el sistema funciona vivir con lo que se tenga. La documentacin debe actualizarse, pero si se tiene recursos limitados. Se utilizara un enfoque de documentar cuando se toque El sistema es crucial para el negocio y debe volver a documentarse por completo.

Ingeniera inversa: El trmino inversa tienes sus orgenes en el mundo del hardware. Esto consiste en desensamblar un producto de hardware con la finalidad de comprender su estructura y diseo de fabricacin. Reestructuracin de cdigo: Algunos sistemas heredados tiene una arquitectura de programa relativamente slida, pero los mdulos individuales se codificaron en una forma que dificulta comprenderlos, probarlos y mantenerlos. En tales casos se puede reestructurar el cdigo dentro de los mdulos sospechosos. Reestructuracin de datos: Un programa con una arquitectura de datos dbil ser difcil de adaptar y mejorar. De hecho en muchas aplicaciones la arquitectura de datos est ms relaciona con la viabilidad a largo plazo de un programa que el cdigo fuente. Ingeniera directa: El programa antiguo seria insertado en el motor; analizando, reestructurando y luego regenerando en una forma que exhibiese los mejores aspectos de la calidad del software.

INGENIERA INVERSA
La ingeniera inversa puede obtener informacin de diseo a partir del cdigo fuente, pero el grado de abstraccin, la completud de la documentacin, el grado en el que las herramientas y un analista humano trabajan en conjunto, y la direccionalidad del proceso son enormemente variables. El grado de abstraccin de un proceso de ingeniera inversa y las herramientas utilizadas para efectuarlo se refieren a la sofisticacin de la informacin del diseo que es posible obtener el cdigo fuente. El proceso de ingeniera inversa debe ser capaz de derivar presentaciones de diseo de procedimiento, informacin de estructura de programa y datos, modelos de objeto, modelos de flujo de datos o control y clases UML, diagramas de estado y despliegue. Conforme el grado de

abstraccin aumenta, el ingeniero de software obtiene informacin que le permitir comprender con ms facilidad el programa. La completud de un proceso de ingeniera inversa se refiere al grado de detalle que se ofrece en un grado de abstraccin. En la mayora de los casos, la integridad disminuye conforme el grado de abstraccin aumenta. La completud mejora en proporcin directa con la cantidad de anlisis que efecta quien realiza la ingeniera inversa. La interactividad se refiere al grado en el que el ser humano est integrado con las herramientas automatizadas para crear un proceso de ingeniera inversa efectivo. En la mayora de los casos, conforme aumenta el grado de abstraccin la interactividad debe aumentar o la completud sufrir. Si la direccionalidad del proceso de ingeniera inversa es unidireccional, toda la informacin extrada del cdigo fuente se ofrece al ingeniero de software que entonces puede usarla durante cualquier actividad de mantenimiento. Si la direccionalidad es bidireccional, la informacin alimenta a una herramienta de reingeniera que intenta reestructurar o regenerar el programa antiguo.

INGENIERA INVERSA PARA COMPRENDER LOS DATOS

La ingeniera inversa de datos ocurre en diferentes grados de abstraccin y con frecuencia es la primera tarea de reingeniera. La ingeniera inversa de las actuales estructuras globales de datos establece el escenario para la introduccin de una nueva base de datos que abarque todo el sistema. Estructura de datos internos. Las tcnicas de ingeniera inversa para datos internos del programa se enfocan en la definicin de clases de objetos. Esto se logra al examinar el cdigo del programa con el propsito de agrupar las variables de programa relacionadas. Estructura de bases de datos. La reingeniera de un esquema de bases de datos en otro requiere comprender los objetos existentes y sus relaciones. Los siguientes pasos se pueden utilizar para definir el modelo de datos existente como un precursor para la reingeniera de un nuevo modelo de base de datos: 1) construccin de un modelo inicial de objeto, 2) determinacin de los candidatos clave, 3) refinar las clases tentativas, 4) definicin de generalizaciones y 5) descubrimiento de asociaciones. Una vez que se conoce la informacin se aplica una serie de transformaciones para correlacionar la estructura antigua de la base de datos con una nueva estructura de base de datos. INGENIERA INVERSA PARA COMPRENDER EL PROCESAMIENTO La ingeniera inversa para comprender el procesamiento comienza con un intento por comprender y luego extraer abstracciones de procedimientos representadas por el cdigo fuente. La funcionalidad global de todo el sistema se debe comprender antes de que ocurra un trabajo de ingeniera inversa ms detallado. En sistemas grandes la ingeniera inversa, se logra utilizando un enfoque semiautomatizado. Las herramientas automatizadas se utilizan para ayudar al ingeniero de software a comprender la semntica del cdigo existente.

INGENIERA INVERSA DE INTERFACES DE USUARIO

Entender por completo una interfaz de usuario existente requiere especificar la estructura y el comportamiento de la interfaz. Las preguntas bsicas a responder conforme comienza la ingeniera inversa de la IGU son: Cules son las acciones bsicas que debe procesar la interfaz? Cul es la descripcin compacta de las respuestas de comportamiento del sistema a estas acciones? Qu se entiende por reemplazo o, ms exactamente, qu concepto de equivalencia de interfaces es relevante en este caso? Una GUI sometida a reingeniera puede utilizar una barra de deslizamiento y un ratn para realizar la misma funcin.

DIFERENCIAS
La ingeniera inversa como su nombre lo indica parte de un sistema existente para realizar modificaciones en el mismo, a travs de modificar el cdigo fuente. En reingeniera en desarrollo de software el cambio es inevitable cuando se construyen sistemas basados en computadora; en consecuencia, se deben desarrollar mecanismos para evaluar, controlar y efectuar modificaciones. En el proceso de desarrollo de software engloba el proceso completo de desarrollo en cambio en la ingeniera inversa, parte del producto final dl desarrollo de software para realizar las modificaciones.