Rational Unified Process

Oswaldo E. Eusebio Rojas Universidad Garcilaso de la Vega

Temario

Introduccin
Concepto Vista

Dinmica y Esttica Caractersticas de RUP

Las seis mejores prcticas Disciplinas y Flujos de Trabajo Fases RUP y CMMI Conclusiones

Qu es un Proceso de Desarrollo de SW?

Define Quin debe hacer Qu, Cundo y Cmo debe hacerlo

Sistema nuevo o modificado

Requisitos nuevos o modificados

Proceso de Desarrollo de Software

No existe un proceso de software universal. Las caractersticas de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable

El Problema
Si un proceso es utilizado, equipos funcionales diferentes normalmente utilizan procesos y lenguajes de modelacin inconsistentes.
? ? ? ? ?
Requerimientos Pruebas Anlisis Diseo

La mayora de los proyectos de software utilizan procesos que no estn bien definidos. En su lugar los miembros del equipo (re)inventan sus propios procesos.

Los procesos no estn apropiadamente relacionados con herramientas, no estn propiamente automatizados.

Proceso

Herramienta

Conceptos fundamentales

Proceso:
Es

un marco de trabajo comn compuesto por actividades de trabajo (conjuntos de tareas, hitos, productos y puntos de garanta de calidad) y actividades de proteccin (garanta de calidad, gestin de configuracin y medicin) (Pressman 2001). el resultado previsto y consistente del proceso.

Producto:
Es

Conceptos fundamentales

Ciclo de vida del software:

Es

el conjunto de fases por las que pasa el software, que abarcan desde su creacin u origen, hasta su eliminacin o liquidacin formal.

Modelo de desarrollo:
Tambin

denominado Modelo de Proceso. Estrategia de desarrollo basada en el ciclo de vida, naturaleza del proyecto y metodologa, que determina las caractersticas especficas del proceso (Pressman 2001).

Rational Unified Process

RUP es un marco de trabajo genrico que puede especializarse para una variedad de tipos de sistemas, diferentes reas de aplicacin, tipos de organizaciones y diferentes tamaos de proyectos.
JACOBSON, Ivar; BOOCH, Grady y RUMBAUGH, James 2000 El proceso unificado de desarrollo de software, Addison Wesley

Nocin de Proceso
Actividad/Cmo? Describe una unidad de trabajo que puede ser asignada a un trabajador.

Trabajador/Quin? Rol que puede ser desempeado por un individuo o conjunto de individuos en la organizacin de desarrollo

Diseador

Diseo de Casos de uso

responsable de

Artefacto/Qu? Pieza de informacin que es producida, modificada, utilizada por un proceso

Caso de Uso

Paquete de Caso de Uso

Rational Unified Process

Creado por los 3 amigos: Grandy Booch (creador de The Booch Method), Ivar Jacobson e James Rumbag (creador de Object Modeling Technique = OMT) Aparece por primera vez en Junio de 1998 con el nombre de Rational Unified Process 5.0 (RUP) Fue puesto a disposicin pblica entre finales de 1998 e inicios de 1999. Centrado en tres Puntos: Personas Procesos Herramientas y mtodos

Evolucin de RUP

Estructura de RUP

El proceso puede describirse en dos dimensiones, o a lo largo de dos ejes: El eje horizontal representa tiempo y muestra el aspecto dinmico del proceso, expresado en trminos de ciclos, fases, iteraciones, y metas. El eje vertical representa el aspecto esttico del proceso; como est descrito en trminos de disciplinas: actividades, artefactos, trabajadores y flujos de trabajo.

El Ciclo de Vida del Software en RUP

El Ciclo de Vida del Software en RUP

El Ciclo de Vida del Software en RUP

El Ciclo de Vida del Software en RUP

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

RUP Visin Esttica

En su visin esttica, el modelo RUP est compuesto por: Roles: analista de sistemas, diseador, diseador de pruebas, roles de gestin y roles de administracin. Actividades: RUP determina el trabajo de cada rol a travs de actividades. Cada actividad del proyecto debe tener un propsito claro, y se asigna a un rol especfico. Las actividades pueden tener duracin de horas o de algunos das; y son elementos base de planificacin y progreso.

RUP Visin Esttica

En su visin esttica, el modelo RUP est compuesto por: Artefactos: Son los elementos de entrada y salida de las actividades. Son productos tangibles del proyecto. Las cosas que el proyecto produce o usa para componer el producto final (modelos, documentos, cdigo, ejecutables) Flujos de trabajo: son el pegamentode los roles, actividades, artefactos y disciplinas, y constituyen la secuencia de actividades que producen resultados visibles.

RUP Visin Esttica

En su visin esttica, el modelo RUP est compuesto por: Disciplinas: son contenedores empleados para organizar las actividades del proceso. RUP comprende 6 disciplinas de proceso y 3 de soporte. Proceso: modelado del negocio, requisitos, anlisis y diseo, implementacin, pruebas y desarrollo. Soporte: gestin de proyecto, gestin de configuracin y cambio, y entorno.

