MODULO IIMODULO II

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

INFINF--162162

II. RUP

2.1 Introducción

1Facilitador: Miguel Facilitador: Miguel CotañaCotaña 01 de Septiembre 2008

Rational Unified Process (RUP o

INTRODUCCIONINTRODUCCION

Rational Unified Process (RUP oProceso Racional Unificado),desarrollado por Rational SoftwareCorporation, es un proceso deingeniería de software que ofrece unenfoque disciplinado para asignar

2

enfoque disciplinado para asignartareas y responsabilidades dentro dela organización del desarrollo.

RUP captura algunas de las mejoresprácticas de la industria para elprácticas de la industria para eldesarrollo de software las cuales sonpara desarrollar el software eniteraciones, administrarrequerimientos, usar arquitecturasbasadas en componentes, verificar la

3

basadas en componentes, verificar lacalidad del software, controlar loscambios al software y modelar elsoftware visualmente usando UML.

Un artefacto es un pedazo de

Artefacto (o que)Artefacto (o que)

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.

4

archivo ejecutable.

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

Define las responsabilidades y el

Rol (quién)Rol (quién)

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 lo

5

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

Es una unidad de trabajo que seasigna a un rol.

Actividad (cómo)Actividad (cómo)

asigna a un rol.

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

Implica una responsabilidad bien definida parael trabajador;

6

el trabajador;

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

Representa una unidad de trabajo.

¿Cómo realizo una asignación deactividades?actividades?

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 Diseñar un caso de

7

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 arquitecturaDiseño de arquitectura

¿QUÉ tareas hacer?ActividadesActividades

¿QUIÉN las hace?Roles

¿CUÁNDO se hace?Workflow

8

Workflow

¿QUÉ generar?artefactos

Es una lista de actividades, roles yartefactos. Es una secuencia de

Workflow (cuándo)Workflow (cuándo)

artefactos. Es una secuencia deactividades que producen un resultadode valor. Propósito:

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

Entender y mejorar el objeto

9

Entender y mejorar el objetoorganizacional;

Asegurar a clientes y usuarios uncomún entendimiento;

Derivar los requisitos.

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

CaracterísticasCaracterísticas

cuándo y cómo).

Pretende implementar las mejoresprácticas en Ingeniería de Software:

Desarrollo iterativo;

Administración de requisitos;

10

Administración de requisitos;

Uso de arquitectura basada encomponentes;

Control de cambios;

Modelado visual del software;

Verificación de la calidad del software.

Guiado por casos de uso: los casosde uso son el instrumento para validar

PRINCIPIOS DE RUPPRINCIPIOS DE RUP

de 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 arquitectura

11

y el diseño constituye la arquitecturadel producto a desarrollar;

Iterativo e incremental: seproducen versiones incrementales.

Los sistemas se crean para dar

Guiados por casos de usoGuiados por casos de uso

Los sistemas se crean para darservicio a los usuarios:

qué requisitos se necesitan;

un caso de uso es una pieza deFUNCIONALIDAD de un sistema

12

FUNCIONALIDAD de un sistemaque le proporciona a algúnUSUARIO un RESULTADO oVALOR.

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);

13

se especifican (analizan);

se diseñan;

se implementan;

se prueban.

Persona

Tomar Préstamo

2.- ANÁLISIS DEL CASO DE

1.- CASO DE USO

Desarrollo guiado por

CASOS DE USO

: IU-1 : GestorLibro : Libro elLibro:Libro

1: Introducir Signatura y NumeroDeSocioSe repite hasta que se

DEL CASO DE USO

14

2: Aceptar

3: obtenerLibro(signaturaLibro:String)

4: getSignatura()

Se repite hasta que seencuentre un libro

con la signatura 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

La arquitectura de un sistema

Centrado en la arquitecturaCentrado en la arquitectura

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

Extracto: vista de cada modelo

15

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

16

1

Centrado en la ARQUITECTURA

VISTA DEL MODELO DE CASOS DE USO VISTA DEL MODELO DEL DOMINIO /

VISTA DEL DIAGRAMA DE CLASES

