Anlisis y Diseo de Sistemas de Informacin II.

PROCESO UNIFICADO DE RATIONAL

Anlisis y Diseo de Sistemas de Informacin II.

I UNIDAD EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE. Antecedentes del RUP. Las 4 PS del Desarrollo de Software. El proceso Dirigido por Casos de Uso El proceso Centrado en la Arquitectura. El Proceso Iterativo e incremental. EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo software iterativo e incremental. Unificado de Rational o simplemente RUP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, el Proceso Unificado de Rational , tambin 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. Un poco de historia Los orgenes 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 investigacin. En 1995 Rational Software es comprada por una compaia sueca llamada Objectory AB. El Rational Unified Process (proceso unificado de Rational) fuel el resultado de una convergencia de Rational Approach y 2 El refinamiento ms conocido y documentado del Proceso Unificado es el Proceso

Anlisis y Diseo de Sistemas de Informacin II.

Objectory, proceso desarrollado por el fundador de Objectory Ivan Jacobson. La primera versin 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 visin que parte de la arquitectura siguiendo un proceso interactivo e incremental, el proceso integra diferentes aspectos como son los ciclos, fases, flujos de trabajo, mitigacion de riesgos, control de calidad, administracin de proyectos y control de configuracin. De manera adicional el proceso unificado considera las cuatro ps del desarrollo de software: personas, proyectos, 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 construccin permite disear edificios desde mltiples puntos de vistas, estructura, electricidad, etc.. las arquitecturas de los sistemas de software deben de permitir visualizar un sistema desde mltiples perspectivas. El desarrollo de un producto de software comercial, pueden significar un gran esfuerzo durante meses, e incluso aos. Es prctico dividir el trabajo en etapas donde cada iteracin resulta en un incremento del proyecto.

El Proceso Racional Unificado o RUP (Rational Unified Process), es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. RUP es en realidad un refinamiento realizado por Rational Software del ms genrico Proceso Unificado.
3

Anlisis y Diseo de Sistemas de Informacin II.

Sus principales caractersticas son:

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software

Desarrollo interactivo Administracin de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificacin 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, el cdigo fuente, etc.) y roles (papel que desempea una persona en un determinado momento, una persona puede desempear distintos roles a lo largo del proceso). El RUP 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 decisin importante:

Inicio: se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos Elaboracin: se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos Construccin: se concentra en la elaboracin de un producto totalmente operativo y eficiente y el manual de usuario Transicin: 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

Anlisis y Diseo de Sistemas de Informacin II.

FASES DEL RUP

Establece oportunidad y alcance Identifica las entidades externas o actores con las que se trata Identifica los casos de uso

donde usted coloca interactivo debera ir la palabra iterativo El proceso, Dirigido por los casos de uso 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 iteracin de un conjunto de casos de uso o escenarios y desarrolle todo el camino a travs de las distintas disciplinas: diseo, implementacin, prueba, etc. Captura de requisitos como caso de uso 1. Artefactos 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

Anlisis y Diseo de Sistemas de Informacin II.

Instancia: es un actor que interacta con el sistema. 3. Caso de uso Interaccin: Es una secuencia de acciones que el sistema lleva a cabo (interactuando con actores) para dar un resultado de valor. Descripcin de CU puede incluir diagramas de actividad. Instancia de CU: Es la realizacin de los CU. Son atmicas: se ejecutan todo o nada. Sin otros de por medio. Los CU tienen atributos, valores que en su ejecucin 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: descripcin de una arquitectura Contiene una vista del modelo de CU que describe los aspectos ms 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. Trabajador Representa los comportamientos, descripciones y responsabilidades del mismo.

Anlisis y Diseo de Sistemas de Informacin II.

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. Diseador de interfaz: Es responsable del prototipo de interfaz de usuario. Arquitecto: Trabaja con la captura de requisitos para disear las vistas de la arquitectura del modelo de CU. 3. Flujos de trabajo Conjunto de actividades que estn 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 travs 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 versin del modelo de CU con actores: Encontrar los actores / CU / describir cada CU / Describir modelo de CU. No requieren de un rden.

Anlisis y Diseo de Sistemas de Informacin II.

El proceso Centrado en la arquitectura El Proceso Unificado asume que no existe un modelo nico que cubra todos los aspectos del sistema. Por dicho motivo existen mltiples modelos y vistas que definen la arquitectura software de un sistema. La analoga con la construccin es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanera, etc. Arquitectura: Da una perspectiva del sistema completo; todos los empleados deben estar de acuerdo con ella. Describe los elementos ms importantes del sistema. El 1er. Objetivo de la fase de elaboracin es construir una arquitectura slida que sirva de base para construir el sistema. 1. Arquitectura en pocas palabras El conjunto de todas las vistas representa a la arquitectura. Cada vista es una perspectiva diferente del sistema. Cantidad de pginas para la Descripcin de arquitectura: Se recomienda que sea de entre 50 y 100 2. Por qu es necesaria la arquitectura Para que los desarrolladores progresen hasta obtener una visin comn (en sistema de software grandes) Para dividir el proyecto en clases y facilitar su reutilizacin (futuros cambios) 1. Compresin del sistema Todos las personas que trabajen en el desarrollo del sistema deben comprenderla lo cual es un reto difcil porque: operan en 8

Anlisis y Diseo de Sistemas de Informacin II.

