El Proceso Unificado

de Desarrollo de Software
Prof. Gustavo J. Sabio

Alcance de la presentacin
QA
Entradas Proceso de desarrollo Salida

Cliente

equipo
sistemas

Cliente

necesidades actividades varias Producto software

MI PROCESO
ADAPTADO

Algunos conceptos fundamentales

Qu es un proceso?
Conjunto de actividades que interactan o se relacionan para
transformar las entradas de clientes en salidas con un valor
agregado.

Un proceso define QUIN hace QU,

CUNDO, y CMO, con un orden que
permite alcanzar un objetivo definido

actividades aisladas

fusionadas sistemticamente para un fin

aplicacin aleatoria

relacionadas y organizadas

reas independientes

se complementan para objetivo comn

Algunos conceptos fundamentales

Proceso de desarrollo de software
Ciclo de vida del desarrollo de software

actividades varias

en
tre
ga

necesidades

Cliente

Producto software

De
spl
ieg
ue
y

equipo
sistemas

salida

int
egr
aci
n

Cliente

Mo
y R delad
eq o d
ue e
rim Ne
ien goc
tos io
An
li
sis
yD
ise
o
Co
nst
ruc
ci
n

entradas Proceso de desarrollo

Pru
eb
ae

Las necesidades del cliente son transformadas en un

producto software

Construccin de SW Panorama mundial

El mundo tecnolgico invade todos los mbitos.
Los sistemas software son cada vez ms:
Grandes Complejos - Distribuidos.
La demanda del mercado es:
software de mejor calidad en menor tiempo!
Se torna sumamente difcil construir
y mantener software de buena calidad
de manera predecible.

Muchos proyectos fracasan !

Algunos causas:
Manejo de requerimientos ad hoc.
Arquitecturas frgiles.
Inconsistencias entre los requerimientos, el diseo
y la implementacin.
Prueba insuficiente.
Valoracin subjetiva del estado del proyecto.
No se atacan oportunamente los riesgos.
Propagacin de cambios no controlada.

La necesidad de un mtodo que:

Proporcione una gua para ordenar las actividades de un
equipo.
Dirija las tareas de cada desarrollador por separado y del
equipo como un todo.
Especifique los productos que deben desarrollarse.
Ofrezca criterios para el control y la medicin de los productos
y actividades del proyecto.

Para qu tener un proceso?

Un proceso permite repetir las prcticas exitosas, y dejar
de lado las infructuosas o al menos mejorarlas.

Qu es el RUP?
Filosofa basada en las Mejores Prcticas y aspectos esenciales
Un conjunto de Artefactos, Actividades y Roles.
La gua de cundo y cmo usarlos.
Promueve una Visin y cultura de trabajo comn.
Reduce los riesgos y hace que el proyecto sea mas predecible
Informacin especificada con un lenguaje estndar (UML)

Antecedentes del RUP

Fue creado por Ivar Jacobson, para el desarrollo de sistemas en
Suecia, trabajando para Eriksson
Posteriormente fue adoptado por numerosas empresas
Cuando Jacobson se incorpor a Rational, Objectory fue
complementado con las ideas de Booch.
El proceso se posiciona fuertemente a nivel mundial. Rational es
comprada por IBM (2002)
Hoy se habla del UP. Es inminente su posicionamiento como
estndar de la disciplina

Ficha tcnica del RUP

Qu es el RUP?
Un proceso de ingeniera de software.
Un framework para procesos de desarrollo
Una amplia librera de contenidos
RUP como un producto.
Upgrades regulares.
Utiliza tecnologa Web.
Puede personalizarse y configurarse de manera especifica.
Integrado con muchas herramientas de desarrollo de Rational.
RUP como un producto Beneficios
EL proceso nunca es obsoleto.
Completamente navegable.
Pueden incluirse mejoras locales fcilmente.
Cada departamento maneja su propia versin del proceso.

Mapa conceptual de RUP