RUP Visin Dinmica

En su visin dinmica, la visin de la estructura del ciclo de vida RUP se basa en un desarrollo iterativo, jalonado por hitos para revisar el avance y planear la continuidad o los posibles cambios de rumbo. Cuatro son las fases que dividen el ciclo de vida de un proyecto RUP: 1.- Inicio. Es la fase de la idea, de la visin inicial de producto, su alcance. El esbozo de una arquitectura posible y las primeras estimaciones. Concluye con el hito de objetivo. 2.- Elaboracin. Comprende la planificacin de las actividades y del equipo necesario. La especificacin de las necesidades y el diseo de la arquitectura. Termina con el hito de Arquitectura.

RUP Visin Dinmica

3.-

Construccin. Desarrollo del producto hasta que se encuentra disponible para su entrega a los usuarios. Termina con el hito del inicio de la capacidad operativa. 4.- Transicin. Traspaso del producto a los usuarios. Incluye: manufactura, envo, formacin, asistencia y el mantenimiento hasta lograr la satisfaccin de los usuarios. Termina con el hito de entrega del producto.

RUP Visin Dinmica

Fases
Disciplinas de Procesos
Inicio Elaboracin Construccin

Transicin

Modelacin de Negocios Requerimientos Anlisis y Diseo

Esttica

Implementacin
Prueba Despliegue

Disciplinas de Soporte
Admin. Configuracin

Administracin Ambiente
Iteracin(es) Preliminar Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1

Iteraciones

Dinmica

Conformacin del Equipo

ROLES Gestor del proyecto Analista del sistema TAREAS ASIGNADAS Establecer Condiciones de Trabajo Encontrar Actores y Casos de Uso Estructurar el Modelo de Casos de Uso Priorizar los Casos de Uso Efectuar el Anlisis Arquitectural Efectuar el Diseo Arquitectural Efectuar la Implementacin Arquitectural Detallar un Caso de Uso Prototipar una Interfaz de Usuario Analizar un Caso de Uso Disear un Caso de Uso

Arquitecto del sistema

Especificador de casos de uso Diseador de interfaz de usuario Ingeniero de casos de uso

Conformacin del Equipo

ROLES TAREAS ASIGNADAS

Ingeniero de componentes

Analizar una Clase Analizar un Paquete Disear una Clase Disear un Subsistema Implementar un Subsistema Implementar una Clase Realizar una Prueba de Unidad Implementar una Prueba
Integrar el Sistema Planear las Pruebas Disear las Pruebas Evaluar las Pruebas Realizar una Prueba de Integracin Realizar las Pruebas del Sistema

Integrador del sistema Ingeniero de pruebas Verificador de integracin Verificador del sistema

Caractersticas de RUP

Dirigido por los Casos de Uso

Centrado en la Arquitectura

Iterativo e Incremental

Dirigido por Casos de Uso

Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un resultado de valor a un usuario. Los casos de uso modelan los requerimientos funcionales del sistema. Los casos de uso tambin guan el proceso de desarrollo (diseo, implementacin y pruebas). De este modo los casos de uso no solo inician el proceso de desarrollo sino que le proporcionan un hilo conductor, que avanza a travs de una serie de flujos de trabajo.

Dependencia entre los Casos de Uso y los dems modelos

<<communicate>> Administrador

Consulta <<extend>>

Identificacion

Especificado por

Realizado por

Distribuido por

Implementado por

Modelo de anlisis

Modelo de diseo Modelo de despliegue

Verificado por Modelo de implementacin

X OX

X OX X OX

Modelo de prueba

Iterativo e incremental

Es prctico dividir el esfuerzo de desarrollo de un proyecto de software en partes mas pequeas o mini proyectos. Cada mini proyecto es una iteracin que resulta en un incremento. Las iteraciones deben seleccionarse y ejecutarse de forma planificada. Esta seleccin se basa en dos cosas: El conjunto de casos de uso que amplan funcionalidad En los riesgos mas importantes que deben mitigarse En cada iteracin se identifica y especifica los casos de uso relevantes, se crea un diseo utilizando la arquitectura seleccionada como gua, para implementar dicho caso de uso.

Desarrollo en cascada tradicional retarda la reduccin del Riesgo

R I E S G O

An. Requer. Diseo Cod. & Test U.

Test Subs. Test. Sistema

T I EMPO

Aplicando cascada iterativamente

Iteracin 1
R D C T R D C T

Iteracin 2

Iteracin 3
R D C T

T I EMPO

Las primeras iteraciones reducen los principales riesgos Cada iteracin produce una versin ejecutable, un incremento adicional al sistema Cada iteracin incluye integracin y test

Centrado en la Arquitectura

La arquitectura se describe mediante diferentes vistas del sistema en construccin. Incluye aspectos estticos y dinmicos. La arquitectura es una vista del diseo completo con las caractersticas ms importantes resaltadas, dejando de los detalles de lado. La arquitectura debe permitir el desarrollo de todos los casos de uso requeridos actualmente y a futuro, y los casos de uso deben encajar en la arquitectura.

