Transcript Ingeniería de Software I Proceso Racional Unificado (RUP)

Ingeniería de Software I
Proceso Racional Unificado (RUP)
¿Qué es el RUP?

RUP es un proceso de desarrollo de software:


Forma disciplinada de asignar tareas y responsabilidades
en una empresa de desarrollo (quién hace qué, cuándo y
cómo).
Objetivos:

Asegurar la producción de software de calidad dentro de
plazos
y presupuestos predecibles. Dirigido por casos
de uso, centrado en la arquitectura, iterativo (miniproyectos) e incremental (versiones).
Beneficios del RUP

Aumenta la productividad de los
desarrolladores mediante acceso a:

Base de conocimiento, plantillas y herramientas.

Se centra en la producción y mantenimiento
de modelos del sistema más que en producir
documentos.

RUP es una guía de cómo usar UML de la
forma más efectiva.
Fases y Flujos de Trabajo
Fase de Inicio

Su objetivo
 Lo que deberá hacer el producto
 Reducción de los peores riesgos
 Preparación para el análisis del negocio inicial
Fase de Inicio

Un documento de visión general:




Caso de negocio:






Requerimientos generales del proyecto
Características principales
Restricciones
Contexto
Criterios de éxito
Pronóstico financiero
Identificación inicial de riesgos.
Plan de proyecto.
Uno o más prototipos.
Fase de Inicio


Modelo inicial de casos de uso (10% a 20 %
listos).
Glosario.
Fase de Elaboración

Objetivos:





Obtener la línea base de la arquitectura
Capturar la mayoría de los requisitos
Reducir los peores riesgos
Estimar costos y fechas
Planificar la fase de construcción con algún
detalle
Fase de Elaboración







Modelo de casos de uso (80% completo) con
descripciones detalladas.
Otros requerimientos no funcionales o no asociados
a casos de uso.
Descripción de la Arquitectura del Software.
Un prototipo ejecutable de la arquitectura.
Lista revisada de riesgos y del caso de negocio.
Plan de desarrollo para el resto del proyecto.
Un manual de usuario preliminar.
Fase de Construcción

Objetivos:


El desarrollo del sistema
Garantía de que el producto puede comenzar su
transición a los clientes
Fase de Construcción

El producto de software integrado y corriendo
en la plataforma adecuada.

Manuales de usuario.

Una descripción del “release” actual.
Fase de Transición

Objetivos:


Garantizar que se tiene el producto preparado
para su entrega (versión del producto)
Entrenar a los usuarios a utilizar el sistema.
Fase de Transición

Pruebas Beta para validar el producto con las
expectativas del cliente

Ejecución paralela con sistemas antiguos

Conversión de datos

Entrenamiento de usuarios

Distribuir el producto
Fases e Hitos (Milestones)
Inicio
Elaboración
Objetivos
(Visión)
Construción
Arquitectura
Transición
Capacidad
Operacional
Inicial
tiempo
Hito: Punto de terminación de la
iteración cuando se toma alguna
decisión o evaluación importante
Release
del Producto
Proceso de Ingeniería de Software
Workflows (Disciplinas)
Proceso de Ingeniería de Software
Workflows (Disciplinas)
Workflows Primarios
• Business Modeling (Modado del Negocio)
• Requirements (Requisitos)
• Analysis & Design (Análisis y Diseño)
• Implementation (Implementación)
• Test (Pruebas)
• Deployment (Despliegue)
Workflows de Apoyo
• Environment (Entorno)
• Project Management (Gestión del Proyecto)
• Configuration & Change Management (Gestión de
Configuración y Cambios)
Artefactos
 Resultado parcial o final que es producido y
usado durante el proyecto. Son las entradas y
salidas de las actividades
 Un artefacto puede ser un documento, un modelo
o un elemento de modelo
 Conjuntos de Artefactos
 Business Modeling Set
 Requirements Set
 Analysis & Design Set
 Implementation Set
 Test Set
 Deployment Set
 Project Management Set
 Configuration & Change Management Set
 Environment Set
