Ingeniería del Software I

Ingeniería del Software I El contenido de los siguientes temas fue tomado del libro Un Enfoque Práctico de Pressman

Filosofías y Enfoques

Unidad IV – 4.1 Estándares y metodologías 4.1 IEEE 4.2 Ingeniería de software de sala limpia 4.3 Ingeniería del software basada en componentes 4.4 Reingeniería del software

Unidad IV – 4.1 Estándares y metodologías 4.1.1 IEEE IEEE corresponde a las siglas de The Institute of Electrical and Electronics Engineers, el Instituto de Ingenieros Eléctricos y Electrónicos, una asociación técnico-profesional mundial dedicada a la estandarización, entre otras cosas. Es la mayor asociación internacional sin fines de lucro formada por profesionales de las nuevas tecnologías, como ingenieros eléctricos, ingenieros en electrónica, ingenieros en sistemas e ingenieros en telecomunicación.... Su creación se remonta al año 1884, contando entre sus fundadores a personalidades de la talla de Thomas Alva Edison, Alexander Graham Bell y Franklin Leonard Pope. En 1963 adoptó el nombre de IEEE al fusionarse asociaciones como el AIEE (American Institute of Electrical Engineers) y el IRE (Institute of Radio Engineers). A través de sus miembros, más de 360.000 voluntarios en 175 países, el IEEE es una autoridad líder y de máximo prestigio en las áreas técnicas derivadas de la eléctrica original: desde ingeniería computacional, tecnologías biomédica y aeroespacial, hasta las áreas de energía eléctrica, control, telecomunicaciones y electrónica de consumo, entre otras. Según el mismo IEEE, su trabajo es promover la creatividad, el desarrollo y la integración, compartir y aplicar los avances en las tecnologías de la información, electrónica y ciencias en general para beneficio de la humanidad y de los mismos profesionales. Los estándares son útiles porque: - Agrupan lo mejor y más apropiado de las buenas prácticas y usos del desarrollo de software. - Engloban los “conocimientos”. - Proporcionan un marco para implementar procedimientos de aseguramiento de la calidad. - Proporcionan continuidad y entendimiento entre el trabajo de personas y organizaciones distintas.

Unidad IV – 4.2 Ingeniería del software de sala limpia 4.2.1 El enfoque de sala limpia Cuantas veces se ha escuchado la expresión: “hazlo bien la primera vez” esa es la filosofía primordial de la ingeniería del software de sala limpia. Un proceso que destaca la verificación matemática de la corrección antes de que comience la construcción del programa y la certificación de la confiabilidad del software como parte de la actividad de pruebas. El rasgo fundamental es tasas de falla extremadamente bajas que serían difíciles o imposibles de lograr empleando métodos menos formales. Lo hace un ingeniero de software especialmente entrenado. Es importante porque los errores implican la reelaboración. Ésta lleva tiempo y aumenta los costos. Esa es la premisa de la ingeniería del software de sala limpia. La sala limpia destaca las pruebas que ejercitan la forma en que el software es realmente utilizado. Los casos de uso ofrecen una introducción al proceso de planeación de pruebas. Las más importantes características de la sala limpia son la prueba de la corrección y las pruebas estadísticas de utilización. Este enfoque es eficaz en cuanto a costo y tiempo para establecer un enfoque de fabricación que evite la introducción de defectos de producción. Más que fabricar un producto y luego trabajar para eliminar los defectos, el enfoque de sala limpia demanda la disciplina requerida para eliminar los errores en la especificación y el diseño y luego fabricarlo en una forma limpia. El enfoque de sala limpia utiliza una versión especializada del modelo de proceso incremental. Mediante pequeños equipos de software independientes se desarrolla una “línea de incrementos de software”. Conforme cada incremento se certifica se integra en el todo. Por ende, la funcionalidad del sistema crece con el tiempo.