Organizacin de Modelos
Vistas de UML: Arquitectura 4 + 1

5 Vistas 9 Diagramas

Diagramas de Casos de Uso

casos de uso

Diagramas de Casos de Uso

Usados Para Comunicarse con el Usuario Final y el Experto de Dominio

Proporciona credibilidad en una etapa inicial del desarrollo del sistema Asegura una comprensin mutua de los requisitos

Usados Para Verificar

Que se hayan capturado todos los requerimientos Que los desarrolladores hayan entendido los requerimientos

Diagramas de Casos de Uso

Lmite
Sistema de Pub

extiende

Informar Bodega

Sistema de Bodega extend

incluye
Vender Bebida Barmen include

caso de uso

Registrar Venta

actor

Diagramas de Clases

Diagramas de Clases

Usados para mostrar la Estructura Esttica de un sistema computacional o una parte relevante del mundo real Son los diagramas ms frecuentemente usados. Y se les puede considerar con Tres Perspectivas posibles:

Conceptual muestra las entidades del mundo real con sus relaciones Especificacin muestra la estructura del sistema o sus partes, destacando las interfaces Implementacin el diseo del cdigo fuente

Diagramas de Clases
asociacin
Cliente 1 1..* 1 Venta Pedido tiene

Bodega

1 almacena 0..* Bebida

1..*

atributo operacin

valor: Doble ImprimirBoleta() 0..* realiza 1

herencia
Jugo Natural Gaseosa

clase

Barmen

multiplicidad

Diagramas de Secuencia

Diagramas de Secuencia

Usados para representar el comportamiento del sistema Muestran colaboracin a travs de mensajes entre los objetos del sistema Destacan:

Mensajes enviados entre los objetos Orden secuencial entre los mensajes Un escenario concreto, sin condiciones

tiles tanto en anlisis (identificacin de clases), como en diseo (especificacin de componentes)

Diagramas de Secuencia
objeto
Pepe :Barmen Interfaz Barmen Motor Venta BD de Ventas

Ingresar Datos Venta

lnea de vida

Confirmar Venta

Ejecutar Venta 12345 :Venta Crear Venta

creacin de objeto ciclos

mensaje
Crear Bebida Frambuesa :Jugo Natural

{x N}

Ingresar Venta

destruccin de objeto

(from Use Case View)

(from Use Case View)

(from Logical Model)

(from Logical Model)

(from Use Case View)

Diagramas de Colaboracin

Diagramas de Colaboracin
Usados para representar el comportamiento del sistema
Muestran colaboracin entre los objetos del sistema Destacan:
Mensajes enviados entre los objetos Enlaces entre los objetos Un escenario concreto, sin condiciones

tiles tanto en anlisis (identificacin de clases), como en diseo (especificacin de componentes)

Diagramas de Colaboracin
objeto
Bucarest :Sistema de Bodega 1.5 Pedir Bebida

mensaje
Pepe :Barmen 1 Vender Jugo Natural

1.4 Pedir Bebida

Comunicador Bodega 1.3 Pedir Bebida

Interfaz Bodega

1.1 Vender Jugo Natural 1.2 Calcular Cantidad Bebida Interfaz Barmen El clculo di la cantidad bajo la mnima permitida - hay que pedir bebida de la bodega

Motor Venta

enlace

Diagramas de Actividades

Diagramas de Actividades
Usados para representar el comportamiento del sistema o negocio
Muestran actividades y procesos Destacan:
Condiciones y flujos alternativos Tareas y procesos concurentes Responsabilidades sobre ciertas actividades

tiles en anlisis de negocio para capturar procesos de alto nivel

Diagramas de Actividades
decisin
Candidad

Venta de Bebida

[si]

< Mnima Permitida

Pedir Bebida de Bodega

Barmen Ingresa Venta Inicio

Sistema Valida Cantidad Bebida

[no]

Fin Sistema Registra Venta

actividad

sincronizacin

Diagrama de Estados

Diagrama de Estados
Usados para representar el comportamiento INTERNO de un objeto o de un mdulo del sistema Muestran estados en los cuales un objeto se puede encontrar

Destacan:
Estados Transiciones y condiciones de las transiciones Actividades realizadas

Tpicamente usados para describir ciclo de vida de un objeto

Diagrama de Estados
inicio
Inicio

estado

INGRESADO
servir

SERVIDO

transicin

cancelar

cobrar

1 da

Si el estado no se cmbia durante 1 da

CANCELADO COBRADO PERDIDO

fin
a Pedidos Anulados a Pedidos Cobrados A Pedidos Perdidos

Diagrama de Componentes

Diagrama de Componentes
Usados para mostrar los Mdulos Fsicos de software:
Los ejecutables y libreras dinmicas Las pginas WEB y los scripts Los mdulos o funciones, etc.

Sin embargo se usan ms bien para capturar la Organizacin de los Componentes de Software (EXE, DLL, EJB, etc) Destacan Dependencias entre los Componentes

Diagrama de Componentes
EJB

interfaz
Barmen (from Use Case View) EJB Vendedor VendedorRemote

Bodeguero BodegueroLocal

executable TouchScreen DAO Venta

Sistema de Bodega (from Use Case View)

dependencia

componente

Oracle BDPub

Diagrama de Distribucin

Diagrama de Distribucin
Usados Para Modelar las Relaciones entre el Software y el Hardware Mapeo de los Componentes de Software a los Nodos de Hardware Tpicamente contienen elementos tales como
Servidores Procesadores Impresoras Redes computacionales Etc.

Cliente TouchScreen

Serv idor Bodega

nodo

executable :TouchScreen

EJB :Bodeguero

Serv idor Pub EJB Barmen (from Use Case View) :Vendedor Sistema de Bodega (from Use Case View)

DAO :Venta

enlace
Serv idor BD

Oracle :BDPub

Diagrama de Distribucin

Modelos y Flujos de Trabajo

Modelado del Nego- Requisitos cio Modelo del Negocio Modelo del Dominio Modelo de Casos de Uso Modelo de Anlisis Modelo de Diseo Modelo de Despliegue Modelo de Implementacin Modelo de Prueba X X X X X X X X X X X X Anlisis Diseo Implementacin Prueba Despliegue

Seis Mejores Prcticas

Seis Mejores Prcticas

Administrar requerimientos

Desarrollar Iterativamente

Verificar Calidad

Modelizar Visualmente

Arquitecturas Basadas en Componentes

Controlar Cambios

Desarrollo Iterativo
El software moderno es complejo y novedoso. No es realista usar un modelo lineal de desarrollo como el de cascada. Un proceso iterativo permite una comprensin creciente de los requerimientos a la vez que se va haciendo crecer el sistema. RUP sigue un modelo iterativo que aborda las tareas ms riesgosas primero. Con esto se logra reducir los riesgos del proyecto y tener un subsistema ejecutable tempranamente.

Desarrollo Iterativo

Cada iteracin resulta en un release ejecutable

Requerimientos Planeamiento Anlisis y Diseo

Planeamiento Inicial

Ambiente de Administracin Evaluacin

Implementacin

Prueba

Distribucin

Administracin de requerimientos
RUP describe cmo: Obtener los requerimientos Organizarlos Documentar requerimientos de funcionalidad y restricciones Rastrear y documentar decisiones Captar y comunicar requerimientos del negocio

Los casos de uso y los escenarios indicados por el proceso han probado ser una buena forma de captar requerimientos y guiar el diseo, la implementacin y las pruebas.

Administracin de requerimientos

Req. 10

Aprobado

Bajo

Alta
Baja

$$$

Req. 13

Propuesto

Medio

$$

Req. 40

Obligatorio

Alto

Alto

Arquitecturas basadas en componentes

El proceso se basa en disear tempranamente una arquitectura base ejecutable. La arquitectura debe ser: Flexible Fcil de modificar Intuitivamente comprensible Promueve la reutilizacin de componentes RUP apoya el desarrollo basado en componentes, tanto nuevos como preexistentes.

Arquitecturas basadas en componentes

Funciones de cliente/ productos Funciones de licenciamiento

Mecanismos de interfaces

Cliente

Producto

Licencia

Comprado

Existente

Database

CRM

Nuevo

Modelamiento Visual
Modelamiento visual de la estructura y el comportamiento de la arquitectura y los componentes. Bloques de construccin: Permiten la comunicacin en el equipo de desarrollo Permiten analizar la consistencia: entre las componentes entre diseo e implementacin UML es la base del modelamiento visual de RUP.

Modelamiento Visual

Diagramas de Casos de Uso Diagramas de Clases Diagramas de Estados Diagramas de Componentes Diagramas de Implementacin
Subsistemas

Modelizacin Visual eleva el nivel de abstraccin

Clases Cdigo

Verificacin de la Calidad
La actividad fundamental de esta prctica es el testing Evaluar continuamente la calidad de un sistema con respecto a funcionalidad, confiabilidad, performance El aseguramiento de la calidad es parte del proceso de desarrollo y no la responsabilidad de un grupo independiente.

Verificacin de la Calidad
Plan de actividades de aseguramiento de la calidad
Conjunto de actividades que sern ejecutadas para generar confianza en que el producto cumplir con los requerimientos y el proceso es efectivo

Cliente

Validaciones
Verificaciones

Necesidades

Requisitos

Producto

Revisiones

Control de cambios
Los cambios son inevitables, pero es necesario evaluar si stos son necesarios y rastrear su impacto. RUP indica como controlar, rastrear y monitorear los cambios dentro del proceso iterativo de desarrollo. Las solicitudes de cambios formales facilitan la claridad de comunicacin La propagacin del cambio es evaluable y controlable Controlar, registrar y monitorear los cambios para posibilitar el desarrollo iterativo

Control de cambios
Administracin de configuracin y cambios
rdenes de Trabajo
Peticin de cambios y arreglo de defectos
Administracin de configuracin

Fallas reportadas

Calidad del producto

Peticin de nuevas caractersticas

Disciplinas y Flujos de Trabajo

Disciplinas
Una disciplina es una coleccin de actividades relacionadas vinculadas con un rea especfica del proyecto. Este agrupamiento de actividades en disciplinas es principalmente para facilitar la comprensin del proyecto desde la perspectiva tradicional del modelo en cascada.

Flujo de Trabajo
Un flujo de trabajo describe la secuencia en que se realizan las actividades en una disciplina, quienes la realizan (trabajadores) y que artefactos producen..

Disciplinas de Proceso
1.

2.

3.

4.

5.

6.

Modelado del negocio: describe la estructura y la dinmica de la organizacin. Requisitos: describe el mtodo basado en casos de uso para extraer los requisitos. Anlisis y diseo: describe las diferentes vistas arquitectnicas. Implementacin: tiene en cuenta el desarrollo de software, la prueba de unidades y la integracin. Pruebas: describe los casos de pruebas, los procedimientos y las mtricas para evaluacin de defectos. Despliegue: cubre la configuracin del sistema entregable.

Disciplinas de Soporte
1.

2.

3.

Gestin de configuraciones: controla los cambios y mantiene la integridad de los artefactos de un proyecto. Gestin del Proyecto: describe varias estrategias de trabajo en un proceso iterativo. Entorno: cubre la infraestructura necesaria para desarrollar un sistema.

Disciplinas y Flujos de Trabajo

Disciplinas de Proceso

Disciplinas de Soporte

Modelamiento de Negocio

Los objetivos son: Entender la estructura y la dinmica del negocio. Asegurar que los clientes, usuarios y desarrolladores tengan un entendimiento comn de la organizacin. Un Modelo de Casos de Uso del Negocio describe los proceso de negocio de una empresa en trminos de

casos de uso del negocio y actores del negocio

que

se corresponden con los procesos del negocio y los clientes respectivamente .

Modelamiento de Negocio Flujo de Trabajo

Requerimientos
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 requerimientos no funcionales se incluyen en una especificacin complementaria.

Requerimientos Flujo de Trabajo

Anlisis y Diseo
Objetivos: Ejecutar las tareas y funciones descritas en los casos de uso Satisfacer todos los requerimientos Flexible a cambios El diseo se centra en la nocin de arquitectura Disear y validar la arquitectura es una tarea esencial. El modelo de diseo consta de Clases estructuradas en paquetes Diseos de subsistemas con interfaces definidas (componentes) Forma de colaboracin entre las clases.

Anlisis y Diseo Flujo de Trabajo

Implementacin
Objetivo:

Definir la organizacin del cdigo Implementar clases y objetos en forma de componentes (fuente, ejecutables, etc.) Probar las componentes desarrolladas Integrar las componentes en un sistema ejecutable

Implementacin Flujo de Trabajo

Test
Objetivo: Verificar la interaccin entre los objetos Verificar la integracin apropiada de componentes Verificar que se satisfacen los requerimientos Identificar los defectos y corregirlos antes de la instalacin RUP describe como planear y ejecutar estas pruebas. RUP propone probar los componentes desde el principio: Confiabilidad, funcionalidad y performance.

Test Flujo de Trabajo

Despliegue
Producir un producto y hacerlo llegar a sus usuarios finales. Incluye varias actividades: Producir un release Empaquetar el software Distribuir el software Realizar pruebas beta Instalar el software Apoyar a los usuarios Migracin de datos

Despliegue Flujo de Trabajo

Administracin y Configuracin de Cambios

Forma de controlar los artefactos producidos por las personas que trabajan en el proyecto. Algunos problemas habituales: Actualizaciones simultneas Mltiples versiones RUP da guas para: Desarrollos en paralelo Automatizar la construccin Administrar defectos

Administracin y Configuracin de Cambios Flujo de Trabajo

Administracin del Proyecto

Es el arte de balancear objetivos contrarios, manejar riesgos y producir software que satisface a clientes y usuarios. Existen pocos proyectos realmente exitosos. RUP incluye: Un framework para manejo de proyectos de software Guas para planificacin, provisin de personal, ejecucin y monitoreo de planes Un framework para manejar riesgos

Administracin del Proyecto Flujo de Trabajo

Entorno
Ambiente y herramientas de desarrollo que harn posible llevar a cabo el proyecto. RUP gua en la configuracin de un ambiente de proceso apropiado a cada proyecto. Se debe seleccionar un conjunto de artefactos para el proyecto, esta eleccin se puede recoger en un documento breve llamado Marco de Desarrollo

Entorno

Requerimientos

