Metodologia rup parte 1

Metodología RUP. (Rational Unific Process)

(Primera parte)

Marbella Castañeda Rivas [email protected]

mailto:[email protected]


es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM

un conjunto de metodologías adaptables al contexto y necesidades de cada organización

Historia

Según Wikipedia, “Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm.

Ken Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la investigación.

En 1995 Rational Software compró una compañía sueca llamada Objectory AB, fundada por

Ivar Jacobson, famoso por haber incorporado los casos de uso a los métodos de desarrollo

orientados a objetos. El Rational Unified Process fue el resultado de una convergencia de

Rational Approach y Objectory (el proceso de la empresa Objectory AB). El primer resultado de

esta fusión fue el Rational Objectory Process, la primera versión de RUP, fue puesta en el

mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten”

• Orígenes

– Modelo original Objectory definido por Ivan Jacobson (1987)

– Rational Software compra la empresa de Objectory (1995)

– Surge la primera versión de UML (1997)

– Se publica la primera versión del Proceso Unificado de Rational - RUP

(junio 1998)


Basado en seis principios claves de desarrollo

1. Proceso adaptable

2. Equilibra prioridades

3. Demuestra valor iterativamente

4. Colaboración entre equipos

5. Eleva el nivel de abstracción

6. Se enfoca en la calidad

Se caracteriza por :

1. Los casos de uso

2. Centrados en la arquitectura

3. Modelo de Ciclo de vida es iterativo e incremental

4. Estructura dinámica



Dirigido por casos de uso – Se centra en la funcionalidad que el sistema debe poseer para satisfacer las

necesidades de un usuario (persona, sistema externo, dispositivo) que

interactúa con él

– Casos de uso como el hilo conductor que orienta las actividades de desarrollo

Casos de Uso

Análisis

Recopilar,

Clarificar y

Validar los

requerimientos

Diseño

Realizar los

casos de uso

Pruebas

Verificar que se

satisfacen los

casos de uso

<<realiza>> <<verifica>> <<defineNecesidades>>

Fuente: Ricardo Borillo. Introducción al Modelado. Metodologías, UML y patrones de diseño.

Metodología RUP. (Rational Unific

Process)

Centrado en la arquitectura

Concepto similar a la arquitectura de un edificio

Varios planos con diferentes aspectos del edificio

Tener una imagen completa del edificio antes que comience la construcción

Arquitectura en software

Diferentes vistas del sistema: estructural, funcional, dinámico, etc.

Plataforma en la que va a operar

Determina la forma del sistema

Arquitectura: determina la forma del sistema

Casos de uso: determinan la función del sistema



Modelo de Ciclo de vida:

Iterativo e incremental

Descomposición de un proyecto grande en mini-proyectos

Cada mini-proyecto es una iteración

Las iteraciones deben estar controladas

Cada iteración trata un conjunto de casos de uso

Ventajas del enfoque iterativo

Detección temprana de riesgos

Administración adecuada del cambio

Mayor grado de reutilización

Mayor experiencia para el grupo de desarrollo



Dimensión Estructura

Dinámica

Ciclo: cada ciclo una nueva versión del producto

Fase: Etapas de un ciclo que finalizan en un HITO

Iteración: Proceso de ingeniería sobre una funcionalidad limitada del

sistema

Estática - Flujos de trabajo

Artefactos

Actividades

Roles


http://www.google.co.ve/imgres?imgurl=http://2.bp.blogspot.com/-

52UeNtFxRY4/UMc3uSSwn5I/AAAAAAAAADM/02yHmzdKYeM/s1600/rup.png&imgrefurl=http://metodologirup.blogspot.com/&h=57

9&w=758&sz=143&tbnid=sBpzetvS3G_F3M:&tbnh=91&tbnw=119&zoom=1&usg=__mTuqFqwmBT7Aa2dW5z4mlfqIDY4=&docid=Oi

YjRTUaXQBweM&sa=X&ei=Pr5_UdWcLYe09gSS8YGQCg&ved=0CDcQ9QEwAQ&dur=325


http://www.google.co.ve/imgres?imgurl=http://2.bp.blogspot.com/-52UeNtFxRY4/UMc3uSSwn5I/AAAAAAAAADM/02yHmzdKYeM/s1600/rup.png&imgrefurl=http://metodologirup.blogspot.com/&h=579&w=758&sz=143&tbnid=sBpzetvS3G_F3M:&tbnh=91&tbnw=119&zoom=1&usg=__mTuqFqwmBT7Aa2dW5z4mlfqIDY4=&docid=OiYjRTUaXQBweM&sa=X&ei=Pr5_UdWcLYe09gSS8YGQCg&ved=0CDcQ9QEwAQ&dur=325





Ciclo de vida : es un desarrollo en espiral


Hito : punto en el tiempo en donde se evalúan objetivos logrados y se toman decisiones

críticas


Ciclo de

desarrollo 1

Ciclo de

desarrollo 2

Ciclo de

desarrollo n

Perfeccionar

el plan

Sincronizar

Artefactos

Análisis Diseño Construcción Pruebas

Construcción



Fase de Inicio o Concepción En esta fase es donde se realiza el modelo del negocio. Se concreta la idea, la visión del producto, como se enmarca en el negocio, el alcance del proyecto. El objetivo en esta etapa es determinar y proponer una visión general de la arquitectura de software y producir el plan de las fases y el de las iteraciones consiguientes. Se construyen los diagramas de caso de uso, requisitos.

Elaboración Aquí en esta fase de desarrollo, es donde se construye el documento arquitectura de las diferentes vistas, para posteriormente construir la base de datos.

Desarrollo o Construcción En esta fase es donde pasamos a modelar el producto que vamos a mostrar al usuario con todo sus requerimientos, además de que en esta etapa se realiza la implantación y las pruebas al mismo.

