PROCESO UNIFICADO DE RATIONAL
1
El Proceso Unificado de Desarrollo Software o simplemente es un refinamiento más conocido y documentado del Proceso Unificado es el o simplemente RUP. RUP.
El
no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el , también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.
Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la investigación. En 1995 Rational Software es comprada por una compañia sueca llamada Objectory AB. El Rational Unified Process (proceso unificado de Rati Ration onal al)) fuel fuel el resu resultltad adoo de una una conve converg rgen enci ciaa de Rati Rationa onall Ap Appr proa oach ch y 2
El Proceso Unificado de Desarrollo Software o simplemente es un refinamiento más conocido y documentado del Proceso Unificado es el o simplemente RUP. RUP.
El
no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el , también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.
Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la investigación. En 1995 Rational Software es comprada por una compañia sueca llamada Objectory AB. El Rational Unified Process (proceso unificado de Rati Ration onal al)) fuel fuel el resu resultltad adoo de una una conve converg rgen enci ciaa de Rati Rationa onall Ap Appr proa oach ch y 2
Objectory, proceso desarrollado por el fundador de Objectory Ivan Jacobson. La primera versión de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten. El proceso unificado tiene como aspecto esencial del desarrollo de software una visi visión ón que que parte parte de la arqu arquititect ectur uraa sigu siguie iend ndoo un proces procesoo intera interact ctiv ivoo e incremental, el proceso integra diferentes aspectos aspectos como son los ciclos, fases, flujos flujos de trabajo, trabajo, mitigacion mitigacion de riesgos, control control de calidad, administra administración ción de proyectos y control de configuración. De manera adicional el proceso unificado cons consid ider eraa las las cuat cuatro ro p’s p’s del del desa desarr rrol ollo lo de soft softwa ware re:: pers person onas as,, proy proyec ecto tos, s, producto y proceso. El proceso unificado se basa en las siguientes creencias: •
•
•
Para construir un sistema exitoso se deben de conocer que quieren y necesitan los usuarios potenciales. Al igual que la arquitectura en la construcción permite diseñar edificios desde desde múltip múltiples les puntos puntos de vistas vistas,, estruc estructur tura, a, electr electrici icidad dad,, etc.. etc.. las arquitecturas de los sistemas de software deben de permitir visualizar un sistema desde múltiples perspectivas. El desarrollo de un producto de software comercial, pueden significar un gran esfuerzo durante meses, e incluso años. Es práctico dividir el trabajo en etapas donde cada iteración resulta en un incremento del proyecto.
El
o RUP RUP (Rat (Ratio iona nall Unif Unifie ied d Proc Proces ess) s),, es un
proc proces eso o de desa desarr rrol ollo lo de soft softwa ware re y junt junto o con con el Leng Lengua uaje je Unif Unific icad ado o de Modelado UML , constituye la metodología metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. RUP es en realidad un refinamiento realizado por Rational Software del más genérico Proceso genérico Proceso Unificado . 3
Sus principales características son: •
•
Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo) Pretende implementar las mejores prácticas en Ingeniería de Software •
•
•
•
•
•
Desarrollo interactivo Administración de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificación de la calidad del software
El RUP es un producto de Rational (IBM). Se caracteriza por ser interactivo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso). divide el proceso de desarrollo en ciclos, teniendo un producto final al final de cada ciclo, cada ciclo se divide en fases que finalizan con un hito donde se debe tomar una decisión importante: •
•
•
•
Inicio: se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos Elaboración: se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos Construcción: se concentra en la elaboración de un producto totalmente operativo y eficiente y el manual de usuario Transición: se implementa el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser analizados. 4
•
•
•
Establece oportunidad y alcance Identifica las entidades externas o actores con las que se trata Identifica los casos de uso
donde usted coloca interactivo debería ir la palabra iterativo
En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración de un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc.
Los artefactos fundamentales en captura de requisitos son: Modelos de CU: Incluye actores y casos de usos 1. Artefacto: modelo de CU El modelo de CU sirve para llegar a un acuerdo entre el cliente y desarrollador sobre los requisitos que deberá tener en cuenta el sistema. Describe lo que hace el sistema para cada tipo de usuario. 2. Artefacto: actor Actor: Representa el entero externo al sistema. Rol: Define lo que hace un trabajador en proceso de negocio. 5
Instancia: es un actor que interactúa con el sistema. 3. Caso de uso Interacción: Es una secuencia de acciones que el sistema lleva a cabo (interactuando con actores) para dar un resultado de valor. Descripción de CU puede incluir diagramas de actividad. Instancia de CU: Es la realización de los CU. Son atómicas: se ejecutan todo o nada. Sin otros de por medio. Los CU tienen atributos, valores que en su ejecución se pueden usar y modificar. Flujos de sucesos: Especifica qué hace el sistema cuando ejecuta un determinado CU. Flujos especiales: Describe a un grupo de requisitos no funcionales. 4. Artefacto: descripción de una arquitectura Contiene una vista del modelo de CU que describe los aspectos más importantes de la arquitectura. 5. Artefacto: Glosario 6. Artefacto: prototipo de interfaz de usuario Mejora la interfaz de usuario y ayuda a comprender los CU. 2.
Representa los comportamientos, descripciones y responsabilidades del mismo.
6
No es lo mismo que un individuo ya que éste puede representar a varios trabajadores si es que realiza distintas actividades. 1. Analista de sistemas Hace la captura de requisitos func. y no func. para moldearlos a los CU. Hay 1 por cada sistema. Especificador de CU: Asiste al analista de sistema. Diseñador de interfaz: Es responsable del prototipo de interfaz de usuario. Arquitecto: Trabaja con la captura de requisitos para diseñar las vistas de la arquitectura del modelo de CU.
Conjunto de actividades que están ordenados. Los trabajadores crean, ejecutan y modifican artefactos. Cada salida de una actividad sirve como entrada para la siguiente. Los artefactos se completan y mejoran a través de las iteraciones. Los analistas para hacer captura de requisitos requiere de la ayuda de usuarios, desarrolladores y otros analistas. 4 pasos para tener una nueva versión del modelo de CU con actores: Encontrar los actores / CU / describir cada CU / Describir modelo de CU. No requieren de un órden.
7
El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura software de un sistema. La analogía con la construcción es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanería, etc. Arquitectura: Da una perspectiva del sistema completo; todos los empleados deben estar de acuerdo con ella. Describe los elementos más importantes del sistema. El 1er. Objetivo de la fase de elaboración es construir una arquitectura sólida que sirva de base para construir el sistema. 1.
El conjunto de todas las vistas representa a la arquitectura. Cada vista es una perspectiva diferente del sistema. Cantidad de páginas para la Descripción de arquitectura: Se recomienda que sea de entre 50 y 100
Para que los desarrolladores progresen hasta obtener una visión común (en sistema de software grandes) Para dividir el proyecto en clases y facilitar su reutilización (futuros cambios) 1. Compresión del sistema Todos las personas que trabajen en el desarrollo del sistema deben comprenderla lo cual es un reto difícil porque: operan en 8
entornos complejos y al dividirlos en mini proyectos es difícil coordinarlos. 2. Organización del desarrollo Mientras más grande sea el proyecto habrá mayor sobrecarga en la comunicación entre los distintos desarrolladores; para ello se divide el sistema en subsistemas donde cada uno tendrá un responsable. También es importante tener interfaces bien definidas. 3. Evolución del sistema Un sistema grande evoluciona con el tiempo incluso durante su desarrollo, o sea, sufrirá futuras modificaciones (nuevos casos de usos). Si el sistema es flexible (tolerable a cambios) dichas modificaciones no deben causar resultados inesperados. Las arquitecturas de sistemas pobres deben ser parcheadas hasta el final y su coste es grande e innecesario.
La arquitectura se ve condicionada por: •
•
Los casos de usos más importantes (más significativos). El producto software que se desea desarrollar. Por ej.: sist.op.; base de datos; etc.
•
Los productos de capa media que se van a utilizar.
•
Sistemas heredados a utilizar.
•
Estándares y políticas corporativas.
•
Requisitos no funcionales.
La arquitectura del sistema se desarrolla en fase de elaboración junto con los casos de usos más importantes. Una vez que se tiene una arquitectura estable 9
se realiza el resto de los casos de uso (los menos relevantes) que por lo general se basan en los requisitos de los clientes y usuarios. El valor de costo de nuevos casos de usos se refleja según la arquitectura del sistema.
El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de Elaboración, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.
El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio sólo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto.
1. Atenuación de riesgos
10
Riesgo: es una variable que pone en peligro o impide el éxito del proyecto. "Aproximación al proceso de desarrollo dirigido por riesgos": El Proceso Unificado reconoce los riesgos más importantes en las primeras 2 fases y reduce los mismos. Los que no, pueden poner en peligro el proyecto entero. Método cascada: El desarrollo del sistema no se divide en iteraciones. Los problemas graves pueden saltar en la fase de integración & prueba; esto obliga a contratar a desarrolladores con más experiencia, el proyecto queda parado y se retrasan las fechas. Método iterativo: Los riesgos importantes se tratan en las primeras fases, quedando muy pocas en la de construcción. El proyecto marcha sin inconvenientes hasta el final. 2. Obtención de una arquitectura robusta Método cascada: Es en las últimas fases donde se sabe con certeza si la arquitectura que se diseñó es la adecuada. Si no lo es, se habrá perdido mucho tiempo y no podremos cumplir con la fecha de entrega. Método iterativo: Es al final de la fase de elaboración donde se evalúa la arquitectura; si aún no está madura se trabaja en una nueva iteración; esto es posible ya que es muy poco lo que se invierte en esta fase y las fechas aún no están definidas.
construcción: es una versión operativa del sistema que demuestra un subconjunto de posibilidades. 11
Es más fácil para el usuario ver un sistema ejecutable en funcionamiento que leer cientos de páginas de documentos. Esto permite a que los usuarios opinen y sugieran modificar o agregar cosas que se nos pasó de largo. En método cascada los usuarios ven al sistema funcionando recién en la integración y prueba, y si desea cambiar algo deberán aumentar presupuesto y atrasar las fechas. 4. Permitir cambios tácticos Con método iterativo los directores se encargan de ver al final de cada iteración.. •
•
•
Si hubo un incremento y se han resueltos los problemas; entonces autorizará a los desarrolladores a seguir con la siguiente iteración. Si el éxito fue parcial, se ampliará la iteración hasta poder cumplir con lo requerido. Si el resultado es negativo puede llegar a cancelarse el proyecto. Conseguir una iteración continua
Método cascada: Muchos errores parecen no estar presentes y el proyecto progresa con norma-lidad hasta llegar a la integración y prueba; ahí salen todos a la luz. Estas ponen en peligro al proy Método iterativo: Ya desde un principio se hacen frecuentes construcciones, y con éstas aparecen los errores que se tratarán a lo largo de todo el proyecto. No habrá sorpresas para el final. Conseguir un aprendizaje temprano Se ingresa gente nueva a medida que se pasa de una iteración a otra. Puede empezar con unas 5 a 10 pers. pasar a 25 y finalmente a 100. Los nuevos
12
tienen una formación adecuada y trabajan con gente con experiencia, rápidamente se ajustan a la velocidad adecuada.
Se analizan los riesgos, luego se priorizan y se organizan las iteraciones para •
Tratar los requisitos pedido por los usuarios
•
Obtener una arquitectura robusta.
•
Tratar otros aspectos como rendimiento, disponibilidad, portabilidad: éstos se ven cuando se implementa y se prueba el software.
Objetivo: acabar con los riesgos en una iteración temprana. En fase de inicio y elaboración se tratan la mayoría de los riesgos. Hay 4 formas de tratar a un riesgo según su prioridad: •
•
•
•
Evitarlo: Quizás se tenga que replanificar el proyecto o hacer un cambio de requisitos. Limitarlo: Achicarlo para que afecta una parte pequeña del proyecto. Atenuarlo: Probar repetidas veces hasta ver si aparecen o no. Controlarlo: Ver si el proyecto puede convivir con ésta. Caso contrario no se podrá continuar: algo que no es tan malo ya que se detectó en un principio y los gastos fueron mínimos.
Se manejan por iteraciones para no tener que tratar con todos los errores a la vez. Qué es una iteración Una iteración es un mini proyecto donde se tiene como resultado una versión interna. Está compuesto por 5 flujos de trabajos: requisitos, análisis, etc. 13
Los trabajadores y artefactos pueden trabajar en más de un flujo de trabajo. Las Fases están divididas en N iteraciones. Descripción de cada fase: •
•
•
•
Inicio: Hacer análisis del negocio y reducir los riesgos más importantes. Elaboración: Obtener línea base de la arquitectura, capturar requisitos, reducir demás riesgos. Construcción: Desarrollar el sistema entero. Ofrecer funcionalidad operativa a clientes. Transición: Tener el producto preparado para la entrega. Se enseña a usuarios a utilizar el software.
Cada iteración se analiza cuando termina y se ven si cambiaron o aparecieron nuevos requisitos que modificarán a la siguiente iteración. Prueba de regresión: Sirve para ver si no se han estropeado iteraciones anteriores. Se aplica al antes de terminar con la iteración actual. Definiciones de Incremento: Diferencia entre la versión interna de la iteración anterior y la siguiente. Diferencia entre 2 líneas bases sucesivas. Colaboración: Es la representación de los CU más significativos para la arquitectura. Sirve para identificar subsistemas e interfaces. Luego se les da forma (implementa código). Hay más incrementos a medida que nos acercamos a la fase de transición. La integración del último incremento se convierte en el sistema final.
14
1. El proceso unificado es adaptado a: Organizaciones y proyectos específicos.
2. Es lo mismo proceso unificado y proceso unificado de Rational? Si
No
3. De quien se deriva el proceso unificado? Del modelo Espiral originario de Barry Boehm
4. Por que compañía es comprada el RUP Por una compañía sueca llamada Objectory AB en 1995 5. Cuando fue puesto al mercado el RUP? En 1998. 6. Cuales son los aspectos que integran el proceso unificado? Ciclos, fases, flujos de trabajo, riesgos, control de calidad, administración de proyectos y control de configuración. 7. Cuales son las cuatro P’s del desarrollo de software? Persona, proyecto, producto y proceso. 15
8. Es cierto que para construir un sistema exitoso se debe de conocer que quieren y que no necesitan los usuarios potenciales? Falso. 9. Es cierto que es mas practico dividir el trabajo en etapas donde cada iteración resulta un incremento del proyecto? Cierto. 10. El RUP se caracteriza por ser? Iterativo e incremental, centrado en la arquitectura y en casos de uso. 11. Cuales son las fases del RUP? Inicio, Elaboración, construcción y transición. 12. En que fase del RUP se identifican los riesgos. En la fase de inicio. 13. En que fase del RUP se realiza el manual del Usuario? En la fase de Construcción. 14. En que fase del RUP se entrenan a los usuarios del sistema?; En la fase de Transición. 15. En que fase del RUP se eliminan los riesgos?
16
En la fase de Elaboración. 16. Es el papel que desempeña una persona en un determinado momento? Rol o Roles. 17. Que son los artefactos? que son los productos tangibles del proceso. 18. Ejemplo de artefactos? El modelo de casos de uso, el código fuente, etc. 19. En que fase del rup suelen surgir de nuevo requisitos para ser analizados y por supuesto considerados? En la fase de Transición.
17
1. organización. 2. requisitos. 3.
: describe la estructura y la dinámica de la
: describe el método basado en casos de uso para extraer los
: describe las diferentes vistas arquitectónicas.
4. : tiene en cuenta el desarrollo de software, la prueba de unidades y la integración. 5. : describe los casos de pruebas, los procedimientos y las métricas para evaluación de defectos. 6.
: cubre la configuración del sistema entregable.
7. : controla los cambios y mantiene la integridad de los artefactos de un proyecto. 8. iterativo.
: describe varias estrategias de trabajo en un proceso
9. : cubre la infraestructura necesaria para desarrollar un sistema. Dentro de cada flujo de trabajo del proceso hay un conjunto de artefactos y actividades relacionados.
18
Un artefacto es algún documento, informe o ejecutable que se produce, se manipula o se consume. Una actividad describe las tareas (pasos de concepción, realización y revisión) que llevan a cabo los trabajadores para crear o modificar los artefactos, junto con las técnicas y guías para ejecutar las tareas, incluyendo quizá el uso de herramientas para ayudar a automatizar algunas de ellas.
INTRODUCCIÓN A LAS HERRAMIENTAS CASE CASE= Ingeniería de Software Asistida por Computadora. •
Son un complemento de la caja de herramientas, del ingeniero de
•
software. Proporciona la capacidad la posibilidad de automatizar actividades
•
manuales y de mejorar su visión general de la ingeniería. Aseguran que la calidad sea algo diseñado antes de construir el producto.
"CASE es una filosofía que se orienta a la mejor comprensión de los modelos de empresa, sus actividades y el desarrollo de los sistemas de información. Esta filosofía involucra además el uso de programas que permiten: 19
Construir los modelos que describen la empresa,
Describir el medio en el que se realizan las actividades,
Llevar a cabo la planificación,
El desarrollo del Sistema Informático, desde la planificación, pasando por el análisis y diseño de sistemas, hasta la generación del código de los programas y la documentación." Michael Lucas Gibson.
Aumentar la productividad de las áreas de desarrollo y mantenimiento de los sistemas informáticos.
Mejorar la calidad del software desarrollado.
Reducir tiempos y costes de desarrollo y mantenimiento del software.
Mejorar la gestión y dominio sobre el proyecto en cuanto a su planificación, ejecución y control.
Mejorar el archivo de datos (enciclopedia) de conocimientos (know-how) y sus facilidades de uso, reduciendo la dependencia de analistas y programadores. Automatiza
el desarrollo del software
La documentación
La generación del código
El chequeo de errores
La gestión del proyecto
Permitir
La reutilización (reusabilidad) del software
La portabilidad del software
La estandarización de la documentación 20
Integrar las fases de desarrollo (ingeniería del software) con las herramientas CASE
Facilitar la utilización de las distintas metodologías que desarrollan la propia ingeniería del software.
En el contexto CASE se entiende por enciclopedia a la base de datos que contiene todas las informaciones relacionadas con las especificaciones, análisis y diseño del software. En está base de datos se incluyen las informaciones de :
DATOS: Elementos atributos (campos), asociaciones (relaciones), entidades (registros), almacenes de datos, estructuras, etc.
PROCESOS: Procesos, Funciones, módulos, etc.
GRÁFICOS: DFD (Diagrama de flujo de datos), DER (Diagrama Entidad Relación) DFD (Diagrama de Descomposición Funcional), ED (Diagrama de Estructura), Diagrama de Clases, etc.
REGLAS: de Gestión, de métodos, etc.
CASE es una combinación de herramientas software (aplicaciones) y de metodologías de desarrollo:
Las herramientas permiten automatizar el proceso de desarrollo del software.
Las metodologías definen los procesos automatizar.
Una primera clasificación del CASE es considerando su amplitud:
21
es una colección de herramientas integradas que permiten automatizar un conjunto de tareas de algunas de las fases del ciclo de vida del sistema informáticos; Planificación estratégica, Análisis, Diseño, Generación de programas. Son conjuntos integrados de herramientas que dan soporte a la automatización del proceso completo de desarrollo del sistema informático. Permiten cubrir el ciclo de vida completo. El producto final aportado por ellas es un sistema en código ejecutable y su documentación.
Una segunda clasificación es teniendo en cuenta las fases (y/o tareas) del ciclo de vida que automatizan
Planificación estratégica, Requerimientos de Desarrollo Funcional de Planes Corporativos. Análisis y Diseño. Generación de código, test e implantación
A continuación se presenta en forma breve, una reseña de cada una de las herramientas que hasta ahora han salido al mercado del SW. Debido a que se tienen herramientas de desarrollo abiertas con conectividad a diversas plataformas, basadas en tecnología orientada a objetos y a tecnología cliente/servidor que permiten la reutilización del software; nos permitimos dividir secciones entre estas, como a continuación se describe. •
Con 30 manejadores de base de datos, ofrece dos opciones de conectividad: ODBC de Microsoft y conectividad nativa . Una de las características principales (muy apreciada por los usuarios, quienes dicen es mejor con Oracle e Informix 22
que sus propias herramientas) de este producto es que comparte el mismo idioma de cada manejador. Incluye entre otros módulos el Optima++, herramienta RAD basada en componentes que combina desarrollos cliente/servidor e Internet con el rendimiento de C++. Asimismo, ofrece un módulo opcional CASE Power Design que genera modelos lógicos y físicos de los distintos manejadores que soporta para acelerar los desarrollos. Power Builder cuenta con conectividad para aplicaciones a través del , desarrollado por Sybase y puede construir aplicaciones sobre driver cualquier plataforma. Precisamente, Java es uno de los lenguajes de programación que más está dando que hablar hoy día por considerarse un nuevo paradigma en el mundo de la computación, con él Sun Microsystems avanzó unos cuantos pasos delante de su principal competidor Microsoft en el área de redes de computadoras. "Es orientado a objetos y tiene la ventaja de que rompe la aplicación en bytecodes diseñados para trabajar y viajar a lo largo de una red desde el servidor hasta el cliente y puede correr encima de un que browser o de un sistema operativo a través del permite correr la aplicación sobre cualquier tipo de cliente". Se considera que una de las fortalezas de Java son sus Interfaces de Programación de Aplicaciones (APIs), que las hay específicas y por áreas de industria y disponibles en la red. "Hoy día existen unas 23 APIs, cada una con una funcionalidad particular que facilita enormemente el desarrollo". Otra de las ventajas de Java para el desarrollador, es el concepto de "escribir una vez y correr en cualquier parte" eso quiere decir que el programador escribe una sola vez el código, lo compila una sola vez y ese programa puede correr en cualquier plataforma. Si bien esta es la bandera de Sun aún está en entredicho que la misma siga ondeando dado que Java está a media asta en Microsoft. Las características novedosas de Java, especialmente su total orientación a objetos ha llevado a muchas empresas a establecer acuerdos con Sun: NetScape, IBM, Oracle, e incluso Microsoft, empresa que para bien o para mal se torna cada
23
vez más agresiva hacia el mercado tuvo que ceder ante sus encantos y ya tiene su Visual J++. •
Actualmente Microsoft continúa impulsando este lenguaje, el cual es una evolución de su antecesor Basic y como su nombre lo indica, es un ambiente de desarrollo más visual. A partir de la versión 5.0 cuenta con un compilador original de códigos y está más orientado a ambientes cliente/servidor e incluye soporte e integración a aplicaciones Internet/intranet a través de la tecnología ActiveX. La popularidad de Visual Basic se debe a su simplicidad ya que en cuanto a conectividad hay otros que lo superan, pero podemos mencionar que soporta FoxPro, Oracle, e Informix vía ODBC y aún cuando no está orientada a objetos porque no soporta polimorfismos, cumple algunas de las reglas de esta tecnología al permitir reutilizar componentes para el desarrollo de aplicaciones personalizadas. •
Las herramientas de desarrollo orientadas a objetos con que Microsoft cuenta son Visual FoxPro y Visual C++, siendo ahora lo más reciente InterDev. De tales herramientas, esta última es la primera que ayuda a los desarrolladores de aplicaciones basadas en Web en la construcción de sitios sofisticados totalmente interactivos. InterDev disminuye el ciclo de desarrollo al soportar los lenguajes de Internet Java y Visual Basic Scrip interconectándose con otros lenguajes como C++ o Visual Basic a través de componentes ActiveX, además, puede interactuar totalmente con FrontPage 97 (herramienta orientada a usuarios finales y diseñadores). De esta manera ambos pueden trabajar en equipo para la construcción de sitios Web. •
24
Siguiendo la orientación al Web, Oracle en la actualidad está enfocada directamente a su Arquitectura de Computación de Redes (NCA), considerada como un servidor universal de datos, aprovechando lo mejor de los tres mundos: Web, cliente/servidor y orientación a objetos . Sus herramientas de desarrollo son básicamente tres: , herramienta tipo RAD, presenta ventajas como sencillez, orientada a cliente/servidor y desarrollar ambientes Web. Genera software basado en Visual Basic y Java para que pueda correr en cualquier browser . Developer/2000 funciona sólo en Oracle, pero soporta básicamente las bases de datos SQL Server de Microsoft e Informix. , un generador de software de objetos en Java que pueden correr en cualquier browser y permite reutilizarlos.
•
Erwin es otra de las herramientas de la tecnología CASE, cuyo mayor diferenciador es su simplicidad (por generar código para la mayoría de los manejadores de base de datos ya que es completamente abierta) y la rapidez para el desarrollo de bases de datos complejas (acelerar los tiempos de desarrollo). Esta herramienta ofrece una metodología para realizar diagramas entidad-relación y cuenta con una interfaz gráfica altamente intuitiva. La versión 3.0 que incluye un servidor de ingeniería de reverso, función que lleva a cabo desde los datos existentes a modelos lógicos de datos. Asimismo trae un editor de disparadores (triggers ) y de stored procedures .
25
•
Esta herramienta cuenta con un módulo para generar ingeniería de software tradicional, así mismo, una línea de productos para desarrollo de aplicaciones cliente/servidor de múltiples capas y para ambientes distribuidos. Además puede generar aplicaciones para Internet/intranets, soporta métodos orientados a objeto UML y cuenta con interfaces MQSeries de IBM o DCE. Cool Stuf cubre todo el ciclo de vida del producto desde la reingeniería de los procesos del negocio, análisis, diseño, distribución de procesos de datos y generación automática de código que puede ser en C++, Java o Cobol. Para ello se apoya en la metodología de James Martin, así como también en metodologías basadas en Orientación a Objetos. Una desventaja de esta es que utilizar una herramienta CASE del tipo Cool Stuf toma más tiempo el desarrollo de software en las primeras fases de análisis y diseño, se asegura la calidad de la aplicación, el entendimiento y la documentación, así como también minimiza el mantenimiento. •
Otra de las empresas que también cuenta con su herramienta de desarrollo NewEra orientada a la plataforma cliente/servidor y es totalmente orientada a objetos. Además posee dos formas de generar aplicaciones: en forma compilada y en interpretada. Ésta última disminuye considerablemente los tiempos de desarrollo. NewEra cuenta con una característica de particionamiento que permite al desarrollador decidir qué parte de la aplicación se va a ejecutar en la PC y qué parte en el servidor y esto se hace desde el mismo lenguaje y no a través de stored procedures . Su conectividad con otras plataformas se realiza por medio de drivers ODBC, específicamente para Informix, Oracle, Sybase. •
•
26
Herramienta de desarrollo que sirve para preservar toda la inversión existente en las aplicaciones que tiene una empresa en funcionamiento y le agrega nuevo valor al integrar diferentes fuentes de información no sólo de ambiente mainframe sino cliente/servidor, AS/400 y todo de manera interactiva y más amigable. Presenta un ambiente de desarrollo gráfico que tiene capacidad de comunicación con cualquier terminal 3270, VT100 y 5250 e integra cualquier base de datos relacional que tenga un driver ODBC. Sin embargo, y aunque pareciese no es un maquillador de pantalla, ya que además de contar con una interfaz tipo Windows permite al usuario crear sus propios temas y multimedios. Uno de las ventajas principales de Opal es CODE, el cual permite desarrollar una aplicación una sola vez independientemente del ambiente bajo el cual vaya a ser ejecutada y esa aplicación va a servir para un ambiente cliente/servidor, así como también para verlo a través de Internet e intranet. Cabe destacar que múltiples y diferentes fuentes de datos en la misma aplicación Opal pueden ser conectadas con una sesión 3270, VT100 y por otro lado estar accesando a una base de datos Oracle cliente/servidor y toda esta información converge en un sólo punto que va a ser la aplicación Opal y luego se despliega de acuerdo a lo que se requiere. Opal está compuesto por tres elementos: Integrator , ambiente de desarrollo orientado a objetos; Opal Player runtime, que permite ejecutar la aplicación para diversas plataformas y para Internet (browser Netscape y Explorer). El tercer y último componente es el Opal Server, para optimizar las comunicaciones entre la aplicación Opal que está corriendo en el cliente y los requerimientos de información hacia las fuentes de datos.
27
La evolución del software esta dividida en varias etapas, una de ellas es la llamada “crisis del software”. Esta crisis fue el resultado de la introducción de la tercera generación del hardware. El hardware dejo de ser un impedimento para el desarrollo de la informática; redujo los costos y mejoro la calidad y eficiencia en el software producido. La crisis se caracterizo por los siguientes problemas: •
•
•
Imprecisión en la planificación del proyecto y estimación de los costos. Baja calidad del software. Dificultad de mantenimiento de programas con un diseño poco estructurado, etc.
A raíz de esta crisis se vio la necesidad de crear estándares de desarrollo del software, esto dio lugar a lo que hoy llamamos “Ingeniería de software” el cual es el establecimiento y uso de principios de la ingeniería a fin de obtener económicamente software que sea fiable y que funcione eficientemente. A pesar de la creación de estos estándares, muchos sistemas siguieron siendo desarrollados y mantenidos sin aplicar ninguna practica de ingeniería de software por lo que hoy en día, muchas organizaciones se ven obligadas a seguir viviendo en esta crisis dado que sus sistemas son vitales para el funcionamiento de dichas organizaciones.
28
Para explicar el origen de la reingeniería de procesos es necesario retroceder al año 1898 durante la guerra de los Estados Unidos con España. Durante esta guerra, la Marina de los Estados Unidos disparó un total de 9500 proyectiles, de los cuales sólo 121 (1.3%) hicieron impacto sobre el objetivo. Durante este año, ese porcentaje representaba la máxima eficiencia mundial aunque en tiempos actuales ese porcentaje sería desastroso. En 1899, haciendo una nueva demostración del liderazgo que entonces ejercía en cañoneo naval de precisión, la Marina de los Estados Unidos realizó una exhibición de práctica de tiro para referenciar su rendimiento. En un total de veinticinco minutos de fuego contra un blanco que era un buque situado a una distancia aproximada de una milla (1.6 Km.), se registraron exactamente dos impactos, y éstos en las velas del buque que servía de blanco. Pero en 1902, las Marina de los Estados Unidos podía dar en un blanco parecido cuantas veces disparará un cañón; la mitad de las balas podían hacer impacto dentro de un cuadrado de 50 pulgadas por lado (1.7 m). , el cual se puede decir que fue el primero en utilizar el proceso que hoy llamamos . [Mang 95] Hace un siglo, apuntar un cañón hacia un blanco en alta mar era una actividad muy aleatoria. El cañón, el blanco y los mares que los rodeaban se hallaban en movimiento continuo. Los héroes tradicionales de los combates navales eran los navegantes que maniobraban para colocar el buque en una u otra posición y dar a los cabos de cañón la oportunidad de cumplir su difícil tarea. Pero en unas maniobras que se hicieron en el Mar de la China, Sims 29
observó los avances decisivos que los artilleros ingleses habían empezado a lograr en la manera de apuntar y disparar. Basándose en los cálculos que hizo en sus notas, Sims predijo que sus modificaciones al proceso tenían el potencial de aumentar la precisión de tiro en más del 3000 por ciento, sin costos adicionales, sin usar tecnología adicional, y sin necesidad de aumentar el personal de maniobra. Los consiguientes avances decisivos en productividad fueron enormes, ¡y llegaron al 3000 por ciento que había predicho Sims! Después de haber revisado el primer caso de reingeniería podríamos dar una vaga idea sobre el proceso llamado Reingeniería; el cual tiene como resultado un cambio radical en los procesos obsoletos para obtener un mejor aprovechamiento y rendimiento de la productividad. Este es considerado como el primer caso documentado en el que se aplica reingeniería ya que cumple con la definición que se da en el siguiente tema, el cual a grandes rasgos, es realizar un cambio radical a todo un proceso para lograr la productividad de una organización.
Una definición de basada en [Mang 95] y [Hamm 94] sería: es la actividad en el que los procesos son objeto de una revisión fundamental y rediseño radical, para lograr así la optimización de los flujos del trabajo y la productividad de una organización. Para poder analizar esta definición es necesario también definir lo que es un proceso. “Definimos
Se dice que durante una reingeniería, los procesos son objeto de una revisión fundamental ya que es necesario realizarse las preguntas básicas sobre su compañía y como funciona sin dar nada por sentado. 30
La revisión fundamental de un proceso nos permitirá aplicarle un rediseño radical lo cual no es simplemente realizar cambios superficiales o correcciones a lo que ya esta instalado.
Al aplicar la reingeniería a un proceso lograremos optimizar los flujos de trabajo y la productividad dando resultados que deben ser notables y hasta sorprendentes, esto debido a que el programa de reingeniería es difícil y nunca se conseguirá un apoyo ejecutivo sin promesas de resultados más que simplemente incrementales. La Reingeniería de Procesos es un enfoque equilibrado que puede contener elementos de los programas más tradicionales de mejoramiento con los cuales a veces se confunde. Pero la Reingeniería de Procesos es mucho más. En primer lugar, la Reingeniería de Procesos
Para lograr estos resultados, la reingeniería de procesos adopta una perspectiva de procesos sobre los negocios, mientras que otros programas conservan una perspectiva funcional u organizacional. La gestión de calidad total si examina los procesos, pero para mejorarlos incrementalmente, no para rediseñarlos.
31
Los sistemas de información heredados generalmente son la columna vertebral del flujo de información de las empresas y la principal forma de agruparla. Un (LIS por sus siglas en ingles Legacy Information System) puede ser definido como “cualquier sistema de información que significativamente se resiste a la modificación y evolución” [Brod 94]. Tales LISs pueden causar serios problemas a la organización: •
•
Los LISs casi siempre son ejecutados sobre hardware obsoleto que son lentos y caros de mantener. El mantenimiento del software puede ser caro, porque carecen de la documentación necesaria para el entendimiento de los detalles del sistema y su seguimiento es costoso y consume mucho tiempo.
•
•
Una falta de interfaces limpias hace que la integración de los LISs con otros sistemas sea difícil. Los LISs son también difíciles mas no imposibles ampliarlos.
La solución a estos problemas según Weiderman [Weid 97] caen en las siguientes categorías: •
•
•
: es un proceso incremental e iterativo en el cual se hacen pequeñas modificaciones al sistema. :
implica cambios más extensos que el mantenimiento pero conserva partes considerables del sistema existente. : el cual consiste en reconstruir desde los inicios al sistema. Esta solución consiste en aplicarle al sistema actividades de Reingeniería.
32
“El Instituto de Ingeniería de software (SEI) desarrollo una definición de Reingeniería como: Reingeniería
de la reingeniería es que los sistemas existentes tomen ventajas de las nuevas tecnologías y habilitar el nuevo esfuerzo de desarrollo para que aproveche las ventajas de reutilizar sistemas existentes. La reingeniería tiene el potencial de mejorar la productividad y calidad del software a través de todo el ciclo de vida. La reingeniería casi siempre implica cambiar la forma de un programa y mejorar su documentación. En este caso, la funcionalidad del programa no es cambiada; sólo su forma es modificada. En otros casos,
Los objetivos de la reingeniería son: [McCl 92] •
Proporcionar asistencia automatizada para el mantenimiento.
•
Reducir los errores y costos del mantenimiento.
•
Hacer sistemas fáciles de entender, cambiar y probar.
•
Mejorar la respuesta a peticiones de mantenimiento.
•
Proteger y extender la vida del sistema.
•
Usar CASE para apoyar sistemas existentes
•
Re-usar componentes de sistema existentes.
La reingeniería puede ayudar a entender sistemas existentes y descubrir los componentes de software que son comunes en todo el sistema. Estos 33
componentes comunes pueden ser re-usados en el desarrollo (o redesarrollo) de sistemas y así reducir el tiempo y riesgos del desarrollo de sistemas. La reingeniería requiere tiempo; implica un costo de dinero enorme y absorbe recursos que de otro modo se podrían emplear en preocupaciones más inmediatas. Por todo esto, 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.
Mucha gente al ver las grandes y viejas mansiones queda asombrado de su belleza, pero no se preguntan que tan bien se puede vivir en ellas. Las personas que lo hacen dicen que es una pesadilla mantenerlas. Todas ellas fueron construidas con viejas tecnología estándar. Sus paredes externas no tienen aislamiento. El alumbrado eléctrico tiene limitaciones y claramente es inadecuada para las necesidades de energía de hoy y su cableado decadente crea un severo peligro eléctrico. Los viejos sistemas son muy similares a los grandes y viejos edificios. Ellos tienen los mismos problemas de mantenimiento, un hecho en gran parte irreconocible por parte de la comunidad corporativa. Muchos de esos edificios son demolidos por que no son mantenibles y ya no sirven para las necesidades de sus ocupantes. Las viejas computadoras tal vez se puedan ver solamente en museos. Pero en muchos casos, software escrito para viejos modelos de computadora están ejecutándose hoy en día. Un caso extremo es el de un software escrito para una IBM 1401 Autocoder. Cuando la compañía remplazó la 1401 con una IBM
34
360/40, compraron un emulador de la 1401 para poder ejecutar el software. Esa aplicación hoy día corre en una PC – la compañía compro otro emulador. La siguiente lista son las heredados: •
Frecuentes fallas de producción (fiabilidad cuestionable).
•
Problemas de rendimiento.
•
Tecnología obsoleta.
•
Problemas de integración del sistema.
•
Código de calidad pobre.
•
Dificultad (peligroso) al cambio.
•
Dificultad para probar.
•
Mantenimiento caro.
•
Incremento de problemas del sistema.
Antes de reconstruir un sistema en uso, es altamente recomendable analizar las diversas alternativas disponibles: •
•
•
Dejar el producto como está. Adquirir uno en el mercado que realice la misma función. Reconstruirlo.
Evidentemente, elegiremos la opción que mejor relación coste/beneficio nos ofrezca. Para calcular los costes de un proyecto de reingeniería, Harry Sneed [Snee 95] propone un modelo basado en cuatro etapas: •
•
•
•
Justificación del proyecto de reingeniería. Análisis de la cartera de aplicaciones. Estimación de costes. Análisis de costes / beneficios.
35
Para justificar un proyecto de reingeniería se requiere de un análisis del software existente, de los procesos de mantenimiento actuales y del valor de negocio que tienen las aplicaciones; todo esto con el objeto de hacer una evaluación en posibles aumentos de valores sobre estos tres factores. La mayoría de las organizaciones sólo toman en consideración los procesos de reingeniería cuando el coste de un nuevo desarrollo es demasiado alto. En cualquier caso, y aunque a primera vista parezca la única o la mejor alternativa, es necesario confirmar la necesidad de reconstruir el sistema.
En esta etapa se cotejan la calidad técnica y el valor de negocio de cada aplicación, con el objetivo de construir una lista de aplicaciones, ordenada según sus prioridades en el proceso de reingeniería.
Se realiza identificando y ponderando, mediante métricas adecuadas, todos los componentes del software que se van a modificar. Se deben considerar los costes de cada proyecto de reingeniería: si éstos son superiores a los beneficios, la reingeniería no será una alternativa viable y la aplicación deberá ser desarrollada de nuevo o bien adquirirse en el mercado. Para estimar los costes de la reingeniería, se tienen ciertas ventajas respecto a la misma estimación en proyectos de ingeniería directa: no se debe calcular factores influyentes como el número de líneas de código, sentencias ejecutables, elementos de datos, accesos a archivos, etc., ya que son medidas que se pueden tomar directamente de la aplicación.
Una vez que se ha calculado el coste de la reingeniería, la última etapa es comparar los costes con los beneficios esperados (no es suficiente con examinar los beneficios que aporte la reingeniería).
36
El beneficio proporcionado por continuar manteniendo el producto sin reingeniería es el siguiente:
Deberá retocarse la fórmula cuando los diversos costes varíen de un año para otro. Si se desarrolla de nuevo el sistema, se obtiene este beneficio:
El beneficio producido por la reingeniería es:
Donde: P1 = Coste de mantenimiento actual para una aplicación (anual). P2 = Coste de operación de una aplicación (anual). P3 = Valor del negocio actual (anual). P4 = Coste previsto de mantenimiento tras la reingeniería (anual). P5 = Coste previsto de operaciones tras la reingeniería (anual). P6 = Valor de negocio previsto tras la reingeniería (anual). P7 = Coste estimado de la reingeniería. P8 = Duración estimada de la reingeniería. P9 = Factor de riesgo de la reingeniería. P10 = Coste previsto de mantenimiento tras el redesarrollo (anual). P11 = Coste previsto de operaciones tras el redesarrollo (anual). P12 = Valor de negocio previsto el nuevo sistema (anual). P13 = Coste estimado del redesarrollo. P14 = Duración estimada del redesarrollo. P15 = Factor de riesgo del redesarrollo. 37
P16 = Vida esperada del sistema.
Este apartado se explica de una forma muy breve el modelo cíclico que es uno de los mas utilizados para llevar a cabo de manera satisfactoria la actividad de reingeniería, sin dejar de mencionar que existen mas modelos como son el de la herradura, actividades del método OAR (análisis de Opciones para Reingeniería) por sus siglas en ingles Options Analysis for Reengineering, por mencionar algunos.
Este modelo define [Pres 02] seis actividades las cuales se muestran en la figura 3.3. En algunas ocasiones, 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.
38
An álisisde inventario Ingenier
ía
directa
Reestructuraci dedocumentos
ón
Reestructuraci ón dedatos
Ingenier
ía
Inversa Reestructuraci del c ódigo
ón
Figura3.3Modeloc
íclico
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 puede repetirse en otras ocasiones. Para un ciclo en particular, el proceso puede terminar después de cualquier de estas actividades.
39
En esta sección se dará una breve explicación de las actividades que se definen en el modelo cíclico: Análisis de inventario, Reestructuración de documentos, Ingeniería inversa, Reestructuración de código, Reestructuración de datos e Ingeniería directa.
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 calculo 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.
Una documentación escasa es la marca de muchos sistemas de información 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 ajustaremos con lo que se tiene. 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á 40
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 es 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.
Todas y cada una de estas opciones son viables. Las organizaciones del software deberán seleccionar aquella que resulte más adecuada para cada caso.
El término “ingeniería inversa” tiene sus orígenes en el mundo del hardware. Una cierta compañía desensambla un producto de hardware competitivo en un esfuerzo por comprender los “secretos” del diseño y fabricación de su competidor. Estos secretos se podrán comprender más fácilmente si se obtuvieran las especificaciones de diseño y fabricación del mismo. Pero estos documentos son privados, y no están disponibles para la compañía que efectúa la ingeniería inversa. En esencia, una ingeniería inversa con éxito precede de una o más especificaciones de diseño y fabricación para el producto, mediante el examen de ejemplos reales de ese producto. La ingeniería inversa del software es algo bastante similar. Sin embargo, en la mayoría de los casos, el programa del cual hay que hacer una ingeniería inversa no es el de un rival, sino, más bien, el propio trabajo de la compañía 41
(con frecuencia efectuado hace muchos años). Los “secretos” que hay que comprender resultan incomprensibles porque nunca se llegó a desarrollar una especificación. Consiguientemente,
El tipo más común de reingeniería es la reestructuración del código. Algunos sistemas heredados tienen una arquitectura de programa relativamente sólida, pero los módulos individuales han sido codificados de una forma que hace difícil comprenderlos, comprobarlos y mantenerlos. En estos casos, se puede reestructurar el código ubicado dentro de los módulos sospechosos. Para llevar a cabo esta actividad, se analiza el código fuente mediante una herramienta de reestructuración, se indican las violaciones de las estructuras de programación estructurada, y entonces se reestructura el código (esto se puede hacer automáticamente). El código reestructurado resultante se revisa y se comprueba para asegurar que no se hayan introducido anomalías. Se actualiza la documentación interna del código.
Un programa que posea una estructura de datos débil será difícil de adaptar y de mejorar. De hecho, para muchas aplicaciones, la arquitectura de datos tiene más que ver con la viabilidad a largo plazo del programa que el propio código fuente. A diferencia de la reestructuración de código, que se produce en un nivel relativamente bajo de abstracción, la estructuración de datos es una actividad 42
de reingeniería a gran escala. En la mayoría de los casos, la reestructuración de datos comienza por una actividad de ingeniería inversa. La arquitectura de datos actual se analiza minuciosamente y se definen los modelos de datos necesarios. Se identifican los objetos de datos y atributos y, a continuación, se revisan las estructuras de datos a efectos de calidad. Cuando la estructura de datos es débil (por ejemplo, actualmente se implementan archivos planos, cuando un enfoque relacional simplificaría muchísimo el procesamiento), se aplica una reingeniería a los datos. Dado que la arquitectura de datos tiene una gran influencia sobre la arquitectura del programa, y también sobre los algoritmos que los pueblan, los cambios en datos darán lugar invariablemente a cambios o bien de arquitectura o bien de código.
En un mundo ideal, las aplicaciones se reconstruyen utilizando un “motor de reingeniería” automatizado. En el motor se insertaría 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.
En la mayoría de los casos, el software procedente de una reingeniería vuelve a implementar la funcionalidad
43
