introduccion al proceso unificado

8/18/2019 Introduccion Al Proceso Unificado

1/51

Autor: Ing. Silverio Bonilla 1

Introducción al Proceso Unificado de

Desarrollo de Software

Sistemas de Información II


2/51


3/51


Concepto de Método

El desarrollo de un sistema se puede explicar también como:

Una secuencia de modelados que ayuda a construir, a partir de larealidad, uno o varios modelos, derivados unos de otros, con elobjetivo de lograr un modelo final o sistema.

Y entonces:

Un método es una guía que define las reglas de paso de unmodelo a otro para evolucionar progresivamente hasta el modelofinal.

Introducción al Proceso unificado RUP



4/51


Qué es un proceso de desarrollo de SW?

Requisitos nuevos

o modificados

Sistema nuevo

o modificadoProceso de Desarrollo

de Software

Define Quién debe hacer Qué, Cuándo y Cómo

debe hacerlo

o existe un proceso de software universal. Lascaracterísticas de cada proyecto (equipo dedesarrollo, recursos, etc.) exigen que el proceso sea

configurable




5/51


¿Qué es RUP?

UML no es una metodología de diseño y que es bastante independiente del proceso de desarrollo, lo quesignifica que se puede utilizar con diferentes procesosde ingeniería del software.

Para poder aplicar UML con garantía de conseguir un

modelo de objetos de calidad, es necesaria unametodología completa, coherente y asequible.

Esto es lo que hicieron «los tres amigos de Rational

Corp. », James Rumbaugh, Gardy Booch e IvarJacobson: Diseñar una metodología que enseña autilizar correctamente UML en el proceso de modeladode sistemas, denominada Proceso Unificado de

Rational (Rational Unified process)




6/51


Características del RUP

Las actividades de desarrollo del RUP están dirigidas

por los Casos de Uso:

El Proceso Unificado pone un gran énfasis en la

construcción de sistemas basada en una amplia

comprensión de cómo se utilizará el sistema que se

entregue

Las nociones de los casos de uso y los escenarios se

utilizan para guiar el flujo de procesos desde la

captura de los requisitos hasta las pruebas, y para

proporcionar caminos que se pueden reproducir

durante el desarrollo del sistema




7/51




por los Casos de Uso:

Es un proceso dirigido por los casos de uso

Requisitos Capturar, definir yvalidar los casos de uso

Realizar los

casos de uso

Verificar que sesatisfacen los casos

de uso

Análisis & Diseño

Implementación

Pruebas

Casos de Uso

integran eltrabajo




8/51




por los Casos de Uso:Es un proceso dirigido por los casos de uso

Caso de Uso Modelo de Análisis Modelo de Diseño

Caso de Prueba

X

«trace» «trace»

«trace» «trace»

Pruebas Funcionales

PruebasUnitarias




9/51



El RUP es un proceso Iterativo-Incremental:

Un enfoque iterativo propone una comprensión

incremental del problema a través de refinamientos

sucesivos y un crecimiento incremental de una solución

efectiva a través de varias versiones

Como parte del enfoque iterativo se encuentra la

flexibilidad para acomodarse a nuevos requisitos o a

cambios tácticos en los objetivos del negocio

Permite que el proyecto identifique y resuelva los

riesgos más bien pronto que tarde.




10/51




Se basa en la ampliación y el refinamiento del sistema

Una serie de desarrollos cortos (mini proyectos de 2 a 6

semanas, cada iteración reproduce el ciclo de vida amenor escala)

No sólo se mejora sino que el sistema también crece:

Proceso iterativo e incremental El resultado de cada iteración es un sistema ejecutable

(aunque sea incompleto y no esté listo para su

instalación)




11/51




Un sistema instalable requiere varias iteraciones

Es una evolución de prototipos ejecutables

Los objetivos de una iteración se establecen en función

de la evaluación de las iteraciones precedentes




12/51




Enfoque

Secuencial

Enfoque

Iterativo e

Incremental

Incremento 1

Incremento 2

Incremento 3




13/51



El RUP es un proceso Centrado en la Arquitectura:

Arquitectura de un sistema es la organización o estructurade sus partes más relevantes

La arquitectura describe los elementos fundamentales del

sistema: Subsistemas, Dependencias, Interfaces,Colaboraciones, Nodos ...

Un arquitectura ejecutable es una implementación parcial

del sistema, construida para demostrar algunas funcionesy propiedades

RUP establece refinamientos sucesivos de una

arquitectura ejecutable, construida como un prototipoevolutivo




14/51



El RUP es un proceso Centrado en la Arquitectura:

El proceso se centra en establecer al principio una

arquitectura software que guía el desarrollo del sistema:

Se facilita el desarrollo en paralelo

Se minimiza la repetición de trabajos

Se incrementa la probabilidad de reutilización de compo-nentes y el mantenimiento posterior del sistema

Este diseño arquitectónico sirve como una sólida base

sobre la cual se puede planificar y manejar el desarrollo

de software basado en componentes.




15/51



El Proceso Unificado soporta las técnicas orientadas a

objetos. Los modelos del Proceso Unificado se basan en los

conceptos de objeto y clase y las relaciones entre ellos, y

utilizan UML como la notación común. El Proceso Unificado es un proceso configurable.

Aunque un único proceso no es adecuado para todas las

organizaciones de desarrollo de software, el ProcesoUnificado es adaptable y puede configurarse para cubrir

las necesidades de proyectos que van desde pequeños

equipos de desarrollo de software hasta grandes empresas

de desarrollo




16/51


Proceso de Dos Dimensiones

Eje Horizontal:

representa el tiempo,

muestra aspectos dinámicos del proceso,

se expresa como ciclos, fases, iteraciones e hitos.

Eje Vertical:

aspectos estáticos del proceso,

actividades, artefactos, trabajadores y flujo de trabajo.




17/51


Ciclos y Fases

RUP divide el proceso de desarrollo en ciclos, teniendoun producto al final de cada ciclo.

Cada ciclo se divide en cuatro Fases:

Inicio (inception),

Elaboración,

Construcción,

Transición.

Cada fase concluye con un hito bien definido donde

deben tomarse ciertas decisiones.




18/51


Flujos de Trabajos y Fases del RUP Introducción al Proceso unificado RUP



19/51


En esta estructura matricial se puede deducir que:

Los resultados de los flujos de trabajo de proceso son los

MODELOSLa conjunción de tiempo (fases) y esfuerzos (flujos de trabajo)

da lugar a las iteraciones

La conjunción de resultados (modelos) y esfuerzos (flujos de

trabajo) da lugar a los tipos de modelos

La conjunción de tiempo (fases) y resultados (modelos) da lugar

a las versiones

Se puede representar esta estructura conceptual mediante unafigura tridimensional donde:

– Eje X: Fases indica tiempo

– Eje Y: Flujos de trabajo indica esfuerzos

– Eje Z: Modelos indica resultados




20/51





21/51


22/51


Se establece la oportunidad y alcance el proyecto.

Se identifica todas las entidades externas con las que setrata (actores) y se define la interacción a un alto nivel de

abstracción:

identificar todos los casos de uso,describir algunos en detalle.

La oportunidad del negocio incluye:

criterios de éxito,identificación de riesgos,

estimación de recursos necesarios,

plan de las fases incluyendo hitos.

Fase Inicio Introducción al Proceso unificado RUP



23/51


24/51


Las partes interesadas deben acordar el alcance y la

estimación de tiempo y costo.

Comprensión de los requerimientos plasmados en casos

de uso.

Hitos

Concepción Elaboración Construcción Transición

Objetivos delCiclo de Vida




25/51


Objetivos:

analizar el dominio del problema,

establecer una arquitectura base sólida,

desarrollar un plan de proyecto,

eliminar los elementos de mayor riesgo para el desarrollo

exitoso del proyecto.

Visión de “una milla de amplitud y una pulgada de

profundidad” porque las decisiones de arquitecturarequieren una visión global del sistema.

Fase de Elaboración Introducción al Proceso unificado RUP



26/51


