METODOLOGIA RUP

METODOLOGA PURA

Es una metodologa cuyo fin es entregar un producto de software. Se estructura todos los
procesos y se mide la eficiencia de la organizacin.
Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de modelado
UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y
documentacin de sistemas orientados a objetos.
El RUP es un conjunto de metodologas adaptables al contexto y necesidades de cada
organiza

Principales caractersticas

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

En est metodologa lo que se pretende es el desarrollo de un software, en el cual se

aplicara el PSP y el CMMI en todos sus fases, que estn en la realizacin de los procesos

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).

CICLO DE VIDA . PON EN ESPAOL

Esfuerzo en actividades segn fase del proyecto
El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las
tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones
en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en
las distintas actividades.

Fases del ciclo de vida del RUP:

1. Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto
con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin
muy general de la arquitectura de software y producir el plan de las fases y el de
iteraciones posteriores.

2. Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que

permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza
la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del
problema, se disea la solucin preliminar.

3. Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del sistema,

para ello se deben clarificar los requerimientos pendientes, administrar los cambios de
acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el
proyecto.

4. Fase de Cierre: El propsito de esta fase es asegurar que el software est disponible
para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de
aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe
verificar que el producto cumpla con las especificaciones entregadas por las personas
 involucradas en el proyecto.

La metodologa RUP tiene 6 principios clave:

1. Adaptacin del proceso: El proceso debe adaptarse a las caractersticas de la

organizacin para la que se est desarrollando el software.

2. Balancear prioridades: Debe encontrarse un balance que satisfaga a todos

los inversores del proyecto.

3. Colaboracin entre equipos: Debe haber una comunicacin fluida para coordinar
requerimientos, desarrollo, evaluaciones, planes, resultados, entre otros.
4. Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de una forma
interna, en etapas iteradas. En cada iteracin se evaluar la calidad y estabilidad del
producto y analizar la opinin y sugerencias de los inversores .

5. Elevar el nivel de abstraccin: Motivar el uso de conceptos reutilizables.

6. Enfocarse en la calidad: La calidad del producto debe verificarse en cada aspecto de la

produccin.

Disciplina de desarrollo de RUP

Determina las etapas a realizar durante el proyecto de creacin del software.

Ingeniera o modelado del negocio: Analizar y entender las necesidades del negocio para
el cual se est desarrollando el software.
Requisitos: Proveer una base para estimar los costos y tiempo de desarrollo del sistema.
Anlisis y diseo: Trasladar los requisitos analizados anteriormente a un sistema
automatizado y desarrollar una arquitectura para el sistema.
 Implementacin: Crear software que se ajuste a la arquitectura diseada y que tenga el
comportamiento deseado.
Pruebas: Asegurarse de que el comportamiento requerido es correcto y que todo lo
solicitado est presente.
Despliegue: Producir distribuciones del producto y distribuirlo a los usuarios.

Disciplina de soporte RUP

Determina la documentacin que es necesaria realizar durante el proyecto.

Configuracin y administracin del cambio: Guardar todas las versiones del proyecto.
Administracin del proyecto: Administrar los horarios y recursos que se deben de
emplear.
Ambiente: Administrar el ambiente de desarrollo del software.
Distribucin: Hacer todo lo necesario para la salida del proyecto.

Elementos del RUP

Actividades: Procesos que se han de realizar en cada etapa/iteracin.

Trabajadores: Personas involucradas en cada actividad del proyecto.
Artefactos: Herramientas empleadas para el desarrollo del proyecto. Puede ser un
documento, un modelo, un elemento del modelo.
Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura esttica) realiza una serie de
artefactos que sirven para comprender mejor tanto el anlisis como el diseo del sistema
(entre otros). Estos artefactos (entre otros) son los siguientes:

Inicio:

Documento Visin
Especificacin de Requerimientos

Elaboracin:

Diagramas de caso de uso

Construccin:
 Documento Arquitectura que trabaja con las siguientes vistas:

VISTA LOGICA:

Diagrama de clases
Modelo E-R (Si el sistema as lo requiere)

VISTA DE IMPLEMENTACION:

Diagrama de Secuencia
Diagrama de estados
Diagrama de Colaboracin

VISTA CONCEPTUAL

Modelo de dominio

VISTA FISICA

Mapa de comportamiento a nivel de hardware.

DSADASDASDASDASD
Metodologa RUP
La metodologa RUP , abreviatura de Rational Unified Process (o Proceso Unificado
Racional), es un proceso propietario de la ingeniera de software creado por Rational
Software , adquirida por IBM , ganando un nuevo nombre Irup que ahora es una
abreviatura Rational Unified Process y lo que es una marca en el rea de
software, proporcionando tcnicas que deben seguir los miembros del equipo de
desarrollo de software con el fin de aumentar su productividad en el proceso
de desarrollo.
 La metodologa RUP utiliza el enfoque de la orientacin a objetos en su diseo y est
diseado y documentado el uso de la notacin UML ( Unified Modeling Language ) para
ilustrar los procesos en accin. Utiliza tcnicas y prcticas probadas comercialmente.
Es un proceso considerado pesado y preferentemente aplicable a grandes equipos de
desarrollo y grandes proyectos , pero el hecho de que es ampliamente personalizable que
permite adaptarse a proyectos de cualquier escala.
Para la gestin del proyecto , la metodologa RUP proporciona una solucin disciplinada
como las tareas y responsabilidades sealadas dentro de una organizacin de desarrollo
de software.
RUP es, en s, un producto de software. Es modular y automatizado, y toda su metodologa
se apoya en varias herramientas de desarrollo integradas y vendidos por IBM a travs de
sus Suites racional.
Los mtodos de la competencia en el campo de la ingeniera de software incluyen salas
blancas (considerado pesado) y gil (luz) como Extreme Programming (Programacin XP-
Extreme), Scrum , FDD y otros.
Contenido
1 Directrices de la metodologa RUP
o 1.1 Requisitos de gestin
o 1.2 El uso de una arquitectura basada en componentes
o 1.3 El uso de modelos visuales de software en la metodologa RUP
o 1.4 Comprobar la calidad del software
o 1.5 Software de gestin y de cambio de control
 2 Fases de la metodologa RUP
