Saltar al contenido

13-Proceso Unificado Racional.

El Proceso Unificado Racional (RUP, Rational Unified Process) es un ejemplo de un modelo de proceso moderno que se derivó del trabajo sobre el UML y el proceso asociado de desarrollo de software unificado. Conjunta elementos de todos los modelos de proceso genéricos, ilustra la buena práctica en especificación y diseño y apoya la creación de prototipos y entrega incremental.

Características esenciales:

  •  Está dirigido por los Casos de Uso,
  •  Está centrado en la arquitectura,
  •  Es iterativo e incremental.

Fases discretas en el proceso de Software.

  1. Concepción/Iniciación: La meta de la fase es establecer un caso empresarial para el sistema. Deben identificarse todas las entidades externas (personas y sistemas) que interactuarán con el sistema y definirán dichas interacciones. Las especificaciones para el producto final y el alcance del proyecto. Luego se usa esta información para valorar la aportación del sistema hacia la empresa. Si esta aportación es menor, entonces el proyecto puede cancelarse después de esta fase.
  2. Elaboración Las metas de la fase de elaboración consisten en desarrollar la comprensión del problema de dominio, establecer un marco conceptual arquitectónico para el sistema, diseñar el plan del proyecto e identificar los riesgos clave del proyecto. Corresponde a la especificación de las particularidades del producto, a la planificación de las actividades, a la determinación de los recursos, al diseño, y a la validación de la arquitectura. Al completar esta fase, debe tenerse un modelo de requerimientos para el sistema, que podría ser una serie de casos de uso en UML, una descripción arquitectónica y un plan de desarrollo para el software.
  3. Construcción Esta fase incluye diseño, programación y pruebas del sistema. Partes del sistema se desarrollan en paralelo y se integran durante esta fase. Al completar ésta, debe tenerse un sistema de software funcionando y la documentación relacionada y lista para entregarse al usuario.
  4. Transición/Transferencia La fase final del RUP se interesa por el cambio del sistema desde la comunidad de desarrollo hacia la comunidad de usuarios, y por ponerlo a funcionar en un ambiente real. Corresponde a la fabricación del prototipo final, de la fabricación industrial, distribución entre usuarios, soporte técnico y mantenimiento. En el complemento de esta fase se debe tener un sistema de software documentado que funcione correctamente en su entorno operacional.
Proceso Unificado Racional 1
Proceso Unificado Racional 2

Propósitos del Modelado del Negocio:

  • Entender los problemas que la organización desea solucionar e identificar mejoras potenciales.
  • Medir el impacto del cambio organizacional.
  • Asegurar que clientes, usuarios finales, desarrolladores y los otros participantes tengan un entendimiento compartido del problema.
  • Derivar los requerimientos del sistema de software, necesarios para dar soporte a los objetivos de la organización.
  • Entender como el sistema a ser desarrollado entra dentro de la organización.

Requisitos o Requerimientos.

Propósito:

  • Establecer y mantener un acuerdo con los clientes y los otros interesados acerca de que debe hacer el sistema.
  • Proveer a los desarrolladores del sistema de un mejor entendimiento de los requerimientos del sistema.
  • Definir los límites (o delimitar ) del sistema.
  • Proveer una base para la planeación de los contenidos técnicos de las iteraciones.
  • Proveer una base para la estimación de costo y tiempo necesarios para desarrollar el sistema.
  • Definir una interfaz de usuario para el sistema, enfocada en las necesidades y objetivos del usuario.

Propósito del análisis y diseño:

  • Transformar los requerimientos a diseños del sistema.
  • Desarrollar una arquitectura robusta para el sistema.
  • Adaptar el diseño para hacerlo corresponder con el ambiente de implementación y ajustarla para un desempeño esperado.

Propósito de la Implementación:

  • Definir la organización del código, en términos de la implementación de los subsistemas organizados en capas.
  • Implementar el diseño de elementos en términos de los elementos (archivos fuente, binarios, ejecutables y otros)
  • Probar los componentes desarrollados como unidades.
  • Integrar los resultados de los implementadores individuales en un sistema ejecutable.

La disciplina de Pruebas actúa como un proveedor de servicios a las otras disciplinas en muchos aspectos. Pruebas se enfoca principalmente en la evaluación y aseguramiento de la calidad del producto desarrollado a través de las siguientes prácticas:

  • Encontrar fallas de calidad en el software y documentarlas.
  • Recomendar sobre la calidad percibida en el software.
  • Validar y probar las suposiciones hechas durante el diseño y la especificación de requerimientos de forma concreta.
  • Validar que el software trabaja como fue diseñado.
  • Validar que los requerimientos son implementados apropiadamente.

Liberación o despliegue:

♦ Esta disciplina describe las actividades asociadas con el aseguramiento de la entrega y disponibilidad del producto de software hacia el usuario final.
♦ Existe un énfasis en probar el software en el sitio de desarrollo, realización de pruebas beta del sistema antes de su entrega final al cliente.

Gestión del cambio y configuraciones.

Consiste en controlar los cambios y mantener la integridad de los productos que incluye el proyecto. Incluye:

  • Identificar los elementos configurables
  • Restringir los cambios en los elementos configurables
  • Auditar los cambios hechos a estos elementos
  • Definir y mantener las configuraciones de estos elementos.
  • Los métodos, procesos y herramientas usadas para proveer la administración y configuración del cambio pueden ser consideradas como el sistema de administración de la configuración.

Propósitos de la gestión del proyecto.

  • Proveer un marco de trabajo para administrar los proyectos intensivos de software.
  • Proveer guías prácticas para la planeación, soporte, ejecución y monitoreo de proyectos.
  • Proveer un marco de trabajo para la administración del riesgo.

Entorno o Ambiente:

  • Se enfoca en las actividades necesarias para configurar el proceso al proyecto.
  • Describe las actividades requeridas para desarrollar las líneas guías de apoyo al proyecto. El propósito de las actividades de ambiente es proveer a las organizaciones de desarrollo de software del ambiente necesario (herramientas y procesos) que den soporte al equipo de desarrollo.
No te olvides de compartir en...

Deja una respuesta

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