El propsito fundamental del flujo de trabajo de los requisitos es guiar el desarrollo hacia el sistema correcto. Hay diferentes puntos de partida para la captura de requisitos. En algunos casos comenzamos haciendo un modelo del negocio o partimos de uno ya desarrollado. En otros casos el cliente puede ya haber desarrollado una especificacin completa de requisitos no basada en objetos, de la cual podemos partir.

Requerimientos - Workflow
Analista
Arquitecto

Especificador de Casos de uso

Diseador de interface

Requerimientos
Trabajador Analista de sistemas Responsable de (artefacto) Modelo de casos de uso

Actores
Glosario Especificador de casos de uso Diseador de Interfaz de Usuario Arquitecto Caso de uso Prototipo de interfaz de usuario Descripcin de la arquitectura (vista del modelo de casos de uso)

Anlisis

Durante el anlisis, revisamos los requisitos que se describieron en la captura de requisitos, refinndolos y estructurndolos. El objetivo de hacerlo es conseguir una comprensin ms precisa de los requisitos y una descripcin de los mismos que sea fcil de mantener y que nos ayude a estructurar el sistema entero, incluyendo su arquitectura.

Anlisis - Workflow
Arquitecto Ing de Casos de Uso Ing de Componentes

Anlisis
Trabajador Arquitecto Responsable de (artefacto) Modelo de Anlisis Descripcin de la arquitectura

Ingeniero de Casos de Uso

Realizacin de casos de usos Anlisis -

Ingeniero de Componentes

Clases del Anlisis Paquete del anlisis

Diseo

Durante el diseo modelamos el sistema y su arquitectura para que soporte los requisitos funcionales y no funcionales. Una entrada esencial al diseo es el modelo de anlisis. El diseo es el centro de atencin al final de la fase de elaboracin y comienzo de las iteraciones de construccin .

Diseo
Modelo de Anlisis
Modelo conceptual. Genrico respecto al diseo (aplicable a varios diseos) Tres estereotipos: entidad, control, interface.

Modelo de Diseo
Modelo fsico (implementacin) Especfico para una implementacin Cualquier nro. de estereotipos fsicos.

Menos formal. Menos caro de desarrollar

Mas formal. Ms caro.

Diseo
Modelo de Anlisis Menos capas. Dinmico (no muy centrado en la secuencia) Creado principalmente como trabajo manual Modelo de Diseo Ms capas. Dinmico (muy centrado en la secuencia) Creado fundamentalmente como "programacin visual" en ing.de ida y vuelta. Debe ser mantenido todo el ciclo de vida.

Puede no mantenerse todo el ciclo de vida.

Diseo - Workflow
Arquitecto Ing de Casos de Uso Ing de Componentes

Diseo
Trabajador Arquitecto Responsable de (artefacto) Modelo de diseo Modelo de despliegue Descripcin de la arquitectura

Ingeniero de Casos de Uso

Realizacin de casos de usos Diseo Clases del diseo

Ingeniero de Componentes

Subsistema de Diseo Interfaz

Implementacin

Se inicia con el resultado del diseo y se implementa el sistema en trmino de componentes, es decir, ficheros de cdigo fuente, scripts, ficheros de cdigo binario, ejecutables, y similares. Es el centro durante las iteraciones de construccin. Aunque tambin se realiza durante:
La

fase de elaboracin, para crear la lnea base ejecutable de la arquitectura La fase de transicin para tratar defectos tardos.

Implementacin
Trabajador Arquitecto Responsable de (artefacto) Modelo de implementacin Modelo de despliegue Descripcin de la arquitectura
Integracin de sistema Componente Implementacin de subsistema Interfaz

Integrador de sistema Ingeniero de Componentes

Implementacin - Workflow
Arquitecto Integrador del Sistema Ingeniero de Componentes

Prueba

Los objetivos de la prueba son:

Planificar

las pruebas necesarias en cada iteracin, incluyendo las pruebas de integracin y las pruebas de sistema. Disear e implementar pruebas creando:
Casos de prueba (especifican qu probar), Procedimientos de prueba (especifican cmo realizar las pruebas), Componentes de prueba para automatizar las pruebas.

Realizar

las pruebas.

Prueba
Trabajador Diseador de Pruebas Responsable de (artefacto) Modelo de pruebas Casos de Prueba Procedimientos de prueba Evaluacin de pruebas Plan de pruebas Componente de pruebas
Defecto

Ingeniero de Componentes
Ingeniero de Pruebas de Integracin

Ingeniero de Pruebas de Sistema

Defecto

Fases

Fase de Inicio

Durante la fase de inicio se desarrolla la descripcin del producto final, y se presenta el anlisis del negocio. Esta fase responde las siguientes preguntas:
Cules son las principales funciones del sistema para los usuarios mas importantes? Cmo podra ser la mejor arquitectura del sistema? Cul es el plan del proyecto y cuanto costar desarrollar el producto?

En esta fase se identifican y priorizan los riesgos mas importantes.

Fase de Inicio

Los objetivos son:

Poner en marcha el proyecto Desarrollar el anlisis del negocio hasta justificar la puesta en marcha plan de proyecto

