INSTITUTO TECNOLOGICO DE

OAXACA
FUNDAMENTOS DE INGENIERA DE SOFTWARE

RUP

(Rational Unied Process)

Profesor: Doroteo Pacheco Azarel

EQUIPO:

ABAD SILVA ORIBE

ACEVEDO MALDONADO JOSUE
BALDERAS TALARICO MAURO CESAR
VSQUEZ ALONSO OMAR EDWING
VSQUEZ MARTNEZ AGUSTN

Grupo: ISA
Fecha: 2014 - Noviembre  04

ndice
1. PROCESO UNIFICADO DE RATIONAL

2. FASE DINMICA DEL PROCESO

2.1.

2.2.

FASE DE INICIO

. . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.1.

FASE DE ELABORACIN . . . . . . . . . . . . . . . . .

2.1.2.

FASE DE CONSTRUCCIN . . . . . . . . . . . . . . . .

2.1.3.

FASE DE TRANSICIN

. . . . . . . . . . . . . . . . . .

ITERACIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3. FACETA ESTATICA DEL RUP

10

3.1.

ROLES

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.

ACTIVIDADES

. . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.3.

ARTEFACTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.4.

FLUJOS DE TRABAJO . . . . . . . . . . . . . . . . . . . . . . .

12

4. ETAPAS DEL PROCESO (FLUJOS DE TRABAJO)

4.1.

4.2.

10

13

Esenciales: reglas del negocio, requisitos, diseo y analisis, implementacion, pruebas y distribucion . . . . . . . . . . . . . . . . . .

13

4.1.1.

Reglas del negocio

. . . . . . . . . . . . . . . . . . . . . .

13

4.1.2.

Requerimientos o requisitos . . . . . . . . . . . . . . . . .

14

4.1.3.

Diseo y anlisis

. . . . . . . . . . . . . . . . . . . . . . .

14

4.1.4.

Implementacin

. . . . . . . . . . . . . . . . . . . . . . .

15

4.1.5.

Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

4.1.6.

Distribucin . . . . . . . . . . . . . . . . . . . . . . . . . .

16

Complementarias: administracion de proyecto, administracion de

cambios, ambiente. . . . . . . . . . . . . . . . . . . . . . . . . . .

17

4.2.1.

Administracin del proyecto

. . . . . . . . . . . . . . . .

17

4.2.2.

Administracin de cambios

. . . . . . . . . . . . . . . . .

17

4.2.3.

Ambiente

. . . . . . . . . . . . . . . . . . . . . . . . . . .

17

5. HISTORIA

19

6. REFERENCIAS

20

1.

PROCESO UNIFICADO DE RATIONAL

El Proceso Unicado Rational (Rational Unied Process, de las siglas en

ingls RUP) es un proceso de desarrollo de software diseado por la empresa

Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unicado de Modelado UML, constituye la metodologa estndar ms utilizada para
el anlisis, diseo, implementacin y documentacin de sistemas orientados a
objetos.
RUP es un framework metodolgico, lo que signica que puede (y debe)
ser adaptada a las caractersticas propias del proyecto. De esta forma, RUP
se puede utilizar para proyectos grandes, pequeos y medianos. De hecho, las
ltimas versiones del RUP ya traen adaptaciones estndar para estos tres tipos
de proyectos.
La losofa del RUP maneja 6 principios que son clave:

Adaptacin del Proceso:

El proceso debe adaptarse a las caractersticas

particulares de cada organizacin, al tamao, as como las regulaciones que lo

condicionen, inuirn en le su diseo especico y se debe tomar en cuenta el
alcance del proyecto

Balancear Prioridades:

Los requerimientos de los diversos clientes a los

cuales se les realizara el proyecto pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos
de todos.

Colaboracin entre Equipos:

El desarrollo de software no lo hace una

nica persona sino mltiples equipos. Debe haber una comunicacin uida para
coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc.

Demostrar Valor Iterativamente:

Los proyectos se entregan, aunque sea

de un modo interno, en etapas iteradas. En cada iteracin se analiza la opcin

de los inversores, la estabilidad y calidad del producto, y se rena la direccin
del proyecto as como tambin los riesgos involucrados.