entornos complejos y al dividirlos en mini proyectos es difcil coordinarlos. 2. Organizacin del desarrollo Mientras ms grande sea el proyecto habr mayor sobrecarga en la comunicacin entre los distintos desarrolladores; para ello se divide el sistema en subsistemas donde cada uno tendr un responsable. Tambin es importante tener interfaces bien definidas. 3. Evolucin 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. 3. Casos de uso y arquitectura La arquitectura se ve condicionada por: Los casos de usos ms importantes (ms 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. Estndares y polticas corporativas. Requisitos no funcionales.

La arquitectura del sistema se desarrolla en fase de elaboracin junto con los casos de usos ms importantes. Una vez que se tiene una arquitectura estable 9

Anlisis y Diseo de Sistemas de Informacin II.

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 segn la arquitectura del sistema. El proceso, Enfocado en los riesgos El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos crticos en una etapa temprana del ciclo de vida. Los resultados de cada iteracin, en especial los de la fase de Elaboracin, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero. Iterativo e Incremental El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio slo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que aade 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 clsico o en cascada: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del proyecto.

1. Por qu un desarrollo iterativo e incremental? 1. Atenuacin de riesgos

10

Anlisis y Diseo de Sistemas de Informacin II.

Riesgo: es una variable que pone en peligro o impide el xito del proyecto. "Aproximacin al proceso de desarrollo dirigido por riesgos": El Proceso Unificado reconoce los riesgos ms importantes en las primeras 2 fases y reduce los mismos. Los que no, pueden poner en peligro el proyecto entero. Mtodo cascada: El desarrollo del sistema no se divide en iteraciones. Los problemas graves pueden saltar en la fase de integracin & prueba; esto obliga a contratar a desarrolladores con ms experiencia, el proyecto queda parado y se retrasan las fechas. Mtodo iterativo: Los riesgos importantes se tratan en las primeras fases, quedando muy pocas en la de construccin. El proyecto marcha sin inconvenientes hasta el final. 2. Obtencin de una arquitectura robusta Mtodo 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. Mtodo iterativo: Es al final de la fase de elaboracin donde se evala la arquitectura; si an no est madura se trabaja en una nueva iteracin; esto es posible ya que es muy poco lo que se invierte en esta fase y las fechas an no estn definidas. 3. Gestin de requisitos cambiantes construccin: es una versin operativa del sistema que demuestra un subconjunto de posibilidades. 11

Anlisis y Diseo de Sistemas de Informacin II.

Es ms fcil para el usuario ver un sistema ejecutable en funcionamiento que leer cientos de pginas de documentos. Esto permite a que los usuarios opinen y sugieran modificar o agregar cosas que se nos pas de largo. En mtodo cascada los usuarios ven al sistema funcionando recin en la integracin y prueba, y si desea cambiar algo debern aumentar presupuesto y atrasar las fechas. 4. Permitir cambios tcticos Con mtodo iterativo los directores se encargan de ver al final de cada iteracin.. Si hubo un incremento y se han resueltos los problemas; entonces autorizar a los desarrolladores a seguir con la siguiente iteracin. Si el xito fue parcial, se ampliar la iteracin hasta poder cumplir con lo requerido. Si el resultado es negativo puede llegar a cancelarse el proyecto. Conseguir una iteracin continua Mtodo cascada: Muchos errores parecen no estar presentes y el proyecto progresa con norma-lidad hasta llegar a la integracin y prueba; ah salen todos a la luz. Estas ponen en peligro al proy Mtodo iterativo: Ya desde un principio se hacen frecuentes construcciones, y con stas aparecen los errores que se tratarn 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 iteracin a otra. Puede empezar con unas 5 a 10 pers. pasar a 25 y finalmente a 100. Los nuevos

12

Anlisis y Diseo de Sistemas de Informacin II.

tienen una formacin adecuada y trabajan con gente con experiencia, rpidamente se ajustan a la velocidad adecuada. 1. La aproximacin iterativa est dirigida por riesgos 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 iteracin temprana. En fase de inicio y elaboracin se tratan la mayora de los riesgos. Hay 4 formas de tratar a un riesgo segn su prioridad: Evitarlo: Quizs se tenga que replanificar el proyecto o hacer un cambio de requisitos. Limitarlo: Achicarlo para que afecta una parte pequea 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 mnimos. Se manejan por iteraciones para no tener que tratar con todos los errores a la vez. Qu es una iteracin Una iteracin es un mini proyecto donde se tiene como resultado una versin interna. Est compuesto por 5 flujos de trabajos: requisitos, anlisis, etc. 13

Anlisis y Diseo de Sistemas de Informacin II.

Los trabajadores y artefactos pueden trabajar en ms de un flujo de trabajo. Las Fases estn divididas en N iteraciones. Descripcin de cada fase:

Inicio: Hacer anlisis del negocio y reducir los riesgos ms importantes. Elaboracin: Obtener lnea base de la arquitectura, capturar requisitos, reducir dems riesgos. Construccin: Desarrollar el sistema entero. Ofrecer funcionalidad operativa a clientes. Transicin: Tener el producto preparado para la entrega. Se ensea a usuarios a utilizar el software.

Cada iteracin se analiza cuando termina y se ven si cambiaron o aparecieron nuevos requisitos que modificarn a la siguiente iteracin. Prueba de regresin: Sirve para ver si no se han estropeado iteraciones anteriores. Se aplica al antes de terminar con la iteracin actual. Definiciones de Incremento: Diferencia entre la versin interna de la iteracin anterior y la siguiente. Diferencia entre 2 lneas bases sucesivas. Colaboracin: Es la representacin de los CU ms significativos para la arquitectura. Sirve para identificar subsistemas e interfaces. Luego se les da forma (implementa cdigo). Hay ms incrementos a medida que nos acercamos a la fase de transicin. La integracin del ltimo incremento se convierte en el sistema final.

14

Anlisis y Diseo de Sistemas de Informacin II.

Cuestionario: 1. El proceso unificado es adaptado a: Organizaciones y proyectos especficos.

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 compaa es comprada el RUP Por una compaa 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, administracin de proyectos y control de configuracin. 7. Cuales son las cuatro Ps del desarrollo de software? Persona, proyecto, producto y proceso. 15

Anlisis y Diseo de Sistemas de Informacin II.

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 iteracin 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, Elaboracin, construccin y transicin. 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 Construccin. 14. En que fase del RUP se entrenan a los usuarios del sistema?; En la fase de Transicin. 15. En que fase del RUP se eliminan los riesgos?

16

Anlisis y Diseo de Sistemas de Informacin II.

En la fase de Elaboracin. 16. Es el papel que desempea 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 cdigo fuente, etc. 19. En que fase del rup suelen surgir de nuevo requisitos para ser analizados y por supuesto considerados? En la fase de Transicin.

17

Anlisis y Diseo de Sistemas de Informacin II.

II UNIDAD FLUJOS DE TRABAJO

1. Modelado del negocio: describe la estructura y la dinmica de la organizacin. 2. Requisitos: describe el mtodo basado en casos de uso para extraer los requisitos. 3. Anlisis y diseo: describe las diferentes vistas arquitectnicas. 4. Implementacin: tiene en cuenta el desarrollo de software, la prueba de unidades y la integracin. 5. Pruebas: describe los casos de pruebas, los procedimientos y las mtricas para evaluacin de defectos. 6. Despliegue: cubre la configuracin del sistema entregable. 7. Gestin de configuraciones: controla los cambios y mantiene la integridad de los artefactos de un proyecto. 8. Gestin del Proyecto: describe varias estrategias de trabajo en un proceso iterativo. 9. Entorno: 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

Anlisis y Diseo de Sistemas de Informacin II.

Un artefacto es algn documento, informe o ejecutable que se produce, se manipula o se consume. Una actividad describe las tareas (pasos de concepcin, realizacin y revisin) que llevan a cabo los trabajadores para crear o modificar los artefactos, junto con las tcnicas y guas para ejecutar las tareas, incluyendo algunas de ellas. III UNIDAD PROCESO ITERATIVO E INCREMENTAL quiz el uso de herramientas para ayudar a automatizar

IV UNIDAD IMPLEMENTACIN DEL MODELADO UTILIZANDO UNA HERRAMIENTAS CASE

INTRODUCCIN A LAS HERRAMIENTAS CASE CASE= Ingeniera 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 visin general de la ingeniera. Aseguran que la calidad sea algo diseado antes de construir el producto. CASE "CASE es una filosofa que se orienta a la mejor comprensin de los modelos de empresa, sus actividades y el desarrollo de los sistemas de informacin. Esta filosofa involucra adems el uso de programas que permiten: 19

Anlisis y Diseo de Sistemas de Informacin II.

Construir los modelos que describen la empresa, Describir el medio en el que se realizan las actividades, Llevar a cabo la planificacin, El desarrollo del Sistema Informtico, desde la planificacin, pasando por el anlisis y diseo de sistemas, hasta la generacin del cdigo de los programas y la documentacin." Michael Lucas Gibson.

OBJETIVOS DE CASE Aumentar la productividad de las reas de desarrollo y mantenimiento de los sistemas informticos. Mejorar la calidad del software desarrollado. Reducir tiempos y costes de desarrollo y mantenimiento del software. Mejorar la gestin y dominio sobre el proyecto en cuanto a su planificacin, ejecucin 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 documentacin La generacin del cdigo El chequeo de errores La gestin del proyecto Permitir La reutilizacin (reusabilidad) del software La portabilidad del software La estandarizacin de la documentacin 20

Anlisis y Diseo de Sistemas de Informacin II.

Integrar las fases de desarrollo (ingeniera del software) con las herramientas CASE Facilitar la utilizacin de las distintas metodologas que desarrollan la propia ingeniera del software.

ENCICLOPEDIA (REPOSITORY) En el contexto CASE se entiende por enciclopedia a la base de datos que contiene todas las informaciones relacionadas con las especificaciones, anlisis y diseo 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, mdulos, etc. GRFICOS: DFD (Diagrama de flujo de datos), DER (Diagrama Entidad Relacin) DFD (Diagrama de Descomposicin Funcional), ED (Diagrama de Estructura), Diagrama de Clases, etc. REGLAS: de Gestin, de mtodos, etc. CLASIFICACION DE LAS HERRAMIENTAS CASE CASE es una combinacin de herramientas software (aplicaciones) y de metodologas de desarrollo: Las herramientas permiten automatizar el proceso de desarrollo del software. Las metodologas definen los procesos automatizar. Una primera clasificacin del CASE es considerando su amplitud:

21

Anlisis y Diseo de Sistemas de Informacin II.

TOOLKIT: es una coleccin de herramientas integradas que permiten automatizar un conjunto de tareas de algunas de las fases del ciclo de vida del sistema informticos; Planificacin estratgica, Anlisis, Diseo, Generacin de programas. WORKBENCH: Son conjuntos integrados de herramientas que dan soporte a la automatizacin del proceso completo de desarrollo del sistema informtico. Permiten cubrir el ciclo de vida completo. El producto final aportado por ellas es un sistema en cdigo ejecutable y su documentacin.

Una segunda clasificacin es teniendo en cuenta las fases (y/o tareas) del ciclo de vida que automatizan

UPPER CASE: Planificacin estratgica, Requerimientos de Desarrollo Funcional de Planes Corporativos. MIDDLE CASE: Anlisis y Diseo. LOWER CASE: Generacin de cdigo, test e implantacin

HERRAMIENTAS CASE EN EL MERCADO ACTUAL A continuacin se presenta en forma breve, una resea 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 tecnologa orientada a objetos y a tecnologa cliente/servidor que permiten la reutilizacin del software; nos permitimos dividir secciones entre estas, como a continuacin se describe.

PowerBuilder de PowerSoft

Con 30 manejadores de base de datos, ofrece dos opciones de conectividad:

ODBC de Microsoft y conectividad nativa. Una de las caractersticas principales

(muy apreciada por los usuarios, quienes dicen es mejor con Oracle e Informix 22

Anlisis y Diseo de Sistemas de Informacin II.

que sus propias herramientas) de este producto es que comparte el mismo idioma de cada manejador. Incluye entre otros mdulos el Optima++, herramienta RAD basada en componentes que combina desarrollos cliente/servidor e Internet con el rendimiento de C++. Asimismo, ofrece un mdulo opcional CASE Power Design que genera modelos lgicos y fsicos de los distintos manejadores que soporta para acelerar los desarrollos. Power Builder cuenta con conectividad para aplicaciones Java a travs del

driver JDBC, desarrollado por Sybase y puede construir aplicaciones sobre

cualquier plataforma. Precisamente, Java es uno de los lenguajes de programacin que ms est dando que hablar hoy da por considerarse un nuevo paradigma en el mundo de la computacin, 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 aplicacin en bytecodes diseados para trabajar y viajar a lo largo de una red desde el servidor hasta el cliente y puede correr encima de un

browser o de un sistema operativo a travs del Java Virtual Machine que

permite correr la aplicacin sobre cualquier tipo de cliente". Se considera que una de las fortalezas de Java son sus Interfaces de Programacin de Aplicaciones (APIs), que las hay especficas y por reas de industria y disponibles en la red. "Hoy da 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 cdigo, lo compila una sola vez y ese programa puede correr en cualquier plataforma. Si bien esta es la bandera de Sun an est en entredicho que la misma siga ondeando dado que Java est a media asta en Microsoft. Las caractersticas novedosas de Java, especialmente su total orientacin 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

Anlisis y Diseo de Sistemas de Informacin II.

vez ms agresiva hacia el mercado tuvo que ceder ante sus encantos y ya tiene su Visual J++.

Visual Basic

Actualmente Microsoft contina impulsando este lenguaje, el cual es una evolucin de su antecesor Basic y como su nombre lo indica, es un ambiente de desarrollo ms visual. A partir de la versin 5.0 cuenta con un compilador original de cdigos y est ms orientado a ambientes cliente/servidor e incluye soporte e integracin a aplicaciones Internet/intranet a travs de la tecnologa 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 va ODBC y an cuando no est orientada a objetos porque no soporta polimorfismos, cumple algunas de las reglas de esta tecnologa al permitir reutilizar componentes para el desarrollo de aplicaciones personalizadas.

Visual FoxPro y Visual C++

Las herramientas de desarrollo orientadas a objetos con que Microsoft cuenta son Visual FoxPro y Visual C++, siendo ahora lo ms reciente InterDev. De tales herramientas, esta ltima es la primera que ayuda a los desarrolladores de aplicaciones basadas en Web en la construccin de sitios sofisticados totalmente interactivos. InterDev disminuye el ciclo de desarrollo al soportar los lenguajes de Internet Java y Visual Basic Scrip interconectndose con otros lenguajes como C++ o Visual Basic a travs de componentes ActiveX, adems, puede interactuar totalmente con FrontPage 97 (herramienta orientada a usuarios finales y diseadores). De esta manera ambos pueden trabajar en equipo para la construccin de sitios Web.

Oracle

24

Anlisis y Diseo de Sistemas de Informacin II.

Siguiendo la orientacin al Web, Oracle en la actualidad est enfocada directamente a su Arquitectura de Computacin de Redes (NCA), considerada como un servidor universal de datos, aprovechando lo mejor de los tres mundos: Web, cliente/servidor y orientacin a objetos. Sus herramientas de desarrollo son bsicamente tres: Developer/2000, 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 slo en Oracle, pero soporta bsicamente las bases de datos SQL Server de Microsoft e Informix. Oracle J-Dveloper, un generador de software de objetos en Java que pueden correr en cualquier browser y permite reutilizarlos. Designer/2000, herramienta de modelaje de alto nivel para procesos, entidad-relacin, work flow y modelajes funcionales. La principal diferencia de esta herramienta es que manteniendo un modelaje de alto nivel puede generar la aplicacin final y luego realiza reingeniera de reverso para actualizar el repositorio central.

Erwin

Erwin es otra de las herramientas de la tecnologa CASE, cuyo mayor diferenciador es su simplicidad (por generar cdigo para la mayora 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 metodologa para realizar diagramas entidad-relacin y cuenta con una interfaz grfica altamente intuitiva. La versin 3.0 que incluye un servidor de ingeniera de reverso, funcin que lleva a cabo desde los datos existentes a modelos lgicos de datos. Asimismo trae un editor de disparadores (triggers) y de stored procedures.

25

Anlisis y Diseo de Sistemas de Informacin II.

Cool Stuf, de Sterling Software

Esta herramienta cuenta con un mdulo para generar ingeniera de software tradicional, as mismo, una lnea de productos para desarrollo de aplicaciones cliente/servidor de mltiples capas y para ambientes distribuidos. Adems puede generar aplicaciones para Internet/intranets, soporta mtodos 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 reingeniera de los procesos del negocio, anlisis, diseo, distribucin de procesos de datos y generacin automtica de cdigo que puede ser en C++, Java o Cobol. Para ello se apoya en la metodologa de James Martin, as como tambin en metodologas basadas en Orientacin a Objetos. Una desventaja de esta es que utilizar una herramienta CASE del tipo Cool Stuf toma ms tiempo el desarrollo de software en las primeras fases de anlisis y diseo, se asegura la calidad de la aplicacin, el entendimiento y la documentacin, as como tambin minimiza el mantenimiento.

Informix

Otra de las empresas que tambin cuenta con su herramienta de desarrollo NewEra orientada a la plataforma cliente/servidor y es totalmente orientada a objetos. Adems posee dos formas de generar aplicaciones: en forma compilada y en interpretada. sta ltima disminuye considerablemente los tiempos de desarrollo. NewEra cuenta con una caracterstica de particionamiento que permite al desarrollador decidir qu parte de la aplicacin se va a ejecutar en la PC y qu parte en el servidor y esto se hace desde el mismo lenguaje y no a travs de stored procedures. Su conectividad con otras plataformas se realiza por medio de drivers ODBC, especficamente para Informix, Oracle, Sybase.

Herramientas CASE tradicionales Opal, de Computer Associates 26

Anlisis y Diseo de Sistemas de Informacin II.

Herramienta de desarrollo que sirve para preservar toda la inversin existente en las aplicaciones que tiene una empresa en funcionamiento y le agrega nuevo valor al integrar diferentes fuentes de informacin no slo de ambiente mainframe sino cliente/servidor, AS/400 y todo de manera interactiva y ms amigable. Presenta un ambiente de desarrollo grfico que tiene capacidad de comunicacin 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 adems 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 aplicacin una sola vez independientemente del ambiente bajo el cual vaya a ser ejecutada y esa aplicacin va a servir para un ambiente cliente/servidor, as como tambin para verlo a travs de Internet e intranet. Cabe destacar que mltiples y diferentes fuentes de datos en la misma aplicacin Opal pueden ser conectadas con una sesin 3270, VT100 y por otro lado estar accesando a una base de datos Oracle cliente/servidor y toda esta informacin converge en un slo punto que va a ser la aplicacin 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 aplicacin 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 aplicacin Opal que est corriendo en el cliente y los requerimientos de informacin hacia las fuentes de datos.

27

Anlisis y Diseo de Sistemas de Informacin II.

REINGENIERIA DE SOFTWARE INTRODUCCIN La evolucin del software esta dividida en varias etapas, una de ellas es la llamada crisis del software. Esta crisis fue el resultado de la introduccin de la tercera generacin del hardware. El hardware dejo de ser un impedimento para el desarrollo de la informtica; redujo los costos y mejoro la calidad y eficiencia en el software producido. La crisis se caracterizo por los siguientes problemas: Imprecisin en la planificacin del proyecto y estimacin de los costos. Baja calidad del software. Dificultad de mantenimiento de programas con un diseo poco estructurado, etc. A raz de esta crisis se vio la necesidad de crear estndares de desarrollo del software, esto dio lugar a lo que hoy llamamos Ingeniera de software el cual es el establecimiento y uso de principios de la ingeniera a fin de obtener econmicamente software que sea fiable y que funcione eficientemente. A pesar de la creacin de estos estndares, muchos sistemas siguieron siendo desarrollados y mantenidos sin aplicar ninguna practica de ingeniera de software por lo que hoy en da, muchas organizaciones se ven obligadas a seguir viviendo en esta crisis dado que sus sistemas son vitales para el funcionamiento de dichas organizaciones. La reingeniera de software es la actividad con el cual se pretende dar solucin a estas organizaciones. La reingeniera de software pretende dejar morir esos sistemas imposibles de mantener, no sin antes extraer de ellos conocimientos que permitan crear un nuevo sistema fiable, eficiente y de fcil mantenimiento. 28

Anlisis y Diseo de Sistemas de Informacin II.

I.

REINGENIERIA DE PROCESOS

PRINCIPIOS DE LA REINGENIERA: Para explicar el origen de la reingeniera de procesos es necesario retroceder al ao 1898 durante la guerra de los Estados Unidos con Espaa. Durante esta guerra, la Marina de los Estados Unidos dispar un total de 9500 proyectiles, de los cuales slo 121 (1.3%) hicieron impacto sobre el objetivo. Durante este ao, ese porcentaje representaba la mxima eficiencia mundial aunque en tiempos actuales ese porcentaje sera desastroso. En 1899, haciendo una nueva demostracin del liderazgo que entonces ejerca en caoneo naval de precisin, la Marina de los Estados Unidos realiz una exhibicin de prctica 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 serva de blanco. Pero en 1902, las Marina de los Estados Unidos poda dar en un blanco parecido cuantas veces disparar un can; la mitad de las balas podan hacer impacto dentro de un cuadrado de 50 pulgadas por lado (1.7 m). Este espectacular rendimiento fue logrado gracias a un oficial de artillera naval llamado William Sonden Sims, el cual se puede decir que fue el primero en utilizar el proceso que hoy llamamos reingeniera . [Mang 95] Hace un siglo, apuntar un can hacia un blanco en alta mar era una actividad muy aleatoria. El can, el blanco y los mares que los rodeaban se hallaban en movimiento continuo. Los hroes tradicionales de los combates navales eran los navegantes que maniobraban para colocar el buque en una u otra posicin y dar a los cabos de can la oportunidad de cumplir su difcil tarea. Pero en unas maniobras que se hicieron en el Mar de la China, Sims 29

Anlisis y Diseo de Sistemas de Informacin II.

observ los avances decisivos que los artilleros ingleses haban empezado a lograr en la manera de apuntar y disparar. Basndose en los clculos que hizo en sus notas, Sims predijo que sus modificaciones al proceso tenan el potencial de aumentar la precisin de tiro en ms del 3000 por ciento, sin costos adicionales, sin usar tecnologa 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 haba predicho Sims! Despus de haber revisado el primer caso de reingeniera podramos dar una vaga idea sobre el proceso llamado Reingeniera; 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 reingeniera ya que cumple con la definicin 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 organizacin. REINGENIERA DE PROCESOS Una definicin de Reingeniera basada en [Mang 95] y [Hamm 94] sera: es la actividad en el que los procesos son objeto de una revisin fundamental y rediseo radical, para lograr as la optimizacin de los flujos del trabajo y la productividad de una organizacin. Para poder analizar esta definicin es necesario tambin definir lo que es un proceso. Definimos un proceso de negocios como un conjunto de actividades que recibe uno o ms insumos y crea un producto de valor para el cliente. [Hamm 94] Se dice que durante una reingeniera, los procesos son objeto de una revisin fundamental ya que es necesario realizarse las preguntas bsicas sobre su compaa y como funciona sin dar nada por sentado. La reingeniera 30

Anlisis y Diseo de Sistemas de Informacin II.

determina

primero

qu debe hacer una compaa para despus

determinar cmo debe hacerlo. Se olvida por completo de lo que es y se concentra en lo que debe ser. La revisin fundamental de un proceso nos permitir aplicarle un rediseo radical lo cual no es simplemente realizar cambios superficiales o correcciones a lo que ya esta instalado. Se trata de desechar por completo los viejos procedimientos e inventar nuevas formas de realizar el trabajo. Redisear es reinventar el negocio, no mejorarlo o modificarlo. Al aplicar la reingeniera 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 reingeniera es difcil y nunca se conseguir un apoyo ejecutivo sin promesas de resultados ms que simplemente incrementales. La Reingeniera de Procesos es un enfoque equilibrado que puede contener elementos de los programas ms tradicionales de mejoramiento con los cuales a veces se confunde. Pero la Reingeniera de Procesos es mucho ms. En primer lugar, la Reingeniera de Procesos busca avances decisivos en medidas importantes del rendimiento, ms que mejoras incrementales. En de segundo los lugar, busca metas multifacticos mientras de mejoramiento, los dems incluyendo calidad, costos, flexibilidad, rapidez, precisin y satisfaccin clientes, todo simultneamente, que programas se concentran en unas pocas metas o relaciones entre ellas. Para lograr estos resultados, la reingeniera de procesos adopta una perspectiva de procesos sobre los negocios, mientras que otros programas conservan una perspectiva funcional u organizacional. La gestin de calidad total si examina los procesos, pero para mejorarlos incrementalmente, no para redisearlos. II. SISTEMAS DE INFORMACIN HEREDADOS 31

Anlisis y Diseo de Sistemas de Informacin II.

Los sistemas de informacin heredados generalmente son la columna vertebral del flujo de informacin de las empresas y la principal forma de agruparla. Un Sistema de Informacin Heredado (LIS por sus siglas en ingles Legacy Information System) puede ser definido como cualquier sistema de informacin que significativamente se resiste a la modificacin y evolucin [Brod 94]. Tales LISs pueden causar serios problemas a la organizacin: 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 documentacin 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 integracin de los LISs con otros sistemas sea difcil. Los LISs son tambin difciles mas no imposibles ampliarlos.

La solucin a estos problemas segn Weiderman [Weid 97] caen en las siguientes categoras: Mantenimiento: es un proceso incremental e iterativo en el cual se hacen pequeas modificaciones al sistema. Modernizacin: existente. Remplazarlo: el cual consiste en reconstruir desde los inicios al sistema. Esta solucin consiste en aplicarle al sistema actividades de Reingeniera. 2.1 REINGENIERA DE SOFTWARE 32 implica cambios ms extensos que el mantenimiento pero conserva partes considerables del sistema

Anlisis y Diseo de Sistemas de Informacin II.

El Instituto de Ingeniera de software (SEI) desarrollo una definicin de Reingeniera como: Reingeniera es la transformacin sistemtica de un sistema existente dentro de una nueva forma de realizar mejoramientos de calidad en unas operaciones, capacidad del sistema, funcionalidad, rendimiento o evolucion a bajo costo, cliente. [Till 95] El propsito de la reingeniera es que los sistemas existentes tomen ventajas de las nuevas tecnologas y habilitar el nuevo esfuerzo de desarrollo para que aproveche las ventajas de reutilizar sistemas existentes. La reingeniera tiene el potencial de mejorar la productividad y calidad del software a travs de todo el ciclo de vida. La reingeniera casi siempre implica cambiar la forma de un programa y mejorar su documentacin. En este caso, la funcionalidad del programa no es cambiada; slo su forma es modificada. En otros casos, la reingeniera va ms all de la forma e incluye redisear para cambiar la funcionalidad del programa para buscar mejores requerimientos de usuario. Los objetivos de la reingeniera son: [McCl 92] Proporcionar asistencia automatizada para el mantenimiento. Reducir los errores y costos del mantenimiento. Hacer sistemas fciles 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. agendas o riesgos para el

La reingeniera puede ayudar a entender sistemas existentes y descubrir los componentes de software que son comunes en todo el sistema. Estos 33

Anlisis y Diseo de Sistemas de Informacin II.

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 reingeniera requiere tiempo; implica un costo de dinero enorme y absorbe recursos que de otro modo se podran emplear en preocupaciones ms inmediatas. Por todo esto, la reingeniera no se lleva a cabo en unos pocos meses, ni siquiera en unos pocos aos. La reingeniera de sistemas de informacin es una actividad que absorber recursos de las tecnologas de la informacin durante muchos aos. 2.2 LA IMPORTANCIA DE APLICAR REINGENIERA DE SOFTWARE Las Viejas Aplicaciones 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 tecnologa estndar. Sus paredes externas no tienen aislamiento. El alumbrado elctrico tiene limitaciones y claramente es inadecuada para las necesidades de energa de hoy y su cableado decadente crea un severo peligro elctrico. 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 estn ejecutndose hoy en da. Un caso extremo es el de un software escrito para una IBM 1401 Autocoder. Cuando la compaa remplaz la 1401 con una IBM

34

Anlisis y Diseo de Sistemas de Informacin II.

360/40, compraron un emulador de la 1401 para poder ejecutar el software. Esa aplicacin hoy da corre en una PC la compaa compro otro emulador. La siguiente lista son las razones por las que es aplicable la reingeniera a los sistemas de informacin heredados: Frecuentes fallas de produccin (fiabilidad cuestionable). Problemas de rendimiento. Tecnologa obsoleta. Problemas de integracin del sistema. Cdigo de calidad pobre. Dificultad (peligroso) al cambio. Dificultad para probar. Mantenimiento caro. Incremento de problemas del sistema.

2.3 COSTES Y BENEFICIOS DE LA REINGENIERA. 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 funcin. Reconstruirlo.

Evidentemente, elegiremos la opcin que mejor relacin coste/beneficio nos ofrezca. Para calcular los costes de un proyecto de reingeniera, Harry Sneed [Snee 95] propone un modelo basado en cuatro etapas: Justificacin del proyecto de reingeniera. Anlisis de la cartera de aplicaciones. Estimacin de costes. Anlisis de costes / beneficios.

2.3.1 Justificacin Del Proyecto De Reingeniera. 35

Anlisis y Diseo de Sistemas de Informacin II.

Para justificar un proyecto de reingeniera se requiere de un anlisis 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 evaluacin en posibles aumentos de valores sobre estos tres factores. La mayora de las organizaciones slo toman en consideracin los procesos de reingeniera 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. 2.3.2 Anlisis De La Cartera De Aplicaciones. En esta etapa se cotejan la calidad tcnica y el valor de negocio de cada aplicacin, con el objetivo de construir una lista de aplicaciones, ordenada segn sus prioridades en el proceso de reingeniera. 2.3.3 Estimacin De Costes. Se realiza identificando y ponderando, mediante mtricas adecuadas, todos los componentes del software que se van a modificar. Se deben considerar los costes de cada proyecto de reingeniera: si stos son superiores a los beneficios, la reingeniera no ser una alternativa viable y la aplicacin deber ser desarrollada de nuevo o bien adquirirse en el mercado. Para estimar los costes de la reingeniera, se tienen ciertas ventajas respecto a la misma estimacin en proyectos de ingeniera directa: no se debe calcular factores influyentes como el nmero de lneas de cdigo, sentencias ejecutables, elementos de datos, accesos a archivos, etc., ya que son medidas que se pueden tomar directamente de la aplicacin. 2.3.4 Anlisis De Costes/Beneficios. Una vez que se ha calculado el coste de la reingeniera, la ltima etapa es comparar los costes con los beneficios esperados (no es suficiente con examinar los beneficios que aporte la reingeniera).

36

Anlisis y Diseo de Sistemas de Informacin II.

El beneficio proporcionado por continuar manteniendo el producto sin reingeniera es el siguiente:

B M = [P 3 (P 1 + P 2)] * P 16
Deber retocarse la frmula cuando los diversos costes varen de un ao para otro. Si se desarrolla de nuevo el sistema, se obtiene este beneficio:

B D = [(P 12 (P 10 + P 11)) * (P 16 P 14) (P 13 * P 15)] B M

El beneficio producido por la reingeniera es:

B R = [(P 6 (P 4 + P 5)) * (P 16 P 8) (P 7 * P 9)] B M

Donde: P1 = Coste de mantenimiento actual para una aplicacin (anual). P2 = Coste de operacin de una aplicacin (anual). P3 = Valor del negocio actual (anual). P4 = Coste previsto de mantenimiento tras la reingeniera (anual). P5 = Coste previsto de operaciones tras la reingeniera (anual). P6 = Valor de negocio previsto tras la reingeniera (anual). P7 = Coste estimado de la reingeniera. P8 = Duracin estimada de la reingeniera. P9 = Factor de riesgo de la reingeniera. 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 = Duracin estimada del redesarrollo. P15 = Factor de riesgo del redesarrollo. 37

Anlisis y Diseo de Sistemas de Informacin II.

P16 = Vida esperada del sistema.

III. METODOS Y MODELOS DE LA REINGENIERA DE SOFTWARE Este apartado se explica de una forma muy breve el modelo cclico que es uno de los mas utilizados para llevar a cabo de manera satisfactoria la actividad de reingeniera, sin dejar de mencionar que existen mas modelos como son el de la herradura, actividades del mencionar algunos. mtodo OAR (anlisis de Opciones para Reingeniera) por sus siglas en ingles Options Analysis for Reengineering, por

3.1 EL MODELO CCLICO 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 ingeniera inversa (la comprensin del funcionamiento interno de un programa) tenga que producirse antes de que pueda comenzar la reestructuracin de documentos.

38

Anlisis y Diseo de Sistemas de Informacin II.

A lis d n is e in e ta v n rio In e ie gn r d c ire ta a

R e tru tu c e s c ra i d d c mn s e o u e to R e tru tu c e s c ra i n d d to e a s

In e ie gn r R e tru tu c e s c ra i d l c d o e ig n In e a v rs

F u 3 M d loc ig ra .3 o e

c o lic

El paradigma de la reingeniera mostrado en la figura es un modelo cclico. 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 despus de cualquier de estas actividades. 3.1.1 Actividades Del Modelo Cclico.

39

Anlisis y Diseo de Sistemas de Informacin II.

En esta seccin se dar una breve explicacin de las actividades que se definen en el modelo cclico: Anlisis de inventario, Reestructuracin de documentos, Ingeniera inversa, Reestructuracin de cdigo, Reestructuracin de datos e Ingeniera directa. Anlisis de inventario. Todas las organizaciones de software debern disponer de un inventario de todas sus aplicaciones. El inventario puede que no sea ms que una hoja de calculo con la informacin que proporciona una descripcin detallada (por ejemplo: tamao, edad, importancia para el negocio) de todas las aplicaciones activas. Los candidatos a la reingeniera aparecen cuando se ordena esta informacin en funcin 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 reingeniera. 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 funcin del tiempo y, como resultado, cambiarn tambin las prioridades para la reingeniera. Reestructuracin de documentos. Una documentacin escasa es la marca de muchos sistemas de informacin heredados. Qu se puede hacer al respecto? Opcin 1: La creacin de documentacin consume muchsimo 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 documentacin para cientos de programas de computadoras. Si un programa es relativamente esttico est 40

Anlisis y Diseo de Sistemas de Informacin II.

llegando al final de vida til, y no es probable que experimente muchos cambios: dejmoslo as!. Opcin 2: Es preciso actualizar la documentacin, 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 aplicacin. Ms bien se documentarn por completo aquellas partes del sistema que estn experimentando cambios en ese momento. La coleccin de documentos til y relevante ir evolucionando con el tiempo. Opcin 3: El sistema es fundamental para el negocio, y es preciso volver a documentarlo por completo. En este caso, un enfoque inteligente necesario. Todas y cada una de estas opciones son viables. Las organizaciones del software debern seleccionar aquella que resulte ms adecuada para cada caso. Ingeniera inversa. El trmino ingeniera inversa tiene sus orgenes en el mundo del hardware. Una cierta compaa desensambla un producto de hardware competitivo en un esfuerzo por comprender los secretos del diseo y fabricacin de su competidor. Estos secretos se podrn comprender ms fcilmente si se obtuvieran las especificaciones de diseo y fabricacin del mismo. Pero estos documentos son privados, y no estn disponibles para la compaa que efecta la ingeniera inversa. En esencia, una ingeniera inversa con xito precede de una o ms especificaciones de diseo y fabricacin para el producto, mediante el examen de ejemplos reales de ese producto. La ingeniera inversa del software es algo bastante similar. Sin embargo, en la mayora de los casos, el programa del cual hay que hacer una ingeniera inversa no es el de un rival, sino, ms bien, el propio trabajo de la compaa 41 consiste en reducir la documentacin al mnimo

Anlisis y Diseo de Sistemas de Informacin II.

(con frecuencia efectuado hace muchos aos). Los secretos que hay que comprender resultan incomprensibles porque nunca se lleg a desarrollar una especificacin. Consiguientemente, la ingeniera inversa del software es el proceso de anlisis de un programa con el fin de crear una representacin de programa con un nivel de abstraccin ms elevado que el cdigo fuente. La ingeniera inversa se extraer del programa existente informacin del diseo arquitectnico y de proceso, e informacin de los datos. Reestructuracin del cdigo. El tipo ms comn de reingeniera es la reestructuracin del cdigo. Algunos sistemas heredados tienen una arquitectura de programa relativamente slida, pero los mdulos individuales han sido codificados de una forma que hace difcil comprenderlos, comprobarlos y mantenerlos. En estos casos, se puede reestructurar el cdigo ubicado dentro de los mdulos sospechosos. Para llevar a cabo esta actividad, se analiza el cdigo fuente mediante una herramienta de reestructuracin, se indican las violaciones de las estructuras de programacin estructurada, y entonces se reestructura el cdigo (esto se puede hacer automticamente). El cdigo reestructurado resultante se revisa y se comprueba para asegurar que no se hayan introducido anomalas. Se actualiza la documentacin interna del cdigo. Reestructuracin de datos. Un programa que posea una estructura de datos dbil ser difcil de adaptar y de mejorar. De hecho, para muchas aplicaciones, la arquitectura de datos tiene ms que ver con la viabilidad a largo plazo del programa que el propio cdigo fuente. A diferencia de la reestructuracin de cdigo, que se produce en un nivel relativamente bajo de abstraccin, la estructuracin de datos es una actividad 42

Anlisis y Diseo de Sistemas de Informacin II.

de reingeniera a gran escala. En la mayora de los casos, la reestructuracin de datos comienza por una actividad de ingeniera 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 continuacin, se revisan las estructuras de datos a efectos de calidad. Cuando la estructura de datos es dbil (por ejemplo, actualmente se implementan archivos planos, cuando un enfoque relacional simplificara muchsimo el procesamiento), se aplica una reingeniera a los datos. Dado que la arquitectura de datos tiene una gran influencia sobre la arquitectura del programa, y tambin sobre los algoritmos que los pueblan, los cambios en datos darn lugar invariablemente a cambios o bien de arquitectura o bien de cdigo. 3.2. INGENIERA DIRECTA (foward engineering). En un mundo ideal, las aplicaciones se reconstruyen utilizando un motor de reingeniera automatizado. En el motor se insertara el programa viejo, que lo analizara, reestructurara y despus regenerara la forma de exhibir los mejores aspectos de la calidad del software. Despus 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 especficos (por ejemplo, aplicaciones que han sido implementadas empleando un sistema de bases de datos especfico). Lo que es ms importante, estas herramientas de reingeniera cada vez son ms sofisticadas. La ingeniera directa, que se denomina tambin renovacin o reclamacin [Chi 90], no solamente recupera la informacin de diseo de un software ya existente, sino que, adems, utiliza esta informacin en un esfuerzo por mejorar su calidad global. En la mayora de los casos, el software procedente de una reingeniera vuelve a implementar la funcionalidad

43

Anlisis y Diseo de Sistemas de Informacin II.

del sistema existente, y aade adems nuevas funciones y/o mejora el rendimiento global.

44