Proceso Unificado Para Desarrollo De Software (Rup)

Laboratorio III de Electrónica Anotaciones RUP Proceso Unificado para Desarrollo de Software (RUP) 1.Generalidades y aportes:

07/05/01 1

Proceso de desarrollo propuesto por “Rational Software Corporation” resultado del esfuerzo de las tres últimas décadas en desarrollo de software y de la experiencia de sus creadores Ivar Jacobson, Grady Booch y James Rumbaugh. 2. Orígenes El antecedentemás importante lo ubicamos en 1967 con la Metodología Ericsson (Ericsson Approach), ésta es una aproximación de desarrollo basada en componentes, que introdujo el concepto de caso de uso; entre los años de 1987 a 1995 Jacobson funda la compañía “Objectory AB” y lanza el proceso de desarrollo Objectory (abreviación de Object Factory), posteriormente en 1995 “Rational Software Corporation” adquiere“Objectory AB” y es entre 1995 y 1997 que se desarrolla “Rational Objectory Process (ROP)” fruto del encuentro y evolución de Objectory 3.8 y la Metodología Rational (Rational Approach) que adopta por primera vez UML como lenguaje de modelamiento. A principios de los noventas, la guerra de los métodos hizo evidente la necesidad de unificar criterios, es así como Grady Booch autor del método Booch yJames Rumbaugh (desarrollador para General Electric) se unieron en Rational en 1994, después en 1995 se une Jacobson y gracias al esfuerzo de varias compañías y metodologistas evolucionó UML hasta ser un estándar en 1997, el cual es adoptado en todos los modelos del ROP. Desde ese entonces y a la cabeza de Booch, Jacobson y Rumbaugh, Rational ha desarrollado e incorporado diversos elementos paraexpandir el ROP, destacándose especialmente el flujo de trabajo conocido como modelamiento del negocio, es así como en junio del 1998 se lanza Rational Unified Process 5.0 evolucionado hasta el momento de elaboración de este documento bajo el nombre de RUP. La evolución y orígenes de este proceso de desarrollo se puede visualizar mejor en la figura 2.1 3 Características principales a.) Guiado/Manejadopor casos de uso: La razón de ser de un sistema software es servir a usuarios ya sean humanos u otros sistemas; un caso de uso es una

Laboratorio III de Electrónica Anotaciones RUP

07/05/01 2

Rational Unified Process 5.0 Otros recursos

Rational Objectory Process 4.1 1996 - 1997 The Rational Approach

Objectory Process 1.0 – 3.8 1987- 1995

UML

The Ericsson Approach

Figura 1Orígenes del proceso Unificado[JBR99]

facilidad que el software debe proveer a sus usuarios. Los casos de uso reemplazan la antigua especificación funcional tradicional y constituyen la guía fundamental establecida para las actividades a realizar durante todo el proceso de desarrollo incluyendo el diseño, la implementación y las pruebas del sistema. b.) Centrado en arquitectura: Laarquitectura involucra los elementos más

significativos del sistema y está influenciada entre otros por plataformas software, sistemas operativos, manejadores de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados y requerimientos no funcionales. Los casos de uso guían el desarrollo de la arquitectura y la arquitectura se realimenta en los casos de uso, los dos juntospermiten conceptualizar, gestionar y desarrollar adecuadamente el software. c.) Iterativo e Incremental: Para hacer más manejable un proyecto se recomienda dividirlo en ciclos. Para cada ciclo se establecen fases de referencia, cada una de las cuales debe ser considerada como un miniproyecto cuyo núcleo fundamental está constituido por una o más iteraciones de las actividades principales básicas decualquier proceso de desarrollo.

Laboratorio III de Electrónica Anotaciones RUP

07/05/01 3

d.) Desarrollo basado en componentes: La creación de sistemas intensivos en software requiere dividir el sistema en componentes con interfaces bien definidas, que posteriormente serán ensamblados para generar el sistema. Esta característica en un proceso de desarrollo permite que el sistema se vaya...