31/10/2011

CICLO 2012-I Mdulo: I Unidad: 2 Semana: 3

ANALISIS Y DISEO DE SISTEMAS DE INFORMACIN

Tema:

Rational Unified Process (RUP)

Ing. Antonio Arqque Pantigozo

Qu es RUP?
Rational Unified Process (RUP) es un producto desarrollado y Mantenido por RATIONAL SOFTWARE. Potencia la Productividad del equipo Las actividades especificadas por RUP crean y mantienen modelos. Es una gua de cmo usar UML. Constituye la metodologa
2

Qu es RUP?
Soportado por herramientas, que automatizan gran parte del proceso.

31/10/2011

Qu es RUP?
Es un proceso configurable. No existe un nico proceso adecuado para todo el desarrollo de software. Sirve para pequeos equipos de desarrollo tanto para grandes organizaciones. Puede adecuarse a diversas situaciones

Caractersticas del RUP?

Orientado a Objetos.

Cualquier cosa del mundo real que puede ser representada. Caractersticas, identidad, estado y comportamiento

Caractersticas del RUP?

Iterativo incremental Guiado por caso de uso Es centrado en tres puntos: o Personas o Procesos o Herramientas y mtodos

31/10/2011

Caractersticas del RUP?

Tomar el ltimo feedback Captura de requerimientos de usuario Mitigar los mayores riesgos temprano Integrado con herramientas de desarrollo

Controlado e Iterativo

Basado en casos de uso

Aumentar el Reuso Mejorar la calidad

Arquitectura centralizada

Configurable
Personalizar el proceso 7

Ciclo de Vida 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

Principales puntos de control (Milestones)

Inception Elaboration Construction Transition

Objetivos Arquitectura (Vision)

tiempo

Capacidad Lanzamiento Operacional del Producto Inicial

Inicio: Definir el alcance del proyecto Elaboracin: Planificar el proyecto, elaborar una arquitectura base Construccin: Construir el sistema Transicin: Transicin a los usuarios 9

31/10/2011

Fase de Conceptualizacin o Incepcin

Inception
tiempo

Resultados
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
10

Fase de Conceptualizacin o Incepcin

Inception
tiempo
Control

Puntos a Controlar (Hitos)

Conocimiento y compromiso por parte de los Stakeholder en los objetivos definidos y estimacin de tareas y el costo de 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 desarrollo del proceso Conocimiento de las arquitecturas involucradas en los sistemas Validar costos actuales vs los costos planificados.
11

Fase de Elaboracin
Elaboration
tiempo

Resultados
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 12 Manual de Usuario preliminar.

31/10/2011

Fase de Elaboracin
Elaboration
tiempo
Control

Puntos de Control - Hitos:

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 13 estimados

Fase de Construccin
Construction
tiempo

Resultados
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.
14

Fase de Construccin
Construction
tiempo

Puntos de Control - Hitos:

Control

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
15

31/10/2011

Fase de Transicin
Transition
tiempo

Resultados
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
16

Fase de Transicin
Transition
tiempo

Objetivos Primarios
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.
17

Fase de Transicin
Transition
tiempo
Control

Puntos de Control - Hitos:

Objetivos han sido alcanzados. Esta satisfecho el usuario?

En algunos casos, este punto de control puede coincidir con el final de la etapa de conceptualizacin del siguiente ciclo.
18

31/10/2011

Fases e Iteraciones
Inception Elaboration Construction Transition

Prelim Iteration

...

Arch Iteration

...

Dev Iteration

Dev Iteration

...

Trans Iteration

...

Versin

Versin

Versin

Versin

Versin

Versin

Versin

Versin

Una iteracin es a secuencia de actividades con un plan establecido y criterios de evaluacin, cuyo resultado es una versin del software
19

Estructura Esttica del RUP

20

Las 6 mejores Prcticas

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

31/10/2011

Las 6 mejores Prcticas

Administrar Desarrollar iterativamente Modelizar visualmente Arquitecturas Basadas en Componentes

Verificar

Control de cambios

22

Las 6 mejores Prcticas 1. Desarrollo iterativo del software

Desarrollo de software dando varios realease al usuario
Requerimiento Planeami ento Anlisis y Diseo Implementacin

Planeamiento Inicial

Ambiente de Administracin

Evaluacin

Prueba

Cada iteracin genera una nueva versin

Distribucin

23

Las 6 mejores Prcticas 1. Desarrollo iterativo del software (cont.)

Beneficios:
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 Feedback para 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 Test en los puntos claves, permite conocer el estado real del proyecto Las inconsistencias entre los reqs, diseos e implementacin son tempranamente detectados
24

31/10/2011

Las 6 mejores Prcticas 1. Desarrollo iterativo del software (cont.)

