Modelo RUP

¿Qué es RUP?

   Es un proceso de ingeniería de software, que hace una propuesta orientada por disciplinas para lograr las tareas y responsabilidades de una organización que desarrolla software.

    Su meta principal es asegurar la producción de software de alta calidad que cumpla con las necesidades de los usuarios, con una planeación y presupuesto predecible.

¿Para quién es RUP?

Diseñado para:

–Profesionales en el desarrollo de software

–Interesados en productos de software

–Profesionales en la ingeniería y administración de procesos de software

•Estos participantes se involucran con RUP cumpliendo roles

¿Por qué usar RUP?

Porque:

–Provee un entorno de proceso de desarrollo configurable, basado en estándares

–Permite tener claro y accesible el proceso de desarrollo que se sigue

–Permite ser configurado a las necesidades de la organización y del proyecto

–Provee a cada participante con la parte del proceso que le compete directamente, filtrando el resto.

Características

•Dirigido por Casos de Uso

•Centrado en la Arquitectura

•Iterativo e Incremental

•Conceptualmente amplio y diverso

•Enfoque orientado a objetos

•En evolución continua

•Adaptable

•Repetible

•Permite mediciones

Ciclo de vida

                            

Ciclo de Vida de RUP

•En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 FASES secuenciales, cada cual concluye con un producto 

intermedio.

•Al terminar cada fase se realiza una evaluación para determinar si se ha cumplido o no con los objetivos de la misma. 

•Las fases son: Inicio (Inception), Elaboración, Construcción y Transición.

Diagrama General de RUP

    En la representación gráfica del Modelo…

•          Eje horizontal: representa el tiempo y muestra los aspectos del ciclo de vida del proceso. Es el aspecto dinámico del proceso a través de las fases, iteraciones y productos intermedios.

•          Eje vertical: representa las disciplinas que agrupan actividades por su naturaleza. Aspecto estático del proceso a través de componentes, disciplinas, actividades, flujos de trabajo, artefactos y roles.

Fases de Ciclo de Vida

Inicio (Inception)

•         El objetivo general de esta fase es establecer un acuerdo entre todos los interesados acerca de los objetivos del proyecto.

•         Es significativamente importante para el desarrollo de nuevo software, ya que se asegura de identificar los riesgos relacionados con el negocio y requerimientos.

•         Para proyectos de mejora de software existente, esta fase es más breve y se centra en asegurar la viabilidad de desarrollar el proyecto.

Elaboración

•         El objetivo en esta fase es establecer la arquitectura base del sistema para proveer bases estables para el esfuerzo de diseño e implementación en la siguiente fase.

•         La arquitectura debe abarcar todas las consideraciones de mayor importancia de los requerimientos y una evaluación del riesgo.

Construcción

•         El objetivo de la fase de construcción es clarificar los requerimientos faltantes y completar el desarrollo del sistema basados en la arquitectura base.

•         Vista de cierta forma esta fase es un proceso de manufactura, en el cual el énfasis se torna hacia la administración de recursos y control de la operaciones para optimizar costos, tiempo y calidad.

Transición

•         Esta fase se enfoca en asegurar que el software esté disponible para sus usuarios.

•         Se puede subdividir en varias interacciones, además incluye pruebas del producto para poder hacer el entregable del mismo, así como realizar ajuste menores de acuerdo a ajuste menores propuestos por el usuario.

•         En este punto, la retroalimentación de los usuarios se centra en depurar el producto, configuraciones, instalación y aspectos sobre utilización.

Disciplinas

•         Una disciplina es una colección de actividades relacionadas con un área de atención dentro de todo el proyecto.

•         El grupo de actividades que se encuentran dentro de una disciplina principalmente son una ayuda para entender el proyecto desde la perspectiva clásica de cascada.

•         Disciplinas

•         Son un conjunto de actividades relacionadas con un área especifica dentro del proyecto.

•         Están inspiradas en las etapas de un proceso de desarrollo en cascada

•         Es una secuencia parcialmente ordenada de actividades que son realizadas para lograr un resultado particular, representado en un conjunto de artefactos.

•         Las disciplinas son:

–       Modelado de Negocios, Requerimientos, Análisis y Diseño, Implementación, Pruebas, Transición, Configuración y Administración del Cambio, Administración de Proyectos y Ambiente.

Modelado de Negocios

Los propósitos que tiene el Modelo de Negocios son:

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

Requerimientos

Esta disciplina tiene el propósito de:

•         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 un base para la planeación de los contenidos técnicos de las interacciones.

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

Análisis y Diseño

El propósito del Análisis y Diseño es:

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

Implementación

El propósito de la implementación es:

•         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 individuales en un sistema ejecutable.

La disciplina de implementación limita su alcance a como las clases individuales serán probadas. Las pruebas del sistema son descritas en futuras disciplinas.

Pruebas

Actúa como un proveedor de servicios a las otras disciplinas en muchos aspectos. 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.

Transición

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

Administración y Configuración del Cambio

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

Administración de Proyectos

El propósito de la Administración de Proyectos es:

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

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.