: IU-1 : Gro

:1:2: 3: 4()

: : Gro

:1:2: 3: 4

()

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

17

+ 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

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

Casos de uso;

Subsistemas;

Interfaces;

18

Interfaces;

Algunas clases y componentes;

Nodos;

Colaboraciones.

También incluye:También incluye:

Aspectos de seguridad,distribución y concurrencia;

Descripción de la plataforma;

Sistemas heredados;

19

Sistemas heredados;

Software comercial;

Almacenamiento y recuperación deobjetos en una BD.

ITERATIVO

Iterativo e incrementalIterativo e incremental

ITERATIVOSe repiten VARIOSMINIPROYECTOS

INCREMENTAL

20

INCREMENTALCada miniproyecto AMPLIA ELPRODUCTO

Divide el producto en miniproyectos;proyectos;Cada mini proyecto es unaiteración que resulta en unincremento;Las iteraciones hacen referencia

21

Las iteraciones hacen referenciaa pasos en el flujo de trabajo, ylos incrementos al crecimientodel producto;

La selección de lo que seimplementará en una iteración seimplementará en una iteración sebasan en casos de uso de mayorutilidad y los riesgos masimportantes;Una iteración es una secuencia

22

Una iteración es una secuenciade actividades con un planestablecido y un criterio deevaluación.

23

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

Estructura de RUPEstructura de RUP

dimensiones, 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 aspecto

24

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

25

El proceso de desarrollo de softwaredemanda un conjunto de conceptos,

1. FASES DE RUP1. FASES DE RUP

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

Inicio (concepción);

26

Inicio (concepción);

Elaboración;

Construcción;

Transición.

Se desarrolla una descripción del

1.1 fase de INICIO1.1 fase de INICIO

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 alcance

27

se enmarca en el negocio, el alcancedel proyecto, se define el plan.

Los artefactos:Un documento con la visión delproyecto;proyecto;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 cual

28

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.

Planificar las actividades necesarias ylos recursos requeridos, especificando

1.2 fase de ELABORACION1.2 fase de ELABORACION

los 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 se

29

de los casos de uso del producto y sediseña la arquitectura del sistema;

Analizar el dominio del problema;

Establecer una buena arquitectura.

Artefactos:

Un modelo de Casos de UsoUn 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 con

30

funcionales o no asociados conningún caso de uso;

Descripción de la arquitectura delsoftware;

Prototipo ejecutable dePrototipo ejecutable dearquitectura;

Una lista revisada de riesgos;

Plan del proyecto, incluyendoiteraciones y criterios de

31

iteraciones y criterios deevaluación para cada iteración;

Manual preliminar de usuario.

Construir el producto, la arquitectura

1.3 fase de CONSTRUCCION1.3 fase de CONSTRUCCION

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 han

32

gerencia y el equipo de desarrollo hanacordado para construir el productode esta versión.

Artefactos:Artefactos:

El producto de softwareintegrado sobre la plataformaadecuada;

Los manuales de usuario;

33

Los manuales de usuario;

Una descripción de la versiónactual.

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

1.2 fase de TRANSICION1.2 fase de TRANSICION

producto a los usuarios, incluye:

Manufactura;

Envío;

Entrenamiento;

Corrección de defectos;

34

Corrección de defectos;

Soporte y;

Mantenimiento del producto.

hasta que el cliente esté satisfecho.

• El producto se encuentra en fase beta

Un grupo reducido de usuarios experimentadosprueba el producto e informa de los defectos yprueba el producto e informa de los defectos ydeficiencias y sugieren mejoras.

Los desarrolladores corrigen las deficiencias eincorporan algunas de las mejoras propuestasen una versión para un grupo de usuariosmayor.

En esta fase se encuentran actividades como la

35

En esta fase se encuentran actividades como laventa, formación de los usuarios, ofrecimientode ayuda en línea y corrección de defectosdescubiertos tras la implantación. Los defectos:(1) los que justifican la aparición de una nuevaversión del sistema, (2) los que se pueden dejarpara la siguiente versión que se cree.