Upload
others
View
9
Download
0
Embed Size (px)
Citation preview
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
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.
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
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.