Metodología RUP
Metodología RUP
Metodología RUP
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.
• 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).
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.
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.
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.
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.
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.
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.
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.