Para ello

Esbozar una arquitectura Mitigar los riesgos Anlisis inicial del negocio (coste, agenda, recuperacin de la inversin)

Fase de Inicio
Artefactos
Un documento de visin general: Requerimientos generales del proyecto Caractersticas principales Restricciones Modelo inicial de casos de uso (10% a 20 % listos). Glosario. Caso de negocio: Contexto Criterios de xito Pronstico financiero Identificacin inicial de riesgos. Plan de proyecto. Uno o ms prototipos.

Fase de Inicio
Hito:
Objetivos del Ciclo de Vida

Inicio

Elaboracin

Construccin

Transicin

Las partes interesadas deben acordar el alcance y la estimacin de tiempo y costo. Comprensin de los requerimientos plasmados en casos de uso.

Fase de Elaboracin

Durante la fase de elaboracin se especifican en detalle la mayora de los casos de uso del producto y se disea la arquitectura. Las iteraciones en la fase de elaboracin:
Establecen

una firme comprensin del problema a

solucionar. Establece un plan detallado para las siguientes iteraciones. Elimina los mayores riesgos.

El resultado de esta fase es la lnea base de la arquitectura.

Fase de Elaboracin

Los objetivos son:

Recopilar

la mayor parte de los requisitos definindolos como casos de uso Establecer una arquitectura slida para guiar las fases posteriores Continuar la observacin y control de los riesgos crticos Completar el plan de proyecto

Para ello

Se toman decisiones considerando la comprensin global del sistema: mbito, requisitos funcionales y no funcionales

Fase de Elaboracin
Artefactos:
Modelo de casos de uso (80% completo) con descripciones detalladas. Otros requerimientos no funcio-nales o no asociados a casos de uso. Descripcin de la Arquitectura del Software. 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.

Fase de Elaboracin
Hito:
Arquitectura de Ciclo de Vida

Concepcin

Elaboracin

Construccin

Transicin

Condiciones de xito de la elaboracin: Es estable la visin del producto? Es estable la arquitectura? Las pruebas de ejecucin demuestran que los riesgos han sido abordados y resueltos? Estn de acuerdo con el plan todas las personas involucradas?

Fase de Construccin
En esta fase todas las componentes restantes se desarrollan e incorporan al producto. Todo es probado en profundidad. El nfasis est en la produccin eficiente y no ya en la creacin intelectual. Puede hacerse construccin en paralelo, pero esto exige una planificacin detallada y una arquitectura muy estable.

Fase de Construccin

Los objetivos son: Lnea base de la arquitectura crece hasta convertirse en el sistema completo Riesgos reducidos o rutinarios Implementacin de los casos de uso Prototipo Para ello A travs de sucesivas iteraciones e incrementos se desarrolla un producto software, listo para operar, ste es frecuentemente llamado versin beta

Fase de Construccin
Artefactos:
El producto de software integrado y corriendo en la plataforma adecuada. Manuales de usuario.

Una descripcin del release actual.

Fase de Construccin
Hito:
Capacidad Operacional

Concepcin

Elaboracin

Construccin

Transicin

Se obtiene un producto Beta que debe decidirse si puede ponerse en ejecucin sin mayores riesgos. Condiciones de xito: El producto est maduro y estable para instalarlo en el ambiente del cliente? Estn los interesados listos para recibirlo?

Fase de Transicin

Los objetivos son: Cumplir requisitos Gestionar todos los aspectos de implantacin Pruebas de aceptacin

Para ello Las iteraciones en esta fase continan agregando caractersticas al sw. El equipo se encuentra ocupado en corregir y extender la funcionalidad del sistema desarrollado en la fase anterior.

Fase de Transicin
El objetivo es traspasar el software desarrollado a la comunidad de usuarios. Una vez instalado surgirn nuevos elementos que implicarn nuevos desarrollos (ciclos). Incluye: Pruebas Beta para validar el producto con las expectativas del cliente Ejecucin paralela con sistemas antiguos Conversin de datos Entrenamiento de usuarios Distribuir el producto

Fase de Transicin
Hito:
Producto

Concepcin

Elaboracin

Construccin

Transicin

Condiciones de xito: Se han alcanzado los objetivos fijados en la fase de Inicio ? El usuario est satisfecho ?

RUP y CMMI

Modelo CMMI

Capability Maturity Model Integration. Modelo para la mejora o evaluacin de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Desarrollado por el Instituto de Ingeniera del Software de la Universidad Carnegie Mellon (SEI), y publicado en su primera versin en enero de 2002. Para los usuarios es difcil especificarlos en forma cuantitativa

Modelo CMMI

CMMI se desarroll para facilitar y simplificar la adopcin de varios modelos de forma simultnea, y su contenido integra y da relevo a la evolucin de sus predecesores:
CMM-SW

(CMM for Sofwtare) SE-CMM(Systems Engineering Capability Maturity Model) IPD-CMM(Integrated Product Development)