Es la parte más crítica del

proceso:

al final toda la ingeniería

“dura” está hecha,

se puede decidir si vale la pena seguir adelante.

A partir de aquí la

arquitectura, losrequerimientos y los

planes de desarrollo son

estables.

Productos de la Fase de Elaboración

Ya hay menos riesgos y se

puede planificar el resto

del proyecto con menos

incertidumbre.

Se construye una

arquitectura ejecutable que

contemple

los casos de uso críticos,

los riesgos identificados.




27/51


Modelo de casos de uso

(80% completo) con

descripciones detalladas.

Otros requerimientos no

funcionales o no asociados

a casos de uso.

Descripción de la

Arquitectura del Software.

Productos Concretos de la Fase de Elaboración

Un prototipo ejecutable de

la arquitectura.

Lista revisada de riesgos y

del caso de negocio.

Plan de desarrollo para el

resto del proyecto.

Un manual de usuario preliminar.




28/51


Condiciones de éxito de la elaboración:

¿es estable la visión del producto?

¿es estable la arquitectura?

¿las pruebas de ejecución convencen de que los riesgos han sido

abordados y resueltos?

¿es el plan del proyecto algo realista?

¿están de acuerdo con el plan todas las personas involucradas?

Hitos


Arquitectura deCiclo de Vida




29/51


En esta fase todas las componentes restantes sedesarrollan e incorporan al producto.

Todo es probado en profundidad.

El énfasis está en la producción eficiente y no ya en lacreación intelectual.

Puede hacerse construcción en paralelo, pero esto exige

una planificación detallada y una arquitectura muyestable.

Fase de Construcción Introducción al Proceso unificado RUP



30/51


El producto de software integrado y corriendo en la plataforma adecuada.

Manuales de usuario.

Una descripción del “release” actual.

Productos de la Fase de Construcción Introducción al Proceso unificado RUP



31/51


Se obtiene un producto beta que debe decidirse si puede

ponerse en ejecución sin mayores riesgos.

Condiciones de éxito:

¿el producto está maduro y estable para instalarlo en el

ambiente del cliente?

¿están los interesados listos para recibirlo?

Hitos


CapacidadOperacional




32/51


El objetivo es traspasar el software desarrollado a la

comunidad de usuarios.

Una vez instalado surgirán nuevos elementos que

implicarán nuevos desarrollos (ciclos).

Incluye:

pruebas beta para validar el producto con las expectativas del

cliente,

ejecución paralela con sistemas antiguos, conversión de datos,

entrenamiento de usuarios,

distribuir el producto.

Fase de Transición




33/51


Obtener autosuficiencia de parte de los usuarios.

Concordancia en los logros del producto de parte de las

personas involucradas.

Lograr el consenso cuanto antes para liberar el producto

al mercado.

Hitos


Producto




34/51


• Un trabajador define el comportamiento y lasresponsabilidades de un individuo.

• Es como un “sombrero” que la persona usa durante el

proyecto: – una persona puede tener varios sombreros,

– es el rol que desempeña en un momento dado.

• Las responsabilidades:

– hacer una serie de actividades,

– ser el responsable de una serie de artefactos.

Flujo de Trabajo (Workflows)

Trabajador




35/51


Una actividad es una unidad detrabajo que se asigna a un

trabajador:

crear o modificar un

artefacto.

Una actividad lleva entre un

par de horas y un par de días,

involucra un solo trabajador yun número pequeño de

artefactos.

Las actividades se consideranen la planificación y

evaluación del progreso del

proyecto.

Ejemplos: Planificar una iteración -

Administrador de proyecto.

Encontrar actores y casos de uso -

Analista.

Revisar el diseño - Revisor de

diseño.

Ejecutar pruebas de performance

- Ing. de pruebas de performance.


Actividades




36/51



Asignación de Actividades

Recurso Trabajador Actividad

Pablo Diseñador Diseño de Objetos

María Autor de Casos de Uso Detallar un Caso de Uso

José Diseñador de Casos de Uso Diseñar un Caso de Uso

Silvia Revisor de Diseño Rever el Diseño

