¿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
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.
Ciclo de vida
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.
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.
Fases de Ciclo de Vida
Inicio Elaboración Construcción Transición
Esfuerzo 5% 20% 65% 10%
Tiempo 10% 30% 50% 10%
Inicio (Inception)
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 identificar los
riesgos relacionados con el negocio y
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.
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.
usuarios
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.
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.
DISCIPLINAS
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 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 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.
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