Elevar el Nivel de Abstraccin:

Este principio dominante motiva el uso

de conceptos reutilizables tales como patrn del software, lenguajes 4GL o esquemas (Frameworks) por nombrar algunos. Estos se pueden acompaar de las
representaciones visuales de la arquitectura, por ejemplo UML.

Enfocarse en la Calidad:

El control de calidad no debe realizarse al nal

de cada iteracin, sino en todos los aspectos de la produccin.

La versin libre OpenUP es una buena aproximacin metodolgica que respeta la mayor parte de la losofa de RUP y se encuentra dentro del concepto

de mtodos giles. Una de las mayores ventajas del RUP es que tiene explcito
todo lo que se debe hacer dentro del proceso de desarrollo de software, a diferencia de muchos procesos que se encuentran en el mercado, tanto libres como
propietarios, que hablan slo de ciertas partes de las disciplinas de desarrollo.
Esta es la razn por la que algunas personas creen que el RUP es un proceso
pesado o slo para proyectos grandes. Realmente el RUP es explcito en lo que
hay que hacer en el desarrollo, y lo que se debe hacer es asignar adecuadamente
las tareas de acuerdo con el tamao del software y el equipo disponible.

2.

FASE DINMICA DEL PROCESO

El ciclo de vida del software es dividido en ciclos, cada ciclo generando una

nueva generacin del producto. RUP divide un ciclo de desarrollo en cuatro fases
consecutivas, donde cada una tiene un objetivo especco. [1]

Fase de inicio.
Fase de elaboracin.
Fase de construccin.
Fase de transicin.

Cada fase termina con un punto lmite especco en el cual deben tomarse
decisiones crticas y alcanzarse los objetivos determinados.

2.1.

FASE DE INICIO

En esta fase se realiza una visin general del proyecto y se delimitan los
alcances del proyecto, para completar esta fase se deben identicar las entidades con las que interacta el sistema y los actores principales. De esta manera
se identican los casos de uso ms signicativos. La visin general incluye los
requisitos necesarios, la evaluacin de riesgos, un estimado de los recursos necesarios y una planeacin de las dems fases en la que se establecen los tiempos y
los puntos lmites.
Los resultados de la fase de inicio son:
Una visin general del proyecto que incluya los requisitos principales, funcionalidades clave y restricciones.
Un diagrama general de caso de uso.
Diagramas particulares de casos de uso crticos.
Un glosario general del proyecto.
Un pronstico nanciero de gastos y ganancias
Anlisis del mercado
El contexto.
Una evaluacin inicial de riesgos.
Un plan de trabajo, mostrando las fases y las iteraciones.

Uno o varios prototipos.

Un modelo del negocio, tiene una gran importancia, pues en ella intervienen reglas del negocio, requisitos y diseo, por lo tanto, aqu podemos
identicar los riesgos en los que puede caer el negocio, as como estableceremos los requerimientos, esto, para denir el alcance que tendr el
proyecto.

Es

menester identicar todo lo que interviene con el nuevo sistema a desarrollar.

Tambin se tendr aqu una visin general del diseo del proyecto.

Punto lmite: objetivos.

El punto lmite de esta fase debe lograr un acuerdo entre las partes interesadas en la denicin del alcance, costos, requisitos, funcionalidades, tiempo
estimado. En este punto el proyecto puede ser cancelado o replanteado si no se
logran acuerdos en este punto lmite.

2.1.1.

FASE DE ELABORACIN

Esta fase tiene el objetivo de lograr una visin general, completa y funcional
del proyecto, si bien no a profundidad, s abarcando ampliamente los requisitos
para preveer los problemas que puedan presentarse. Es una fase crtica, de vital
importancia porque en ella se determina la viabilidad de la continuacin del
proyecto, el replanteamiento del mismo o la denitiva cancelacin. Esta etapa
debe arrojar un prototipo (o varios elaborados cclicamente) funcional que pueda servir de demostracin para el usuario nal, posibles inversionistas o clientes.
Est claro que el diseo tiene una gran importancia aqu, pues estableceremos
la arquitectura base del sistema, tal arquitectura debe abarcar todas las consideraciones de mayor importancia de los requerimientos y una evaluacin del
riesgo. Podra decirse que esta etapa es difcil, pues requiere anlisis de riesgos.
Las decisiones aqu deben ser estables, ya que sern parte de la construccin,
tambin se deben minimizar los riesgos previstos en la etapa de inicio, aparte
que todos los casos de uso deben ser identicados as como la interacciones del
sistema.
El resultado de esta fase debe ser:

