Metodología RUP

La metodología RUP , abreviatura de Rational Unified Process (o Proceso Unificado Racional), es un proceso propietario de la ingeniería 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 técnicas que deben seguir los miembros del equipo de desarrollo de software con el fin de aumentar su productividad en el proceso de desarrollo.

metodología RUP

La metodología RUP utiliza el enfoque de la orientación a objetos en su diseño y está diseñado y documentado el uso de la notación UML ( Unified Modeling Language ) para ilustrar los procesos en acción. Utiliza técnicas y prácticas 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 gestión del proyecto , la metodología RUP proporciona una solución disciplinada como las tareas y responsabilidades señaladas dentro de una organización de desarrollo de software.

RUP es, en sí, un producto de software. Es modular y automatizado, y toda su metodología se apoya en varias herramientas de desarrollo integradas y vendidos por IBM a través de sus “Suites racional.”

Los métodos de la competencia en el campo de la ingeniería de software incluyen ” salas blancas ” (considerado pesado) y ágil (luz) como Extreme Programming (Programación XP-Extreme), Scrum , FDD y otros.

Directrices de la metodología RUP

RUP define las siguientes líneas maestras y los esqueletos ( plantillas ) para los miembros del personal de un ciclo de producción: parte del cliente, y una evaluación de los avances del proyecto por su gestión. Ayuda a los desarrolladores para mantener la concentración en el proyecto.

Requisitos de gestión

La documentación apropiada es esencial para cualquier proyecto de gran envergadura; en cuenta que RUP describe cómo documentar la funcionalidad, las limitaciones del sistema, restricciones de diseño y requisitos de negocio.

Los casos de uso (en Inglés Casos de uso ) y los escenarios son ejemplos de artefactos de proceso dependiente, que se han considerado mucho más 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 fácilmente extensible, promoviendo la reutilización y el software una comprensión intuitiva. Un componente se refiere normalmente a un objeto en la programación orientada a objetos.

RUP proporciona una manera sistemática para construir este tipo de sistema, centrándose en la producción 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 metodología RUP

Al abstraer la programación de su código y representarla utilizando bloques de construcción gráficas, RUP puede una manera eficaz de conseguir una visión general de una solución.

El uso de modelos visuales también puede permitir que los individuos menos perfil técnico (como clientes) tienen una mejor comprensión de un problema dado, y así estar más involucrados en el proyecto en su conjunto.

El lenguaje de modelado UML se ha convertido en un estándar 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 más común en todos los proyectos de sistemas informáticos. Por lo general, uno piensa en la calidad del software después de la finalización 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 planificación de la calidad, comprobando que en la construcción de todo el proceso y la participación de todos los miembros del equipo de desarrollo.

Software de gestión y de cambio de control

En todos los proyectos de software de la existencia del cambio es inevitable. RUP define métodos para controlar y vigilar los cambios. Como un pequeño cambio puede afectar a las aplicaciones de maneras totalmente impredecibles, el control de cambio es esencial para el éxito de un proyecto.

RUP también 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 metodología RUP

Hasta ahora estas líneas guía 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 dimensión temporal de un proyecto, RUP divide el proyecto en cuatro fases diferentes:

La metodología RUP

  • Iniciación o Diseño : énfasis en el alcance del sistema;
  • Preparación : énfasis en la arquitectura;
  • Construcción : énfasis en el desarrollo;
  • Transición : énfasis en la aplicación.
  • RUP se basa también en las 4 Ps:
  • Personas
  • Diseño
  • Producto
  • Proceso

Las capas se componen de iteraciones. Iteraciones son ventanas de tiempo; iteraciones han definido término como las fases son objetivos.

Todas las fases generan artefactos. Estos serán utilizados en la siguiente fase y documentar el proyecto y permite un mejor seguimiento.

Fase de diseño

La fase de diseño o de iniciación contiene los flujos de trabajo necesarios para el acuerdo de las partes interesadas – interesados – con los objetivos, la arquitectura y la planificación del proyecto. Si estos actores tienen un buen conocimiento, no será necesario analizar. De lo contrario, se requiere un análisis más 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 sólo las que sean necesarias para dar forma a la opinión.

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 elaboración

