Tema #1 Proceso Unificado de Desarrollo

Objetivos
Tema #1. Proceso Unificado de Desarrollo

Proporcionar una perspectiva general de RUP y la Ingeniera del Software Caracterizar las fases y flujos de trabajo principales en el Proceso Unificado de Desarrollo Contextualizar el uso de los Modelos del Negocio como paso inicial del Desarrollo del Software Aprender la diferencia entre fase y disciplina

Desarrollo de Software. Las 4 P

Tema #1. Proceso Unificado de Desarrollo

Procesos

Unified Process (UP) Rational Unified (Process) RUP OPEN OOSP ... Automatizacin

Plantilla

Personas

Participantes

Proyecto

Herramientas
Modelado Visual UML Rational Rose, Visual UML, Objecteering Integrated Development Environment (IDE) Visual Studio .NET, NetBeans... Gestin de la Configuracin CVS, ClearCase Gestin de Requisitos RequiistPro,.. Automatizacin documentacin SoDa ....

Resultado

Producto
Modelos Codigo fuente Ejecutables Documentacin

Proceso de Ingeniera de Software

Tema #1. Proceso Unificado de Desarrollo

Conjunto de actividades que permiten transformar los requisitos de un cliente/usuario en un sistema software. Conjunto de procedimientos, tcnicas, herramientas y soporte documental que ayuda a los desarrolladores a realizar nuevo software.
Requisitos
Proceso de Desarrollo Software

Sistema Software

LESE-1 Introduccin al Modelado Visual

El Proceso Unificado de Desarrollo

Tema #1. Proceso Unificado de Desarrollo

Es un proceso de ingeniera del software que agrupa las 6 mejores prcticas de desarrollo software que existen en el mercado

Tiempo

Contenido

Proceso Unificado 6 Best Practices

Tema #1. Proceso Unificado de Desarrollo

Desarrollar Iterativamente Gestionar Requisitos Usar Arquitecturas de Componentes Modelar Visualmente (UML) Continuamente verificar Calidad del Software Controlar Cambios en el Software

Proceso Unificado - Caractersticas

Tema #1. Proceso Unificado de Desarrollo

Dirigido por Casos de Uso

Funcionalidad de valor para los usuarios Descripcin de aspectos estticos y dinmicos del software que son mas significativos Divide el trabajo en mini-proyectos que incrementalmente crean el producto software

Centrado en la Arquitectura

Iterativo e Incremental

Modelos de Sistema Software en RUP

Tema #1. Proceso Unificado de Desarrollo
realizado por

Bussiness Use Case Model

Bussines Object Model

automatizado por

Use Case Model

especificado por realizado por

Analysis Model

implementado por

Design Model

distrbuido por verificado por

Modelos en el Proceso Unificado de Desarrollo de Software

Implementation Model Deployment Model Test Model 9

Metodologa Cobertura del Curso

Tema #1. Proceso Unificado de Desarrollo

10

Disciplinas-Modelos-Artefactos
Tema #1. Proceso Unificado de Desarrollo

Bussiness Modeling Modelo Conceptual

Casos de Uso del Negocio Modelo de Objetos del Negocio

Requirements/Analysis Modelo de Casos de Uso

Diagramas UML de Casos de Uso Especificacin de Casos de Uso

Modelo de Comportamiento
Diagramas UML de Secuencia/Colaboracin Diagramas UML de Estados/Actividades

11

Metodologa (requerimientos)
Tema #1. Proceso Unificado de Desarrollo

Dominio
conceptos reglas dominio

Restricciones OCL

Glosario

Modelo Conceptual

Process Sale

Payment Authorization Service

System : Cashier makeNewSale() enterItem(id,quantity)

Cashier Process Rental Accounting System

: Payment Authorization Service

add file

add file [ numberOffile==MAX ] / flag OFF

Writ ing

Openning

endSale()

Cash In
makePayment(amount)
Reading close file Closing

close file

HR System Manage Users

performed

validatePayment() ok

Requisitos Automatizacin

System Administrator Mangage Accounts

...

Descripciones c.u.

Modelo Comportamiento Secuencia Eventos Diagramas Estados

(actores-sistema)
(objetos dominio / Sistema)

Modelo Casos de Uso

12

Metodologa - (Anlisis y Diseo)

Tema #1. Proceso Unificado de Desarrollo

Glosario

Modelo Conceptual (atributos-relaciones)

Payment Authorization Service
System : Cashier makeNewSale() enterItem(id,quantity)

Process Sale

Cashier Process Rental Accounting System

: Payment Authorization Service

add file

add file [ numberOffile==MAX ] / flag OFF

Writ ing

Openning

endSale()

Cash In
makePayment(amount)
Reading close file Closing

close file

HR System Manage Users

performed

validatePayment() ok

System Administrator

Requisitos Automatizacin

Mangage Accounts

Descripciones c.u.
...

Casos de Uso

Secuencia Eventos

Diagramas Estados
(objetos dominio Sistema)

1: makeNewSale() reg : POSRegister : Cashier

2: create() sale : POSSale

3: create(amount)

Arquitectura Diseo Clases (atributos/operaciones-relaciones)

p: POSPayment

Diseo Colaboraciones Clases para evento (secuencia de llamadas a mtodos)

13

Fases de RUP: Inicio

Se establece la oportunidad y alcance el proyecto. Se identifican todas las entidades externas con las que se trata (actores) y se define la interaccin a un alto nivel de abstraccin:
Identificar todos los casos de uso Describir algunos en detalle

La oportunidad del negocio incluye:

Criterios de xito Identificacin de riesgos Estimacin de recursos necesarios Plan de las fases incluyendo hitos

Fases de RUP: Inicio

Productos:
Un documento de visin general:
Requerimientos generales del proyecto Caractersticas principales Restricciones

Caso de negocio:
Contexto Criterios de xito Pronstico financiero

Modelo inicial de casos de uso (10% a 20 % listos). Glosario.

Identificacin inicial de riesgos. Plan de proyecto. Uno o ms prototipos.

Fases de RUP: 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.

Fases de RUP: Elaboracin

Objetivos:
Analizar el dominio del problema Establecer una arquitectura base slida Desarrollar un plan de proyecto Eliminar los elementos de mayor riesgo para el desarrollo exitoso del proyecto

Visin de una milla de amplitud y una pulgada de profundidad porque las decisiones de arquitectura requieren una visin global del sistema.

Fases de RUP: Elaboracin

Productos:
Es la parte ms crtica del proceso:
Al final toda la ingeniera dura est hecha Se puede decidir si vale la pena seguir adelante

Ya hay menos riesgos y se puede planificar el resto del proyecto con menor incertidumbre. Se construye una arquitectura ejecutable que contemple:
Los casos de uso crticos Los riesgos identificados

A partir de aqu la arquitectura, los requerimientos y los planes de desarrollo son estables.

Fases de RUP: Elaboracin

Productos:
Modelo de casos de uso (80% completo) con descripciones detalladas. Otros requerimientos no funcionales 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.

Fases de RUP: 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? Es el plan del proyecto algo realista? Estn de acuerdo con el plan todas las personas involucradas?

Fases de RUP: 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.

Fases de RUP: Construccin

Productos:
El producto de software integrado y corriendo en la plataforma adecuada. Manuales de usuario. Una descripcin del release actual.

Fases de RUP: 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?

Fases de RUP: 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

Fases de RUP: Transicin

Objetivos: Obtener autosuficiencia de parte de los usuarios. Concordancia en los logros del producto de parte de las personas involucradas. Lograr el concenso cuanto antes para liberar el producto al mercado.
Concepcin Elaboracin Construccin Transicin

Producto

Definiciones Trabajador
Un trabajador define el comportamiento y las responsabilidades de un individuo. Es como un sombrero que la persona usa durante el proyecto:
Una persona puede tener varios sombreros Es el rol que desempea en un momento dado

Responsabilidades:
Hacer una serie de actividades Ser el responsable de una serie de artefactos

Definiciones Actividades
Una actividad es una unidad de trabajo que se asigna a un trabajador. Ej.:
Crear o modificar un artefacto

Las actividades se consideran en la planificacin y evaluacin del progreso del proyecto. Ejemplos:
Planificar una iteracin - Administrador de proyecto Encontrar actores y casos de uso Analista Revisar el diseo - Revisor de diseo Ejecutar pruebas de performance - Ing. de pruebas de performance

Una actividad lleva entre un par de horas y un par de das, involucra un solo trabajador y un nmero pequeo de artefactos.

Asignacin de actividades
Recurso
Pablo Mara Jos Silvia Eduardo

Trabajador
Diseador Autor de Casos de Uso Diseador de Casos de Uso Revisor de Diseo Arquitecto

Actividad
Diseo de Objetos Detallar un Caso de Uso Disear un Caso de Uso Revisar el Diseo Anlisis de Arquitectura Diseo de Arquitectura

Artefactos

Elementos de informacin producidos, modificados o usados por el proceso. Son los productos tangibles del proyecto. Son usados por los trabajadores para realizar nuevas actividades y son el resultado de esas actividades.

Ejemplos:
Un modelo, como el modelo de casos de uso o el modelo de diseo. Un elemento del modelo, como una clase o un caso de uso. Un documento tal como el Caso del Negocio o la Arquitectura del Software. Cdigo fuente. Cdigo ejecutable.

Flujos de trabajo
Una lista de actividades, trabajadores y artefactos 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.
Anlisis de Arquitectura Arquitecto Anlisis de Casos de Uso Diseador de Casos de Uso Anlisis de Objetos Diseador Diseo de Objetos Diseo de Casos de Uso Diseo de Arquitectura Describir Concurrencia Describir Distribucin

Revisor de Diseo

Revisar el Anlisis

Revisar el Diseo

Revisar la Arquitectura

Flujos de trabajo esenciales

Flujos de Trabajo de Ingeniera

Flujos de Trabajo de Apoyo

Flujos de trabajo
Existen habitualmente problemas de comunicacin entre ingenieros de software e ingenieros de negocios. RUP proporciona un lenguaje y proceso comn para estos dos mbitos. Para el modelamiento del negocio se usan business use cases (casos de uso del negocio):
La forma en que el software dar apoyo al negocio.

Requerimientos
Imprimir Informe Operador

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

Cliente

Reciclar

Administrar Depsito

Los casos de uso describen la funcionalidad. Los requerimientos no funcionales se incluyen en una especificacin complementaria.

Anlisis y diseo
Descripcin de cmo se implementar el sistema: un plano Debe:
Ejecutar las tareas y funciones descritas en los casos de uso Satisfacer todos los requerimientos Flexible a cambios

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.

El diseo se centra en la nocin de arquitectura.

Implementacin
Propsito:
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

Pruebas
Propsito:
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 propone probar las componentes desde el principio:

Confiabilidad, funcionalidad y performance

Las pruebas de regresin son importantes en desarrollos iterativos. Rational tiene herramientas para automatizar algunas pruebas.

RUP describe como planear y ejecutar estas pruebas.

Distribucin
Producir un producto y hacerlo llegar a sus usuarios finales. Incluye varias actividades:
Producir un release Empaquetar el software Distribuir el software Instalar el software Apoyar a los usuarios

A veces tambin incluye:

Realizar pruebas beta Migracin de datos Aceptacin formal

La mayor parte de la distribucin ocurre durante la transicin. Este es uno de los flujos de trabajo menos documentados en RUP.

Administracin de proyectos
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 de configuracin y 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

Ambiente

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.

Modelado del Negocio

Una empresa organiza su actividad por medio de un conjunto de procesos de negocio. Cada uno de ellos con una coleccin de datos que son producidos y manipulados mediante un conjunto de tareas, en las que ciertos agentes (por ejemplo, trabajadores o departamentos) participan de acuerdo a un flujo de trabajo determinado. Adems, estos procesos se hallan sujetos a un conjunto de reglas de negocio, que determinan las polticas y la estructura de la informacin de la empresa. La finalidad del modelado del negocio es describir cada proceso del negocio, especificando sus datos, actividades (o tareas), roles (o agentes) y reglas de negocio.

Modelado del Negocio

La extensin UML para el modelado de Negocios se basa en la adicin de algunos estereotipos. Todos los conceptos de UML pueden ser usados para el modelado de negocios, pero los estereotipos que se presentarn proveen una terminologa ms afn a este propsito. El modelado del negocio se basa en dos diagramas principales, el modelo de casos de uso del negocio y los modelos de objetos del negocio. Adicionalmente se presenta el modelo del dominio

Casos de Uso del Negocio

Son usados para representar la funcionalidad provista por una organizacin. Preguntas tpicas son:

Qu es lo que el negocio hace? Por qu construimos el sistema..etc

Estos son representados desde una perspectiva organizacional No diferencian entre procesos manuales y automatizados (Los diagramas de Casos de Uso, se centran el los procesos automatizados) Muestran las interacciones entre casos de uso del negocio y actores del negocio.

Los casos de uso del negocio representan los procesos que un negocio ejecuta. Los actores del negocio, representan roles con los cuales el negocio interacta, tales como cliente o vendedores, etc. Los actores del negocio representan a cualquiera o cualquier cosa fuera del negocio que interacte con ste. No representa roles o trabajadores en el interior de un negocio.

Trabajadores en el interior de un negocio, son representado por business workers.

Un worker representa la abstraccin de un humano que interactua con el sistema. Un worker interactua con otros workers y manipula entidades mientras participa en la realizacin de un caso de uso. Un case worker es un worker que interactua directamente con actores fuera del sistema. Un internal worker es un worker que interactua con otros workers y entidades dentro del sistema. Una entity es una clase pasiva, que no inicia interacciones. En el modelo de negocios representa objetos que los workers acceden, inspeccionan, manipulan y/o producen

Estereotipos en Herramienta CASE

<<business use case>> NewUseCase NewUseCase2 NewUseCase3

<<business actor>> NewClass <Actor Name>

(f rom Actors)

<Actor Name>
(f rom Actors)

Estereotipos en Herramienta CASE

<<business actor>> NewClass <Actor Name>
(f rom Actors)

<<business use case>> NewUseCase

NewUseCase2

NewUseCase3

<Actor Name>
(f rom Actors)

Modelo de Casos de Uso del Negocio

La empresa interacta con distintos elementos externos, entre los que se identifican el cliente externo (persona o entidad que solicita la compra de productos a la empresa), el proveedor (persona o entidad que reabastece de productos a la empresa) y por ltimo la empresa de transportes, que es una subcontratada encargada de servir los pedidos desde los distintos almacenes regionales a los clientes de la empresa.

Modelo de Objetos del Negocio

Vender Producto

Seguimiento y Consulta de Productos

Modelo de Dominio del Negocio

Los objetos de informacin que fluyen entre las actividades de un caso de uso del negocio representan datos del dominio, por lo que constituyen el modelo del dominio, que incluir los conceptos y sus relaciones, representadas en un diagrama de clases UML. En esta etapa, identificamos conceptos y no tanto relaciones entre ellos, concentrndose en las asociaciones debe conocer. Por ej. Un pedido debe conocer el cliente que los solicita y los productos que lo componen.

Ejercicio Prctico
Modelacin del Negocio de un Conjunto Federado de Bibliotecas:
Un usuario puede ser: Socio de una biblioteca (S) Bibliotecario (B) Las bibliotecas estn conectadas entre s para permitir el prstamo a socios de otras bibliotecas Dos partes claramente diferenciadas del sistema de una de estas bibliotecas: Operaciones de un usuario en la propia biblioteca
Altas y bajas de socios (B) Altas y bajas de libros (B) Consulta de libros disponibles (B,S) Reservas (S), prstamos y devoluciones de libros (B) Consulta de reservas realizadas y libros prestados (B,S)

Operaciones que implican una conexin a otra biblioteca

Consulta de los libros de otras bibliotecas (S) Reserva de un libro de otra biblioteca (S) Consulta de reservas realizadas y libros prestados en otra biblioteca (S)
50

Referencias
Understading UML Shinan Salhir, http://home.earthlink.net/~salhir

The Object Oriented Paradigm Shinan Salhir, http://home.earthlink.net/~salhir

Applying UML and Patterns. An Introduction to Object Oriented Analysis and Design and the Unified Process Craig Larman. Ed Prentice Hall

El Proceso Unificado de Desarrollo Software, I. Jacobson, Grady Booch, J. Rumbaugh, Ed Addison Wesley
es.geocities.com/gustsucc www.uml.org www.omg.org

51