Algunos conceptos
Trabajador :
Es un determinado ROL que define las competencias-habilidades necesarias
para desempear ese papel dentro del desarrollo de software
Su funcin hacer una serie de actividades y ser el responsable de una serie
de artefactos
Actividades:
Es una unidad de trabajo que se asigna a un trabajador: por ejemplo crear o
modificar un artefacto.
Una actividad puede llevar desde un par de horas hasta un par de das,
involucra a un solo trabajador responsable y un nmero acotado de artefactos.
Artefactos :
Elemento de informacin 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
resultado de esas actividades.

Estructura: Ciclo de vida en Fases

UP tiene 4 fases:
Inicio

Elaboracin

Construccin

Transicin

tiempo

Inicio

Define el alcance del proyecto

Elaboracin

Plan de proyecto, especificacin de

caractersticas, arquitectura base

Construccin
Transicin

Construir el producto
Despliegue del producto en el cliente

Grandes Hitos entre las fases

Inicio

Elaboracin

Construccin

Transicin

tiempo
LCO

LCA

Objetivos del
Ciclo de Vida
Arquitectura del
Ciclo de Vida
Alcance acordado
Riesgos comprendidos y razonables

IOC

Riesgos principales contenidos

Arquitectura estable

Capacidad
Operativa Inicial
Producto
entregado
Producto completado
Calidad aceptable

Fases e Iteraciones
Inicio

Elaboracin

Construccin

Transicin

tiempo
Iter

Iter

Iter

Iter

Iter

Iter

Iter

Iter

inicial

arq1

arq2

desa1

desa2

desa3

Tran1

Tran2

Hitos intermedios: versiones

Una Iteracin es una secuencia de actividades distintas basadas
en establecer un plan y criterios de evaluacin, resultando en una
versin ejecutable (interna o externa)

Juntemos todo! : proceso iterativo

Discipline

Las Disciplinas agrupan

actividades relacionadas
En una iteracin se
lgicamente
atraviesan todas las
Disciplinas

Las Disciplinas producen Modelos

Las Disciplinas guan el desarrollo iterativo

Disciplina

Modelo RUP en funcionamiento

Discipline
Discipline
Caractersticas del RUP
INICIO
ELABORACION
TRANSICION
Definir el alcance del sistema propuesto.
Crear una
lneaCONSTRUCCION
base
para laDirigido
arquitectura.
Preparar
actividades
de distribucin.
por Casos de Uso
Esbozar una arquitectura candidata
Identificacin
y
mitigacin
de
Riesgos.

Recomendar
al
cliente
sobre
hardware
necesarios.
la
descripcin
y
realizacin
de
todos
los la
CU.Arquitectura

Centrado
en
Identificar Riesgos crticos
Especificar
atributos
de
calidad
(fiabilidad,
performance,
etc. )

Preparar
manuales
y
otros
para
la
entrega
del
producto.
Lade
finalizacin
anlisis, diseo, implementacin
y pruebas.
Creacin
prototiposdel
(opcional)

Iterativo
e
Incremental
Recopilar
CU
para
cubrir
el
80%
de
los
requisitos
funcionales.
Parametrizar
el de
software.
Mantener
la integridad
la arquitectura.
Proponer
planificacin
general
(personal,
costos, etc.)
Correcciones
de
defectos
y adecuaciones.
Seguimiento
y mitigacin
de los
riesgos.

RUP Recorriendo las Fases.doc

Caractersticas principales del RUP

Est dirigido por los Casos de Uso
Est centrado en la arquitectura
Es iterativo e incremental

10

Dirigido por los casos de uso

El proceso avanza a travs de las distintas disciplinas, obteniendo
sucesivos modelos que parten de los casos de uso.

Dirigido por casos de uso

Por qu
qu casos de uso?
Medio sistemtico e intuitivo de capturar
requisitos funcionales (slo lo que brinda valor
para el usuario)

Registrar prstamo

Bibliotecario

Se considera la perspectiva de cada usuario

qu necesitan para hacer su trabajo?

Comprar material

Integrando todas las perspectivas tendremos

toda la funcionalidad que se espera del sistema.

11

Dirigido por casos de uso

Por qu
qu casos de uso?
Al preguntar Qu
Qu se quiere que haga el
sistema para cada actor?
Mantenernos centrados en la
comprensin de cmo el sistema debe
dar soporte a cada uno de los usuarios.
Nos ayuda a abstenernos de sugerir
funciones superfluas que ninguno de
los usuarios necesita.
La seleccin de conjunto correcto de casos de uso permite construir una
arquitectura robusta.

Dirigido por casos de uso

Por qu
qu casos de uso?
Involucra a los usuarios, clientes, desarrolladores y a todo el
equipo del proyecto
Todos los involucrados
deben acordar y
consensuar en el
modelo de casos de
uso.

Son el punto de partida

ideal para explicar como
puede interactuar el
usuario con el sistema en
los manuales de usuario.

Ayudan a desarrollar iterativamente.

12

Caractersticas principales del RUP

Est dirigido por los Casos de Uso
Est centrado en la arquitectura
Es iterativo e incremental

Centrado en la arquitectura
La arquitectura del sistema es:
Una representacin del sistema que
incluye los componentes estructurales,
el comportamiento visible de esos
componentes para el resto del sistema
y el modo en que dichos componentes
interactan.

Registrar prstamo

Bibliotecario

Soy
H
la a ola!
rqu
ite
ctu
ra

Los CU deben encajar en la arquitectura al momento de

crearlos. La arquitectura debe permitir el desarrollo de
los CU requeridos ahora y en el futuro.

Comprar material

13

Qu es la arquitectura?
Representaci
Representacin de la arquitectura: el Modelo 4 + 1

DOC
ARQUITECTURA

Caractersticas principales del RUP

Est dirigido por los Casos de Uso
Est centrado en la arquitectura
Es iterativo e incremental

14

Es iterativo e incremental

El ciclo de vida iterativo

se basa en la evolucin de
prototipos ejecutables
que se muestran a los
usuarios y clientes

Iterativo e incremental.
El proceso iterativo est organizado en fases.

Dentro de cada
fase el proceso
pasa por una
serie de
iteraciones e
incrementos.

15

Iterativo e incremental.

La estrategia para desarrollar un producto de software en pasos

pequeos y manejables consiste en:
Planificar un poco.
Especificar, disear e implementar un poco.
Integrar, probar, ejecutar un poco en cada iteracin.

Iteraciones, entregas internas y externas y objetivos parciales.

Beneficios vs. Modelo cascada

Atenuacin de riesgos:
riesgos:

16

Iterativo e incremental
Beneficios

Gestin de requisitos cambiantes:

El tener un sistema en funcionamiento
parcial en una fase inicial permite contar
con retroalimentacin oportuna.

Conseguir una integracin continua.

Cada iteracin arroja resultados tangibles.
Al final de cada iteracin se superan ciertos
riesgos.
El cliente hace su retroalimentacin en el
momento oportuno
Las sucesivas iteraciones nos indican claramente el
estado del proyecto.

Iterativo e incremental
Beneficios de la integracin continua

17

Iterativo e incremental
Beneficios

Lograr un aprendizaje temprano

Despus de un par de iteraciones todas
las personas del equipo tienen una
buena comprensin de lo que
significan y pretenden los diferentes
flujos de trabajo.

Los errores no se pagan tan caros

Cometer un error no es tan crtico
para el proyecto, debido a que se
atender en la siguiente
iteracin.

Caractersticas principales del RUP

Est dirigido por los Casos de Uso
Est centrado en la arquitectura
Es iterativo e incremental

18

En dnde estamos?

Entradas Proceso de desarrollo Salida

Cliente

equipo
sistemas

Cliente

necesidades actividades varias Producto software

MI PROCESO
ADAPTADO

Definir nuestro proceso

Qu actividades y artefactos se usarn?, cules
sern optativos? Cules se podr desistir de usarlos?

Cunto dura una Fase? Cmo reconocer el

momento de cada fase?

Qu nivel de formalidad debe aplicarse? Puedo

definir formatos propios?

19

Desarrollar software con un proceso

nuestro Proceso

RUP y la primera impresin

Cuando recorra la extensa cantidad de artefactos, actividades, y
documentos de RUP, puede suceder que se formule las siguientes
preguntas:

Esto es necesario?
De todos estos items, cules son
aplicables a mi proyecto?
El RUP es slo es para grandes
proyectos?

20

Trminos de una implementacin

Caso de desarrollo development case
Guas guidelines
Entorno de desarrollo organizacional
Proyecto piloto
Ingeniero de proceso
Lder de proyecto

Implementacin: la experiencia dice

Motivos de fracaso

Fallas en la introduccin incremental del proceso y las

herramientas.
Falta de apoyo de la direccin
Sponsors e involucrados mal informados.
Mala predisposicin o incapacidad para el cambio
Incertidumbre en la Visin y Fundamentos del cambio

21

Un proyecto de implementacin exitoso

Evaluar el proyecto y la organizacin
Implementar el proceso y herramientas en forma incremental
Planificar y dirigir las actividades de entorno
Usar tutores
Transmitir que el proceso es de todos
(Acadmicos y expertos de dominio)

Ser prgmatico y simple

(Primero HACER, despus mejorar!)

Comunicar el estado de avance

Brinde entrenamiento a las personas

Pasos para implementar el proceso y herramientas

en una Organizacin
Diferentes formas de implementacin
Una implementacin tpica
Implementacin Rpida
Implementacin Cuidadosa
Implementar un ambiente de desarrollo

22

Diferentes formas de implementacin

Una implementacin tpica

Diferentes formas de implementacin

Implementacin Rpida

23

Diferentes formas de implementacin

Implementacin cuidadosa

Diferentes formas de implementacin

Implementar un ambiente de desarrollo

24

Desarrollar software con mi proceso

nuestro Proceso

INICIO

hito
s

ELABORACION

hito
s

CONSTRUCCION

hito
s

TRANSICION

hito
s

Beneficios de tener un proceso

Todo el mundo en el equipo comprende lo que tiene que hacer para
desarrollar el producto.
Se puede medir lo que se est haciendo, saber cmo vamos, qu es lo
que sigue....
La Empresa puede contar con formacin estandarizada.
La descripcin de la arquitectura ayuda a los stakeholders entender lo
que se est desarrollando.
Se puede planificar y estimar costos de forma efectiva.
Le brinda garantas a nuestro clientes.

25

Proceso y proyecto
nuestro Proceso
Nuevos proyectos...
Proyecto 1

Proyecto 3
Proyecto 2

Caso real: implementacin UP

Organizacin dedicada al desarrollo de software
Implementacin focalizada en el desarrollo de
adaptaciones por cliente
1 proyecto piloto
Mucho consenso y participacin sobre la adecuacin de
templates
Definicin minimalista del proceso

EJ.
FASE I

26

Funcionan las recetas ?

Construir un primer esqueleto del proceso
Proteger al equipo No burocratizar.
No incluir actividades ni artefactos que no se justifiquen claramente
Minimizar los artefactos formales.
Usar formatos convenientes generacin automtica
Usar internet e intranet.
Revisar regularmente el proceso.
Adaptar mientras se mantengan las mejores prcticas

Haciendo bien nuestro trabajo

Tener Mi proceso de desarrollo definido
Emplear las herramientas de

UML

Mejorar continuamente la manera en que hacemos las

cosas.
Asegurando la calidad de nuestro proceso
Podremos certificar estndares de calidad

ISO 9001:2000; CMM o CMMi

27

FIN

Muchas Gracias!
Preguntas?

Lo nuevo
The underlying process definition language.
Underlying it all is a process meta-model. This model
provides a language of process definition elements for
describing a software engineering process. This
language is based on the SPEM extension to the UML
for software process engineering and the Unified
Process methodology.

28