o 2.1 Fase de diseo
o 2.2 Fase de elaboracin
o 2.3 Fase de construccin
o 2.4 Fase de transicin
3 Disciplinas de la metodologa RUP
o 3.1 Seis Disciplinas de Ingeniera de Software
o 3.2 Tres Disciplinas Soporte / Servicio de la metodologa RUP
4 Principios y las mejores prcticas de la metodologa RUP
o 4.1 Desarrollo iterativo
o 4.2 La gestin de requisitos
o 4.3 El uso de una arquitectura basada en componentes
o 4.4 Software de modelado visual
o 4.5 Software de control de calidad
o 4.6 Control de cambios en el software
DIRECTRICES DE LA METODOLOGA RUP
RUP define las siguientes lneas maestras y los esqueletos ( plantillas ) para los miembros
del personal de un ciclo de produccin: parte del cliente, y una evaluacin de los avances
del proyecto por su gestin. Ayuda a los desarrolladores para mantener la concentracin
en el proyecto.
REQUISITOS DE GESTIN
La documentacin apropiada es esencial para cualquier proyecto de gran envergadura; en
cuenta que RUP describe cmo documentar la funcionalidad, las limitaciones del sistema,
restricciones de diseo y requisitos de negocio.
Los casos de uso (en Ingls Casos de uso ) y los escenarios son ejemplos de artefactos de
proceso dependiente, que se han considerado mucho ms eficaz en la captura de
requisitos funcionales.
EL USO DE UNA ARQUITECTURA BASADA EN COMPONENTES
La arquitectura basada en componentes crea un sistema que puede ser fcilmente
extensible, promoviendo la reutilizacin y el software una comprensin intuitiva. Un
componente se refiere normalmente a un objeto en la programacin orientada a objetos.
RUP proporciona una manera sistemtica para construir este tipo de sistema, centrndose
en la produccin de una arquitectura ejecutable en las primeras etapas del proyecto, es
decir, antes de comprometer recursos a gran escala.
Estos componentes se incluyen normalmente en las infraestructuras existentes, tales
como CORBA y COM (Component Object Model).
EL USO DE MODELOS VISUALES DE SOFTWARE EN LA METODOLOGA RUP
Al abstraer la programacin de su cdigo y representarla utilizando bloques de
construccin grficas, RUP puede una manera eficaz de conseguir una visin general de
una solucin.
El uso de modelos visuales tambin puede permitir que los individuos menos perfil tcnico
(como clientes) tienen una mejor comprensin de un problema dado, y as estar ms
involucrados en el proyecto en su conjunto.
El lenguaje de modelado UML se ha convertido en un estndar de la industria para
representar los proyectos, y es ampliamente utilizado por RUP!
COMPROBAR LA CALIDAD DEL SOFTWARE
No asegura la calidad del software es el fallo ms comn en todos los proyectos de
sistemas informticos. Por lo general, uno piensa en la calidad del software despus de la
finalizacin de los proyectos, o la calidad es la responsabilidad de un equipo de desarrollo
de equipo diferente.
RUP tiene como objetivo ayudar en el control de la planificacin de la calidad,
comprobando que en la construccin de todo el proceso y la participacin de todos los
miembros del equipo de desarrollo.
SOFTWARE DE GESTIN Y DE CAMBIO DE CONTROL
En todos los proyectos de software de la existencia del cambio es inevitable. RUP define
mtodos para controlar y vigilar los cambios. Como un pequeo cambio puede afectar a
las aplicaciones de maneras totalmente impredecibles, el control de cambio es esencial
para el xito de un proyecto.
RUP tambin define las reas de trabajo y seguridad , lo que garantiza un programador
que cambia en otro sistema no afectar a su sistema.
FASES DE LA METODOLOGA RUP
Hasta ahora estas lneas gua son generales, para ser adherido a pasar por la vida de un
ciclo de proyecto. Las fases (ver figura abajo) indican el nfasis se da en el proyecto en un
instante dado. Para capturar la dimensin temporal de un proyecto, RUP divide el
proyecto en cuatro fases diferentes:

Iniciacin o Diseo : nfasis en el alcance del sistema;

Preparacin : nfasis en la arquitectura;
Construccin : nfasis en el desarrollo;
Transicin : nfasis en la aplicacin.
RUP se basa tambin en las 4 Ps:
Personas
 Diseo
Producto
Proceso
Las capas se componen de iteraciones. Iteraciones son ventanas de tiempo; iteraciones
han definido trmino como las fases son objetivos.
Todas las fases generan artefactos. Estos sern utilizados en la siguiente fase y
documentar el proyecto y permite un mejor seguimiento.
FASE DE DISEO
La fase de diseo o de iniciacin contiene los flujos de trabajo necesarios para el acuerdo
de las partes interesadas interesados con los objetivos, la arquitectura y la
planificacin del proyecto. Si estos actores tienen un buen conocimiento, no ser
necesario analizar. De lo contrario, se requiere un anlisis ms elaborado.
En esta etapa, los requisitos esenciales del sistema se transforman en los casos de uso . El
objetivo no es para cerrarlas en absoluto, sino slo las que sean necesarias para dar forma
a la opinin.
El paso es generalmente corto y se utiliza para definir si es factible para continuar con el
proyecto y definir los riesgos y el coste de la ltima. Un prototipo se puede hacer para que
el cliente apruebe. Como cita el RUP, lo ideal es realizar iteraciones , las cuales deben
estar bien definida en cuanto a su importe y objetivos.
FASE DE ELABORACIN
La preparacin ser para el diseo del sistema, como complemento de la encuesta y / o
documentacin de casos de uso, frente a la arquitectura del sistema, revisar el modelo de
negocio para el proyecto e iniciar la versin del manual del usuario. Uno debe aceptar:
Descripcin del producto (aumento + integracin) es estable;? El plan del proyecto es
fiable?; Los costos son elegibles?
FASE DE CONSTRUCCIN
En la fase de construccin, el desarrollo fsico del software se inicia, cdigos de
produccin, pruebas alfa. pruebas beta se llevaron a cabo al inicio de la fase de transicin.
Se debe aceptar las pruebas, procesos estables y de prueba, y el cdigo del sistema son
lnea de base.
FASE DE TRANSICIN
En esta fase es la entrega ( despliegue) de software, que se lleva a cabo el plan de
despliegue y entrega, el seguimiento y la calidad del software. Productos (lanzamientos,
las versiones) se van a entregar, y coloque la satisfaccin del cliente. Esta etapa tambin
se lleva a cabo la formacin de los usuarios.
DISCIPLINAS DE LA METODOLOGA RUP
SEIS DISCIPLINAS DE INGENIERA DE SOFTWARE
LA DISCIPLINA MODELADO DE NEGOCIO
Las organizaciones dependen cada vez ms de los sistemas de TI , por lo que es imperativo
que los ingenieros de sistemas de informacin saben cmo se integran las aplicaciones en
el desarrollo de la organizacin. Las empresas invierten en TI, que entienden la ventaja
competitiva del valor aadido por la tecnologa.
El objetivo de modelado de negocio es establecer primero una mejor comprensin y
comunicacin entre ingeniera de negocios y la ingeniera de software.
Comprender el negocio significa que los ingenieros de software deben entender la
estructura y la dinmica de la empresa objetivo (el cliente), los problemas actuales de la
organizacin y las posibles mejoras. Tambin deben asegurar una comprensin comn de
la organizacin de destino entre los clientes, usuarios finales y desarrolladores.
El modelado de negocios explica cmo describir la visin de una organizacin en la que se
implementar el sistema y cmo utilizar esta visin como base para describir los procesos,
funciones y responsabilidades.
REQUISITOS DEL CURSO
Este curso explica cmo al llegar peticiones de las partes interesadas ( partes
interesadas) y los convierten en un conjunto de requisitos que los productos funcionan
dentro del sistema que se construirn y proporcionar los requisitos detallados para lo que
es necesario que el sistema.
ANLISIS Y DISEO DE LA DISCIPLINA ( DISEO)
El propsito del anlisis y diseo es mostrar cmo se llevar a cabo el sistema. El objetivo
es construir un sistema que:
Ejecutar en un entorno de ejecucin especfica, las tareas y las funciones especificadas en
las descripciones de casos de uso
Satisfacer todas sus necesidades
Es fcil de mantener cuando no son cambios en los requisitos funcionales, los resultados
del proyecto en un modelo de anlisis y diseo tiene opcionalmente un modelo de
anlisis. El modelo de diseo sirve como una abstraccin del cdigo fuente, es decir, el
proyecto sirve como modelo de retroalimentacin de la forma en que el cdigo fuente
est estructurado y escrito.
El modelo de diseo consta de clases de diseo estructurados en paquetes y subsistemas
con interfaces bien definidas, en representacin de lo que se convertir componentes de
la aplicacin. Tambin contiene descripciones de cmo los objetos de estas clases
colaboran para llevar a cabo el diseo de casos de uso.
LA DISCIPLINA IMPLEMENTACIN
Los efectos de la aplicacin son:
Para configurar el cdigo de la organizacin en trminos de subsistemas de aplicacin
organizados en capas
Para llevar a cabo las clases y objetos en trminos de componentes (archivos de
cdigo fuente, binarios, ejecutables, etc.)
Para probar los componentes desarrollados como unidades
Incorporar los resultados producidos por los ejecutores individuales (o equipos), en
un sistema ejecutable
Los sistemas se logran a travs de los componentes de la aplicacin. El proceso describe
cmo reutilizar componentes existentes o implementar nuevos componentes con
responsabilidades bien definidas, haciendo que el sistema sea ms fcil de mantener y
aumentar las posibilidades de reutilizacin.
PRUEBA DE DISCIPLINA
Los fines de disciplina prueba son:
Comprobar la interaccin entre los objetos
Comprobar la correcta integracin de todos los componentes de software
Compruebe que todos los requisitos han sido ejecutadas correctamente
Identificar y asegurar que los defectos se tratan antes de la implementacin de software
Asegrese de que todos los defectos son corregidos, revisados y cerrados
El Rational Unified Process propone un enfoque iterativo, lo que significa que debera
estar probando el proyecto en su totalidad. Esto le permite encontrar defectos tan pronto
como sea posible, lo que reduce drsticamente el costo de reparar el defecto.
Las pruebas se realizan a lo largo de cuatro dimensiones de la calidad: fiabilidad,
funcionalidad, rendimiento de las aplicaciones y el rendimiento del sistema . Para cada
una de estas dimensiones de la calidad, el proceso se describe cmo a pasar la prueba de
la planificacin, diseo, implementacin, ejecucin y evaluacin.
LA DISCIPLINA IMPLEMENTACIN
El propsito del despliegue es producir lanzamientos de productos exitosos y entregar el
software a los usuarios finales. Abarca una amplia gama de actividades, incluyendo la
produccin de versiones de software externos, el envase de aplicaciones de software y de
negocios, distribucin de software, instalacin de software y proporcionar ayuda y
asistencia a los usuarios.
Aunque las actividades de despliegue se centran principalmente en torno a la transicin,
muchas de las actividades se deben incluir en las etapas anteriores para preparar la
aplicacin, al final de la fase de construccin. Los procesos ( flujos de trabajo) de
Implementacin y Medio Ambiente RUP contienen menos detalles que otros flujos de
trabajo.
TRES DISCIPLINAS SOPORTE / SERVICIO DE LA METODOLOGA RUP
DISCIPLINA PARA EL MEDIO AMBIENTE
El medio ambiente se centra en las actividades necesarias para configurar el proceso para
un proyecto. En l se describen las actividades necesarias para desarrollar directrices para
apoyar un proyecto.
La propuesta de las actividades ambientales es proporcionar a los procesos de
organizacin de desarrollo de software y herramientas que apoyarn al equipo de
desarrollo. Si los usuarios no entienden que RUP RUP es un marco de proceso, pueden
percibirlo como un proceso engorroso y costoso. Sin embargo, un concepto clave en las
RUP era la lata RUP y, a menudo debe ser refinado.
Esto se hizo inicialmente de forma manual, es decir, un documento caso del complejo
escrito que especifica el proceso de refinado para ser utilizado. Ms tarde, IBM producto
Compositor Mtodo Racional fue creado para ayudar a hacer este paso simple, ingenieros
de proceso y los directores de proyectos podra ms fcilmente personalizar el RUP para
sus necesidades del proyecto.
Muchas de las variaciones posteriores de las regiones ultraperifricas, incluidas OpenUP /
Basic, el cdigo abierto, versin ligera de RUP, se presentan ahora como procesos
separados en su propio derecho, y atender a los diferentes tipos y tamaos de proyectos,
tendencias y tecnologas de desarrollo de software.
Histricamente, como el RUP es a menudo la medida para cada proyecto por un experto
en procesos RUP, el xito global del proyecto puede ser algo dependiente de la capacidad
de esta persona.
CONFIGURACIN DE LA DISCIPLINA Y DE LA GESTIN
La disciplina de la gestin del cambio en el negocio con RUP abarca tres tratamientos
especficos: configuracin, solicitudes de cambio, y el estado y de medida.
La gestin de configuracin: gestin de la configuracin es responsable de la
estructuracin sistemtica de productos. Los artefactos tales como documentos y
modelos necesitan estar bajo el control de versiones y estos cambios deben ser visibles.
Tambin realiza un seguimiento de las dependencias entre los artefactos de manera que
todos los artculos relacionados se actualizan cuando se realizan cambios
La gestin del cambio de solicitud: Durante el proceso de desarrollo del sistema con
muchos artefactos que existen varias versiones. El CRM realiza un seguimiento de los
cambios propuestos
El estado y la medicin de la gestin: las solicitudes de cambio tienen los estados: nuevo ,
conectado , aprobado , asignado y completa . La solicitud de cambio tambin tiene
atributos como la causa raz, o la naturaleza (como el incumplimiento y recuperacin),
prioridad, etc.
Estos estados y atributos se almacenan en la base de datos para producir informes tiles
sobre el progreso del proyecto. Racional tambin tiene un producto para mantener las
solicitudes de cambio llamados ClearQuest . Esta actividad tiene procedimientos a seguir
PROYECTO DE GESTIN DE LA DISCIPLINA
La planificacin del proyecto en el RUP se produce en dos niveles. Hay un grano fino o
planes de fase que describe el proyecto en su totalidad, y un nmero de alta granularidad
o planes de iteracin que describe los pasos iterativos.
Este curso se centra principalmente en los aspectos importantes de un proceso de
desarrollo iterativo: La gestin de riesgos; La planificacin de un proyecto iterativo a
travs del ciclo de vida y para una iteracin en particular; Y el proceso de seguimiento de
un proyecto iterativo, la mtrica. Sin embargo, esta disciplina de RUP no pretende cubrir
todos los aspectos de la gestin de proyectos.
Por ejemplo, no cubre cuestiones tales como:
Gestin de personas: contratacin, formacin, etc.
Presupuesto general: definicin, asignacin, etc.
Gestin de contratos: con los proveedores, clientes, etc.
PRINCIPIOS Y LAS MEJORES PRCTICAS DE LA METODOLOGA RUP
La metodologa RUP se basa en un conjunto de principios de desarrollo de software y las
mejores prcticas, por ejemplo:
1. Desarrollo de software iterativo
2. La gestin de requisitos
 3. El uso de una arquitectura basada en componentes
