UNIVERSIDAD NACIONAL DEL ALTIPLANO

FACULTAD DE INGENIERA MECNICA ELCTRICA ELECTRNICA Y SISTEMAS

ESCUELA PROFESIONAL DE INGENIERA DE SISTEMAS

EL PROCESO RACIONAL UNIFICADO

POR: ANALI SANDRA QUISPE CASTILLO

PUNO, 2013 IMPLEMENTACION DE SISTEMAS DE INFORMACION DOCENTE: EDGAR HOLGUIN HOLGUIN

I.

RESMEN El proceso racional unificado (RUP) es un proceso para el desarrollo de software

que define claramente quien, como, cuando y que debe hacerse en el proyecto. Este proceso debe adaptarse a las organizaciones de la organizacin, se deben de balancear los diversos requerimientos para satisfacer los deseos de todos, el control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de la produccin. RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menos hincapi en los distintas actividades.

Ilustracin 1: Fases del Proceso Racional Unificado

pg. 1

II. I. II. III.

NDICE RESMEN .................................................................................................... 1 NDICE .......................................................................................................... 2 NDICE DE ILUSTRACIONES ...................................................................... 3

IV. INDICE DE TABLAS...................................................................................... 3 V. INTRODUCCION........................................................................................... 4

VI. PROCESO RACIONAL UNIFICADO............................................................. 5 A. B. C. D. 1. 2. 3. 4. E. VII. VIII. HISTORIA .................................................................................................. 5 DEFINICION .............................................................................................. 6 CARACTERISTICAS.................................................................................. 8 FASES ....................................................................................................... 8 FASE DE INICIO..................................................................................... 8 FASE DE ELABORACIN .................................................................... 10 FASE DE CONSTRUCCIN ................................................................ 10 FASE DE TRANSICIN ....................................................................... 12 ROLES ..................................................................................................... 12 CONCLUSION ......................................................................................... 14 GLOSARIO .............................................................................................. 15

IX. BIBLIOGRAFA ........................................................................................... 16

pg. 2

III.

NDICE DE ILUSTRACIONES Ilustracin 1: Fases del Proceso Racional Unificado ............................................ 1 Ilustracin 2: Creadores de RUP. .......................................................................... 5

IV.

INDICE DE TABLAS Tabla 1: Diagramas UML empleados en cada fase de la metodologa RUP y los

artefactos que genera. ................................................................................................ 7

pg. 3

V.

INTRODUCCION La presente monografa se refiere al tema Proceso Racional Unificado el cual

puede ser definido como un proceso de ingeniera de software, para producir software de calidad, que cumpla con las normas a nivel mundial y que ofrezca flexibilidad en plazos y presupuestos. Gracias a la incorporacin de las mejores prcticas de la ingeniera de software, como: gestin de requisitos, uso de arquitectura de componentes, modelado visual, verificacin continua de la calidad y control de cambios entre otros. Convierte a RUP en una de las metodologas estndares ms utilizadas para el anlisis, implementacin y documentacin de sistemas orientados a objetos. La importancia de la investigacin de esta metodologa radica, en los altos niveles de calidad de software exigidos por las grandes empresas. RUP puede ser utilizada sin importar el tamao y rubro de la organizacin, sin embargo es ms utilizada en las grandes empresas, debido a la complejidad y tamao de los sistemas.

pg. 4

VI.

PROCESO RACIONAL UNIFICADO A. HISTORIA RUP fue creado por Grady Booch (creador del mtodo Booch), Ivar Jacobson y James Jacobson (Creador de la Tcnica de Modelado de Objetos), la misma aparece en Junio de 1998 con el acrnimo RUP 5.0 y puesto a la disposicin del pblico a inicios de 1999 y su funcionamiento se centraba en las personas, los procesos y las herramientas.

Ilustracin 2: Creadores de RUP.

Su funcionalidad parte de una serie de mtodos los cuales se puede comentar, el mtodo ericcson, mtodo utilizado por la compaa del mismo nombre para el proceso unificado de desarrollo, a este proceso se le anexa un proceso denominado Objetory creado por Jacobson. En el ao 1995 se anexa el enfoque Rational dando paso a ROP 4.0 (Rational Objetory Process) que junto a la OMT (Objects Modeling Technique) de Rumbaugh y Booch lo que permiti dar origen a UML, esta herramienta fortaleci mucho ms a ROP en el empleo de caso de usos. Para el ao 1996, surge ROP 4.1 con la integracin de actividades SQA (Software Quality Assurance, Software de Control de Calidad por sus siglas en ingles), esto permita el aseguramiento

pg. 5

de un software de calidad que se adapte a las necesidades del usuario final por medio de la actualizacin de UML. Para 1998 se lanza al mercado una fase de prueba, con un UML fortalecido y la integracin de los enfoques de la ingeniera de Negocios y la Ingeniera de Datos a partir de aqu nace RUP, con los lineamientos y vertientes que hoy da conocemos (Metodologa RUP). B. DEFINICION RUP (Rational Unified Process) es una secuencia de pasos necesarios para el desarrollo y/o mantenimiento de gran cantidad de sistemas, en diferentes reas de aplicacin diferentes organizaciones, diferentes medios de competencia y en proyectos de tamaos variables (desde el ms bsico al ms complejo). Actualmente es propiedad de International Business Machines (IBM) y est basado en un enfoque disciplinado de asignacin de tareas y responsabilidades dentro de una organizacin de desarrollo con la finalidad de asegurar la obtencin de un software de alta calidad que satisfagan la necesidad de los usuarios finales dentro de un calendario y tiempo predecible. ELEMENTOS DE RUP Disciplinas: son los 'contenedores' empleados para organizar todas las actividades durante el ciclo de vida del sistema. Artefactos: son los elementos de entrada y salida de las actividades. Es un elemento que el proyecto produce y utiliza para componer el producto final. Flujos de Trabajo: constituye la secuencia de actividades que producen resultados visibles por medio de la integracin de los roles y las actividades, artefactos y disciplinas.