Diagramas particulares de casos de uso, abarcando al menos el 80 % del

total.
Requisitos complementarios que incluyan los no funcionales.
Una descripcin de la arquitectura de software.

Un prototipo funcional ejecutable.

Una lista revisada de riesgos de implementacin y de negocio.
Un plan de elaboracin del proyecto que incluya las iteraciones y la evaluacin
de cada una de ellas.
Un manual de usuario preliminar.

Punto lmite: Arquitectura.

Al nal de esta fase debe vericarse que la arquitectura del proyecto sea
viable y estable, que la mayora de los riesgos de implementacin hayan sido
valorados y resueltos, que el plan de desarrollo sea lo sucientemente preciso y
detallado, que las partes involucradas concuerden el las adecuaciones realizadas
a los costos y tiempos, que la viabilidad del proyecto con la revisin actual siga
siendo aceptable en comparacin con la valoracin inicial. De cumplirse con
todos estos aspectos se puede continuar con la siguiente fase, de no ser as el
proyecto debe ser cancelado o replanteado.

2.1.2.

FASE DE CONSTRUCCIN

Durante la fase de construccin son rediseadas todas las funcionalidades

e integradas al producto para pruebas, en pocas palabras esta fase consiste en
la administracin y optimizacin del tiempo, los recursos tcnicos y humanos
para reducir costos manteniendo altos estndares de calidad en el desarrollo
del proyecto. De la eciencia de la fase de elaboracin depende la facilidad con
la que el trabajo ser coordinado y sincronizado en la fase de construccin,
sobre todo cuando se trata de arquitecturas robustas con mdulos funcionales
diversos. Ya queda claro que en la elaboracin todo debe quedar estable, as
en la construccin nos dedicaremos a optimizar costos, tiempo y calidad como
parte del proceso de manufactura. Aqu ya todo es integrado al proyecto y es
preparado para las pruebas necesarias.
El resultado de esta fase es un producto listo para llegar al usuario nal que
por lo menos debe consistir en :

El software integrado en las plataformas adecuadas.

El manual de usuario.
Una descripcin de la versin actual.

Punto lmite: Capacidad operativa inicial.

Al nal de esta fase se decide si el producto esta listo para ser operacional,
sin correr altos riesgos. Esta versin generalmente se conoce como la versin
beta. Los criterios de evaluacin consisten en saber si el producto es lo sucientemente estable y maduro para ser entregado al usuario nal, si todos los
actores estn listos para la transicin al uso del sistema y si los recursos utilizados siguen siendo aceptables en comparacin con los previstos. Si estos criterios
no se cumplen la fase de transicin debe ser pospuesta hasta lograr los objetivos.

2.1.3.

FASE DE TRANSICIN

La fase de transicin estar completa cuando el producto haya alcanzado

el nivel de madurez y calidad necesario para que todas las partes involucradas
queden satisfechas, es decir que se debe realizar:
Una comparacin entre el resultado nal y las expectativas del usuario.

Una implementacin del sistema y en su caso, el reemplazo de sus prede-

cesores sin prdidas de informacin.

Capacitacin de los usuarios nales y administradores del sistema.

Canalizacin del producto a los equipos de mercadeo, distribucin y venta.
Esta fase puede ser muy simple o muy compleja, dependiendo del tipo de software, por ejemplo, una nueva versin de un sistema puede sustituir fcilmente
a otra, pero un sistema de registro de poblacin a nivel nacional probablemente
sea complejo de sustituir.
Es sencillo, distribuir el nuevo software al pblico, ya que el usuario nal lo
ha probado, surgen pequeos temas que nos ayudarn a pulir nuestro software,
tales como nuevas versiones o correccin de pequeos bugs que no se hayan
contemplado, as que la retroalimentacin de los usuarios cuenta mucho.

Punto lmite: Entrega del producto.

Al nalizar la fase de transicin se deben analizar dos puntos principales: la
satisfaccin del usuario nal y la viabilidad resultante del proyecto.

2.2.

ITERACIONES

En RUP cada fase se divide en iteraciones. Cada iteracin es un ciclo completo de desarrollo de software cuyo resultado es una versin, ya sea interna o
externa, del sistema. Con cada una de ellas la complejidad del sistema se va
incrementando y alcanzando su funcionalidad completa.[2]

VENTAJAS DE LAS APROXIMACIONES ITERATIVAS

Ante el sistema tradicional de cascada, las aproximaciones sucesivas por
iteraciones tienen sustanciales ventajas, como la identicacin y mitigacin temprana de riesgos y dicultades, mayor manejabilidad de cambios, mayor calidad
general del producto nal, adems todo el equipo se ve involucrado y aprende
en el proceso.

3.

FACETA ESTATICA DEL RUP

Un proceso de desarrollo de software dene quin hace qu, cmo y cundo.

RUP dene cuatro elementos los roles, que responden a la pregunta Quin?, las
actividades que responden a la pregunta Cmo?, los productos, que responden
a la pregunta Qu? y los ujos de trabajo de las disciplinas que responde a la
pregunta Cundo?.

Relacin entre roles, actividades, artefactos

3.1.

ROLES

Un rol dene el comportamiento y responsabilidades de un individuo, o de

un grupo de individuos trabajando juntos como un equipo. Una persona puede
desempear diversos roles, as como un mismo rol puede ser representado por
varias personas.
Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de
actividades como el entregar un conjunto de artefactos.
RUP dene grupos de roles, agrupados por participacin en actividades relacionadas. Estos grupos son:
Analistas:

Analista de procesos de negocio.

Diseador del negocio.

10

Analista de sistema.
Especicador de requisitos.

Desarrolladores:

Arquitecto de software.
Diseador
Diseador de interfaz de usuario
Diseador de cpsulas.
Diseador de base de datos.
Implementador.
Integrador.

Gestores:

Jefe de proyecto
Jefe de control de cambios.
Jefe de conguracin.
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 grco

Especialista en pruebas:

Especialista en Pruebas (tester)

Analista de pruebas
Diseador de pruebas

Otros roles:

3.2.

Revisor
Coordinacin de revisiones
Revisor tcnico
Cualquier rol

ACTIVIDADES

Una actividad en concreto es una unidad de trabajo que una persona que
desempee un rol puede ser solicitado a que realice. Las actividades tienen un

11

objetivo concreto, normalmente expresado en trminos de crear o actualizar

algn producto.

3.3.

ARTEFACTOS

Un producto o artefacto es un trozo de informacin que es producido, modicado o usado durante el proceso de desarrollo de software. Los productos son
los resultados tangibles del proyecto, las cosas que va creando y usando hasta
obtener el producto nal.
Un artefacto puede ser cualquiera de los siguientes:

Un documento, como el documento de la arquitectura del software.

Un modelo, como el modelo de Casos de Uso o el modelo de diseo.
Un elemento del modelo, un elemento que pertenece a un modelo como

una clase, un Caso de Uso o un subsistema.

3.4.

FLUJOS DE TRABAJO

Con la enumeracin de roles, actividades y artefactos no se dene un proceso,

necesitamos contar con una secuencia de actividades realizadas por los diferentes
roles, as como la relacin entre los mismos. Un ujo de trabajo es una relacin
de actividades que nos producen unos resultados observables. A continuacin se
dar una explicacin de cada ujo de trabajo.
Tales ujos de trabajo se dividen en dos, y son:
Del proceso...

reglas del negocio requisitos,

diseo y anlisis,
implementacin,
pruebas y distribucin
Del soporte...

administracin de proyecto
administracin de cambios
ambiente o entorno

12

4.

ETAPAS DEL PROCESO (FLUJOS DE TRABAJO)

Como en cada modelo es esencial el trabajo en equipo, el RUP tambin tiene

subdivisiones que cooperan para lograr un n.

Tales etapas no podran empezar sin terminar la anterior y esto lo hace
interesante, pues signica que debe haber un buen trabajo en cada una para
no afectar a las dems. Cada etapa o fase tiene una signicativa inclusin en
RUP, es decir que en cada una se hace un mayor o menor hincapi segn las
actividades correspondientes.
Hay cuatro fases en RUP, son la organizacin dinmica del proceso, cada
una de ellas tiene tpicos a desarrollar antes de pasar a la siguiente, como ya se
ha mencionado.
Cuales son esos tpicos? Son los ncleos de trabajo, permiten el buen ujo
del proceso. Se dividen en dos, del proceso y del mantenimiento o soporte y se
explican a continuacin.

4.1.

Esenciales: reglas del negocio, requisitos, diseo y

analisis, implementacion, pruebas y distribucion

4.1.1.

Reglas del negocio

Prcticamente hay que documentar todos los casos del negocio, tales casos
son analizados pues es difcil entenderse con los clientes [2], ya que al no
ser desarrolladores de software no hablamos el mismo idioma y eso conlleva a
confusiones.
Con este ujo de trabajo pretendemos llegar a un mejor entendimiento de
la organizacin donde se va a implantar el producto.
Los objetivos del modelado de negocio son:

Entender la estructura y la dinmica de la organizacin para la cual el

sistema va ser desarrollado (organizacin objetivo).
Entender el problema actual en la organizacin objetivo e identicar potenciales mejoras.
Asegurar que clientes, usuarios nales y desarrolladores tengan un entendimiento comn de la organizacin objetivo.
Derivar los requisitos del sistema necesarios para apoyar a la organizacin
objetivo.

13

4.1.2.

Requerimientos o requisitos

Aqu se analiza qu debe hacer el sistema y qu puede hacer cada usuario,

se discute si van a tener privilegios diferentes, niveles de control y se hacen
diagramas sencillos, pueden tratarse como prototipos nmos, recordemos que
un prototipo se puede hacer a lpiz y papel.
Este es uno de los ujos de trabajo ms importantes, porque en l se establece
qu tiene que hacer exactamente el sistema que construyamos. En esta lnea los
requisitos son el contrato que se debe cumplir, de modo que los usuarios nales
tienen que comprender y aceptar los requisitos que especiquemos.
Los objetivos del ujo de datos Requisitos son:

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.
Denir el mbito del sistema.
Proveer una base para la planeacin de los contenidos tcnicos de las
iteraciones.
Proveer una base para estimar costos y tiempo de desarrollo del sistema.
Denir una interfaz de usuarios para el sistema, enfocada a las necesidades
y metas del usuario.

Los requisitos se dividen en dos grupos. Los requisitos funcionales representan la funcionalidad del sistema. Se modelan mediante diagramas de Casos
de Uso. Los requisitos no funcionales representan aquellos atributos que debe
exhibir el sistema, pero que no son una funcionalidad especca. Por ejemplo
requisitos de facilidad de uso, abilidad, eciencia, portabilidad, etc.

4.1.3.

Diseo y anlisis

Hay muchas formas de llevar esta parte, lo ideal es usar UML para establecer
las bases, pues el diseo entra mucho en la etapa de elaboracin. As, podemos
disear una buena arquitectura que tendr el software y llevarla despus a la
implementacin.
Los objetivos del anlisis y diseo son:

Transformar los requisitos al diseo del futuro sistema.

Desarrollar una arquitectura para el sistema.
Adaptar el diseo para que sea consistente con el entorno de implementa-

cin, diseando para el rendimiento.

14

El anlisis consiste en obtener una visin del sistema que se preocupa de ver
qu hace, de modo que slo se interesa por los requisitos funcionales. Por otro
lado el diseo es un renamiento del anlisis que tiene en cuenta los requisitos no
funcionales, en denitiva cmo cumple el sistema sus objetivos. Pero el resultado
nal ms importante de este ujo de trabajo ser el modelo de diseo. Consiste
en colaboraciones de clases, que pueden ser agregadas en paquetes y subsistemas.