4. Software de modelado visual
5. La verificacin de la calidad del software
6. Control de cambios en el software
DESARROLLO ITERATIVO
Teniendo en cuenta el tiempo necesario para desarrollar un software grande y sofisticada,
no se puede definir el problema y construir software en un solo paso. Los requisitos
cambiarn a menudo en el curso del desarrollo del proyecto , debido a las restricciones de
la arquitectura , las necesidades del usuario o para una mayor comprensin del problema
original.
Los cambios permiten que el proyecto para estar constantemente refinada, y la seal a los
elementos del proyecto de alto riesgo como las tareas de mayor prioridad. Idealmente, al
final de cada iteracin habr una versin ejecutable , lo que ayuda a reducir el riesgo de
configuracin de diseo, que permite una mayor respuesta de los usuarios y ayudar al
desarrollador a permanecer centrado.
RUP utiliza el desarrollo iterativo e incremental por las siguientes razones:
La integracin se hace paso a paso durante el proceso de desarrollo, cada paso se
limita a unos pocos elementos
La integracin es menos complejo, reduciendo el coste y aumentar la eficiencia
diseo de las piezas por separado y / o implementacin pueden ser fcilmente
identificados para su posterior reutilizacin
Requisitos cambios son registrados y pueden ser acomodados
Los riesgos se abordan en el comienzo del desarrollo y cada iteracin permite la
verificacin de riesgos ya percibidas y la identificacin de nuevos
Para la arquitectura de software se mejora a travs de un repetidor scrutinize
El uso de iteraciones, un proyecto tendr un plan general, as como varios planes de
iteracin. La participacin de las partes interesadas a menudo se alienta a cada entrega.
En esta forma, las entregas sirven como una manera de conseguir el compromiso de los
involucrados, mientras que tambin promueve una comparacin constante entre las
necesidades y el desarrollo de la organizacin a los conflictos que surjan.
LA GESTIN DE REQUISITOS
La gestin de requisitos en RUP se centra en encontrar el final el usuario necesita para la
identificacin y especificacin de lo que necesita y la identificacin de lo que debe ser
cambiado. Esto trae los siguientes beneficios:
La correccin de los requisitos genera la correccin del producto, por lo que se satisfacen
las necesidades de los usuarios.
se incluirn las caractersticas requeridas, lo que reduce el costo de los acontecimientos
posteriores.
RUP sugiere que la administracin de requerimientos tiene que seguir las actividades:
Anlisis de los problemas es que de acuerdo con el problema y crear medidas que
probarn su valor para la organizacin
 La comprensin de las necesidades de sus grupos de inters es para compartir el
problema y los valores con los principales interesados y elevar lo que las necesidades
estn involucrados en el desarrollo de la idea
La definicin del problema es la definicin de las caractersticas de las necesidades y
el diseo de los casos de uso , actividades que mostrarn fcilmente los requisitos de
alto nivel y el esquema modelo de uso del sistema
Administrar el alcance del sistema es el alcance de los cambios que se comunica con
base en el progreso y los resultados seleccionados en el orden en que los diagramas
de flujo de los casos de uso son atacados
Refinar los ajustes del sistema de ofertas con los detalles de los diagramas de flujo
de casos de uso con las partes interesadas con el fin de crear una especificacin de las
aplicaciones de software que puede servir como un contrato entre su grupo y el
cliente y puede guiar las actividades de ensayo y proyecto
Los requisitos de gestin del cambio es la forma de identificar las llegadas de los
cambios en las aplicaciones en un proyecto que ya ha comenzado
EL USO DE UNA ARQUITECTURA BASADA EN COMPONENTES
La arquitectura basada en componentes crea un sistema que es fcilmente extensible,
intuitiva y fcil de entender y promueve la reutilizacin de software.
Un componente de frecuencia asociado con un conjunto de objetos en objetos
programacin orientada .
Arquitectura de software aumenta en importancia cuando un sistema se hace ms grande
y ms compleja. RUP se centra en la produccin de arquitectura bsica en los primeros
pocos iteraciones. Esta arquitectura se convierte en un prototipo en los ciclos iniciales de
desarrollo.
La arquitectura desarrollada en cada iteracin para convertirse en la arquitectura final del
sistema. RUP tambin propuso reglas de diseo y limitaciones para capturar normas de
arquitectura. Para el desarrollo iterativo es posible para identificar gradualmente
componentes que a continuacin se pueden desarrollar o comprado reutilizada. Estos
componentes se construyen a menudo en las infraestructuras existentes, tales como
CORBA y COM o Java EE , o PHP
SOFTWARE DE MODELADO VISUAL
Haciendo abstraccin de su programacin de su cdigo y representarla por medio de
bloques de construccin grficas constituye una forma eficaz de obtener una visin
general de una solucin. El uso de esta representacin, los recursos tcnicos pueden
determinar la mejor manera de poner en prctica un conjunto dado de interdependencias
lgicas .
Esto tambin crea una capa intermedia entre el proceso de negocio y el cdigo necesario
a travs de tecnologa de la informacin. Un modelo en este contexto es una pantalla y al
mismo tiempo una simplificacin de un diseo complejo. RUP especifica qu modelos son
necesarios y por qu.
El Lenguaje de Modelado Unificado (UML) se puede utilizar para el modelado de casos de
uso , diagramas de clases y otros objetos. RUP tambin analiza otras formas de construir
estos modelos.
SOFTWARE DE CONTROL DE CALIDAD
Aseguramiento de la calidad del software es el punto de fallo ms comn en los proyectos
de software , ya que esto es a menudo algo que no se haba pensado anteriormente y, a
veces es tratado por diferentes equipos. RUP ayuda en la planificacin del control de
calidad y se encarga de su construccin en todos los procesos de participacin de todos
los miembros del equipo.
No es una tarea est dirigida especficamente a la calidad ; RUP supone que cada
miembro del equipo es responsable de la calidad durante todo el proceso. El proceso se
centra en el descubrimiento de el nivel esperado de la calidad y proporciona pruebas en
los procesos para medir este nivel.
CONTROL DE CAMBIOS EN EL SOFTWARE
En todos los proyectos de software, los cambios son inevitables. RUP define mtodos para
controlar, seguir y supervisar estos cambios. RUP define tambin el trabajo seguro de
espacios (espacios de trabajo seguros en ingls), lo que garantiza que un sistema de
ingeniera de software no se ve afectada por los cambios en otros sistemas. Este concepto
es pegar bien con arquitecturas de software basados en componentizacin.