La preparación será para el diseño del sistema, como complemento de la encuesta y / o documentación de casos de uso, frente a la arquitectura del sistema, revisar el modelo de negocio para el proyecto e iniciar la versión del manual del usuario. Uno debe aceptar:

Descripción del producto (aumento + integración) es estable;? El plan del proyecto es fiable?; Los costos son elegibles?

Fase de construcción

En la fase de construcción, el desarrollo físico del software se inicia, códigos de producción, pruebas alfa. pruebas beta se llevaron a cabo al inicio de la fase de transición.

Se debe aceptar las pruebas, procesos estables y de prueba, y el código del sistema son “línea de base”.

Fase de transición

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 satisfacción del cliente. Esta etapa también se lleva a cabo la formación de los usuarios.

Disciplinas de la metodología RUP

Seis Disciplinas de Ingeniería de Software

La disciplina modelado de negocio

Las organizaciones dependen cada vez más de los sistemas de TI , por lo que es imperativo que los ingenieros de sistemas de información saben cómo se integran las aplicaciones en el desarrollo de la organización. Las empresas invierten en TI, que entienden la ventaja competitiva del valor añadido por la tecnología.

El objetivo de modelado de negocio es establecer primero una mejor comprensión y comunicación entre ingeniería de negocios y la ingeniería de software.

Comprender el negocio significa que los ingenieros de software deben entender la estructura y la dinámica de la empresa objetivo (el cliente), los problemas actuales de la organización y las posibles mejoras. También deben asegurar una comprensión común de la organización de destino entre los clientes, usuarios finales y desarrolladores.

El modelado de negocios explica cómo describir la visión de una organización en la que se implementará el sistema y cómo utilizar esta visión como base para describir los procesos, funciones y responsabilidades.

Requisitos del curso

Este curso explica cómo 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 construirán y proporcionar los requisitos detallados para lo que es necesario que el sistema.

Análisis y Diseño de la disciplina ( “Diseño”)

El propósito del análisis y diseño es mostrar cómo se llevará a cabo el sistema. El objetivo es construir un sistema que:

Ejecutar en un entorno de ejecución específica, las tareas y las funciones especificadas en las descripciones de casos de uso

Satisfacer todas sus necesidades

Es fácil de mantener cuando no son cambios en los requisitos funcionales, los resultados del proyecto en un modelo de análisis y diseño tiene opcionalmente un modelo de análisis. El modelo de diseño sirve como una abstracción del código fuente, es decir, el proyecto sirve como modelo de “retroalimentación” de la forma en que el código fuente está estructurado y escrito.

El modelo de diseño consta de clases de diseño estructurados en paquetes y subsistemas con interfaces bien definidas, en representación de lo que se convertirá componentes de la aplicación. También contiene descripciones de cómo los objetos de estas clases colaboran para llevar a cabo el diseño de casos de uso.

La disciplina Implementación

