Metodología RUP

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 7

Metodología RUP

Metodologia RUP (Rational Unified Process)


RUP es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado
(UML), constituye la metodología estándar más utilizada para el análisis, implementación y
documentación de sistemas orientados a objetos

RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado
en la arquitectura y guiado por lo casos de uso. Incluye artefactos, que son los productos tangibles
del proceso como por ejemplo el modelo de casos de uso, el código fuente y roles los cuales
desempeña una persona en lo largo del proceso.

Principios de desarrollo
1. Adaptación del proceso a las necesidades del cliente interactuando con el.
2. Equilibrar las necesidades o requerimientos de los participantes con prioridades justas.
3. Etapas iteradas en el proceso.
4. Colaboración continúa entre equipos de desarrollo del software.
5. Uso de elementos reutilizables que permita elevar el nivel de abstracción. 6. La calidad del producto
debe verificarse en todas las etapas del proceso

Ciclo de vida
El ciclo de vida RUP es una implementación del desarrollo en espiral. Fue creado ensamblando los elementos
en secuencias semi-ordenadas.

• Las primeras iteraciones en las fases de inicio y elaboración se enfocan en el entendimiento


del problema y tecnología. Durante la fase de inicio las iteraciones hacen mayor énfasis en
actividades de modelado del negocio y de requisitos.
• En la fase de elaboración las iteraciones son orientadas al desarrollo de la baseline de la
arquitectura, abarcan aún más en los flujos de los requisitos, modelado de negocios, análisis y
diseño y una parte de implementación orientada a la baseline de la arquitectura.

• En la fase de construcción se lleva a cabo la creación del producto por medio de una serie de
iteraciones (a cada interacción se dan algunos casos de uso).

• En la fase de transición se garantiza que tiene un producto preparado para su entrega a la


comunidad de usuarios

Principales características

Desarrollo iterativo
Teniendo en cuenta el tiempo necesario para desarrollar un software grande y sofisticado, no se puede
definir el problema y construir software en un solo paso. Los requisitos cambiarán a menudo en el
curso del desarrollo del proyecto, debido a las restricciones de la arquitectura, las necesidades del
usuario o para una mayor comprensión del problema original.

RUP utiliza el desarrollo iterativo e incremental por las siguientes razones:


• La integración se hace paso a paso durante el proceso de desarrollo, cada paso se limita a unos
pocos elementos
• La integración es menos complejo, reduciendo el coste y aumentar la eficiencia diseño de las
piezas por separado y / o implementación pueden ser fácilmente identificados para su
posterior reutilización
• Requisitos cambios son registrados y pueden ser acomodados
• Los riesgos se abordan en el comienzo del desarrollo y cada iteración permite la verificación
de riesgos ya percibidas y la identificación de nuevos
• Para la arquitectura de software se mejora a través de un repetidor scrutinize

Gestión de requisitos
La gestión de requisitos en RUP se centra en encontrar el final – el usuario necesita para la
identificación y especificación de lo que necesita y la identificación de lo que debe ser cambiado.
Esto trae los siguientes beneficios:

• Análisis de los problemas es que de acuerdo con el problema y crear medidas que probarán
su valor para la organización
• La comprensión de las necesidades de sus grupos de interés es para compartir el
problema y los valores con los principales interesados y elevar lo que las necesidades están
involucrados en el desarrollo de la idea
• La definición del problema es la definición de las características de las necesidades y el
diseño de los casos de uso , actividades que mostrarán fácilmente 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 especificación 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 gestión del cambio es la forma de identificar las llegadas de los cambios en las
aplicaciones en un proyecto que ya ha comenzado.

Uso de una arquitectura basada en componentes


La arquitectura basada en componentes crea un sistema que es fácilmente extensible, intuitiva y
fácil de entender y promueve la reutilización de software.

Un componente de frecuencia asociado con un conjunto de objetos en objetos – programación orientada.


Arquitectura de software aumenta en importancia cuando un sistema se hace más grande y más
compleja. RUP se centra en la producción de arquitectura básica en los primeros pocas
iteraciones. Esta arquitectura se convierte en un prototipo en los ciclos iniciales de desarrollo.

La arquitectura desarrollada en cada iteración para convertirse en la arquitectura final del sistema.
RUP también propuso reglas de diseño y limitaciones para capturar normas de arquitectura. Para el
desarrollo iterativo es posible para identificar gradualmente componentes que a continuación 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 abstracción de su programación y de su código representada por medio de bloques de
construcción gráficas constituye una forma eficaz de obtener una visión general de una solución. El
uso de esta representación, los recursos técnicos pueden determinar la mejor manera de poner en
práctica un conjunto dado de interdependencias lógicas.

Esto también crea una capa intermedia entre el proceso de negocio y el código necesario a través de
tecnología de la información. Un modelo en este contexto es una pantalla y al mismo tiempo una
simplificación de un diseño 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 también analiza otras formas de construir estos modelos.

Software de control de calidad


Aseguramiento de la calidad del software es el punto de fallo más común en los proyectos de software
, ya que esto es a menudo algo que no se había pensado anteriormente y, a veces es tratado por
diferentes equipos. RUP ayuda en la planificación del control de calidad y se encarga de su
construcción en todos los procesos de participación de todos los miembros del equipo.

No es una tarea dirigida específicamente 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 del
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. Define métodos para controlar,
seguir y supervisar estos cambios. Define también el trabajo seguro de espacios (espacios de trabajo
seguros en inglés), lo que garantiza que un sistema de ingeniería de software no se ve afectada por
los cambios en otros sistemas. Este concepto es pegar bien con arquitecturas de software basados en
componentización.

Fases de la metodología RUP


Fase de inicio
En esta fase tiene como propósito definir y establecer el alcance del proyecto con los patrocinadores,
identificar los riesgos asociados al proyecto, producir el plan de las fases y el de iteraciones
posteriores.

Fase de elaboración
En esta fase se diseña la solución preliminar, se seleccionan los casos de uso que permiten definir la
arquitectura inicial del sistema y se desarrollaran en esta fase el primer análisis del problema.

Fase de construcción
En esta fase se completa la funcionalidad del sistema, para ello se debe aclarar los requisitos pendientes,
organizar los cambios de acuerdo a las evaluaciones realizadas por los usuarios y posteriormente se
realizarán las mejoras al proyecto.
Fase de transición
En esta fase se asegura que el software esté disponible para los usuarios también se ajustan los
errores y defectos encontrados en las pruebas de aceptación, y de lo cual se capacitan a los usuarios
y se provee soporte técnico necesario.

Ventajas
• Proceso configurable para satisfacer necesidades específicas de un proyecto.

• Facilita la reutilización del código teniendo en cuenta que se realizan revisiones en las primeras
iteraciones lo cual además permite que se aprecian oportunidades de mejoras en el diseño.

• Incorpora fielmente el objetivo de calidad.

• Integra desarrollo con mantenimiento.

Desventajas
• Por el grado de complejidad puede ser no muy adecuado

• En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo
de profesionales necesarios.

También podría gustarte