miércoles, 20 de noviembre de 2013

RUP, EL PROCESO

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

Diagrama General de RUP


     En el eje horizontal se representa el tiempo y muestra los aspectos del ciclo de vida del proceso. Representa el aspecto dinámico del proceso a través de las fases, iteraciones y productos intermedios.

     El eje vertical representa las disciplinas que agrupan actividades por su naturaleza. Representa el aspecto estático del proceso a través de componentes, disciplinas, actividades, flujos de trabajo, artefactos y roles.

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  
  • Transición


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. Esta fase es significativamente primaria 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 que vale la pena y es posible, 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 todos 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 este disponible para sus usuarios. Esta fase se puede subdividir en varias iteraciones, 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.

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

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 de los implementadores 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

Esta disciplina 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.


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.

Ahora para poner a prueba lo que aprendiste... visita el siguiente link:

http://www.quia.com/hm/853040.html


Para finalizar sigue el siguiente link:

2 comentarios:

  1. Como siempre, muy completa y detallada la información, muy buen trabajo :D

    ResponderEliminar
  2. Es una metodologia agil de las mejores diria yo, muy buena informacion y detallada

    ResponderEliminar