Proceso Iterativo e Incremental
 El ciclo de vida iterativo se basa en la
evolución de prototipos ejecutables que se
muestran a los usuarios y clientes (miniproyectos)
 En el ciclo de vida iterativo a cada iteración
se reproduce el ciclo de vida en cascada a
menor escala
 Los objetivos de una iteración se establecen
en función de la evaluación de las iteraciones
precedentes
Proceso Iterativo e Incremental
 Las actividades se encadenan en una mini-cascada
con un alcance limitado por los objetivos de la
iteración
Req.
Análisis
Diseño
Imple.
n veces
Pruebas e
Integración
Proceso Iterativo e Incremental
 Cada iteración comprende:
 Planificar la iteración (estudio de riesgos)
 Análisis de los Casos de Uso y escenarios
 Diseño de opciones arquitectónicas
 Codificación y pruebas. La integración del nuevo
código con el existente de iteraciones anteriores
se hace gradualmente durante la construcción
 Evaluación de la entrega ejecutable (evaluación
del prototipo en función de las pruebas y de los
criterios definidos)
 Preparación de la entrega (documentación e
instalación del prototipo)
Las iteraciones sobre el ciclo de vida

Cada una de las cuatro fases termina con
hito principal.
Plan de iteraciones

El número de iteraciones planeado para cada
fase
depende,
básicamente
de
la
complejidad del sistema propuesto. Un
proyecto simple puede realizarse con una
sola iteración por fase. Un proyecto mas
complejo podría comprender el siguiente
numero de iteraciones.
Plan de iteraciones

Fase de Inicio: una iteración, principalmente
dedicada a definir el ámbito del sistema

Fase de elaboración: dos iteraciones, la
primera para esbozar la arquitectura y la
segunda para completar la línea base de la
arquitectura
Plan de iteraciones

Fase de construcción: dos iteraciones, para
asegurar que los incrementos resultantes
funcionan satisfactoriamente

Fase de transición: una iteración
Proceso Iterativo e Incremental
Enfoque
Secuencial
Enfoque
Iterativo e
Incremental
Iteraciones

Cada fase consiste en las iteraciones del desarrollo
en las cuales un subconjunto del sistema se
desarrolla. En general, estas iteraciones:




Reducen los riesgos técnicos;
Proporcionan versiones tempranas;
Permiten mayor flexibilidad para el lanzamiento de cada
característica; y
Permiten controlar los cambios con respecto al alcance de
manera efectiva con las iteraciones durante los ciclos.
Proceso Centrado en la Arquitectura



Arquitectura de un sistema es la organización o
estructura de sus partes más relevantes
Un arquitectura ejecutable es una implementación
parcial del sistema, construida para demostrar algunas
funciones y propiedades
RUP establece refinamientos sucesivos de una
arquitectura ejecutable, construida como un prototipo
evolutivo
Inception
Elaboration
Construction
Architecture
Transition
Fases, Base Line, Versión, Release
ciclo de desarrollo
base line
(release asociada
a un hito)
versión
(subconjunto de
artefactos
estable
y ejecutable)
ciclo de evolución
release
(producto al final de
una iteración, lanzado
para su puesta en producción)
Base Line

Conjunto de artefactos revisados y aprobados que
constituyen una base convenida para la evolución y
desarrollo adicional y que se puede cambiar
solamente a través de la administración de cambios.

Asegurarse qué subsistemas, cuándo alcanzan un
nivel especifico de la madurez, son la línea base
para que esté disponible para el release
(“liberación), o la reutilización en iteraciones
subsecuentes del proyecto y/o otros proyectos.
Base Line

Se considera como candidato para una Línea
Base el conjunto de archivos y directorios
bajo
control
de
versión
que
son
desarrollados, integrados y puestos juntos en
un release.

Una línea base se crea al final de cada
iteración
Versiones

Identifican el estado de un elemento de
configuración o una configuración en un
punto definido en el tiempo

Conjunto
de
artefactos
relativamente
completo y consistente –que incluye
posiblemente una construcción- entregado a
un usuario interno o externo;
Versiones