4.1.4.

Implementacin

Es hora del cdigo! La implementacin trata de eso, de armar el software

con sus respectivas clases y objetos requeridos, de aqu saldr la primera versin
que ser sometida a pruebas. En este ujo de trabajo se implementan las clases
y objetos en cheros fuente, binarios, ejecutables y dems. Adems se deben
hacer las pruebas de unidad: cada implementador es responsable de probar las
unidades que produzca. El resultado nal de este ujo de trabajo es un sistema
ejecutable.
En cada iteracin habr que hacer lo siguiente:
Planicar qu subsistemas deben ser implementados y en que orden deben
ser integrados, formando el Plan de Integracin.
Cada implementador decide en que orden implementa los elementos del
subsistema.
Si encuentra errores de diseo, los notica.
Se prueban los subsistemas individualmente.
Se integra el sistema siguiendo el plan.

4.1.5.

Pruebas

El propsito aqu es la revisin del software, debe tener una correcta integracin, no que sea el clsico cdigo espagueti, hay que identicar posibles defectos
y las mejoras que podran caber antes de distribuirlo.
Este ujo de trabajo es el encargado de evaluar la calidad del producto que
estamos desarrollando, pero no para aceptar o rechazar el producto al nal del
proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.
Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos son:
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 especicacin
de requisitos por medio de demostraciones concretas.

15

Vericar las funciones del producto de software segn lo diseado.

Vericar que los requisitos tengan su apropiada implementacin.

Las actividades de este ujo comienzan pronto en el proyecto con el plan de

prueba (el cual contiene informacin sobre los objetivos generales y especcos
de las prueba en el proyecto, as como las estrategias y recursos con que se
dotar a esta tarea), o incluso antes con alguna evaluacin durante la fase de
inicio, y continuar durante todo el proyecto.
El desarrollo del ujo de trabajo consistir en planicar que es lo que hay
que probar, disear cmo se va a hacer, implementar lo necesario para llevarlos
a cabo, ejecutarlos en los niveles necesarios y obtener los resultados, de forma
que la informacin obtenida nos sirva para ir renando el producto a desarrollar.

4.1.6.

Distribucin

Tal como en la cuarta etapa el usuario nal nos dar retroalimentacin para
pulir nuestro programa, adems, aqu se trata como llegar nuestro software
al usuario nal, en caso de ser software a la medida, pues no habr mucho
problema, sencillamente podemos grabarlo en un CD-ROM, pero en caso se
ser software empaquetado podemos distribuirlo por internet. Tambin hay que
incluir ayuda al usuario nal. El objetivo de este ujo de trabajo es producir con
xito distribuciones del producto y distribuirlo a los usuarios. Las actividades
implicadas incluyen:

Probar el producto en su entorno de ejecucin nal.

Empaquetar el software para su distribucin.
Distribuir el software.
Instalar el software.
Proveer asistencia y ayuda a los usuarios.
Formar a los usuarios y al cuerpo de ventas.
Migrar el software existente o convertir bases de datos.

Este ujo de trabajo se desarrolla con mayor intensidad en la fase de transicin, ya que el propsito del ujo es asegurar una aceptacin y adaptacin sin
complicaciones del software por parte de los usuarios. Su ejecucin inicia en fases
anteriores, para preparar el camino, sobre todo con actividades de planicacin,
en la elaboracin del manual de usuario y tutoriales.

16

4.2.

Complementarias: administracion de proyecto, administracion de cambios, ambiente.

4.2.1.

Administracin del proyecto

Un software siempre requiere de mantenimiento, es por eso que la retroalimentacin del usuario nal es importante, pues nos dar una visin para libe
-rar y/o desarrollar una nueva versin, quitar elementos innecesarios o agregar
nuevas funciones.

4.2.2.

Administracin de cambios

Es la forma en que se valoran las modicaciones al proyecto planteado inicialmente y se ajustan los tiempos, costos y las funcionalidades en algunos casos,
busca optimizar.
La Gestin del proyecto es el arte de lograr un balance al gestionar objetivos, riesgos y restricciones para desarrollar un producto que sea acorde a los
requisitos de los clientes y los usuarios.
Los objetivos de este ujo de trabajo son:

Proveer un marco de trabajo para la gestin de proyectos de software

intensivos.

Proveer guas prcticas realizar planeacin, contratar personal, ejecutar y

monitorear el proyecto.

Proveer un marco de trabajo para gestionar riesgos.

La planeacin de un proyecto posee dos niveles de abstraccin: un plan para

las fases y un plan para cada iteracin. La nalidad de este ujo de trabajo es
mantener la integridad de todos los artefactos que se crean en el proceso, as
como de mantener informacin del proceso evolutivo que han seguido.

4.2.3.

Ambiente

Esta parte provee elementos necesarios para que quien use nuestro software
se sienta conectado con l. La nalidad de este ujo de trabajo es dar soporte
al proyecto con las adecuadas herramientas, procesos y mtodos. Brinda una
especicacin de las herramientas que se van a necesitar en cada momento, as
como denir la instancia concreta del proceso que se va a seguir.
En concreto las responsabilidades de este ujo de trabajo incluyen:
Seleccin y adquisicin de herramientas
Establecer y congurar las herramientas para que se ajusten a la organizacin.
Conguracin del proceso.

17

Mejora del proceso.

Servicios tcnicos.

El principal artefacto que se usa en este ujo de trabajo es el caso de desarrollo que especca para el proyecto actual en concreto, como se aplicar el
proceso, que productos se van a utilizar y cmo van a ser utilizados. Adems se
tendrn que denir las guas para los distintos aspectos del proceso, como pueden ser el modelado del negocio y los Casos de Uso, para la interfaz de usuario,
el diseo, la programacin, el manual de usuario.

18

5.

HISTORIA
La metodologa RUP fue creado por Grady Booch, Ivan Jacobson y James

Jacobson.
Su predecesor fue el mtodo Ericsson implementado en 1967 el cual utilizaba
la compaa del mismo nombre para la creacin de sus productos, e introduca
el empleo de caso de uso. Despus se complement con la tcnica de modelado
de objetos de James Jacobson.
En 1995 la metodologa RUP se complementa con el enfoque de RATIONAL
SOFTWARE su empresa creadora; permitiendo el lanzamiento de la versin 4
de RUP y optando por UML como el lenguaje de modelado ocial.
En 1996 se agregan a RUP las actividades SQA (Software de control de
calidad) lo que permite al mtodo la produccin de software de calidad sin
importar los objetivos buscados por el cliente, adaptndose a sus necesidades.
En 1998 se lanza al mercado una fase de prueba del modelo RUP optimizado
con los enfoques de la ingeniera de negocios y la ingeniera de datos.
En 1999 se lanza la versin denitiva de lo que conocemos como RUP en la
actualidad.

19

6.
[1]

REFERENCIAS
Rational, Best Practices for software development teams- IBM, pp.
4-7. [fecha de consulta 26 de Septiembre de 2014]. Disponible en:
<https://www.ibm.com/ developerworks /rational /library/ content/
03July/ 1000/ 1251/ 1251_bestpractices_TP026B.pdf>

[2]

http://metodologiadesoftware.blogspot.mx/2012/11/fases-del-modelorup_27.html consultada 26 de septiembre 2014

[3]

http://softwarerecopilation.wordpress.com/modelo-rup/ consultada
26 de septiembre 2014

[4]

Rational Unied Process Equipo1.Metodologia RUP[en linea]:documento

electronico fuente en internet.2012[fecha de consulta: 26 septiembre
2014].Disponible en: <http://rupequipo1.blogspot.mx/2012/12/algode-historia.html >

[5]

Belloso Cecilia, Claudia Ivonne. Trabajo de graduacin para optar al grado de ingeniero en ciencias de la computacin [en linea].
UNIVERSIDAD DON BOSCO.2009 [fecha de consulta: 26 septiembre 2014]. Disponible en: <http:// rd.udb.edu.sv:8080/ jspui/ bitstream/ 123456789/ 257/ 1/ 47400_tesis.pdf >

20