III. RUP

MODULO III

3.1 Introducción

1

Análisis y Diseño de Sistemas de Información

INF-162

Facilitador: Miguel Cotaña 26 de Abril 2010

2

Rational Unified Process (RUP oProceso Racional Unificado),desarrollado por Rational SoftwareCorporation, es un proceso deingeniería de software que ofrece unenfoque disciplinado para asignartareas y responsabilidades dentro dela organización del desarrollo.

INTRODUCCION

3

RUP captura algunas de las mejoresprácticas de la industria para eldesarrollo de software las cuales sonpara desarrollar el software eniteraciones, administrarrequerimientos, usar arquitecturasbasadas en componentes, verificar lacalidad del software, controlar loscambios al software y modelar elsoftware visualmente usando UML.

4

Un artefacto es un pedazo deinformación que es creado,modificado o usado por un procesotal como un modelo, un caso de uso,un documento, código fuente o unarchivo ejecutable.

Son usados por los roles pararealizar nuevas actividades y son elresultado de esas actividades.

Artefacto (o qué)

5

Define las responsabilidades y elcomportamiento de una persona.

Las personas (actores) suelencorresponderse con trabajadores (oactores del negocio) en un negocio.

Cada rol (de un trabajador) define loque hace un trabajador en unproceso de negocio concreto.

Rol (quién)

6

Es una unidad de trabajo que seasigna a un rol.

Unidad tangible de trabajo realizadapor un trabajador en un flujo detrabajo, de forma que:

Implica una responsabilidad bien definida parael trabajador;

Produce un resultado bien definido (conjuntode artefactos) basado en una entrada biendefinida;

Representa una unidad de trabajo.

Actividad (cómo)

7

¿Cómo realizo una asignación deactividades?

RECURSO ROL ACTIVIDAD

Zorka Diseñador Diseño de objetos

Mary Autor de casos de uso Detallar un caso de

uso

Carlos Diseñador de casos de

uso

Diseñar un caso de

uso

Oscar Revisor de diseño Revisar el diseño

Melina Arquitecto Análisis de

arquitectura

Diseño de arquitectura

8

¿QUÉ tareas hacer?

Actividades

¿QUIÉN las hace?

Roles

¿CUÁNDO se hace?

Workflow

¿QUÉ generar?

Artefactos

9

Es una lista de actividades, roles yartefactos. Es una secuencia deactividades que producen un resultadode valor. Propósito:

Entender la estructura y dinámica de laorganización;

Entender y mejorar el objetoorganizacional;

Asegurar a clientes y usuarios uncomún entendimiento;

Derivar los requisitos.

Workflow (cuándo)

10

Forma disciplinada de asignar tareas yresponsabilidades (quién hace qué,cuándo y cómo).

Pretende implementar las mejoresprácticas en el Análisis y Diseño:

Desarrollo iterativo;

Administración de requisitos;

Uso de arquitectura basada encomponentes;

Control de cambios;

Modelado visual del software;

Verificación de la calidad del software.

Características

11

Guiado por casos de uso: los casosde uso son el instrumento para validarla arquitectura del software y extraerlos casos de prueba;

Centrado en la arquitectura: losmodelos son proyecciones del análisisy el diseño constituye la arquitecturadel producto a desarrollar;

Iterativo e incremental: seproducen versiones incrementales.

PRINCIPIOS DE RUP

12

Los sistemas se crean para darservicio a los usuarios:

qué requisitos se necesitan;

un caso de uso es una pieza deFUNCIONALIDAD de un sistemaque le proporciona a algúnUSUARIO un RESULTADO oVALOR.

Guiados por casos de uso

13

Todos juntos constituyen el modelo decasos de uso (MCU):

funcionalidad completa;

para todos los usuarios.

El desarrollo guiado por casos de uso:

capturan requisitos;

se especifican (analizan);

se diseñan;

se implementan;

se prueban.

14

Persona

Tomar Préstamo

: IU-1 : GestorLibro : Libro AyDSI:Libro

1: Introducir Código y Num_Socio

2: Aceptar

3: obtenerLibro(códigoLibro:String)

4: getCódigo()

Se repite hasta que seencuentre un libro

con el código queestamos buscando

elLibro

5: getCopias()

6: isCopiaPrestada()

3.- DISEÑO DEL CASO DE

USO

4.- IMPLEMENTACIÓN DEL CASO DE USO

5.- PRUEBA DEL CASO DE USO

2.- ANÁLISIS DEL CASO DE

USO

1.- CASO DE USO

Desarrollo guiado por

CASOS DE USO

15

La arquitectura de un sistemasoftware es un extracto de losmodelos del sistema

Extracto: vista de cada modelo

da una idea de qué forma se tiene elsistema completo.

Centrado en la arquitectura

16

17

1

: IU-1 :

G

r

o

:1:

2: 3:4()

: :

G

r

o

:1:

2:3: 4

()

Centrado en la ARQUITECTURA

VISTA DEL MODELO DE CASOS DE USOVISTA DEL MODELO DEL DOMINIO /

