1

Ing. Antoni o Arqque Panti gozo

CICLO 2012-II Mdulo: I
Unidad: 2 Semana: 3
ANALISIS Y DISEO DE
SISTEMAS DE INFORMACIN
Tema:
Rational Unified Process (RUP)
1
Qu es RUP?
Rati onal Uni fi ed Process (RUP) es un producto
desarrol l ado y Manteni do por RATIONAL
SOFTWARE.
Potenci a l a Producti vi dad del equi po
Las acti vi dades especi fi cadas por RUP crean y
manti enen model os.
Es una gua de cmo usar UML. Consti tuye l a
metodol oga
2
Soportado por herrami entas, que automati zan
gran parte del proceso.
3
Qu es RUP?
2
Es un proceso confi gurabl e. No exi ste un ni co
proceso adecuado para todo el desarrol l o de
software.
Si rve para pequeos equi pos de desarrol l o
tanto para grandes organi zaci ones.
Puede adecuarse a di versas si tuaci ones
4
Qu es RUP?
Ori entado a Obj etos.
Cual qui er cosa del mundo real que puede ser
representada. Caractersti cas, i denti dad, estado y
comportami ento
5
Caractersticas del RUP?
Iterati vo i ncremental
Gui ado por caso de uso
Es centrado en tres puntos:
o Personas
o Procesos
o Herrami entas y mtodos
6
Caractersticas del RUP?
3
Controlado
e Iterativo
Basado en
casos de uso
Arquitectura
centralizada
Configurable
Captura de requerimientos
de usuario
Mitigar los mayores
riesgos temprano
Tomar el ltimo
feedback
Integrado conherramientas
de desarrollo
Mejorar la calidad
Personalizar el
proceso
Aumentar el
Reuso
7
Caractersticas del RUP?
El ciclo de vida esta partido en ciclos, y cada ciclo trabaja
sobre una nueva generacin del producto.
RUP divide cada ciclo de desarrollo en cuatros fases:
Fase de Conceptualizacin
Fase de Elaboracin
Fase de Construccin
Fase de Transicin
8
Ciclo de Vida del RUP
9
Inicio: Definir el alcance del proyecto
Elaboracin: Planificar el proyecto, elaborar una
arquitectura base
Construccin: Construir el sistema
Transicin: Transicin a los usuarios
tiempo
Objetivos
(Vision)
Arquitectura Capacidad
Operacional
Inicial
Lanzamiento
del Producto
Inception Elaboration Construction Transition
Principales puntos de control (Milestones)
4
tiempo
Inception
Visin documentada, en donde se define los reqs principales del proyecto,
principales caractersticas y restricciones
Un inicial modelo USE-CASE del negocio (10% - 20%)
Un glosario de conceptos y trminos del proyecto
Un inicial modelo del Negocio, que incluya el contexto de la empresa y
factores de xito (Costo - Beneficio).
Un inicial inventario y costeo de riesgos
El plan del proyecto (donde se muestren las etapas e iteraciones)
Si es posible un prototipo inicial
Resul tados
10
Fase de Conceptualizacin o Incepcin
tiempo
Inception
Conocimiento y compromiso por parte de los Stakeholder en los
objetivos definidos yestimacinde tareas yel costode las mismas
Evidenciar en los USE - CASE primarios el entendimiento de los reqs
del Usuario
Credibilidad en la estimacin de tiempos y costeo, prioridades, riesgos
y desarrollodel proceso
Conocimientodelas arquitecturasinvolucradas enlos sistemas
Validar costos actuales vs los costos planificados.
Puntos a Control ar (Hi tos)
Control
11
Fase de Conceptualizacin o Incepcin
tiempo
Elaboration
Modelo del USE - CASE (80% completado), todos los USE - CASE y
actores han sido identificados y las descripciones de los USE - CASE
han sido elaboradas
Requerimientos suplementarios son recolectados y asociados a un
diagrama USE - CASE
Descripcin de la arquitectura del Software
Prototipo del Software
Lista de riesgos y Cases del negocio validados
Plan del Proyecto completo y aprobado por el Usuario Lider
Manual de Usuario preliminar.
Resul tados
12
Fase de Elaboracin
5
Es la visin del producto estable?
Es arquitectura estable?
La presentacin del prototipo demostr que los principales reqs y
riesgos estn resueltos con la solucin elaborada
El plan para la construccin del SW es lo suficientemente detallado y
de acuerdo a los costos estimados?
Estn de acuerdo los Stakeholder con el plan definido?
Validacin de los Costos incurridos hasta el momento versus los costos
estimados
Puntos de Control - Hi tos:
Control
tiempo
Elaboration
13
Fase de Elaboracin
tiempo
Construction
Primera versin del Producto (Versin Beta)
Pruebas del Producto
Los Manuales de Usuario
Validacin de los Costos incurridos hasta el momento versus los costos
estimados.
Resul tados
14
Fase de Construccin
tiempo
Se han cumplido el plan de pruebas (en todos los niveles)?
Estn todos los Stakeholder listos para colocar la versin actual
(realese) en el ambiente del Usuario
Estan todos los recursos listos para la transicin hacia la comunidad
usuaria.
Validacin de los Costos incurridos hasta el momento versus los costos
estimados
Control
Construction
Puntos de Control - Hi tos:
15
Fase de Construccin
6
tiempo
Transition
Testeo de la Versin BETA para validar el nuevo sistema versus las
expectativas del usuario
Plan de puesta en produccin respecto al sistema antiguo
Tareas de migracin y conversin de datos
Entrenamiento de usuarios y del Area de Sistemas de la empresa
Instalacin del producto en todos los ambientes del usuario
Resul tados
16
Fase de Transicin
tiempo
Transition
Obtener autonoma del usuario
Obtener el acuerdo de los participantes de que la instalacin ha sido
completa y que es consistente con los criterios de evlaucin de la
visin
Perfeccionar el producto final.
Obj eti vos Pri mari os
17
Fase de Transicin
tiempo
Objetivos hansido alcanzados. Estasatisfechoel usuario?
En algunos casos, este punto de control puede coincidir con el final de la
etapade conceptualizacindel siguienteciclo.
Control
Transition
Puntos de Control - Hi tos:
18
Fase de Transicin
7
Una iteracines a secuencia de actividades con un plan establecido y
criterios de evaluacin, cuyo resultado es una versin del software
Arch
Iteration
... Dev
Iteration
Dev
Iteration
... Trans
Iteration
...
Versin Versin Versin Versin Versin Versin Versin Versin
Prelim
Iteration
...
Inception Elaboration Construction Transition
19
Fases e Iteraciones
20
Estructura Esttica del RUP
1. Desarrollo Iterativo del software
2. Administracin de requierimientos
3. Uso de arquitecturas basadas en componentes
4. Modelamiento visual del software
5. Verificacin de la calidad del software
21
Las 6 mejores Prcticas
8
Admi ni strar
Desarrol l ar
i terati vamente
Veri fi car
Model i zar
vi sual mente
Arqui tecturas
Basadas en
Componentes
Control de cambi os
22
Las 6 mejores Prcticas
1. Desarrollo iterativo del software
Desarrollo de software dando varios realease al usuario
Planeamiento
Inicial
Planeami
ento
Requerimiento
Anlisis y Diseo
Implementacin
Prueba
Distribucin
Evaluacin
Ambiente de
Administracin
Cada iteracin genera
una nueva versin
23
Las 6 mejores Prcticas
Los puntos no entendidos son puestos en evidencia tempranamente
en la vida del ciclo, por lo tanto es posible reaccionar a ellos
Permite utilizar el Feedbackpara obtener los reqs reales del
sistema
El equipo de desarrollo es forzado a dar importancia a las tareas ms
crticas en el proyecto, que son en conclusin los puntos de riesgo del
proyecto.
La revisin del proyecto Testen los puntos claves, permite conocer
el estado real del proyecto
Las inconsistencias entre los reqs, diseos e implementacin son
tempranamente detectados
1. Desarrollo iterativo del software (cont.)
Benefi ci os:
24
Las 6 mejores Prcticas
9
Benefi ci os:
La carga del equipo, especialmente del equipo de testeo, es extendida
a travs de la vida del proyecto
El equipo de trabajopuede evidenciar los problemas conrapidez
Todos los involucrados en el proyecto Stakeholders, pueden dar un
evidencia concreta del estado del proyecto entodas la partes del ciclo
de vida.
1. Desarrollo iterativo del software (cont.)
25
Las 6 mejores Prcticas
2. Administracin de requerimientos
Un requerimiento es una condicin o capacidad que un sistema debe
tener
Para definir un requerimiento, se tienen 3 tareas:
Obtener la informacin
Organizarla
Documentacin
La documentacin permite:
Registro de reqs del sistema
Evaluacin y costeo de los cambios
Seguimiento
Registro de acuerdos y decisiones
26
Las 6 mejores Prcticas
Benefi ci os:
Comunicaciones basadas en requerimientos bien
definidos
Los requerimientos pueden ser priorizados, filtrados y
monitoreados
Es posible realizar evaluaciones objetivas acerca del
exito de un proyecto
2. Administracin de requerimientos (cont.)
27
Las 6 mejores Prcticas
10
Desi gn Model
Impl ementati on Model
Test Model
verifies
realization
influenced
by
Use-Case Model
Importancia de l os
Casos de Uso
28
Las 6 mejores Prcticas
3. Uso de a arquitectura basada en compontes
Todo si stema se basa en l a uni n de muchas partes
l l amados componentes
Un componente de software puede defi ni rse como
una pi eza no tri vi al de software, un modul o un
subsi stema que compl eta una funci n cl ara ti ene
li mi tes claros y puede ser i ntegrado a una
arqui tectura bi en defi ni da
29
Las 6 mejores Prcticas
3. Uso de a arquitectura basada en
compontes (Cont.)
Definir arquitecturas muy modulares e identificar, aislar,
disear, desarrollar y probar componentes bien formados.
Desarrollar componentes para ser reutilizados. Formar la
base de reuso de la organizacin.
Para desarrol l ar un si stema ori entado a componentes se
debe:
30
Las 6 mejores Prcticas
11
4. Modelar Software Visualmente
Eleva el nivel de abstraccin, pudiendo administrar ms
fcilmente los requerimientos, dando un lenguaje de mas
sencillo y administrable.
Por ejemplo UML (Unified Modeling Languaje), define
un conjunto de modelos (estndar) que permite una
comunicacin no ambigua entre el equipo desarrollo
31
Las 6 mejores Prcticas
Code
Classes
Sub Systems
Model ami ento
Vi sual
Permi te el ni vel de
Abstracci n
4. Modelar Software Visualmente (cont.)
32
Las 6 mejores Prcticas
Model os y Vi stas
Use Case
Diagrams
Use Case
Diagrams
Use Case
Diagrams
Scenario
Diagrams
Scenario
Diagrams
Collaboration
Diagrams
State
Diagrams
State
Diagrams
Component
Diagrams
Component
Diagrams Component
Diagrams
Deployment
Diagrams
State
Diagrams
State
Diagrams
Object
Diagrams
Scenario
Diagrams
Scenario
Diagrams
Statechart
Diagrams
Use Case
Diagrams
Use Case
Diagrams
Sequence
Diagrams
State
Diagrams
State
Diagrams
Class
Diagrams
Activity
Diagrams
Un modelo es una
completa descripcin de
un sistema desde una
particular perspectiva
Models
4. Modelar Software Visualmente (cont.)
33
Las 6 mejores Prcticas
12
Cada flujo de trabajo describe como crear y
mantener un
modelo particular
Modelos y Flujo del trabajo
Design
Model
Implementation
Model
Test
Model
realized by
implementedby
Requi rements
Workfl ow
Anal ysi s Desi gn
Workfl ow
Impl ementati on
Workfl ow
Test Workfl ow
Use-Case
Model
Busi ness
Model i ng
Business Model
verified by
4. Modelar Software Visualmente (cont.)
34
Las 6 mejores Prcticas
5. Verificar la Calidad del Software
Crear tareas de testeo para cada escenario clave y asegurar que
todos los reqs estn correctamente definidos en las etapas de
reqs, diseoe implementacin.
Verifica la elasticidaddel diseoy performancedel sistema.
Defectos encontradosrpidamentedisminuyenlos costos.
La tarea de verificacin forma parte de cada Iteracin en el
desarrolloiterativo.
Existen herramientas automatizadas para el testing de
funcionalidad, confiabilidadyperformance.
35
Las 6 mejores Prcticas
6. Control de Cambios
Controlar, registrar y lmonitorear los cambios para posibilitar el
desarrolloiterativo
Establecer workspacesseguros paracadadesarrollador.
Automatizarla integracinyla administracinde builds
Fi nal idad
36
Las 6 mejores Prcticas
13
6. Control de Cambios
Permite descomponer la arquitectura en subsistemas y asignar
la responsabilidad sobre cada uno a un equipo o persona
especifico.
Establecereas de trabajoseguras para cadadesarrollador.
Permite aislarsede cambios efectuados por otros.
Controlatodos los artefactos - modelos, cdigo, doc, etc.
Estableceunmecanismode control de cambios inexpugnable.
Permite saber que cambios aparecenenque versiones.
Liberauna versinde referenciaal terminode cadaiteracin.
Benefi ci os
37
Las 6 mejores Prcticas
6. Control de Cambios
El Proceso Unificado
Desarrol l o Iterati vamente El progreso es incremental solo si
se controlanlos cambios
Admi ni stre requeri mi entos Para evitar los alcances sean
variables, evaluar cada cambio
antes de aprobarlo
Use arqui tectura de componente Los componentes deben ser
confiables, las versiones deben
componerse a partir de las partes
correctas
Model e vi sual mente Para asegurar convergencia, se
debe controlar modelos
incrementalmente
Veri fi que cal i dad Los test son muy significativos solo
si los tems testeados estn
perfectamente identificados y
protegidos decambios
38
39
Esfuerzo y dedicacin
por Fases en RUP
Inicio Elaboracin Construccin Transicin
Esfuerzo 5 % 20 % 65 % 10%
Tiempo
Dedicado
10 % 30 % 50 % 10%
14
40
Distribucin de Recursos
por Fases en RUP
Disciplina Diagrama
Requerimientos Diagramas de Casos de Uso
Anlisis Refinamiento y documentacin de los casos de usos
Definicinpreliminar de clases y
Diagramas de Interaccin(Secuencia y Colaboraciones)
Diseo Empaquetamiento
Diagramas de Interaccin de diseo (Secuencia y
Colaboraciones)
Diagrama de Clases de diseo
Modelo de Datos
Implementacin Diagrama de Componentes
Diagrama de Despliegue
Relacin entre Diagramas UML
y Disciplinas de RUP
41
Gracias por su Atencin
42