Eduardo Arquitecto Análisis de ArquitecturaDiseño de Arquitectura




37/51


Elemento de información producido, modificado o usado

por el proceso.

Son los productos tangibles del

proyecto.

Son usados por los trabajadores

para realizar nuevas

actividades y son el resultadode esas actividades.

Ejemplos: Un modelo como el modelo

de casos de uso o el modelo

de diseño.

Un elemento del modelo,como una clase o un caso

de uso.

Un documento tal como elCaso del Negocio o la

Arquitectura del Software.

Código fuente.

Código ejecutable.


Artefactos




38/51


Una lista de actividades,trabajadores y artefactos no

constituye un proceso.

Un flujo de trabajo es una

secuencia de actividades que produce un resultado valioso.

No siempre es posible

representar flujos de trabajo.

Flujos de Trabajo (Workflows)

Análisis deArquitectura

Diseño deArquitectura

Describir Concurrencia

Describir Distribución

Análisis deCasos de Uso

Diseño deCasos de Uso

Análisis deObjetos Diseño deObjetos

Revisar elAnálisis

Revisar elDiseño

Revisar laArquitecturaRevisor de

Diseño

Diseñador

Diseñador deCasos de Uso

Arquitecto



Si d I f ió II


39/51


Flujos de Trabajo Esenciales

Flujos de Trabajode Ingeniería

Flujos de Trabajode Apoyo



Si d I f ió II


40/51


Existen habitualmente problemas de comunicación entreingenieros de software e ingenieros de negocios.

RUP proporciona un lenguaje y proceso común para

ambos ámbitos. Para el modelamiento del negocio se usan “business use

cases” y su objetivo es conocer el sistema actual o el

negocio.


Modelamiento del egocio



Si t d I f ió II


41/51


Los desarrolladores y clientes

deben acordar qué es lo que el

sistema debe hacer:

relevar requerimientos, documentar funcionalidad y

restricciones,

documentar decisiones,

identificar actores,

identificar casos de uso

Los casos de uso describen la

funcionalidad.

Los requerimientos no

funcionales se incluyen en una

especificación complementaria.


Requerimientos

Cliente Reciclar

Imprimir Informe

Operador

Administrar Depósito




42/51



43/51


Propósito:

definir la organización del código,

implementar clases y objetos en forma de componentes

(fuente, ejecutables, etc.),

probar las componentes desarrolladas,

integrar las componentes en un sistema ejecutable.


Implementación




44/51



45/51


Producir un producto yhacerlo llegar a sus

usuarios finales.

Incluye varias actividades: producir un “release”,

empaquetar el software,

distribuir el software,instalarlo,

asistir a los usuarios

A veces también incluye:realizar pruebas beta,

migración de datos,

aceptación formal. La mayor parte de la

distribución ocurre durante

la transición. Este es uno de los flujos

de trabajo menos

documentados en RUP.


Distribución





46/51


Flujo de Trabajo (Workflows)Elementos del RUP

Workflow, Workflow Detail , Workers, Actividades y Artefactos

Ejemplo

Workflow Detail:Analyse the ProblemWorkflow: Requirements

Actividades

Workers Artefactos





47/51


Modelo del negocio: establece una abstracción de la

organización Modelo del dominio: establece el contexto del sistema

Modelo de casos de uso: establece los requisitos

funcionales del sistema Modelo de análisis: establece un diseño de las ideas

Modelo de diseño: establece el vocabulario del problema

y su solución Modelo del proceso (opcional): establece los

mecanismos de concurrencia y sincronización del sistema

Artefactos Modelos





48/51


Modelo de despliegue: establece la topología hardware

sobre la cual se ejecutará el sistema Modelo de implementación: establece las partes que se

utilizarán para ensamblar y hacer disponible el sistema

físico Modelo de pruebas: establece las formas de validar y

verificar el sistema.

Artefactos Modelos





49/51


Artefactos Modelos





50/51


Modelos y flujos de trabajo del Proceso Unificado





51/51


Modelos y

Diagramas

en RUP


f

introduccion al proceso unificado

Documents