VISTA DEL DIAGRAMA DE CLASES

VISTA DEL MODELO DEL ANÁLISISVISTA DEL MODELO DEL DISEÑO

+ VISTAS DEL MODELO DE IMPLEMENTACIÓN Y PRUEBAS

SON VISTAS DE LOS MODELOS (NO MODELOS COMPLETOS).

SÓLO APARECEN LOS QUE CORRESPONDEN

A CASOS DE USOS CRÍTICOS

18

La descripción de la arquitectura es unextracto, un conjunto de vistas.Incluyen elementos arquitectónicossignificativos:

Casos de uso;

Subsistemas;

Interfaces;

Algunas clases y componentes;

Nodos;

Colaboraciones.

19

También incluye:

Aspectos de seguridad,distribución y concurrencia;

Descripción de la plataforma;

Sistemas heredados;

Software comercial;

Almacenamiento y recuperación deobjetos en una BD.

20

ITERATIVO

Se repiten VARIOS

MINIPROYECTOS

INCREMENTAL

Cada miniproyecto AMPLIA EL

PRODUCTO

Iterativo e incremental

21

Divide el producto en mini

proyectos;

Cada mini proyecto es una

iteración que resulta en un

incremento;

Las iteraciones hacen referencia

a pasos en el flujo de trabajo, y

los incrementos al crecimiento

del producto;

22

La selección de lo que se

implementará en una iteración se

basan en casos de uso de mayor

utilidad y los riesgos mas

importantes;

Una iteración es una secuencia

de actividades con un plan

establecido y un criterio de

evaluación.

23

24

El proceso puede describirse en dosdimensiones, o a lo largo de dos ejes:

El eje horizontal: representa tiempoy muestra el aspecto dinámico delproceso, expresado en términos deciclos, fases, iteraciones y metas.

El eje vertical: representa el aspectoestático del proceso; cómo estádescrito en términos de actividades,artefactos, trabajadores y workflow.

Estructura de RUP

25

26

El proceso de desarrollo de softwaredemanda un conjunto de conceptos,metodología y lenguaje propio,conocido esto como Ciclo de vida delsoftware, comprendiendo 4 fases:

Inicio (concepción);

Elaboración;

Construcción;

Transición.

1. FASES DE RUP

27

Se desarrolla una descripción delproducto final a partir de una buenaidea y se presenta el análisis denegocio para el producto.

La idea, la visión del producto, comose enmarca en el negocio, el alcancedel proyecto, se define el plan.

1.1 fase de INICIO

28

Los artefactos:Un documento con la visión delproyecto;El modelo de Casos de Uso con unalista de todos los Casos de Uso y losactores que puedan ser identificados;Un glosario inicial del proyecto;Un CU inicial de Negocio el cualincluye: contexto del negocio, criteriosde éxito y planificación financiera;Un estudio inicial de riesgos;Un plan del proyecto que muestre lasfases y las iteraciones.

29

Planificar las actividades necesarias ylos recursos requeridos, especificandolas características y el diseño de laarquitectura;

Se especifican en detalle la mayoríade los casos de uso del producto y sediseña la arquitectura del sistema;

Analizar el dominio del problema;

Establecer una buena arquitectura.

1.2 fase de ELABORACION

30

Artefactos:

Un modelo de Casos de Uso(completo en al menos un 80%),con todos los actores identificados ylas descripciones de CU;

Requerimientos adicionales: los nofuncionales o no asociados conningún caso de uso;

Descripción de la arquitectura delsoftware;

31

Prototipo ejecutable dearquitectura;

Una lista revisada de riesgos;

Plan del proyecto, incluyendoiteraciones y criterios deevaluación para cada iteración;

Manual preliminar de usuario.

32

Construir el producto, la arquitecturay los planes, hasta que el productoestá listo para ser enviado a lacomunidad de usuarios.

Con todos los casos de uso que la altagerencia y el equipo de desarrollo hanacordado para construir el productode esta versión.

1.3 fase de CONSTRUCCION

33

Artefactos:

El producto de softwareintegrado sobre la plataformaadecuada;

Los manuales de usuario;

Una descripción de la versiónactual.

34

Realizar la transición final delproducto a los usuarios, incluye:

Manufactura;

Envío;

Entrenamiento;

Corrección de defectos;

Soporte y;

Mantenimiento del producto.

hasta que el cliente esté satisfecho.

1.2 fase de TRANSICION

35

• El producto se encuentra en fasebeta

Un grupo reducido de usuariosexperimentados prueba elproducto e informa de los defectosy deficiencias y sugieren mejoras;

Los desarrolladores corrigen lasdeficiencias e incorporan algunasde las mejoras propuestas en unaversión para un grupo de usuariosmayor;

36

En esta fase se encuentranactividades como la venta,formación de los usuarios,ofrecimiento de ayuda en línea ycorrección de defectosdescubiertos tras la implantación.Los defectos: (1) los que justificanla aparición de una nueva versióndel sistema, (2) los que se puedendejar para la siguiente versión quese cree.