CMMI Niveles de Madurez

NIVEL 1-Inicial 2-Repetible Descripcin Punto base. La organizacin tiene procesos ad-hoc o caticos. El xito se debe a personas herocas. La organizacin empieza a guardar informacin. Ya hay definiciones, pueden repetirse xitos anteriores.

3-Definido

Se conocen procesos estndares para desarrollar o mantener software. Hay prcticas de Ingeniera de Software y de Administracin de procesos.

4-Administrado

Se usan datos recolectados. Las decisiones estn basadas en datos cuantitativos. Los procesos son medidos, hay retroalimentacin. La organizacin se dedica a mejorar contnuamente. Se localizan debilidades y fortalezas.

5-Optimizado

CMMI Areas Clave de Proceso (KPAs)

NIVEL 1-Inicial 2-Repetible Gestin de Requisitos (REQM), Planificacin de proyecto, Monitorizacin y control de Proyectos, Gestin y acuerdo de suministros, Medicin y Anlisis, Gestin de la calidad de procesos y productos, Gestin de la configuracin Desarrollo de requisitos (RD), Solucin tcnica, Verificacin, Validacin, Integracin de producto, Procesos orientados a la organizacin, Formacin, Gestin Integrada de proyecto, Gestin de riesgos, Anlisis y resolucin de decisiones Gestin cuantificada de proyectos, Rendimiento de los procesos de la organizacin Innovacin y desarrollo reas Clave de Proceso

3-Definido

4-Administrado 5-Optimizado

Anlisis RUP CMMI

RUP es un proceso que define quin debe hacer las cosas, qu debe hacerse, cmo y cundo. Dado su enfoque mantiene modelos en lugar de gran cantidad de documentacin, utiliza un lenguaje concreto y bien definido (UML).
CMMI es un modelo esttico que define reas claves (PA) en las que se deben llevar a cabo prcticas especficas o genricas, por lo tanto el hecho de implementar RUP en el desarrollo de un proyecto implica que ciertas KPA de CMMI sean alcanzadas y otras no.

Anlisis RUP CMMI

reas Clave de Proceso Gestin de Requisitos Planificacin de proyecto Monitorizacin y control de Proyectos Revisin RUP define claramente el proceso de administracin de requerimientos y aporta herramientas como los casos de uso, es una de las bases de RUP RUP habla de la planeacin del proyecto de manera iterativa y del control de riesgos. RUP define cmo debe ser el control del proyecto.

Gestin de la configuracin

RUP es muy claro cuando se habla de administracin de la configuracin incluso es una de las mejores prcticas recomendada.

Anlisis RUP CMMI

reas Clave de Proceso Revisin

Gestin y acuerdo de RUP no menciona nada sobre administracin de suministros acuerdos, es algo no considerado. Medicin y Anlisis Gestin de la calidad de procesos y productos La medicin y anlisis no estn contemplados detalladamente en RUP. En la etapa de transicin se lleva a cabo la verificacin de la calidad aunque no tan detallada como lo exige CMMI. La verificacin de calidad del producto est bien definida pero la evaluacin de calidad del proceso no est considerada.

Conclusiones

Conclusiones

La aplicacin formal del Proceso Unificado supone: Desventajas: Grandes esfuerzos en la construccin de modelos. Necesidad del soporte de herramientas informticas. Ventajas: Disminuye el riesgo del error de anlisis / diseo acumulado. Aligera el esfuerzo en implementacin. Proporciona la documentacin del ciclo de vida en el mismo proceso.

Conclusiones

El Proceso Unificado es flexible y se puede adaptar al grado de complejidad del modelo de proceso de desarrollo (descarte de algunos modelos o flujos). El Proceso Unificado es abierto y permite la incorporacin de enfoques y artefactos complementarios: Patrones de diseo. Patrones de implementacin. Combinacin de varios modelos de proceso. Arquitecturas Dirigidas por Modelos (Model Driven Architectures).

Bibliografa
1.

2.

3.

4.

5.

6.

7.

Booch G., Rumbaugh J., Jacobson I. El Lenguaje Unificado de Modelado, Addison-Wesley, Madrid, 1999. Bruegge B., Dutoit A.H. Ingeniera de Software Orientado a Objetos, Prentice Hall Pearson educacin, Mxico, 2002. Jacobson I., Booch G., Rumbaugh J. El Proceso Unificado de Desarrollo de Software, Addison-Wesley, Madrid, 2000. Pressman R.S. Ingeniera del Software. Un enfoque prctico (5 ed.) Mc Graw-Hill; New York , 2001. Rumbaugh J., Jacobson I., Booch G. El Lenguaje Unificado de Modelado. Manual de Referencia, Addison-Wesley, Madrid, 2000. Sommerville I. Ingeniera de software, 6 edicin, Prentice Hall Pearson educacin, Mxico, 2002. Stevens P., Pooley R. Utilizacin de UML en Ingeniera del Software con Objetos y Componentes, Addison-Wesley, Madrid, 2002.