Beneficios:
La carga del equipo, especialmente del equipo de testeo, es extendida a travs de la vida del proyecto El equipo de trabajo puede evidenciar los problemas con rapidez Todos los involucrados en el proyecto Stakeholders, pueden dar un evidencia concreta del estado del proyecto en todas la partes del ciclo de vida.

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 2. Administracin de requerimientos (cont.)

Beneficios: 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
27

31/10/2011

Las 6 mejores Use-Case Model Prcticas

Importancia de los Casos de Uso
verifies

realization

influenced by

Design Model

Implementation Model

Test Model
28

Las 6 mejores Prcticas

3. Uso de a arquitectura basada en compontes
Todo sistema se basa en la unin de muchas partes llamados componentes Un componente de software puede definirse como una pieza no trivial de software, un modulo un subsistema que completa una funcin clara tiene limites claros y puede ser integrado a una arquitectura bien definida
29

Las 6 mejores Prcticas 3. Uso de a arquitectura basada en compontes (Cont.)

Para desarrollar un sistema orientado a componentes se debe: 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.
30

10

31/10/2011

Las 6 mejores Prcticas

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

4. Modelar Software Visualmente (cont.)

Sub Systems

Classes

Modelamiento Visual Permite el nivel de Abstraccin

Code

32

Las 6 mejores Prcticas

4. Modelar Software Visualmente (cont.)
Modelos y Vistas
Un modelo es una completa descripcin de un sistema desde una particular perspectiva
Use Case Use Case Diagrams Sequence Diagrams Diagrams Use Case Use Case Diagrams Use Case Diagrams Diagrams State State Diagrams Class Diagrams Diagrams

State State Diagrams Object Diagrams Diagrams

Scenario Scenario Diagrams Collaboration Diagrams Diagrams

Models

State State Diagrams Component Diagrams Diagrams

Scenario Scenario Diagrams Statechart Diagrams Diagrams

Component Component Diagrams Deployment Diagrams

Activity Diagrams

Diagrams

33

11

31/10/2011

Las 6 mejores Prcticas

4. Modelar Software Visualmente (cont.)
Modelos y Flujo del trabajo
Business Modeling Requirements Workflow Analysis Design Workflow
Use-Case Model
Cada flujo de trabajo describe como crear y mantener un modelo particular

Business Model

realized by

implemented by
Design Model

Implementation Workflow Test Workflow

Implementation Model

verified by

34

Test Model

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, diseo e implementacin. Verifica la elasticidad del diseo y performance del sistema. Defectos encontrados rpidamente disminuyen los costos. La tarea de verificacin forma parte de cada Iteracin en el desarrollo iterativo. Existen herramientas automatizadas para funcionalidad, confiabilidad y performance. el testing de
35

Las 6 mejores Prcticas

6. Control de Cambios
Finalidad

Controlar, registrar y lmonitorear los cambios para posibilitar el desarrollo iterativo Establecer workspaces seguros para cada desarrollador. Automatizar la integracin y la administracin de builds

36

12

31/10/2011

Las 6 mejores Prcticas

6. Control de Cambios
Beneficios Permite descomponer la arquitectura en subsistemas y asignar la responsabilidad sobre cada uno a un equipo o persona especifico. Establece reas de trabajo seguras para cada desarrollador. Permite aislarse de cambios efectuados por otros. Controla todos los artefactos - modelos, cdigo, doc, etc. Establece un mecanismo de control de cambios inexpugnable. Permite saber que cambios aparecen en que versiones. Libera una versin de referencia al termino de cada iteracin.
37

El Proceso Unificado 6. Control de Cambios

Desarrollo Iterativamente Administre requerimientos El progreso es incremental solo si se controlan los cambios Para evitar los alcances sean variables, evaluar cada cambio antes de aprobarlo Los componentes deben ser confiables, las versiones deben componerse a partir de las partes correctas Para asegurar convergencia, se debe controlar modelos incrementalmente Los test son muy significativos solo si los tems testeados estn perfectamente identificados y 38 protegidos de cambios

Use arquitectura de componente

Modele visualmente

Verifique calidad

Esfuerzo y dedicacin por Fases en RUP

Inicio Esfuerzo Tiempo Dedicado 5% 10 %

Elaboracin 20 % 30 %

Construccin 65 % 50 %

Transicin 10% 10%

39

13

31/10/2011

Distribucin de Recursos por Fases en RUP

40

Relacin entre Diagramas UML y Disciplinas de RUP

Disciplina Requerimientos Anlisis Diagrama Diagramas de Casos de Uso Refinamiento y documentacin de los casos de usos Definicin preliminar de clases y Diagramas de Interaccin (Secuencia y Colaboraciones) Empaquetamiento Diagramas de Interaccin de diseo (Secuencia y Colaboraciones) Diagrama de Clases de diseo Modelo de Datos

Diseo

Implementacin

Diagrama de Componentes Diagrama de Despliegue

41

Gracias por su Atencin

42

14