Transición Durante esta fase de transición busca garantizar que se tiene un producto preparado para su entrega al usuario. Pruebas finales de adaptación , puesta en producción.

Inicio o Concepción Elaboración Construcción Transición

• Objetivo: Definir el alcance del

proyecto. Estudio de

oportunidad

Modelo de Negocio

Visión= Qué + PARA

QUÉ + CUÄNTO

• Actividades o Especificación de los

criterios de éxito

del proyecto

o Especificación de los

requerimientos

o Estimación de los

recursos necesarios

• Artefactos o Documento de

definición del

proyecto

• Objetivo: Establecer un plan

de proyecto y una arquitectura

correcta del sistema.

• Actividades: o Análisis del dominio del

Problema

o Definición de la arquitectura

básica

o Análisis de riesgo

o Planificación del proyecto

• Artefactos: o Vista Lógica

Diagrama de clases

Modelo E-R (Si el sistema así lo

requiere)

o Vista de Implementación Diagrama de Secuencia

Diagrama de estados

Diagrama de Colaboración

o Vista Conceptual Modelo de dominio

o Vista física Mapa de comportamiento a

nivel de hardware.

• Objetivo: desarrollar

el sistema a lo largo de

una serie de iteraciones

• Especificación de

requisitos faltantes

• Diseño y desarrollo de

casos de uso y/o flujos

de acuerdo con la

planeación iterativa

• Pruebas de los casos de

uso desarrollados, y

pruebas de regresión

según sea el caso

• Pruebas finales de

aceptación

• Puesta en producción

• Estabilización


• El Modelado de Negocios se define como un proceso de representación de uno o mas

aspectos de la empresa tales como:

o Propósito

o Estructura

o Funcionalidad

o Dinámica

o Lógica de negocios

o Componentes:

Fines

Procesos de negocio

Reglas de negocio

Objetos de negocio

Acciones

Unidades organizativas



Modelado del negocio

En esta fase el equipo se familiariza con el funcionamiento de la organización o empresa, conoce los procesos de interés relacionados con el problema.

Entender la estructura y la dinámica de la organización para la cual el sistema va ser desarrollado.

Entender el problema actual en la organización objetivo e identificar potenciales mejoras.

Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización objetivo.


Según Booch (2002) “el modelado de negocio se define como “el flujo de trabajo en el cual se pretende llegar a un mejor entendimiento de la organización donde se va a implantar el producto”. Plantea como objetivos:

• Entender la estructura y la dinámica de la organización para el cual el sistema va a ser desarrollado (organización objetivo)

• Entender el problema actual en la organización objetivo e identificar potenciales mejoras.

• Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización objetivo.

• Derivar los requisitos del sistema necesarios para apoyar a la organización objetivo

Para lograr estos objetivos:

• Desarrollar la visión de la organización

• Definir los procesos, roles y responsabilidades de la organización por medio de un modelo de Caso de Uso del Negocio

• Definir el Modelo de objetos del Negocio


Requisitos

o En esta línea los requisitos son el contrato que se debe cumplir, de modo

que los usuarios finales tienen que comprender y aceptar los requisitos que

especifiquemos.

o Establecer y mantener un acuerdo entre clientes y otros stakeholders

sobre lo que el sistema podría hacer.

o Proveer a los desarrolladores un mejor entendimiento de los requisitos del

sistema.

o Definir el ámbito del sistema.

o Proveer una base para estimar costos y tiempo de desarrollo del sistema.

o Definir una interfaz de usuarios para el sistema, enfocada a las necesidades

y metas del usuario.


Según Booch (2002), los requisitos se dividen en dos

grupos:

funcionales los cuales representan la funcionalidad del sistema y se modelan

mediante los diagramas de Casos de Uso.

Los requisitos no funcionales representan aquellos atributos que debe exhibir el

sistema, pero que no son de funcionalidad específica, como por ejemplo facilidad de

uso, fiabilidad, eficiencia, portabilidad

La especificación de los requerimientos de Entradas, que consiste en el

prototipado de las interfaces o pantallas de actualización de datos. Se debe contemplar

aspectos propios de la implementación, como ser: ubicación de menú, ubicación de botones

de opciones, barra de acceso rápido, diseño de íconos, uso de colores corporativos, tipo de

letra, tamaño de letra, etc

La especificación de los requerimientos de Salidas, que consiste en el

prototipado de los reportes, pantallas de consulta, informes gráficos, estadísticas, salidas a

archivos, etc. Comprende un modelado lo más preciso posible a lo que se implementará.

Especificación de interfaces con otros sistemas o aplicaciones. Consiste en

determinar el nivel de procesos y de datos, los requerimientos de transferencia de

información con otros sistemas o aplicaciones existentes.



El enfoque de Rational-IBM

• ‰ Énfasis en el

modelado de:

• „ Procesos de negocio

• „ Objetos de negocios

• ‰ Los procesos de negocio se modelan con

casos de uso

• ‰ Los objetos de negocio se modelan con

diagramas de clases

AC


Fases

Inicio Elaboración Construcción Transición

Artefacto o

Producto

Workflows

de

Proceso

Conceptualizar

el sistema

Requerimientos

Modelo

Conceptual

Modelo de

Casos de Uso:

Actores, caso

de usos,

relaciones

Actividades

• Indagar, conocer el negocio

• Especificar los requerimientos

• Conceptualizar el sistema

• Confeccionar el modelo conceptual

Actividades

• Identificar los actores

• Estructurar el sistema a partir del modelo conceptual

• Describir cada caso de Uso

• Establecer las relaciones

Metodologia rup parte 1

Education

Transcript of Metodologia rup parte 1