Inenieria de Software I – Ingeniería de Sistemas

Rational Unified Process (RUP)

Ing. Johnny Rosas Callaú

  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
¿Qué es software.
RUP?  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
 Los casos de uso son los artefactos primarios para
establecer el comportamiento deseado del sistema
 Centrado en la Arquitectura
 La arquitectura es utilizada para conceptualizar, construir,
administrar y evolucionar el sistema en desarrollo
 Iterativo e Incremental
 Maneja una serie de entregas ejecutables
 Integra continuamente la arquitectura para producir nuevas
versiones mejoradas
 Características (2)

 Conceptualmente amplio y diverso

 Enfoque orientado a objetos
 En evolución continua
 Adaptable
 Repetible
 Permite mediciones
 Estimación de costos y tiempo, nivel de avance,
etc.
Conceptos
Ciclo de vida
Diagrama General de RUP
 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
En la intermedios.
representación Eje vertical: representa las
gráfica del disciplinas que agrupan
actividades por su
Modelo… naturaleza. Aspecto
estático del proceso a
través de componentes,
disciplinas, actividades,
flujos de trabajo, artefactos
y roles.
 En cuanto a tiempo el ciclo
de vida de RUP se
descompone en 4 FASES
secuenciales, cada cual
concluye con un producto
intermedio.
Ciclo de Vida Al terminar cada fase se
realiza una evaluación para
de RUP 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.
 Fases de Ciclo de Vida

Inicio Elaboración Construcción Transición

Esfuerzo 5% 20% 65% 10%

Tiempo 10% 30% 50% 10%

  El objetivo general de esta fase
es establecer un acuerdo entre
todos los interesados acerca de
los objetivos del proyecto.
proyecto
 Es significativamente importante
para el desarrollo de nuevo
software, ya que se asegura de
Inicio identificar los riesgos
relacionados con el negocio y
(Inception) requerimientos.
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.
 El objetivo en esta fase es
establecer la
arquitectura base del
sistema para proveer bases
estables para el esfuerzo
de diseño e
Elaboració implementación en la
siguiente fase.
n La arquitectura debe
abarcar todas las
consideraciones de mayor
importancia de los
requerimientos y una
evaluación del riesgo.
  El objetivo de la fase de
construcción es clarificar los
requerimientos faltantes y
completar el desarrollo del
sistema basados en la
arquitectura base.
Construcció  Vista de cierta forma esta fase es
n 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.
  Esta fase se enfoca en
asegurar que el software
esté disponible para sus
usuarios.
usuarios
 Se puede subdividir en varias
iteraciones, además incluye
pruebas del producto para
poder hacer el entregable del
mismo, así como realizar
Transición 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.
 Una disciplina es una
colección de actividades
relacionadas con un área
de atención dentro de
todo el proyecto.
Disciplina El grupo de actividades
s que se encuentran dentro
de una disciplina
principalmente son una
ayuda para entender el
proyecto.
 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,
Disciplinas Transición, Configuración
y Administración del
Cambio, Administración
de Proyectos y Ambiente.
 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
Modelado de participantes tengan un entendimiento
Negocios 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.
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.
Requerimiento
Definir los límites (o delimitar) del sistema.
 Proveer uns 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.
 El propósito del Análisis y
Diseño es:
Transformar los
requerimientos a diseños
del sistema.
Desarrollar una
Análisis y arquitectura robusta para el
sistema.
Diseño
Adaptar el diseño para
hacerlo corresponder con el
ambiente de
implementación y ajustarla
para un desempeño
esperado.
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
Implementació
elementos (archivos fuente, binarios, ejecutables y otros)
 Probar los componentes
n 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.
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.
Pruebas
 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.
  Esta disciplina describe las
actividades asociadas con el
aseguramiento de la entrega y
disponibilidad del producto de
software hacia el usuario
final.
Transición
 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.
 Consiste en controlar los cambios y mantener la integridad de
los productos que incluye el proyecto.
 Incluye:
Administració
 Identificar los elementos configurables.
n los
 Restringir y cambios en los elementos configurables.
Configuración
Auditar los cambios hechos a estos elementos.
 Definir y mantener las configuraciones de estos elementos.
del Cambio
 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.
 El propósito de la
Administración de
Proyectos es:
Proveer un marco de
trabajo para administrar los
proyectos intensivos de
software.
Administració
Proveer guías prácticas para
n de Proyectos la planeación, soporte,
ejecución y monitoreo de
proyectos.
Proveer un marco de
trabajo para la
administración del riesgo.
  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.
Ambiente  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.
 Disciplinas
 Workflow
 Detalles del
workflow
 Actividades
 Artefactos
 Guías de
aplicación
 Roles
 Definen el comportamiento y
responsabilidades de individuos o grupos de
individuos
 Un individuo puede jugar más de un rol
 Son descripciones abstractas de
 Conjuntos de actividades realizadas
 Responsabilidad sobre artefactos
 Ejemplos de roles
 Software Architect
 Architecture Reviewer
 Actividades
Una actividad es algo que un rol hace y que
provee un resultado de interés en el contexto del
proyecto.
Es una unidad de trabajo que individuos jugando
cierto rol pueden ser llamados a realizar.
Son utilizadas para detallar los workflows.
Toman artefactos como entrada y producen
artefactos (o nuevas versiones) como salida.
 Artefactos
Unidades de
información
creadas,
producidas,
cambiadas o
utilizadas en el
proceso de
desarrollo.
 ¿Cuándo usar RUP?
Alta complejidad técnica
- embebidos, tiempo real, distribuidos, tolerancia a fallas
- alta performance
- personalizado, sin precedentes, re-ingeniería arquitectónica

Mayor necesidad de seguir

un proceso definido

Baja complejidad gerencial Alta complejidad gerencial

- pequeña escala - gran escala
- informal - contractual
- pocos stakeholders - muchos stakeholders

Baja complejidad técnica

- 4GL, basado en componentes
- re-ingeniería de aplicaciones
¿Cuándo usar RUP? (2)
 RUP puede utilizarse
 En proyectos de nuevos productos de software
 En ciclos de desarrollo subsecuentes
 Consideraciones que alteran cuándo y cómo
usar partes de RUP
 El ciclo de vida del proyecto
 Los objetivos del negocio, la visión, el alcance y
los riesgos
 El tamaño del esfuerzo de desarrollo
 Conclusiones
 Es un modelo de proceso de desarrollo de
software
 Es una base para procesos particulares
 El objetivo es asegurar el desarrollo
 De productos de software de alta calidad
 Que satisfagan los requerimientos
 En tiempo y presupuesto predecible
 Permite un vocabulario común entre equipos
de desarrollo