Unidad IV – 4.2 Ingeniería del software de sala limpia 4.2.1 El enfoque de sala limpia Las principales tareas llevadas a cabo como parte de la ingeniería del software de sala limpia son: *Planificación del incremento: se crea un plan de desarrollo de sala limpia, donde se crea la funcionalidad de cada incremento. *Recopilación de requisitos. *Especificación de la estructura de cajas: ajustarse a los principios de análisis operativos. Se utiliza un método de especificación que emplea estructuras de cajas, para describir la especificación funcional. *Diseño formal. especificaciones, estableciendo distinciones entre las actividades a realizar. (cajas negras) *Verificación de la corrección. *Generación de código, inspección y verificación. *Planificación de pruebas estadísticas. *Certificación. La única forma de que en un programa ocurran los errores es que un autor los coloque ahí. No se conocen otros mecanismos. La práctica correcta busca evitar la inserción de errores y, cuando se falla al respecto, eliminarlos antes de probarlo o cualquiera otra forma de ejecutar el programa.

Unidad IV – 4.2 Ingeniería del software de sala limpia 4.2.1 El enfoque de sala limpia La sala limpia representa el primer intento práctico de someter el proceso de desarrollo de software al control estadístico de la calidad con una estrategia bien definida para la mejora continua de los procesos. Con el fin de alcanzar esta meta se definió un ciclo de vida único de sala limpia, el cual se enfoca en la ingeniería del software basada en matemáticas para corregir diseños de software y en la prueba de software basada en estadísticas para la certificación de la fiabilidad del software. Esta ingeniería de software de sala limpia implementa técnicas de prueba con una alta probabilidad de descubrir errores de alto impacto, además de verificar las especificaciones del diseño utilizando una prueba de corrección basada matemáticamente.Obviamente , el enfoque de sala limpia aplica la mayoría, si no todos, los principios y conceptos básicos de la ingeniería del software. Los bueno análisis y procedimientos de diseño son esenciales si se quiere obtener alta calidad. En la ingeniería de sala limpia se realizan pruebas basadas en la estadística. Aquí la prueba unitaria y la depuración se sustituyen verificando la corrección y las pruebas basadas en estadística.

Unidad IV – 4.2 Ingeniería del software de sala limpia 4.2.2 Especificación funcional La ingeniería del software de sala limpia cumple con los principios de análisis operativo empleando un método llamado especificación de estructura de cajas. Una caja encapsula al sistema en algún grado de detalle. Por medio de un proceso de elaboración o refinamiento en niveles, las cajas se refinan en una jerarquía donde cada una tiene transparencia referencial. Esto es: “el contenido de información de cada especificación de caja es suficiente para definir su refinamiento, sin depender de la implementación de alguna otra caja. Esto le permite al analista partir un sistema jerárquicamente, moverse desde la representación esencial en la parte superior hacia un detalle específico de la implementación en el fondo. Se utilizan 3 tipos de cajas: Caja negra: la cual especifica el comportamiento de un sistema o parte de este. Caja de estado: encapsula los datos de estado y servicio en una forma análoga a los objetos (estímulos – respuestas) Caja transparente: contiene el diseño de procedimiento para la caja de estado.

Unidad IV – 4.2 Ingeniería del software de sala limpia 4.2.3 Diseño de sala limpia • Utiliza con amplitud la filosofía de programación estructurada aplicada mucho más rigurosa. Un enfoque de programación estructurada se emplea con eficacia para refinar la función. (si son aplicables las estructuras estructuradas). Los datos de programas se encapsulan como un conjunto de abstracciones que atienden las subfunciones. Los conceptos de encapsulado de datos, ocultamiento de información y clasificación de datos se aprovecha para crear el diseño de datos. • Si el lector se limita sólo a los estructuras estructuradas conforme desarrolla un diseño de procedimiento, la prueba de corrección es directa. Si se violan las estructuras las pruebas de corrección son difíciles o imposibles. • Probar que un diseño es correcto requiere primero, identificar todas las condiciones y luego probar que cada una toma el valor booleano adecuado. A estas condiciones se les llama subpruebas. • Las ventajas de la verificación del diseño son: • Reducir la verificación a un proceso finito. • *Permitir al equipo de sala limpia verificar cada línea de diseño y código. • *Produce mejor código que la prueba unitaria, entre otros… • Es bueno aclarar que la verificación del diseño debe aplicarse al propio código fuente. (Vericficación de la corrección)

Unidad IV – 4.2 Ingeniería del software de sala limpia 4.2.3 Prueba de sala limpia Las pruebas estadísticas son parte integral de la misma estrategia de pruebas del mismo enfoque de sala limpia. La prueba estadística equivale a probar el software en la forma que los usuarios intentarían usarlo. Esto se logra si los equipos de prueba de sala limpia (también llamados equipos de certificación) determinan una distribución de probabilidad de uso para el software. La especificación (caja negra) de cada incremento del software se analiza para definir un conjunto de estímulos (entradas o eventos) que provocan el cambio de comportamiento del software. Con base en entrevistas con usuarios potenciales, la creación de escenarios de uso y una comprensión general del dominio de la aplicación, se asigna una probabilidad de uso a cada estímulo. La certificación para la ingeniería del software requiere de 3 pasos: Modelo de muestreo (para verificar que funcione bien, que se logra la fiabilidad requerida) Modelo de componentes (donde el analista hipotéticamente determinará posibles fallas del software) Modelo de certificación (se refiere a la fiabilidad global del sistema ). Proyectado y certificado.

Unidad IV – 4.3 Ing. del software basado en componentes 4.3.1 Ingeniería de sistemas basada en componentes Hace referencia a un conjunto de componentes de software estandarizados pre construidos que se hacen disponibles para encajar en un estilo arquitectónico específico para cierto dominio de aplicación. En el contexto de la ingeniería del software la reutilización es una idea tanto antigua como nueva. Los programadores han reutilizado ideas, abstracciones y procesos desde los primeros días de la computación, pero el enfoque original para la reutilización era específico. En la actualidad, los complejos sistemas de alta calidad basados en computadoras se deben construir en un tiempo muy corto y demanda un enfoque más organizado de la reutilización. Esta ingeniería (ISBC)es un proceso que concede particularmente importancia al diseño y la construcción de sistemas reutilizables. Por lo tanto, alienta el uso de patrones arquitectónicos predecibles y de infraestructura de software estándar, y por lo tanto conduce a un resultado de mayor calidad.La ISBC abarca dos actividades de ingenierías paralelas: La ingeniería de dominio : la cual explora un dominio de aplicación con la intención específica de encontrar componentes funcionales, de comportamientos y de datos que sean candidatos para la reutilización. Dichos componentes son colocados en librerías de reutilización. El desarrollo: el desarrollo basado en componentes obtiene requisitos de los clientes; selecciona un estilo arquitectónico apropiado para satisfacer los objetivos del sistema a construir; y luego:* Selecciona componentes potenciales para reutilización.*Califica los componentes para asegurarse que encajan adecuadamente en la arquitectura para el sistema.*Adapta los componentes si se deben hacer modificaciones para integrarlos adecuadamente.

Unidad IV – 4.3 Ing. del software basado en componentes 4.3.1 Ingeniería de sistemas basada en componentes *Integra los componentes para formar subsistemas y la aplicación cono un todo. Además, algunos componentes personalizados son sometidos a ingeniería para enfrentar aquellos aspectos del sistema que no pueden ser implementados con el uso de los componentes existentes..El resultado de la ISBC es un software operativo, ensamblado con el uso de componentes de software existentes y desarrollados recientemente.Esta ingeniería parece bastante similar a la ingeniería del software orientado a objetos convencional. El proceso comienza cuando un equipo de software establece requisitos para el sistema que construirá mediante técnicas convencionales de investigación de requisitos. Se establece un diseño arquitectónico, pero en lugar de dirigirse inmediatamente hacia tareas de diseño más detalladas, el equipo examina los requisitos para determinar qué subconjunto está directamente dispuesto para la composición, y no para la construcción. Se plantean las siguientes preguntas:Hay componentes comerciales de línea (CDL) disponibles para implementar los requisitos? Hay disponibles componentes reutilizables desarrollados internamente para implementar los requisitos? Las interfases para los componentes disponibles son compatibles dentro de la arquitectura del sistema que se construirá. COMPONENTE: parte importante, casi independiente y reemplazable de un sistema que satisface una función clara en el contexto de una arquitectura bien definida.

Unidad IV – 4.3 Ing. del software basado en componentes 4.3.2 El proceso de ISBC Se caracteriza de tal forma que no sólo identifica los componentes candidatos sino que también cualifica la interfaz de cada componente, adapta los componentes para eliminar las equivocaciones arquitectónicas, ensambla los componentes en un estilo arquitectónico seleccionado y actualiza los componentes conforme los requisitos del sistema cambian. El modelo de proceso para la ingeniería de software basada en componentes destaca las pistas paralelas en las cuales la ingeniería del dominio se lleva a cabo concurrentemente con el desarrollo basado en componentes.Los pasos de análisis y diseño arquitectónico definidos en el contexto de un paradigma de diseño abstracto (ADP) implica que el modelo global del software representado como datos, funciones y comportamientos (control) , se puede descomponer jerárquicamente. Conforme la descomposición comienza, el sistema se representa como una colección de marcos de trabajo arquitectónico, cada uno compuesto de uno o más patrones de diseño.

Unidad IV – 4.3 Ing. del software basado en componentes 4.3.3 Ingeniería de dominio Esta ingeniería trata de encontrar los aspectos comunes entre los sistemas para identificar los componentes que sea posible aplicar en muchos sistemas, y para identificar familias de programas que se posicionen para sacar la mayor ventaja de dichos componentes. (Paul Clements)La finalidad de la ingeniería de dominio es identificar, construir, catalogar y diseminar un conjunto de componentes de software que sean aplicables para el software existente y futuro en un dominio de aplicación particular. La meta global es establecer mecanismos que les permitan a los ingenieros de software compartir dichos componentes para reutilizarlos durante el trabajo en sistemas nuevos y existentes. La ingeniería de dominio incluye tres grandes actividades: análisis, construcción y diseminación. Se puede argumentar que la reutilización desaparecerá, no por eliminación, sino por integración en la estructura de la práctica de la ingeniería del software. Como la reutilización cada vez tiene mayor auge algunos creen que la ingeniería del dominio adquirirá tanta importancia como la ingeniería del software durante la década siguiente. En el proceso de análisis lo importante es definir el dominio que se investigará, categorizar los elementos extraídos del dominio , recopilar una muestra representativa de las aplicaciones en el dominio, analizar cada aplicación en la muestra y definir las clases de análisis, por último desarrollar un modelo de análisis para las clases. Es importante advertir que el análisis del dominio es aplicable a cualquier paradigma de ingeniería del software, y que se puede aplicar al desarrollo convencional y al orientado a objetos.

Unidad IV – 4.3 Ing. del software basado en componentes 4.3.4 Desarrollo basado en componentes Es una actividad de ISBC que ocurre en paralelo con la ingeniería del dominio. Al aplicar los métodos de diseño de análisis y arquitectónico, el equipo de software refina un estilo arquitectónico apropiado para el modelo de análisis creado para la aplicación que se construirá. Una vez que la arquitectura se ha establecido, deben agregársele componentes que:*Estén disponibles en bibliotecas de reutilización.*Sean diseñados para satisfacer las necesidades personales del cliente. Por tanto, el flujo de tareas para el desarrollo basado en componentes tiene dos trayectorias paralelas. Cuando los componentes reutilizables están disponibles para su potencial integración en la arquitectura tienen que cualificarse y adaptarse. Cuando se requieren nuevos componentes es preciso diseñarlos. Entonces los componentes resultantes se componen (integran) en la plantilla arquitectónica y se prueban en forma minuciosa.Además de valorar si es justificado el costo de adaptación para la reutilización, el equipo de software también evalúa si lograr la funcionalidad requerida y el desempeño se pueden hacer eficientes respectos del costo.Desgraciadamente, la existencia de componentes reutilizables no garantiza que puedan integrarse con facilidad o eficacia en la arquitectura elegida para una nueva aplicación. Por esta razón se aplica una sucesión de actividades de desarrollo basada en componentes cuando se propone el uso de un componente. *Calificación de componentes.(si realiza la función requerida)*Adaptación de componentes*Composición de componentes*Modelo de intercambio de datos (se debe definir mecanismos que permitan que los usuarios y

Unidad IV – 4.3 Ing. del software basado en componentes 4.3.4 Desarrollo basado en componentes Aplicaciones interactúen y transfieran datos (arrastrar y soltar, cortar y pegar). Los mecanismos de intercambio de datos no sólo permiten la transferencia de datos humano-software y componente-componente, sino también la transferencia entre recursos del sistema (arrastrar un archivo a un icono de impresora para imprimirlo) *Automatización: implementar varias herramientas, macros y guiones para facilitar la interacción entre componentes reutilizables. *Almacenamiento estructurado. Los datos heterogéneos (datos gráficos, voz, video, texto y datos numéricos) que contiene un documento compuesto, deben estar organizados y ofrecer acceso como una sola estructura de datos y no como una colección de archivos separados. Los datos estructurados conservan un índice descriptivo de estructuras anidadas por las cuales las aplicaciones pueden navegar libremente para ubicar, crear o editar contenidos de datos individuales según ordene el usuario final. *Modelo de objeto subyacente. Asegura que los componentes desarrollados en diferentes lenguajes de programación y que residen en diferentes plataformas pueden ser interoperables. Es decir, los objetos deben ser capaces de comunicarse a través de una red. Esto se logra si el modelo de objeto define un estándar para la interoperabilidad de los componentes.

Unidad IV – 4.3 Ing. del software basado en componentes 4.3.5 Clasificación y recuperación de componentes Considérese un gran depósito de componentes. Cientos de miles de componentes de software reutilizables se hallan en él. Pero ¿cómo encuentra un ingeniero de software el componente que necesita? Tendencias actuales que permitirán a los futuros ingenieros de software navegar entre bibliotecas de reutilización. *Descripción de los componentes reutilizables. El concepto de un componente de software es una descripción de lo que hace el componente. La interfaz con el componente está completamente descrita y la semántica representada dentro del contexto de las precondiciones y las pos condiciones identificada. El concepto debe comunicar la intención del componente.El contenido de un componente describe cómo se construye el concepto. En esencia, el contenido es información oculta para los usuarios habituales y que sólo necesitan conocerla quienes quieran modificar o probar el componente. El contexto sitúa un componente de software reutilizable en su dominio de aplicabilidad. Es decir, al especificar las características conceptuales, operativas y de implementación el contexto permite que un ingeniero de software encuentre el componente apropiado para satisfacer los requisitos de la aplicación. Para que sean útiles en la práctica, concepto, contenido y contexto se deben traducir en un esquema de especificación concreto.

Unidad IV – 4.3 Ing. del software basado en componentes 4.3.6 Economía de la ISBC La ingeniería del software basada en componentes tiene un atractivo intuitivo. En teoría, debe proporcionar a una organización de software ventajas en cuanto a calidad y oportunidad, lo que debe traducirse en ahorros. IMPACTO SOBRE LA CALIDAD, LA PRODUCTIVIDAD Y EL COSTO CALIDAD: en un entorno ideal, un componente de software que se desarrolle para reutilización se verificaría como correcto y no contendría defectos. Con cada reutilización los defectos se encuentran y eliminan, y, como resultado, mejora la calidad del componente. Con el tiempo el componente que da virtualmente libre de defectos. PRODUCTIVIDAD: cuando los componentes reutilizables se aplican a lo largo del proceso del software, se dedica menos tiempo a la creación de planes, modelos, documentos, código y daos que se requieren para crear un sistema fiable. Por lo tanto, se entrega al cliente el mismo nivel de funcionalidad con menos esfuerzo, lo que mejora la productividad. Aunque los reportes de mejora porcentual en la productividad son notablemente difíciles de interpretar, parece que la reutilización del 30 al 50 por ciento puede resultar en mejoras en la productividad en el rango del 25-40 por ciento. COSTO: los ahorros en el costo neto por la reutilización se estiman al proyectar el costo del proyecto si éste fuese desarrollado desde cero, y luego se resta la suma de los costos asociados con la reutilización y el costo real del software en el momentos de la entrega.El costo desarrollar un componente reutilizable con frecuencia es mayor que el de desarrollar un componente específico para una aplicación.

Unidad IV – 4.4 Reingeniría de software 4.4.1 Reingeniería de procesos de negocio La RPN, rebasa el ámbito de las tecnologías de la información y de la ingeniería del software. Hace referencia a la búsqueda e implementación de un cambio radical en el proceso de negocios para lograr resultados de vanguardia. PROCESO DE NEGOCIOSEs un conjunto de tareas lógicamente relacionadas que se ejecutan para lograr un resultado de negocios específico. Dentro del proceso de negocio, la gente, el equipo. Los recursos materiales y los procedimientos del negocio se combinan para producir un resultado específico. Los ejemplos de procesos de negocios incluyen el diseño de un nuevo producto, la compra de servicios y suministros, la contratación de un nuevo empleado y el pago a proveedores. Cada uno demanda un conjunto de tareas y también emplea diversos recursos dentro del negocio.Cada proceso de negocio tiene un cliente definido: una persona o grupo que recibe el resultado (una idea, un informe, un diseño, un producto). Además, los procesos de negocios traspasan las fronteras de la organización. Esto requiere que diferentes grupos de organizaciones participen en las tareas lógicamente relacionadas que definen el proceso.La RPN se puede aplicar en cualquier nivel de la jerarquía, pero conforme se amplía su ámbito los riesgos asociados con ello crecen sustancialmente. Por esta razón, la mayoría de los esfuerzos de la RPN se enfoca en procesos individuales o subprocesos. NEGOCIO: reducción de costo, reducción de tiempos, mejora de calidad y desarrollo y fortalecimiento del personal.

Unidad IV – 4.4 Reingeniría de software 4.4.1 Reingeniería de procesos de negocio IDENTIFICACION DEL PROCESO. EVALUACION DEL PROCESO. ESPECIFICACION Y DISEÑO DEL PROCESO. ELABORACION DE PROTOTIPOS REFINAMIENTO Y PARTICULARIZACION. El objetivo de las herramientas del RPN es apoyar el análisis y la evaluación de los procesos de negociación existentes y la especificación y el diseño de unos nuevos.La mecánica de las herramientas varía. En general, las herramientas de la RPN permiten que un analista de negocios modele los procesos de negocio existentes en un esfuerzo destinado a evaluar las ineficiencias del flujo de trabajo o problemas funcionales. Una vez que se identifican los problemas existentes las herramientas permiten que los analistas elaboren prototipos o simulen procesos de negocio revisados.

Unidad IV – 4.4 Reingeniría de software 4.4.2 Reingeniería del software El software al cual no se le puede dar mantenimiento no es un problema nuevo. De hecho, la importancia cada vez mayor que se le concede a la reingeniería del software la han impulsado los problemas en el mantenimiento del software que han ido creciendo durante más de 40 años. MANTENIMIENTO DEL SOFTWAREEl mantenimiento del software existente explica casi el 60 por ciento del esfuerzo que emplea una organización de desarrollo, y el porcentaje continúa elevándose conforme se produce más software.Gran parte del software del que dependemos en la actualidad tiene en promedio de 10 a 15 años de antigüedad. Aun cuando dichos programas se crearon empleando las mejores técnicas de diseño y codificación conocidas en la época, se crearon cuando el tamaño de los programas y el espacio de almacenamiento eran las principales preocupaciones. Entonces emigraron hacia nuevas plataformas, se ajustaron para adecuarlos a los cambios en las máquinas y a la tecnología de los sistemas operativos aumentaron para satisfacer las necesidades de nuevos usuarios. Otra razón respecto del problema del mantenimiento del software es la movilidad del personal. Es posible que el equipo o persona que realizó el software ya no esté. En la actualidad pueda que no haya nadie que tenga algún conocimiento directo del sistema heredado. *MODELO DE PROCESO DE REINGENIERIA DEL SOFTWARE

Unidad IV – 4.4 Reingeniría de software 4.4.3 Ingeniería inversa Invoca una imagen de ranura mágica. En la ranura se inserta una lista fuente sin documentar y diseñado casualmente, y del otro extremo sale una descripción (y toda la documentación) completa del diseño para el programa de computadora. La ingeniería inversa puede obtener información de diseño a partir del código fuente, pero el grado de abstracción, la completud (grado de detalle que se ofrece en un grado de abstracción) de la documentación, 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 abstracción de un proceso de ingeniería inversa y las herramientas utilizadas para efectuarlo se refieren a la sofisticación de la información del diseño que es posible obtener del código fuente. El proceso de ingeniería inversa debe ser capaz de derivar representaciones de diseño de procedimiento, información de estructura de programa y datos (un grado de abstracción un poco más elevado), modelos de objetos, modelo de flujo de datos o control y clases UML, diagramas de estado y despliegue. Conforme el grado de abstracción aumenta, el ingeniero de software obtiene información que le permitirá comprender con más facilidad el programa. Se deben abordar 3 temas de la ingeniería inversa:*Grado de abstracción. *Integridad *Direccionamiento.

Unidad IV – 4.4 Reingeniría de software 4.4.4 Reestructuración Aunque la reestructuración del código puede aliviar inmediatamente los problemas asociados con la depuración o los cambios pequeños , esto no es reingeniería, el beneficio real se logra sólo cuando se reestructuran los datos y la arquitectura. La reestructuración modifica el código fuente o los datos con la finalidad de adecuarlos para futuros cambios. En general, la reestructuración no modifica la arquitectura global del programa. Tiende a tocarse sobre los detalles de diseño de los módulos individuales y en las estructuras de datos locales definidos dentro de los módulos.La reestructuración ocurre cuando la arquitectura básica de una aplicación es sólida, aun cuando el interior técnico necesite trabajarse. Se inicia cuando grandes partes del software son funcionales y sólo un subconjunto de los componentes y datos necesitan una modificación extensa. *Reestructuración del código. (Diseño que produzca la misma función que el programa original) *Reestructuración de los datos. (se debe primero analizar el código fuente para poderlo rediseñar.) El objetivo de las herramientas de reestructuración es transformar el antiguo software de computara carente de estructura en lenguajes de programación y estructuras de diseño modernos. En general, el código fuente se ingresa y transforma en un mejor programa estructurado. En algunos casos, la transformación ocurre dentro del mismo lenguaje de programación. Un lenguaje de programación antiguo se transforma en un lenguaje más moderno.

Unidad IV – 4.4 Reingeniría de software 4.4.5 Ingeniería directa Qué opciones existen cuando se enfrenta un programa deficiente diseñado e implementado?La reingeniería es muy parecida a la limpieza dental. Puede pensar en miles de razones para demorarla, y la aplazará muchas veces. Pero eventualmente sus tácticas dilatorias regresarán para provocarle dolor.En la mayoría de los casos, la ingeniería directa no simplemente crea el equivalente moderno de un programa antiguo. Más bien, los nuevos requisitos de usuario y tecnología se integran en el trabajo de reingeniería. Ingeniería del software pag.918)En algunos casos, la migración hacia la arquitectura cliente servidor no debe enfocarse como reingeniería, sino como un nuevo esfuerzo de desarrollo. La reingeniería ingresa al cuadro sólo cuando la funcionalidad específica del sistema antiguo se integrará en la nueva arquitectura.*Ingeniería directa para arquitecturas orientadas a objetos. *Ingeniería directa de interfaces de usuario.

Unidad IV – 4.4 Reingeniría de software 4.4.6 La economía de la reingeniería En un mundo perfecto, cualquier programa al que no se le pudiera dar mantenimiento sería retirado inmediatamente, y sería sustituido por aplicaciones de mayor calidad con reingeniería desarrollada empleando modernas prácticas de ingeniería del software. Sin embargo, se vive en un mundo de recursos limitados. La reingeniería demanda recursos que pueden utilizarse para otros propósitos del negocio. En consecuencia, antes de que una organización intente someter a reingeniería una aplicación existente, debe realizar un análisis costo – beneficio. El análisis costo - beneficio representado en las ecuaciones se puede realizar para todas las aplicaciones de alta prioridad identificadas durante el análisis de inventario.

Ingeniería del Software I