pg. 6

Roles: son las personas o entes que estn involucradas en cada proceso (Metodologa RUP).

Tabla 1: Diagramas UML empleados en cada fase de la metodologa RUP y los artefactos que genera.

pg. 7

C.

CARACTERISTICAS Las caractersticas que se consideran en el Proceso Racional Unificado

son las que se mencionan a continuacin: Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo 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 iterativo 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) (Wikipedia). D. FASES 1. FASE DE INICIO Durante la fase de inicio las iteraciones hacen ponen mayor nfasis en actividades modelado del negocio y de requisitos (Gomez Gallego, 2007).

pg. 8

Modelado del negocio En esta fase el equipo se familiarizar ms al funcionamiento de la empresa, sobre conocer sus procesos. Entender la estructura y la dinmica de la organizacin para la cual el sistema va ser desarrollado ( Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras. Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la organizacin objetivo. Requisitos En esta lnea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos. Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podra hacer. Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema. Definir el mbito del sistema. Proveer una base para estimar costos y tiempo de desarrollo del sistema. Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.

pg. 9

2.

FASE DE ELABORACIN En la fase de elaboracin, las iteraciones se orientan al desarrollo

de la baseline de la arquitectura, abarcan ms los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado a la baseline de la arquitectura. Anlisis Y Diseo En esta actividad se especifican los requerimientos y se describen sobre cmo se van a implementar en el sistema Transformar los requisitos al diseo del sistema. Desarrollar una arquitectura para el sistema. Adaptar el diseo para que sea consistente con el entorno de implementacin 3. FASE DE CONSTRUCCIN

Implementacin Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y dems. El resultado final es un sistema ejecutable. Planificar qu subsistemas deben ser implementados y en qu orden deben ser integrados, formando el Plan de Integracin. Cada implementador decide en qu orden implementa los elementos del subsistema. Si encuentra errores de diseo, los notifica. Se integra el sistema siguiendo el plan.

pg. 10

Pruebas Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida. Encontrar y documentar defectos en la calidad del software. Generalmente asesora sobre la calidad del software percibida. Provee la validacin de los supuestos realizados en el diseo y especificacin de requisitos por medio de demostraciones concretas. Verificar las funciones del producto de software segn lo diseado. Verificar que los requisitos tengan su apropiada

implementacin. Despliegue Esta actividad tiene como objetivo producir con xito distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen: Probar el producto en su entorno de ejecucin final. Empaquetar el software para su distribucin. Distribuir el software. Instalar el software. Proveer asistencia y ayuda a los usuarios.

pg. 11

 4.

Formar a los usuarios y al cuerpo de ventas. Migrar el software existente o convertir bases de datos. FASE DE TRANSICIN Esta fase se enfoca en asegurar que el software est disponible para sus usuarios.

Se puede subdividir en varias iteraciones, adems incluye pruebas del producto para poder hacer el entregable del mismo, as como realizar ajuste menores de acuerdo a ajuste menores propuestos por el usuario.

En este punto, la retroalimentacin de los usuarios se centra en depurar el producto, configuraciones, instalacin y aspectos sobre utilizacin (Ingeniero en Software).

E.

ROLES

Analistas: Analista de procesos de negocio. Diseador del negocio. Analista de sistema. Especificador de requisitos.

Desarrolladores: Arquitecto de software. Diseador Diseador de interfaz de usuario Diseador de cpsulas.

pg. 12

Diseador de base de datos. Implementador. Integrador.

Gestores: Jefe de proyecto Jefe de control de cambios. Jefe de configuracin. Jefe de pruebas Jefe de despliegue Ingeniero de procesos Revisor de gestin del proyecto Gestor de pruebas.

Apoyo: Documentador tcnico Administrador de sistema Especialista en herramientas Desarrollador de cursos Artista grfico

Especialista en pruebas: Especialista en Pruebas (tester) Analista de pruebas Diseador de pruebas

pg. 13

VII.

CONCLUSION

Se puede concluir que, el RUP, como herramienta colaboradora en el desarrollo de software, aumenta la visin de desarrollo del mismo, es decir, el RUP es una herramienta que permite prever los cambios que un software pueda tener de acuerdo a los requerimientos y avance social que se tenga, brindando objetivos ms amplios y visin de requerimientos global. Visto desde su punto ms simple, el RUP es aquel mtodo que da cabida al cambio en las etapas del desarrollo de software, no siguiendo al pie de la letra los requerimientos, sino, por el contrario, mostrando otros campos que mejoren y optimicen el desarrollo del mismo.

pg. 14

VIII.

GLOSARIO Stakeholders: Son los grupos que tienen inters en que la empresa sobreviva. Estos grupos de inters (personas u organizaciones) pueden afectar o verse afectados por las decisiones de la empresa de la que estn interesados.

pg. 15

IX.

BIBLIOGRAFA

Gomez Gallego, J. P. (2007). FUNDAMENTOS DE LA METODOLOGIA RUP . UNIVERSIDAD TECNOLGICA DE PEREIRA . Ingeniero en Software. (s.f.). Ingeniero en Software. Recuperado el 14 de 11 de 2013, de http://softwarerecopilation.wordpress.com/modelo-rup/ Metodologa RUP. (s.f.). Metodologa RUP. Recuperado el 14 de 11 de 2013, de http://rupequipo1.blogspot.com/2012/12/algo-de-historia.html Wikipedia. (s.f.). Wikipedia la enciclopedia libre. Recuperado el 14 de 11 de 2013, de http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

pg. 16