La mayoría de los programas grandes se
desarrollan en release evolutivos. Un release podría
estar en uso del cliente, mientras que otro está en
prueba, y el tercero todavía está en el desarrollo. Si
se encuentran problemas en cualquiera de las
versiones, los arreglos necesitan ser propagados
entre ellas. La confusión puede acrecentarse
conduciendo a arreglos costosos y retrabajo a
menos de que los cambios sean cuidadosamente
controlados y supervisados.
Release

Es una versión que se ha puesto disponible a
los usuarios.
La frecuencia y la formalidad de los releases
son
descritos en el plan del CM
(Configuration Management ). El grado de la
formalidad es claramente mucho más alto
para un producto que es liberado a un
cliente, que el que es generado para la
estructura o la revisión siguiente de la
iteración.
Release

Regularmente está asociado a un baseline
de una configuración
Esfuerzo y dedicación por Fases en RUP
Inicio
Elaboración
Esfuerzo
5%
20 %
65 %
10%
Tiempo
Dedicado
10 %
30 %
50 %
10%
Construcción Transición
Distribución de Recursos por Fases en RUP
Roles: Analista de Sistemas
El papel del analista de sistemas conduce y coordina la captura de requisitos y el
modelado de casos de uso que definiendo la funcionalidad del sistema y delimitando el
sistema.
Roles: Diseñador

El
diseñador
define
las
responsabilidades,
operaciones, atributos y relaciones entre las clases y
determina cómo éstas deben ajustarse a el ambiente
de implantación. Además el diseñador puede tener la
responsabilidad de uno o más paquetes de diseño o
diseño de susbsistemas.
Roles: Diseñador de pruebas

El Diseñador de pruebas es el responsable de definir los
métodos de prueba y asegurarse del éxito de su
implementación. Debe identificar las técnicas apropiadas,
herramientas y guías para implementar las pruebas requeridas, y
brindar dirección en los requisitos correspondientes al esfuerzo
de las pruebas.
Roles: Programador (Implementador)

El
programador
es
responsable de
desarrollar y probar los componentes, de
acuerdo a los estándares adoptados para el
proyecto, y la integración de los subsistemas.
Roles: Integrador

Los desarrolladores entregan sus componentes probados en un
espacio de trabajo de la integración, mientras que los integradores los
combinan para producir una estructura. Un integrador es también
responsable de planear la integración, que ocurre en los niveles del
subsistema y de sistema, con cada uno teniendo un espacio de
trabajo separado de la integración. Los componentes probados se
entregan del espacio de trabajo privado del desarrollo de un ejecutor
en un espacio de trabajo de la integración del subsistema,
Roles: Administrador de proyecto

El Administrador de Proyecto asigna
recursos, asigna prioridades, coordina
interacciones con los clientes y usuarios, y
generalmente mantiene al equipo de
proyecto centrado en la meta. Además
establece un conjunto de prácticas que
aseguran la integridad y calidad de los
artefactos del proyecto.
Roles: Administrador de proyecto
Roles: Administrador de la Configuración

El Administrador de la Configuración proporciona toda la
infraestructura y el ambiente la administración
de la
configuración (CM) al equipo del desarrollo de producto. La
función del CM apoya la actividad del desarrollo de producto de
modo que los desarrolladores y los integradores tengan espacios
de trabajo apropiados para construir y para probar su trabajo, y
de modo que todos los artefactos estén disponibles para la
inclusión en la unidad del despliegue según lo requerido. El
encargado de la configuración también tiene que asegurarse de
que el ambiente del CM facilite la revisión del producto, y las
actividades que siguen del cambio y del defecto. El encargado
de la configuración es también responsable de escribir el plan
del CM y de dar a conocer la estadística del progreso basada en
peticiones del cambio.
Roles: Administrador de la Configuración
Referencias



El Proceso Unificado de Desarrollo de Software, Ivar
Jacobson, Grady Booch, James Rumbaugh
RUP 2001
UML y Patrones, Craig Larman