Los efectos de la aplicación son:

  • Para configurar el código de la organización en términos de subsistemas de aplicación organizados en capas
  • Para llevar a cabo las clases y objetos en términos de componentes (archivos de código 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 través de los componentes de la aplicación. El proceso describe cómo reutilizar componentes existentes o implementar nuevos componentes con responsabilidades bien definidas, haciendo que el sistema sea más fácil de mantener y aumentar las posibilidades de reutilización.

Prueba de disciplina

Los fines de disciplina prueba son:

Comprobar la interacción entre los objetos
Comprobar la correcta integración 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 implementación de software
Asegúrese de que todos los defectos son corregidos, revisados y cerrados

El Rational Unified Process propone un enfoque iterativo, lo que significa que debería estar probando el proyecto en su totalidad. Esto le permite encontrar defectos tan pronto como sea posible, lo que reduce drásticamente 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 cómo a pasar la prueba de la planificación, diseño, implementación, ejecución y evaluación.

La disciplina Implementación

El propósito del despliegue es producir lanzamientos de productos exitosos y entregar el software a los usuarios finales. Abarca una amplia gama de actividades, incluyendo la producción de versiones de software externos, el envase de aplicaciones de software y de negocios, distribución de software, instalación de software y proporcionar ayuda y asistencia a los usuarios.

Aunque las actividades de despliegue se centran principalmente en torno a la transición, muchas de las actividades se deben incluir en las etapas anteriores para preparar la aplicación, al final de la fase de construcción. Los procesos ( “flujos de trabajo”) de “Implementación y Medio Ambiente” RUP contienen menos detalles que otros flujos de trabajo.

Tres Disciplinas Soporte / Servicio de la metodología 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 organización de desarrollo de software y herramientas que apoyarán 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. Más tarde, IBM producto Compositor Método Racional fue creado para ayudar a hacer este paso simple, ingenieros de proceso y los directores de proyectos podría más fácilmente personalizar el RUP para sus necesidades del proyecto.

Muchas de las variaciones posteriores de las regiones ultraperiféricas, incluidas OpenUP / Basic, el código abierto, versión ligera de RUP, se presentan ahora como procesos separados en su propio derecho, y atender a los diferentes tipos y tamaños de proyectos, tendencias y tecnologías de desarrollo de software.

Históricamente, 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.

Configuración de la disciplina y de la gestión

La disciplina de la gestión del cambio en el negocio con RUP abarca tres tratamientos específicos: configuración, solicitudes de cambio, y el estado y de medida.

La gestión de configuración: gestión de la configuración es responsable de la estructuración sistemática de productos. Los artefactos tales como documentos y modelos necesitan estar bajo el control de versiones y estos cambios deben ser visibles. También realiza un seguimiento de las dependencias entre los artefactos de manera que todos los artículos relacionados se actualizan cuando se realizan cambios

La gestión 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 medición de la gestión: las solicitudes de cambio tienen los estados: nuevo , conectado , aprobado , asignado y completa . La solicitud de cambio también tiene atributos como la causa raíz, o la naturaleza (como el incumplimiento y recuperación), prioridad, etc.

Estos estados y atributos se almacenan en la base de datos para producir informes útiles sobre el progreso del proyecto. Racional también tiene un producto para mantener las solicitudes de cambio llamados ClearQuest . Esta actividad tiene procedimientos a seguir

Proyecto de Gestión de la disciplina

La planificación 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 número de alta granularidad o planes de iteración que describe los pasos iterativos.

Este curso se centra principalmente en los aspectos importantes de un proceso de desarrollo iterativo: La gestión de riesgos; La planificación de un proyecto iterativo a través del ciclo de vida y para una iteración en particular; Y el proceso de seguimiento de un proyecto iterativo, la métrica. Sin embargo, esta disciplina de RUP no pretende cubrir todos los aspectos de la gestión de proyectos.

Por ejemplo, no cubre cuestiones tales como:

  • Gestión de personas: contratación, formación, etc.
  • Presupuesto general: definición, asignación, etc.
  • Gestión de contratos: con los proveedores, clientes, etc.

Principios y las mejores prácticas de la metodología RUP

La metodología RUP se basa en un conjunto de principios de desarrollo de software y las mejores prácticas, por ejemplo:

  1. Desarrollo de software iterativo
  2. La gestión de requisitos
  3. El uso de una arquitectura basada en componentes
  4. Software de modelado visual
  5. La verificación 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 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.

Los cambios permiten que el proyecto para estar constantemente refinada, y la señal a los elementos del proyecto de alto riesgo como las tareas de mayor prioridad. Idealmente, al final de cada iteración habrá una versión ejecutable , lo que ayuda a reducir el riesgo de configuración de diseño, 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 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

El uso de iteraciones, un proyecto tendrá un plan general, así como varios planes de iteración. La participación 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 también promueve una comparación constante entre las necesidades y el desarrollo de la organización a los conflictos que surjan.

La 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:

La corrección de los requisitos genera la corrección del producto, por lo que se satisfacen las necesidades de los usuarios.
se incluirán las características requeridas, lo que reduce el costo de los acontecimientos posteriores.

RUP sugiere que la administración de requerimientos tiene que seguir las actividades:

  • 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

El 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 pocos 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 de su código y representarla 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 está 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 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 métodos para controlar, seguir y supervisar estos cambios. RUP 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.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *