RUP-analisis-diseño

Rational Unified Process

Oswaldo E. Eusebio RojasUniversidad Garcilaso de la Vega

Temario

Introducción Concepto Vista Dinámica y Estática Características de RUP

Las seis mejores prácticas Disciplinas y Flujos de Trabajo Fases RUP y CMMI Conclusiones

¿Qué es un Proceso de Desarrollo de SW?

Requisitos nuevoso modificados

Sistema nuevoo modificado

Proceso de Desarrollo de Software

Define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo

No existe un proceso de software universal. Las características de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable

El Problema

•Si un proceso es utilizado, equipos funcionales diferentes normalmente utilizan procesos y lenguajes de modelación inconsistentes.

Requerimientos

Pruebas

Análisis

Diseño

•La mayoría de los proyectos de softwareutilizan procesos que no están biendefinidos. En su lugar los miembros del equipo (re)inventan sus propios procesos.

????

????

????

??

•Los procesos no están apropiadamente relacionados con herramientas, ó no están propiamente automatizados.

?Proceso Herramienta

Conceptos fundamentales

Proceso: Es un marco de trabajo común compuesto por

actividades de trabajo (conjuntos de tareas, hitos, productos y puntos de garantía de calidad) y actividades de protección (garantía de calidad, gestión de configuración y medición) (Pressman 2001).

Producto: Es el resultado previsto y consistente del proceso.

Conceptos fundamentales

Ciclo de vida del software: Es el conjunto de fases por las que pasa el

software, que abarcan desde su creación u origen, hasta su eliminación o liquidación formal.

Modelo de desarrollo: También denominado Modelo de Proceso. Estrategia de desarrollo basada en el ciclo de

vida, naturaleza del proyecto y metodología, que determina las características específicas del proceso (Pressman 2001).


“RUP es un marco de trabajo genérico que puede especializarse para una variedad de tipos de sistemas, diferentes áreas de aplicación, tipos de organizaciones y diferentes tamaños de proyectos”.

JACOBSON, Ivar; BOOCH, Grady y RUMBAUGH, James 2000 El proceso unificado de desarrollo de software, Addison Wesley

Noción de Proceso

Rol que puede ser

desempeñado por un

individuo o conjunto de

individuos en la organización de desarrollo

Trabajador/Quién?

Diseñador

Actividad/Cómo?

Describe una unidad de trabajo

que puede ser asignada a un trabajador.

Diseño deCasos de uso

Pieza de información que es producida,

modificada, ó utilizada por un proceso

Artefacto/Qué?

Paquete deCaso de Uso

Caso de Uso

responsable de


Creado por los 3 amigos: Grandy Booch (creador de “The Booch Method”), Ivar Jacobson e James Rumbag (creador de “Object Modeling Technique” = OMT)

Aparece por primera vez en Junio de 1998 con el nombre de Rational Unified Process 5.0 (RUP)

Fue puesto a disposición pública entre finales de 1998 e inicios de 1999.

Centrado en tres Puntos: Personas Procesos Herramientas y métodos

Evolución de RUP

Estructura de RUP

El proceso puede describirse en dos dimensiones, o a lo largo de dos ejes: El eje horizontal representa tiempo y muestra el

aspecto dinámico del proceso, expresado en términos de ciclos, fases, iteraciones, y metas.

El eje vertical representa el aspecto estático del proceso; como está descrito en términos de disciplinas: actividades, artefactos, trabajadores y flujos de trabajo.

El Ciclo de Vida del Software en RUP

Disciplina Diagrama

Requerimientos Diagramas de Casos de Uso

Análisis Refinamiento y documentación de los casos de usosDefinición preliminar de clases y Diagramas de Interacción (Secuencia y Colaboraciones)

Diseño EmpaquetamientoDiagramas de Interacción de diseño (Secuencia y Colaboraciones)Diagrama de Clases de diseño Modelo de Datos

Implementación Diagrama de ComponentesDiagrama de Despliegue

Relación entre Diagramas UML y Disciplinas de RUP

RUP Visión Estática En su visión estática, el modelo RUP está

compuesto por:Roles: analista de sistemas, diseñador,

diseñador de pruebas, roles de gestión y roles de administración.

Actividades: RUP determina el trabajo de cada rol a través de actividades. Cada actividad del proyecto debe tener un propósito claro, y se asigna a un rol específico. Las actividades pueden tener duración de horas o de algunos días; y son elementos base de planificación y progreso.


compuesto por:Artefactos: Son los elementos de entrada y

salida de las actividades. Son productos tangibles del proyecto. Las cosas que el proyecto produce o usa para componer el producto final (modelos, documentos, código, ejecutables…)

Flujos de trabajo: son el “pegamento”de los roles, actividades, artefactos y disciplinas, y constituyen la secuencia de actividades que producen resultados visibles.


compuesto por:Disciplinas: son “contenedores” empleados

para organizar las actividades del proceso. RUP comprende 6 disciplinas de proceso y 3 de soporte.Proceso: modelado del negocio, requisitos, análisis y diseño, implementación, pruebas y desarrollo.Soporte: gestión de proyecto, gestión de configuración y cambio, y entorno.

RUP Visión Dinámica En su visión dinámica, la visión de la estructura del ciclo de

vida RUP se basa en un desarrollo iterativo, jalonado por hitos para revisar el avance y planear la continuidad o los posibles cambios de rumbo.

Cuatro son las fases que dividen el ciclo de vida de un proyecto RUP: 1.- Inicio. Es la fase de la idea, de la visión inicial de

producto, su alcance. El esbozo de una arquitectura posible y las primeras estimaciones. Concluye con el “hito de objetivo”.

2.- Elaboración. Comprende la planificación de las actividades y del equipo necesario. La especificación de las necesidades y el diseño de la arquitectura. Termina con el “hito de Arquitectura”.

RUP Visión Dinámica

3.- Construcción. Desarrollo del producto hasta que se encuentra disponible para su entrega a los usuarios. Termina con el “hito del inicio de la capacidad operativa”.

4.- Transición. Traspaso del producto a los usuarios. Incluye: manufactura, envío, formación, asistencia y el mantenimiento hasta lograr la satisfacción de los usuarios. Termina con el “hito de entrega del producto”.

AdministraciónAmbiente

Modelación de Negocios

Implementación

Prueba

Análisis y Diseño

Iteración(es)Preliminar

Iter.#1

FasesDisciplinas de Procesos

Iteraciones

Disciplinas de Soporte

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Despliegue

Admin. Configuración

Requerimientos

Elaboración TransiciónInicio Construcción

Estática

RUP Visión Dinámica

Dinámica

Conformación del Equipo

ROLES TAREAS ASIGNADAS

Gestor del proyecto Establecer Condiciones de Trabajo

Analista del sistema Encontrar Actores y Casos de Uso Estructurar el Modelo de Casos de Uso

Arquitecto del sistema Priorizar los Casos de Uso Efectuar el Análisis Arquitectural Efectuar el Diseño Arquitectural Efectuar la Implementación Arquitectural

Especificador de casos de uso Detallar un Caso de Uso

Diseñador de interfaz de usuario Prototipar una Interfaz de Usuario

Ingeniero de casos de uso Analizar un Caso de Uso Diseñar un Caso de Uso

Conformación del Equipo

ROLES TAREAS ASIGNADAS

Ingeniero de componentes Analizar una Clase Analizar un Paquete Diseñar una Clase Diseñar un Subsistema Implementar un Subsistema Implementar una Clase Realizar una Prueba de Unidad Implementar una Prueba

Integrador del sistema Integrar el Sistema

Ingeniero de pruebas Planear las Pruebas Diseñar las Pruebas Evaluar las Pruebas

Verificador de integración Realizar una Prueba de Integración

Verificador del sistema Realizar las Pruebas del Sistema

Características de RUP

Dirigido por los Casos de Uso

Centrado en laArquitectura

Iterativo e Incremental

Dirigido por Casos de Uso

Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un resultado de valor a un usuario. Los casos de uso modelan los requerimientos funcionales del sistema.

Los casos de uso también guían el proceso de desarrollo (diseño, implementación y pruebas).

De este modo los casos de uso no solo inician el proceso de desarrollo sino que le proporcionan un hilo conductor, que avanza a través de una serie de flujos de trabajo.

Identificacion

AdministradorConsulta

<<extend>>

<<communicate>>

XOX

XOX

XOX

Modelo de análisis Modelo de diseño

Modelo de despliegue Modelo de implementación

Modelo de prueba

Especificado por Realizado por Distribuido por Implementado por

Verificado por

Dependencia entre los Casos de Uso y los demás modelos

Iterativo e incremental

Es práctico dividir el esfuerzo de desarrollo de un proyecto de software en partes mas pequeñas o mini proyectos. Cada mini proyecto es una iteración que resulta en un incremento.

Las iteraciones deben seleccionarse y ejecutarse de forma planificada. Esta selección se basa en dos cosas:

El conjunto de casos de uso que amplían funcionalidad

En los riesgos mas importantes que deben mitigarse

En cada iteración se identifica y especifica los casos de uso relevantes, se crea un diseño utilizando la arquitectura seleccionada como guía, para implementar dicho caso de uso.

Desarrollo “en cascada” tradicional retarda la reducción del Riesgo

RIESGO

T I E M P O

Test Subs.

Test. Sistema

Cod. & Test U.

Diseño

An. Requer.

Aplicando cascada iterativamente

Las primeras iteraciones reducen los principales riesgos Cada iteración produce una versión ejecutable, un

incremento adicional al sistema Cada iteración incluye integración y test

TC

DR

T I E M P O

Iteración 1 Iteración 2 Iteración 3

TC

DR

TC

DR

Centrado en la Arquitectura La arquitectura se describe mediante diferentes

vistas del sistema en construcción. Incluye aspectos estáticos y dinámicos.

La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando de los detalles de lado.

La arquitectura debe permitir el desarrollo de todos los casos de uso requeridos actualmente y a futuro, y los casos de uso deben encajar en la arquitectura.

Vistas de UML: Arquitectura 4 + 1

5 Vistas 9 Diagramas

Organización de Modelos

casos de uso

Diagramas de Casos de Uso

• Proporciona credibilidad en una etapa inicial del desarrollo del sistema

• Asegura una comprensión mutua de los requisitos

• Que se hayan capturado todos los requerimientos• Que los desarrolladores hayan entendido los

requerimientos

Usados Para VerificarUsados Para Verificar

Usados Para Comunicarse Usados Para Comunicarse con el Usuario Final y el Experto de Dominio con el Usuario Final y el Experto de Dominio


Sistema de Pub

Barmen

Vender Bebida

Informar Bodega

Registrar Venta

Sistema de Bodega

«extend»

«include»

incluye

caso de uso

actor

extiende

Límite


Diagramas de Clases

Usados para mostrar la Estructura Estática de un sistema computacional o una parte relevante del mundo real

Son los diagramas más frecuentemente usados. Y se les puede considerar con Tres Perspectivas posibles:

Conceptual – muestra las entidades del mundo realcon sus relaciones

Especificación – muestra la estructura del sistemao sus partes, destacando las interfaces

Implementación – el diseño del código fuente

Diagramas de Clases

Cliente

Bebida

Barmen

Pedido

Venta

- valor: Doble

+ ImprimirBoleta()

Bodega

Jugo Natural

Gaseosa

1

1..*

1

realiza

0..*

1tiene

1..*

1almacena

0..*

asociación

multiplicidad

atributooperación

herencia

clase

Diagramas de Clases

Diagramas de Secuencia

Usados para representar el comportamiento del sistema

Muestran colaboración a través de mensajes entre los objetos del sistema

Destacan: Mensajes enviados entre los objetos Orden secuencial entre los mensajes Un escenario concreto, sin condiciones

Útiles tanto en análisis (identificación de clases), como en diseño (especificación de componentes)


mensaje

objeto

línea de vida

{x N}

Pepe :Barmen

Interfaz Barmen

(from Use Case View)

Motor Venta


BD de Ventas


Frambuesa :Jugo Natural

(from Logical Model)

12345 :Venta

(from Logical Model)

Ingresar Datos Venta

Confirmar Venta

Ejecutar Venta

Crear Venta

Crear Bebida

Ingresar Venta

destrucción de objeto

creación de objeto

ciclos


Diagramas de Colaboración

• Usados para representar el comportamiento del sistema

• Muestran colaboración entre los objetos del sistema

• Destacan:– Mensajes enviados entre los objetos– Enlaces entre los objetos– Un escenario concreto, sin condiciones

• Útiles tanto en análisis (identificación de clases),como en diseño (especificación de componentes)


Pepe :Barmen

Bucarest :Sistema de

Bodega

Interfaz Barmen

Comunicador Bodega

Motor Venta

Interfaz Bodega

El cálculo dió la cantidad bajo la mínima permitida - hay que pedir bebida de la bodega

1 Vender Jugo Natural

1.1 Vender Jugo Natural

1.2 Calcular Cantidad Bebida

1.3 Pedir Bebida

1.4 Pedir Bebida

1.5 Pedir Bebida

enlace

objeto

mensaje


Diagramas de Actividades

• Usados para representar el comportamiento del sistema o negocio

• Muestran actividades y procesos

• Destacan:– Condiciones y flujos alternativos– Tareas y procesos concurentes– Responsabilidades sobre ciertas actividades

• Útiles en análisis de negocio para capturar procesos de alto nivel


Inicio

Fin

Barmen Ingresa Venta

Sistema Valida Cantidad Bebida

Candidad

<

Mínima

Permitida

Sistema Registra Venta

Pedir Bebida de BodegaVenta de Bebida

[si]

[no]

actividad

decisión

sincronización


Diagrama de Estados

• Usados para representar el comportamiento INTERNO de un objetoo de un módulo del sistema

• Muestran estados en los cuales un objeto se puede encontrar

• Destacan:– Estados – Transiciones y condiciones de las transiciones– Actividades realizadas

• Típicamente usados para describirciclo de vida de un objeto

Diagrama de Estados

Inicio

a Pedidos Cobrados

INGRESADO SERVIDO

COBRADO PERDIDO

CANCELADO

a Pedidos Anulados A Pedidos

Perdidos

Si el estado no se cámbia durante 1 día

servir

cancelar1 díacobrar

estado

transición

inicio

fin

Diagrama de Estados

Diagrama de Componentes

• Usados para mostrar los Módulos Físicosde software:– Los ejecutables y librerías dinámicas– Las páginas WEB y los scripts– Los módulos o funciones, etc.

• Sin embargo se usan más bien para capturar la Organización de los Componentes de Software (EXE, DLL, EJB, etc)

• Destacan Dependencias entre los Componentes


«executable»

TouchScreen

«DAO»

Venta

«Oracle»

BDPub

«EJB»

Bodeguero

«EJB»

Vendedor

VendedorRemote

BodegueroLocal

Barmen


Sistema de Bodega


dependencia

componente

interfaz


Diagrama de Distribución

• Usados Para Modelar las Relaciones entre el Software y el Hardware

• Mapeo de los Componentes de Softwarea los Nodos de Hardware

• Típicamente contienen elementos tales como– Servidores– Procesadores– Impresoras– Redes computacionales– Etc.


Serv idor Pub

Serv idor BodegaCliente TouchScreen

«executable»

:TouchScreen

«EJB»

:Vendedor

«DAO»

:Venta

«EJB»

:Bodeguero

Serv idor BD

«Oracle»

:BDPub

Barmen

(from Use Case View) Sistema de Bodega


nodo

enlace


Modelado del Nego-

cio Requisitos Análisis Diseño

Implemen-tación

Prueba Despliegue

Modelo del Negocio

X

Modelo del Dominio X X

Modelo de Casos de Uso X

Modelo de Análisis

X

Modelo de Diseño X

Modelo de Despliegue

X X

Modelo de Imple-mentación

X X

Modelo de Prueba

X X

Modelos y Flujos de Trabajo

Seis Mejores Prácticas

Seis “Mejores Prácticas”

Controlar Cambios

Administrar requerimientos

ArquitecturasBasadas en

Componentes

DesarrollarIterativamente

Verificar Calidad

ModelizarVisualmente

• El software moderno es complejo y novedoso. No es realista usar un modelo lineal de desarrollo como el de cascada.

• Un proceso iterativo permite una comprensión creciente de los requerimientos a la vez que se va haciendo crecer el sistema.

• RUP sigue un modelo iterativo que aborda las tareas más riesgosas primero.

• Con esto se logra reducir los riesgos del proyecto y tener un subsistema ejecutable tempranamente.

Desarrollo Iterativo

Desarrollo Iterativo

PlaneamientoPlaneamientoInicialInicial

PlaneamientoPlaneamiento

RequerimientoRequerimientoss

Análisis y DiseñoAnálisis y Diseño

ImplementaciónImplementación

PruebaPrueba

DistribuciónDistribución

EvaluaciónEvaluación

Ambiente deAmbiente deAdministraciónAdministración

Cada iteración resulta en un release ejecutable

• RUP describe cómo:

– Obtener los requerimientos

– Organizarlos

– Documentar requerimientos de funcionalidad y restricciones

– Rastrear y documentar decisiones

– Captar y comunicar requerimientos del negocio

• Los casos de uso y los escenarios indicados por el proceso han probado ser una buena forma de captar requerimientos y guiar el diseño, la implementación y las pruebas.

Administración de requerimientos

Req. 10 Aprobado Bajo Alta

Req. 13 Propuesto Medio Baja

Req. 40 Obligatorio Alto Alto

$$$

$$

$

Costo Esfuerzo

RiesgoStatus

Prioridad

Administración de requerimientos

Arquitecturas basadas en componentes

• El proceso se basa en diseñar tempranamente una arquitectura base ejecutable.

• La arquitectura debe ser:– Flexible– Fácil de modificar– Intuitivamente comprensible– Promueve la reutilización de componentes

• RUP apoya el desarrollo basado en componentes, tanto nuevos como preexistentes.

Arquitecturas basadas en componentes

Comprado

Existente

NuevoDatabaseDatabase CRMCRM

Funciones de cliente/productos

Mecanismos de interfaces

Funciones de licenciamiento

Cliente Producto Licencia

Modelamiento Visual

• Modelamiento visual de la estructura y el comportamiento de la arquitectura y los componentes.

• Bloques de construcción:– Permiten la comunicación en el equipo de

desarrollo– Permiten analizar la consistencia:

• entre las componentes• entre diseño e implementación

• UML es la base del modelamiento visual de RUP.

Diagramas de Casos de Uso Diagramas de Clases Diagramas de Estados Diagramas de Componentes Diagramas de Implementación

Código

Clases

Subsistemas

Modelización Visualeleva el nivel de abstracción

Modelamiento Visual

Verificación de la Calidad

La actividad fundamental de esta práctica es el testing

Evaluar continuamente la calidad de un sistema con respecto a funcionalidad, confiabilidad, performance

• El aseguramiento de la calidad es parte del proceso de desarrollo y no la responsabilidad de un grupo independiente.

Plan de actividades de aseguramiento de la calidad

Conjunto de actividades que serán ejecutadas para generar confianza en que el producto cumplirá con los requerimientos y el proceso es efectivo

Cliente

NecesidadesNecesidades

RequisitosRequisitos

Revisiones

Verificaciones

Validaciones

ProductoProducto

Verificación de la Calidad

• Los cambios son inevitables, pero es necesario evaluar si éstos son necesarios y rastrear su impacto.

• RUP indica como controlar, rastrear y monitorear los cambios dentro del proceso iterativo de desarrollo.

Las solicitudes de cambios formales facilitan la claridad de comunicación

La propagación del cambio es evaluable y controlable

Controlar, registrar y monitorear los cambios para posibilitar el desarrollo iterativo

Control de cambios

Control de cambios

Administración de configuración y cambios

Fallas reportadasFallas reportadas

Órdenes de TrabajoÓrdenes de Trabajo

Petición de nuevasPetición de nuevascaracterísticascaracterísticas

Petición de Petición de cambios y cambios y arreglo de arreglo de defectosdefectos

Petición de Petición de cambios y cambios y arreglo de arreglo de defectosdefectos

Administración Administración de de

configuraciónconfiguración

Administración Administración de de

configuraciónconfiguración

Calidad Calidad del del

productoproducto

Calidad Calidad del del

productoproducto

Disciplinas y Flujos de Trabajo

Disciplinas • Una disciplina es una colección de actividades

relacionadas vinculadas con un área específica del proyecto.

• Este agrupamiento de actividades en disciplinas es principalmente para facilitar la comprensión del proyecto desde la perspectiva tradicional del modelo en cascada.

Flujo de Trabajo• Un flujo de trabajo describe la secuencia en que

se realizan las actividades en una disciplina, quienes la realizan (trabajadores) y que artefactos producen..

1. Modelado del negocio: describe la estructura y la dinámica de la organización.

2. Requisitos: describe el método basado en casos de uso para extraer los requisitos.

3. Análisis y diseño: describe las diferentes vistas arquitectónicas.

4. Implementación: tiene en cuenta el desarrollo de software, la prueba de unidades y la integración.

5. Pruebas: describe los casos de pruebas, los procedimientos y las métricas para evaluación de defectos.

6. Despliegue: cubre la configuración del sistema entregable.

Disciplinas de Proceso

1. Gestión de configuraciones: controla los cambios y mantiene la integridad de los artefactos de un proyecto.

2. Gestión del Proyecto: describe varias estrategias de trabajo en un proceso iterativo.

3. Entorno: cubre la infraestructura necesaria para desarrollar un sistema.


Disciplinas y Flujos de Trabajo

Disciplinas de Proceso


Modelamiento de Negocio

Los objetivos son:Entender la estructura y la dinámica del negocio.Asegurar que los clientes, usuarios y desarrolladores

tengan un entendimiento común de la organización.Un Modelo de Casos de Uso del Negocio describe los

proceso de negocio de una empresa en términos de casos de uso del negocio y actores del negocio

que se corresponden con los procesos del negocio y los clientes respectivamente .

Modelamiento de Negocio – Flujo de Trabajo

Requerimientos

• Los desarrolladores y clientes deben acordar qué es lo que el sistema debe hacer:– Relevar requerimientos– Documentar funcionalidad y restricciones– Documentar decisiones– Identificar actores– Identificar casos de uso

• Los requerimientos no funcionales se incluyen en una especificación complementaria.

Requerimientos – Flujo de Trabajo

Objetivos:• Ejecutar las tareas y funciones descritas en los casos

de uso• Satisfacer todos los requerimientos• Flexible a cambiosEl diseño se centra en la noción de arquitecturaDiseñar y validar la arquitectura es una tarea esencial.El modelo de diseño consta de

• Clases estructuradas en paquetes• Diseños de subsistemas con interfaces

definidas (componentes)• Forma de colaboración entre las clases.

Análisis y Diseño

Análisis y Diseño – Flujo de Trabajo

Implementación

• Objetivo:

– Definir la organización del código– Implementar clases y objetos en forma de

componentes (fuente, ejecutables, etc.)– Probar las componentes desarrolladas– Integrar las componentes en un sistema

ejecutable

Implementación – Flujo de Trabajo

Test

• Objetivo:– Verificar la interacción entre los objetos– Verificar la integración apropiada de componentes– Verificar que se satisfacen los requerimientos– Identificar los defectos y corregirlos antes de la

instalación

• RUP describe como planear y ejecutar estas pruebas.• RUP propone probar los componentes desde el

principio: Confiabilidad, funcionalidad y performance.

Test – Flujo de Trabajo

Despliegue

• Producir un producto y hacerlo llegar a sus usuarios finales.

• Incluye varias actividades:– Producir un “release”– Empaquetar el software– Distribuir el software– Realizar pruebas beta– Instalar el software– Apoyar a los usuarios– Migración de datos

Despliegue – Flujo de Trabajo

Administración y Configuración de Cambios• Forma de controlar los artefactos producidos por las

personas que trabajan en el proyecto.

• Algunos problemas habituales:– Actualizaciones simultáneas– Múltiples versiones

• RUP da guías para:– Desarrollos en paralelo– Automatizar la construcción– Administrar defectos

Administración y Configuración de Cambios – Flujo de Trabajo

Administración del Proyecto

• Es el arte de balancear objetivos contrarios, manejar riesgos y producir software que satisface a clientes y usuarios.

• Existen pocos proyectos realmente exitosos.• RUP incluye:

– Un framework para manejo de proyectos de software

– Guías para planificación, provisión de personal, ejecución y monitoreo de planes

– Un framework para manejar riesgos

Administración del Proyecto – Flujo de Trabajo

Entorno

• Ambiente y herramientas de desarrollo que harán posible llevar a cabo el proyecto.

• RUP guía en la configuración de un ambiente de proceso apropiado a cada proyecto.

• Se debe seleccionar un conjunto de artefactos para el proyecto, esta elección se puede recoger en un documento breve llamado Marco de Desarrollo

Entorno

Requerimientos

El propósito fundamental del flujo de trabajo de los requisitos es guiar el desarrollo hacia el sistema correcto.

Hay diferentes puntos de partida para la captura de requisitos. En algunos casos comenzamos haciendo un modelo

del negocio o partimos de uno ya desarrollado. En otros casos el cliente puede ya haber desarrollado

una especificación completa de requisitos no basada en objetos, de la cual podemos partir.

Analista Arquitecto Especificador de Casos de uso

Diseñador de interface

Requerimientos - Workflow

Requerimientos

Trabajador Responsable de (artefacto)

Analista de sistemas Modelo de casos de uso

Actores

Glosario

Especificador de casos de uso Caso de uso

Diseñador de Interfaz de Usuario Prototipo de interfaz de usuario

Arquitecto Descripción de la arquitectura (vista del modelo de casos de uso)

Análisis

Durante el análisis, revisamos los requisitos que se describieron en la captura de requisitos, refinándolos y estructurándolos.

El objetivo de hacerlo es conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y que nos ayude a estructurar el sistema entero, incluyendo su arquitectura.

Análisis - WorkflowArquitecto Ing de Casos

de UsoIng de Componentes

Análisis


Arquitecto Modelo de Análisis

Descripción de la arquitectura

Ingeniero de Casos de Uso Realización de casos de usos - Análisis -

Ingeniero de Componentes Clases del Análisis

Paquete del análisis

Diseño

Durante el diseño modelamos el sistema y su arquitectura para que soporte los requisitos funcionales y no funcionales. Una entrada esencial al diseño es el modelo de análisis.

El diseño es el centro de atención al final de la fase de elaboración y comienzo de las iteraciones de construcción .

Diseño

Modelo de Análisis Modelo de Diseño

Modelo conceptual. Modelo físico (implementación)

Genérico respecto al diseño (aplicable a varios diseños)

Específico para una implementación

Tres estereotipos: entidad, control, interface.

Cualquier nro. de estereotipos físicos.

Menos formal. Mas formal.

Menos caro de desarrollar Más caro.

Diseño

Modelo de Análisis Modelo de Diseño

Menos capas. Más capas.

Dinámico (no muy centrado en la secuencia)

Dinámico (muy centrado en la secuencia)

Creado principalmente como trabajo manual

Creado fundamentalmente como "programación visual" en ing.de ida y vuelta.

Puede no mantenerse todo el ciclo de vida.

Debe ser mantenido todo el ciclo de vida.

Diseño - WorkflowArquitecto Ing de Casos

de UsoIng de Componentes

DiseñoTrabajador Responsable de (artefacto)

Arquitecto Modelo de diseño

Modelo de despliegue


Ingeniero de Casos de Uso Realización de casos de usos - Diseño -

Ingeniero de Componentes Clases del diseño

Subsistema de Diseño

Interfaz

Implementación Se inicia con el resultado del diseño y se implementa

el sistema en término de componentes, es decir, ficheros de código fuente, scripts, ficheros de código binario, ejecutables, y similares.

Es el centro durante las iteraciones de construcción. Aunque también se realiza durante:

La fase de elaboración, para crear la línea base ejecutable de la arquitectura

La fase de transición para tratar defectos tardíos.

Implementación


Arquitecto Modelo de implementación

Modelo de despliegue


Integrador de sistema Integración de sistema

Ingeniero de Componentes Componente

Implementación de subsistema

Interfaz

Implementación - WorkflowArquitecto Integrador del

SistemaIngeniero de

Componentes

Prueba Los objetivos de la prueba son:

Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de integración y las pruebas de sistema.

Diseñar e implementar pruebas creando: Casos de prueba (especifican qué probar),

Procedimientos de prueba (especifican cómo realizar las pruebas),

Componentes de prueba para automatizar las pruebas.

Realizar las pruebas.

Prueba


Diseñador de Pruebas Modelo de pruebas

Casos de Prueba

Procedimientos de prueba

Evaluación de pruebas

Plan de pruebas

Ingeniero de Componentes Componente de pruebas

Ingeniero de Pruebas de Integración

Defecto

Ingeniero de Pruebas de Sistema Defecto

Fase de Inicio Durante la fase de inicio se desarrolla la

descripción del producto final, y se presenta el análisis del negocio.

Esta fase responde las siguientes preguntas:• ¿Cuáles son las principales funciones del sistema para

los usuarios mas importantes?

• ¿Cómo podría ser la mejor arquitectura del sistema?

• ¿Cuál es el plan del proyecto y cuanto costará desarrollar el producto?

En esta fase se identifican y priorizan los riesgos mas importantes.

Fase de Inicio

Los objetivos son:• Poner en marcha el proyecto• Desarrollar el análisis del negocio hasta

justificar la puesta en marcha plan de proyecto

• Para ello• Esbozar una arquitectura• Mitigar los riesgos• Análisis inicial del negocio (coste, agenda,

recuperación de la inversión)

• Un documento de visión general:

– Requerimientos generales del proyecto

– Características principales

– Restricciones

• Modelo inicial de casos de uso (10% a 20 % listos).

• Glosario.

• Caso de negocio:

– Contexto

– Criterios de éxito

– Pronóstico financiero

• Identificación inicial de riesgos.

• Plan de proyecto.

• Uno o más prototipos.

Artefactos

Fase de Inicio

Inicio Elaboración Construcción Transición

Objetivos del Ciclo de Vida

• Las partes interesadas deben acordar el alcance y la estimación de tiempo y costo.

• Comprensión de los requerimientos plasmados en casos de uso.

Hito:

Fase de Inicio

Fase de Elaboración Durante la fase de elaboración se especifican

en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura.

Las iteraciones en la fase de elaboración:Establecen una firme comprensión del problema a

solucionar.Establece un plan detallado para las siguientes

iteraciones.Elimina los mayores riesgos.

El resultado de esta fase es la línea base de la arquitectura.

Fase de Elaboración Los objetivos son:

Recopilar la mayor parte de los requisitos definiéndolos como casos de uso

Establecer una arquitectura sólida para guiar las fases posteriores

Continuar la observación y control de los riesgos críticos

Completar el plan de proyecto• Para ello

• Se toman decisiones considerando la comprensión global del sistema: ámbito, requisitos funcionales y

no funcionales

• Modelo de casos de uso (80% completo) con descripciones detalladas.

• Otros requerimientos no funcio-nales 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 Elaboración

Artefactos:

• Condiciones de éxito de la elaboración:

– ¿Es estable la visión del producto?

– ¿Es estable la arquitectura?

– ¿Las pruebas de ejecución demuestran que los riesgos han sido abordados y resueltos?

– ¿Están de acuerdo con el plan todas las personas involucradas?

Concepción Elaboración Construcción Transición

Arquitectura de Ciclo de Vida

Hito:

Fase de Elaboración

• En esta fase todas las componentes restantes se desarrollan e incorporan al producto.

• Todo es probado en profundidad.• El énfasis está en la producción eficiente y no

ya en la creación intelectual.• Puede hacerse construcción en paralelo,

pero esto exige una planificación detallada y una arquitectura muy estable.

Fase de Construcción


Los objetivos son:Línea base de la arquitectura crece hasta convertirse

en el sistema completoRiesgos reducidos o rutinariosImplementación de los casos de usoPrototipo

• Para ello• A través de sucesivas iteraciones e incrementos

se desarrolla un producto software, listo para operar, éste es frecuentemente llamado versión beta

• El producto de software integrado y corriendo en la plataforma adecuada.

• Manuales de usuario.

• Una descripción del “release” actual.

Artefactos:


• Se obtiene un producto Beta que debe decidirse si puede ponerse en ejecución sin mayores riesgos.

• Condiciones de éxito:– ¿El producto está maduro y estable para instalarlo

en el ambiente del cliente?– ¿Están los interesados listos para recibirlo?


CapacidadOperacional

Hito:


Fase de Transición Los objetivos son:

Cumplir requisitosGestionar todos los aspectos de implantaciónPruebas de aceptación

• Para ello• Las iteraciones en esta fase continúan

agregando características al sw. • El equipo se encuentra ocupado en

corregir y extender la funcionalidad del sistema desarrollado en la fase anterior.

• El objetivo es traspasar el software desarrollado a la comunidad de usuarios.

• Una vez instalado surgirán nuevos elementos que implicarán nuevos desarrollos (ciclos).

• Incluye:– 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

Fase de Transición

• Condiciones de éxito:– ¿Se han alcanzado los objetivos fijados en la fase

de Inicio ?– ¿El usuario está satisfecho ?


Hito:

Fase de Transición

Producto

RUP y CMMI

Modelo CMMI

Capability Maturity Model Integration. Modelo para la mejora o evaluación de los

procesos de desarrollo y mantenimiento de sistemas y productos de software.

Desarrollado por el Instituto de Ingeniería del Software de la Universidad Carnegie Mellon (SEI), y publicado en su primera versión en enero de 2002.

Para los usuarios es difícil especificarlos en forma cuantitativa

CMMI se desarrolló para facilitar y simplificar la adopción de varios modelos de forma simultánea, y su contenido integra y da relevo a la evolución de sus predecesores: CMM-SW (CMM for Sofwtare) SE-CMM(Systems Engineering Capability Maturity

Model) IPD-CMM(Integrated Product Development)

Modelo CMMI

CMMI – Niveles de Madurez

NIVEL Descripción

1-Inicial Punto base. La organización tiene procesos ad-hoc o caóticos. El éxito se debe a personas heroícas.

2-Repetible La organización empieza a guardar información. Ya hay definiciones, pueden repetirse éxitos anteriores.

3-Definido Se conocen procesos estándares para desarrollar o mantener software. Hay prácticas de Ingeniería de Software y de Administración de procesos.

4-Administrado Se usan datos recolectados. Las decisiones están basadas en datos cuantitativos. Los procesos son medidos, hay retroalimentación.

5-Optimizado La organización se dedica a mejorar contínuamente. Se localizan debilidades y fortalezas.

CMMI Areas Clave de Proceso (KPAs)

NIVEL Áreas Clave de Proceso

1-Inicial

2-Repetible Gestión de Requisitos (REQM), Planificación de proyecto, Monitorización y control de Proyectos, Gestión y acuerdo de suministros, Medición y Análisis, Gestión de la calidad de procesos y productos, Gestión de la configuración

3-Definido Desarrollo de requisitos (RD), Solución técnica, Verificación, Validación, Integración de producto, Procesos orientados a la organización, Formación, Gestión Integrada de proyecto, Gestión de riesgos, Análisis y resolución de decisiones

4-Administrado Gestión cuantificada de proyectos, Rendimiento de los procesos de la organización

5-Optimizado Innovación y desarrollo

Análisis RUP – CMMI RUP es un proceso

que define quién debe hacer las cosas, qué debe hacerse, cómo y cuándo.

Dado su enfoque mantiene modelos en lugar de gran cantidad de documentación, utiliza un lenguaje concreto y bien definido (UML).

CMMI es un modelo estático que define áreas claves (PA) en las que se deben

llevar a cabo prácticas específicas o genéricas, por lo tanto el hecho de implementar RUP en el desarrollo de un proyecto implica que ciertas KPA de CMMI sean alcanzadas y otras no.

Áreas Clave de Proceso

Revisión

Gestión de Requisitos

RUP define claramente el proceso de administración de requerimientos y aporta herramientas como los casos de uso, es una de las bases de RUP

Planificación de proyecto

RUP habla de la planeación del proyecto de manera iterativa y del control de riesgos.

Monitorización y control de Proyectos

RUP define cómo debe ser el control del proyecto.

Gestión de la configuración

RUP es muy claro cuando se habla de administración de la configuración incluso es una de las mejores prácticas recomendada.

Análisis RUP – CMMI

Áreas Clave de Proceso

Revisión

Gestión y acuerdo de suministros

RUP no menciona nada sobre administración de acuerdos, es algo no considerado.

Medición y Análisis La medición y análisis no están contemplados detalladamente en RUP.

Gestión de la calidad de procesos y productos

En la etapa de transición se lleva a cabo la verificación de la calidad aunque no tan detallada como lo exige CMMI. La verificación de calidad del producto está bien definida pero la evaluación de calidad del proceso no está considerada.

Análisis RUP – CMMI

Conclusiones

La aplicación formal del Proceso Unificado supone: Desventajas:

Grandes esfuerzos en la construcción de modelos. Necesidad del soporte de herramientas

informáticas. Ventajas:

Disminuye el riesgo del error de análisis / diseño acumulado.

Aligera el esfuerzo en implementación. Proporciona la documentación del ciclo de vida en

el mismo proceso.

Conclusiones

El Proceso Unificado es flexible y se puede adaptar al grado de complejidad del modelo de proceso de desarrollo (descarte de algunos modelos o flujos).

El Proceso Unificado es abierto y permite la incorporación de enfoques y artefactos complementarios:

Patrones de diseño. Patrones de implementación. Combinación de varios modelos de proceso. Arquitecturas Dirigidas por Modelos (Model

Driven Architectures).

Conclusiones

1. Booch G., Rumbaugh J., Jacobson I. El Lenguaje Unificado de Modelado, Addison-Wesley, Madrid, 1999.

2. Bruegge B., Dutoit A.H. Ingeniería de Software Orientado a Objetos, Prentice Hall– Pearson educación, México, 2002.

3. Jacobson I., Booch G., Rumbaugh J. El Proceso Unificado de Desarrollo de Software, Addison-Wesley, Madrid, 2000.

4. Pressman R.S. Ingeniería del Software. Un enfoque práctico (5ª ed.) Mc Graw-Hill; New York , 2001.

5. Rumbaugh J., Jacobson I., Booch G. El Lenguaje Unificado de Modelado. Manual de Referencia, Addison-Wesley, Madrid, 2000.

6. Sommerville I. Ingeniería de software, 6ª edición, Prentice Hall – Pearson educación, México, 2002.

7. Stevens P., Pooley R. Utilización de UML en Ingeniería del Software con Objetos y Componentes, Addison-Wesley, Madrid, 2002.

Bibliografía

RUP-analisis-diseño

Documents

Transcript of RUP-analisis-diseño