EL PROCESO UNIFICADO (RUP) DE

DESARROLLO DE SOFTWARE
INTRODUCCIN
La comunidad de desarrollo de software necesita una forma
controlada de trabajar, un proceso que:
proporcione una gua para el orden de las actividades del
equipo;
dirija las tareas de los desarrolladores individuales y del
equipo como un todo;
especifique qu artefactos deben ser desarrollados y cundo;
ofrezca criterios para supervisar y medir los productos y
actividades del proyecto.

1
El RUP es:
un proceso de desarrollo de software el conjunto de
actividades necesarias para transformar los requisitos de un
cliente/usuario en un sistema de software;
ms que un proceso individual un armazn genrico para
procesos que puede ser especializado para una clase grande
de sistemas de software, para diferentes dominios de
aplicacin, tipos de organizaciones, niveles de competencia,
y tamaos de proyectos.

Adems, el RUP:
es un proceso basado en componentes el sistema de
software que se construye est hecho de componentes de
software interconectadas via interfaces bien definidas;
usa UML para preparar todos los planos del sistema de
software UML y el RUP fueron desarrollados
conjuntamente.

Sin embargo, las caractersticas ms distintivas del RUP son:

es un proceso dirigido por casos de uso;
es un proceso centrado en la arquitectura;
es un proceso iterativo e incremental.

2
 LAS MEJORES PRCTICAS
DE INGENIERA DE SOFTWARE

ACTIVIDAD DE EQUIPOS. Debido al tamao y complejidad de los

sistemas de software modernos, su desarrollo es una actividad
de equipos:
gerente de proyecto encargados de pruebas
analistas de sistemas ingenieros de desempeo
desarrolladores ingenieros de instalacin.

Estos equipos presentan desafos de comunicacin.

las tecnologas ms complejas requieren expertos
especializados en slo un rea;
un equipo puede incluir muchos de estos especialistas;
hay que asegurarse que
estos especialistas se comuniquen efectivamente con el
resto del equipo
las tecnologas construidas por cada especialista se
integren para producir un sistema exitoso;
la velocidad de los cambios tecnolgicos sigue aumentando y
muchas tecnologas son usadas antes de haber sido
probadas.

3
SNTOMAS. Cmo nos va?
muchos proyectos de software son exitosos a pesar de los
problemas lo demuestran los muchsimos sistemas de los
que dependemos a diario
nuestra tasa de fallas es an demasiado alta necesitamos
cambiar nuestras prcticas.

Producir software de buena calidad y a tiempo es muy desafiante,

debiendo superarse innumerables problemas.

stos son a menudo reconocidos primero por sus sntomas:

Entendimiento inexacto de las necesidades del usuario
Incapacidad para manejar requisitos cambiantes
Mdulos que no calzan unos con otros
Software que es difcil de mantener o extender
Descubrimiento tardo de fallas serias en el proyecto
La calidad del software es pobre
El desempeo del software es inaceptable
Los miembros del equipo se entorpecen unos a otros, y son
incapaces de reconstruir quin cambi qu, cundo, dnde, y
por qu
Un proceso de construccin-y-entrega no confiable

4
CAUSAS. Tratar los sntomas no cura la enfermedad:
p.ej., el descubrimiento tardo de fallas serias en el proyecto es
slo un sntoma de un problema ms grande realizacin
inadecuada de pruebas.

El tradicional desarrollo en cascada agrava el problema:

las pruebas se hacen muy tarde las fallas no pueden
corregirse sin retrasar significativamente la entrega.

Races de los problemas:

Insuficiente gestin de requisitos
Comunicacione ambiguas
Arquitecturas frgiles
Complejidad abrumadora
Inconsistencias no detectadas entre requisitos, diseos, e
implementaciones
Insuficientes pruebas
Evaluacin subjetiva del estado del proyecto
Reduccin de riesgos atrasada debido al desarrollo en
cascada
Propagacin incontrolada de cambios
Insuficiente automatizacin

Hay que tratar estas causas para eliminar los sntomas.

Eliminando los sntomas uno est en mucho mejor posicin para

construir software de calidad de manera predecible y repetible.

5
LAS MEJORES PRCTICAS:
un conjunto de enfoques para desarrollo de software proba-
dos comercialmente que, cuando se usan combinadamente,
atacan las races de los problemas del desarrollo de software;
son mejores no tanto porque podamos cuantificar en forma
precisa su valor, sino porque se ha observado que son
usadas habitualmente por organizaciones exitosas.

Las 6 mejores prcticas de la ingeniera de software:

Desarrollar software iterativamente
Gestionar los requisitos
Usar arquitecturas basadas en componentes
Modelar software visualmente (con UML)
Verificar la calidad del software
Controlar los cambios al software

Estas prcticas se refuerzan unas a otras:

el total es mucho ms grande que la suma de las partes;
en algunos casos, adems, unas prcticas facilitan otras.

6
P.ej., el desarrollo iterativo mejora
la gestin de requisitos asegura que los usuarios se
involucran a medida que los requisitos evolucionan
el uso de arquitecturas de componentes valida
tempranamente las decisiones arquitectnicas
el modelamiento visual aborda incrementalmente la
complejidad del diseo e implementacin
la verificacin de la calidad mide la calidad tempranamente
y a menudo
el control de cambios hace evolucionar incrementalmente
las lneas bases

Pero adems, el desarrollo iterativo podra fcilmente no

converger sin una adecuada gestin de requisitos:
los requisitos cambian a discresin,
los usuarios no se ponen de acuerdo, y
las iteraciones siguen para siempre.

En cambio, con gestin de requisitos:

los cambios a los requisitos son visibles,
puede evaluarse el impacto de los cambios sobre el proceso
de desarrollo antes de aceptarse, y
se asegura la convergencia en un conjunto estable de
requisitos.

7
 UN PROCESO DIRIGIDO POR CASOS DE USO
Un sistema de software es creado para servir a sus usuarios.

Para que sea exitoso debemos saber qu es lo que stos quieren

y necesitan no slo personas, tambin otros sistemas que
interactan con el sistema desarrollado.

P.ej., una interaccin es una persona que usa un cajero

automtico:
l (o ella) inserta la tarjeta, contesta las preguntas hechas por
el sistema a travs de la pantalla, y recibe una suma de
dinero en efectivo;
como respuesta a la tarjeta y a las respuestas del usuario, el
sistema realiza una secuencia de acciones que porporcionan
al usuario un resultado de valor el dinero en efectivo.

Una interaccin como esta es un caso de uso:

un caso de uso es una parte de la funcionalidad del sistema
que por si sola entrega a un usuario un resultado de valor;
los casos de uso capturan los requisitos funcionales;
el conjunto de casos de uso constituye el modelo de casos
de uso descripcin de la funcionalidad completa del
sistema reemplazando a la tradicional especificacin
funcional.

La especificacin funcional tradicional contesta la pregunta qu

se supone que hace el sistema?

8
En cambio, el modelo de casos de uso
contesta la pregunta qu se supone que el sistema hace
para cada usuario?
nos obliga a pensar en el valor para los usuarios, no slo en
funciones que sera bueno tener.

Los casos de uso, adems, dirigen el proceso de desarrollo el

diseo, la implementacin, y las pruebas del sistema:
a partir del modelo de casos de uso, los desarrolladores
crean una serie de modelos de diseo e implementacin que
realizan los casos de uso;
los desarrolladores revisan cada modelo para asegurar que
concuerde con el modelo de casos de uso;
los encargados de las pruebas prueban la implementacin
para asegurarse que los componentes del modelo de imple-
mentacin implementan correctamente los casos de uso.

Dirigido por casos de uso significa que el desarrollo sigue un flujo

avanza a travs de una serie de flujos de trabajo derivados de
los casos de uso:
los casos de uso se especifican;
los casos de uso se disean; y
al final, los casos de uso son la fuente a partir de la cual se
construye los casos de prueba.

Finalmente, los casos de uso son elegidos en colaboracin

recproca con la arquitectura del sistema ambos maduran a
medida que avanza el ciclo de vida.

9
 UN PROCESO CENTRADO EN LA ARQUITECTURA
El rol de la arquitectura en la construccin de edificios:
el edificio es visto desde distintos puntos de vista: estructura,
servicios, conductos para calefaccin, caeras de agua,
electricidad, etc.
esto permite al constructor tener un cuadro completo antes de
que comience la construccin.

La arquitectura en un sistema de software consiste en las

diferentes vistas del sistema en construccin:
incluye los aspectos estticos y dinmicos ms relevantes del
sistema;
nace de las necesidades de la empresa, detectadas por
usuarios y otros interesados, y reflejadas en los casos de
uso;
es influenciada por varios factores: () plataforma sobre la
cual va a correr el software, () componentes reusables
disponibles, () consideraciones de instalacin, () sistemas
legados, () requisitos no funcionales;
es una vista de todo el diseo en que las caractersticas im-
portantes se hacen ms visibles dejando de lado los detalles.

El valor de la arquitectura depende del arquitecto, pero la

existencia de un proceso ayuda al arquitecto a enfocarse en los
objetivos correctos:
() inteligibilidad, () adaptabilidad, () reusabilidad.

10
Todo producto (de software) tiene funcin (casos de uso) y forma
(arquitecura):
una u otra por s sola no es suficiente;
deben ser balanceadas para crear un producto exitoso;
es necesario que se influyan mutuamente problema del
huevo y la gallina y que evolucionen en paralelo;
los casos de uso, una vez realizados, deben calzar en la
arquitectura;
la arquitectura debe permitir las realizaciones de todos los
casos de uso, ahora y en el futuro.

La arquitecura de un sistema la forma que le da el arquitecto

debe permitir su evolucin.

El arquitecto trabaja a partir de una comprensin general de las

funciones claves los casos de uso claves (p.ej., el 10% ms
significativo, que forma el ncleo de las funciones del sistema):
primero crea un esbozo de la arquitectura, comenzando con
aquellas partes que no son especficas a los casos de uso;
luego trabaja con los casos de uso claves, los especifica en
detalle y los realiza en trminos de subsistemas, clases, y
componentes;
finalmente, a medida que los casos de uso se especifican y
maduran, se descubre ms de la arquitecura, lo que a su vez
ayuda a la maduracin de ms casos de uso;
este proceso contina hasta que la arquitectura es
considerada estable.

11
 UN PROCESO ITERATIVO E INCREMENTAL
El desarrollo de un producto de software puede durar meses o
aos; conviene dividir el trabajo en miniproyectos:
cada miniproyecto es una iteracin que resulta en un
incremento;
las iteraciones son los pasos en el flujo de trabajo, y deben
ser controladas elegidas y ejecutadas planificadamente;
los incrementos se refieren al crecimiento del producto.

Los desarrolladores eligen qu se va a implementar en una

iteracin, tomando en cuenta que cada iteracin lidia con:
un grupo de casos de uso que en conjunto extienden la
usabilidad vigente del producto; y
los riesgos ms importantes.

En cada iteracin, los desarrolladores:

identifican y especifican los casos de uso relevantes;
crean un diseo a partir de la arquitectura elegida;
implementan el diseo en componentes; y
verifican que las componentes satisfacen los casos de uso.

Si una iteracin
satisface sus objetivos lo que ocurre normalmente el
desarrollo prosigue con la prxima iteracin;
no satisface sus objetivos, hay que revisar decisiones
anteriores e intentar un nuevo enfoque.

12
Para economizar durante el desarrollo, el equipo debe:
seleccionar slo las iteraciones requeridas para alcanzar el
objetivo del proyecto;
secuenciar las iteraciones en un orden lgico;
proceder a lo largo de un curso bien establecido, permitiendo
slo pequeas desviaciones.

Si aparecen imprevistos que agregan iteraciones o alteran su

secuencia, el proceso tomar ms esfuerzo y tiempo.

Uno de los objetivos de la reduccin de riesgos es minimizar los

imprevistos.

13
Beneficios de un proceso iterativo controlado:

Reduce el riesgo del costo a los gastos hechos en un

incremento
Si hay que repetir la iteracin, perdemos slo el esfuerzo
de esa iteracin, no el valor de todo el producto.

Reduce el riesgo de no terminar el producto en el plazo

planificado:
Cuando los problemas difciles aparecen durante las
pruebas del sistema, el tiempo necesario para resolverlos
excede al tiempo que queda, retrasando la entrega.
Al identificar los riesgos al comienzo del desarrollo, el
tiempo empleado en resolverlos transcurre cuando la
gente est menos apurada

Apura el ritmo del esfuerzo de desarrollo

Los desarrolladores trabajan ms eficientemente hacia
resultados precisos y de corto plazo que dentro de
planificaciones a largo plazo que no se cumplen.

Acepta una realidad a menudo ignorada:

Las necesidades del usuario y los requisitos correspon-
dientes no pueden definirse totalmente al principio.
Los requisitos tpicamente son refinados en iteraciones
sucesivas este enfoque facilita la adaptacin a
requisitos cambiantes.

14
 LA VIDA DEL PROCESO UNIFICADO
INTRODUCCIN. Hemos presentado los tres conceptos claves
dirigido por casos de uso, centrado en la arquitectura, e iterativo
e incremental; ahora miremos al proceso en su totalidad:
ciclos de vida fases
artefactos iteraciones
flujos de trabajo

El RUP se repite en una serie de ciclos que constituyen la vida

de un sistema; cada ciclo:
termina con la entrega de un producto al cliente;
consiste en 4 fases: inicio, elaboracin, construccin, y
transicin, cada una subdividida en iteraciones.

nacimiento muerte

Los ciclos concluyen con un release

Inicio Elaboracin Construccin Transicin

iter.1 iter.2 iter.n

releases

15
EL PRODUCTO. El resultado de cada ciclo es un nuevo
producto listo para entregar:
cdigo fuente componentes compilables y ejecutables;
manuales.

El producto terminado, sin embargo, debe

acomodar las necesidades de todos los interesados
clientes, usuarios, analistas, diseadores, implementado-
res, encargados de pruebas, y gerencia;
incluir () requisitos, () casos de uso, () especificaciones
no funcionales, () casos de prueba, () arquitectura, y ()
modelos visuales (en UML) en conjunto, permiten a los
interesados usar y modificar el sistema.

Para llevar a cabo el prximo ciclo, los componentes

ejecutables no son suficientes:
cambia el entorno sistema operativo, base de datos,
arquitectura de hardware;
cambian los requisitos.

16
Los desarrolladores necesitan todas las representaciones:
modelo de casos de uso todos los casos de uso, sus
relaciones con los usuarios;
modelo de anlisis refina los casos de uso, asigna
inicialmente el comportamiento del sistema a un conjunto
de objetos que proporciona tal comportamiento;
modelo de diseo estructura esttica del sistema en
trminos de subsistemas, clases, e interfaces, y casos de
uso realizados como colaboraciones entre subsistemas,
clases, e interfaces;
modelo de implementacin componentes (cdigo
fuente), correspondencia entre clases y componentes;
modelo de instalacin nodos fsicos (computadores),
correspondencia entre componentes y nodos;
modelo de pruebas casos de prueba que verifican los
casos de uso; y
por supuesto, una representacin de la arquitectura.

Tambin puede haber un modelo del dominio o del negocio

que describe el contexto del sistema.

Todos estos modelos estn relacionados:

en conjunto, representan la totalidad del sistema;
los elementos en un modelo tienen dependencias
rastros hacia atrs y hacia adelante mediante vnculos
a otros modelos.

17
LAS FASES EN UN CICLO. Cada ciclo transcurre en el tiempo y
est dividido en 4 fases inicio, elaboracin, construccin, y
transicin :
Visualizamos lo que pasa en estas fases a travs de una
secuencia de modelos.
En cada fase el trabajo se descompone en iteraciones e
incrementos.
Cada fase termina en un hito
un conjunto de artefactos est disponible
ciertos modelos o documentos han alcanzado un
estado preestablecido.

Los hitos sirven para varios propsitos:

Los gerentes tienen que tomar ciertas decisiones antes
que el trabajo pueda proseguir a la siguiente fase.
Gerentes y desarrolladores pueden supervisar el progreso
del trabajo cuando se pasa por estos 4 puntos claves.
Al medir el esfuerzo y el tiempo gastados en cada fase,
desarrollamos un conjunto de datos tiles para:
estimar las necesidades de tiempo y personal para
otros proyectos
proyectar las necesidades de personal a lo largo de los
proyectos
controlar progresos a partir de estas proyecciones.

18
Fase de inicio:
Una buena idea es convertida en una visin del producto
final, para el cual se elabora el caso de negocio.
Contesta las preguntas:
Qu va a hacer el sistema para cada usuario?
Cmo sera una arquitectura para ese sistema?
Cul es el plan y cunto costar desarrollar el producto?
Se construye un modelo de casos de uso simplificado, slo
con los casos ms crticos.
La arquitectura es tentativa un esbozo con los subsistemas
cruciales.
Se identifica y prioriza los riesgos ms importantes.
Se planifica la fase de elaboracin en detalle.
Se hace una estimacin aproximada de todo el proyecto.

19
Fase de elaboracin:
Se especifica en detalle la mayora de los casos de uso del
producto
Se realiza los casos de uso ms crticos.
Se disea la arquitectura del sistema vistas de todos los
modelos: casos de uso, anlisis, diseo, etc.
La vista del modelo de implementacin incluye componentes
para demostrar que la arquitectura es ejecutable.
El resultado de la fase es una fundacin arquitectnica.
Al finalizar la fase, se puede planificar las actividades y
estimar los recursos necesarios para completar el proyecto.
La pregunta es
son los casos de uso, la arquitectura y los planes suficien-
temente estables y estn los riesgos suficientemente bajo
control para comprometerse a todo el trabajo de desarrollo
en un contrato?

20
Fase de construccin:
Se construye el producto queda listo para ser transferido a
la comunidad de usuarios.
La fundacin arquitectnica crece y se convierte en un
sistema completo.
Se gasta la mayor parte de los recursos necesarios.
Al finalizar la fase, el producto contiene todos los casos de
uso que la gerencia y el cliente acordaron desarrollar para
este release.
El producto an puede contener defectos que sern
corregidos durante la fase de transicin.
La pregunta es
satisface el producto las necesidades de los usuarios
suficientemente como para entregarlo a algunos clientes?

21
Fase de transicin:
El producto pasa a una versin que es puesta a prueba por
unos pocos usuarios experimentados
Los desarrolladores
corrigen los problemas informados
incorporan las mejoras sugeridas
en un release general para la comunidad de usuarios.
Incluye
manufacturacin
capacitacin del personal del cliente
habilitacin de ayuda en lnea
correccin de defectos encontrados despus de la
entrega.
Los defectos pueden ser divididos en dos categoras:
los que, por sus efectos sobre las operaciones, justifican
un release delta inmediato; y
los que pueden ser corregidos en el prximo release
regular.

22
 FLUJOS DE TRABAJO

INTRODUCCIN. En cada fase y en cada iteracin se lleva a cabo

los siguientes 9 flujos de trabajo:
Modelamiento del Negocio Instalacin
Requisitos Gestin de Configuracin y
Anlisis & Diseo Cambios
Gestin del Proyecto
Implementacin
Entorno
Pruebas

Flujos Inicio Elaboracin Construccin Transicin

Model.

Requis.

A&D

Implem.

Test

Instal.

C&CM

Gestin

Entorno

Inicial iter.n

23
MODELAMIENTO DEL NEGOCIO. Un paso opcional; sus objetivos
son:
Entender la estructura y dinmica de la organizacin.
Asegurar que clientes, usuarios, y desarrolladores tengan un
entendimiento comn de la organizacin.
Derivar requisitos de sistemas para apoyar la organizacin.

Para lograr estos objetivos, es necesario desarrollar:

un modelo de casos de uso del negocio,
un modelo de objetos del negocio,
una Especificacin Suplementaria del Negocio,
un Glosario.

Participan:
Analista del Proceso de Negocio: () captura vocabulario
comn; () determina actores y casos de uso; () estructura el
modelo de casos de uso del negocio
Diseador del Negocio: () detalla caso de uso del negocio; ()
determina y detalla ejecutantes y entidades del negocio
Revisor del Modelo del Negocio: () revisa los modelos

24
REQUISITOS. Sus objetivos son:
Llegar a un acuerdo con los clientes y usuarios acerca de qu
debera hacer el sistema.
Proporcionar a los desarrolladores del sistema un mejor
entendimiento del sistema.
Delimitar el sistema.
Proporcionar una base para planificar el contenido tcnico de
las iteraciones.
Definir una interfaz de usuario para el sistema.

Para lograrlos, se desarrolla los siguientes documentos:

Visin Glosario
Necesidades de Clase de delimitacin
Interesados Prototipo de la interfaz de
Modelo de casos de uso usuario
Especificacin
Suplementaria

Participan:
Analista de Sistema: () desarrolla visin, () extrae
necesidades de interesados, () maneja dependencias, ()
captura vocabulario comn, () determina actores y casos de
uso, () estructura modelo de casos de uso
Especificador de Casos de Uso: () detalla casos de uso
Diseador de Interfaz de Usuario: () modela y construye
prototipo de interfaz de usuario
Arquitecto: () prioriza casos de uso
Revisor de Requisitos: () revisa requisitos

25
ANLISIS Y DISEO. Sus objetivos son:
Transformar los requisitos en un diseo del futuro sistema.
Desarrollar una arquitectura robusta para el sistema.
Adaptar el diseo al entorno de implementacin.

Los artefactos principales son:

Modelo de Diseo realizaciones de casos de uso, clases,
paquetes/subsistemas de diseo
Documento de Arquitectura de Software
Modelo de datos

Participan:
Arquitecto: () anlisis y diseo arquitectnicos, () describe
concurrencia y distribucin
Diseador: () anlisis de casos de uso, () diseo de
subsistemas, clases, y casos de uso
Diseador de Base de Datos: () disea base de datos
Revisor de Arquitectura: () revisa arquitectura
Revisor de Diseo: () revisa diseo

26
IMPLEMENTACIN. Sus objetivos son:
Definir la organizacin del cdigo, en trminos de
subsistemas y estratos o niveles.
Implementar clases y objetos en trminos de componen-tes
(archivos fuentes, binarios, ejecutables, otros).
Probar individualmente las componentes desarrolladas.
Integrar los resultados, producidos por individuos o equipos
de implementadores, para formar un sistema ejecutable.

Sus artefactos principales son:

Modelo de Implementacin define componentes y
subsistemas.
Plan de Integracin.

Participan:
Arquitecto: () estructura el modelo de implementacin
Integrador de Sistemas: () planifica y realiza la integracin
del sistema
Implementador: () planifica y realiza la integracin de
subsistemas, () implementa clases, () realiza pruebas
unitarias, () corrige defectos
Revisor de Cdigo: () revisa el cdigo

27
PRUEBAS. Calidad es ms que satisfacer los requisitos, o las
necesidades y expectativas de los usuarios.

El PROCESO UNIFICADO define calidad como la caracterstica de

haber demostrado el logro de producir un producto que:
satisface o supera requisitos acordados, segn mediciones
hechas de acuerdo con medidas y criterios acordados, y
es producido siguiendo un proceso acordado.

Probar software:
es muy difcil, y
tpicamente se hace sin una metodologa clara y sin la
automatizacin o el apoyo de herramientas necesario.

Los problemas son 100 a 1000 veces ms caros de encontrar y

corregir despus de la instalacin; es importante:
comenzar a hacer pruebas tempranamente;
evaluar continuamente la calidad del sistema con res-pecto a
su funcionalidad, confiabilidad, y desempeo; y
estructurar el plan de desarrollo de modo que permita
verificar decisiones arquitectnicas desde las primeras
iteraciones.

28
El desarrollo iterativo permite hacer pruebas continuamente:
cada iteracin produce un release ejecutable;
el release es integrado y probado exhaustivamente dentro de
la iteracin en que es producido, contra los requisitos
abordados en esa iteracin;
a medida que el desarrollo avanza a travs de varias
iteraciones, ms partes del sistema se completan, integran, y
prueban al final de cada iteracin;
al terminar la ltima iteracin, toda la funcionalidad est en su
lugar y el sistema completo se prueba como un todo;
muchos errores se encuentran temprano en el ciclo de vida,
cuando son mucho menos caros de corregir;
como las primeras iteraciones se enfocan en validar
decisiones arquitectnicas la ms caras de cambiar
solucionamos temprano los problemas ms caros.

La realizacin continua de pruebas es ideal pero exige contar con

herramientas automticas; en un caso real:

13,000 pruebas en 2 versus 13,000 pruebas en 6

semanas, 6 personas horas, una persona.

aspecto por qu? cmo?

Funcionalidad hace lo que se Casos de prueba para
necesita? cada escenario
Confiabilidad tiene problemas de Herramientas de anlisis,
memoria? instrumentalizar el cdigo
Desempeo de Responde Verificar desempeo para
la aplicacin aceptablemente? cada escenario
Desempeo puede trabajar bajo Probar desempeo para
del sistema carga real? todos los casos de uso

29
Los objetivos del flujo de trabajo Pruebas son:
Verificar la interaccin entre objetos.
Verificar la integracin de todas las componentes.
Verificar que todos los requisitos han sido implementados
correctamente.
Identificar los defectos y asegurarse que sean abordados con
anterioridad a la instalacin del software.

Sus principales artefactos son:

Modelo de pruebas define casos, procedimientos, y
guiones de pruebas
Plan de pruebas
Defectos
Paquetes, clases, subsistemas, y componentes para pruebas

Participan:
Diseador de Pruebas: () planifica, disea, implementa, y
evala las pruebas
Verificador de Integracin: () ejecuta pruebas de integracin
Verificador de Sistema: () ejecuta pruebas del sistema
Verificador de Desempeo: () ejecuta pruebas de
desempeo
Diseador: () disea clases y paquetes de pruebas
Implementador: () implementa componentes y subsistemas
de pruebas

30
GESTIN DEL PROYECTO. Sus objetivos son:
Proporcionar un marco de referencia para gestionar
proyectos intensivos en software.
Proporcionar pautas prcticas para planificar, asignar
personal, ejecutar, y supervisar proyectos.
Proporcionar un marco de referencia para manejar riesgos.

El Gerente del Proyecto es responsable por los siguientes

artefactos:
el caso del negocio
el plan de iteraciones
la evaluacin de las iteraciones
evaluaciones de situacin

Participa:
Gerente de Proyecto: () desarrolla caso de negocio,
() identifica riesgos, () desarrolla plan del proyecto,
() asigna personal al proyecto, () desarrolla y ejecuta plan
de iteraciones, () revisa riesgos, () evala iteraciones

31
GESTIN DE CAMBIOS Y CONFIGURACIN. No podemos impe-dir
que se introduzcan cambios en un proyecto, pero debe-mos
controlar cmo y cundo se introducen y por quin.
mltiples desarrolladores organizados en diferentes equi-pos
localizados en diferentes sitios, trabajando juntos en mltiples
iteraciones, releases, proyectos, y plataformas.

Problemas tpicos:
actualizaciones simultneas cuando dos o ms ejecu-
tantes modifican el mismo artefacto por separado, el ltimo en
hacer cambios destruye el trabajo del primero
notificaciones incompletas al corregir un problema en
artefactos compartidos, algunos de sus usuarios no son
informados
versiones mltiples y simultneas de un artefacto en
diferentes estados de desarrollo, debido al desarrollo iterativo

Sin un control disciplinado, el proceso de desarrollo se vuelve

rpidamente un caos.

Un Sistema de CM es el conjunto de mtodos, procesos, y

herramientas usados para administrar los cambios y las
configuraciones:
mantiene informacin clave sobre los procesos de desa-rrollo,
instalacin, y mantenimiento de los productos;
forma una base de artefactos potencialmente reusables
resultantes de la ejecucin de estos procesos.

32
Los componentes principales de un Sistema de CM son:
Gestin de Solicitudes de Cambios aborda la
infraestructura organizacional necesaria para evaluar los
impactos en costo y tiempo de un cambio solicitado para un
producto existente.
Gestin de la Configuracin
describe la estructura de los productos de software e
identifica los tems de configuracin que la conforman
(considerados entidades individuales sometidas a
versiones en el proceso de CM);
define configuraciones, construye e identifica, y
colecciona artefactos (sometidos a versiones) en
conjuntos que conforman configuraciones, y mantiene un
seguimiento entre sus versiones.
Mediciones describe el estado de un producto a base del
tipo, nmero, tasa, y seriedad de los defectos encontrados o
corregidos durante el desarrollo.

33
Conceptos de la gestin de cambios y configuracin; hay que:
Descomponer la arquitectura en subsistemas y asignar la
responsabilidad de cada subsistema a un equipo.
Establecer espacios de trabajo seguros para cada
desarrollador, que:
lo aislan de los cambios hechos en otros espacios de
trabajo, y
controlan todos los artefactos de software requisitos,
modelos, cdigos, etc.
Establecer un espacio de trabajo para integracin.
Establecer un mecanismo obligatorio de control de cambios.
Priorizar las solicitudes de cambios, evaluar sus impactos, y
establecer un plan para introducirlos en una iteracin y
release particular.
Supervisar las tasas de ocurrencias de los cambios
requisitos inestables, interfaces inestables de componentes,
trabajo que hay que rehacer por cada reparacin de un
defecto.
Saber qu cambios aparecen en cules releases.
Poder identificar la versin particular de cada artefacto al que
aplican informes de problemas o solicitudes de mejoras.
Liberar una baseline probada al trmino de cada iteracin,
con la informacin necesaria para poder determinar
exactamente qu contiene un release.

34
Un Sistema de CM permite:
manejar mltiples variantes de sistemas de software en
evolucin,
saber cules versiones son usadas en determinados armados
de software,
producir armados de programas individuales o de releases
completos segn especificaciones de versin definidas por
los usuarios, y
hacer cumplir polticas de desarrollo especficas.

Algunos beneficios directos de un Sistema de CM son:

permite el empleo de mtodos de desarrollo,
mantiene la integridad y asegura la complecin y correccin
del producto,
proporciona un entorno estable en el cual desarrollar el
producto,
restringe los cambios a los artefactos segn las polticas del
proyecto, y
proporciona informacin acerca de por qu, cundo, y por
quin se hizo modificaciones a un artefacto, y
almacena informacin acerca del propio proceso.

35
Participan:
Gerente de Proyecto: () establece proceso para cambios
de productos, () define informacin de status y requisitos
para lnea base
Arquitecto: () estructura modelo de implementacin
Gerente de CM: () escribe plan de CM, ()
Integrador de Sistema: () crea espacios de trabajo para
integracin, () construye producto
otros: () crean espacios de trabajo privados, () chequean
artefactos in/out

36
ENTORNO:
Configuracin del proceso adaptar el PROCESO UNIFICADO
a las necesidades de una organizacin o proyecto
Mejoramiento del proceso hacer evolucionar el proceso a
base de las lecciones aprendidas a medida que un proyecto
se lleva a cabo
Seleccin y adquisicin de herramientas
Fabricacin de herramientas para () apoyar necesi-dades
especiales, () proporcionar automatizacin de tareas
tediosas o propensas a errores, y () proporcionar mejor
integracin entre herramientas
Apoyo al desarrollo () mantenimiento del entorno de
desarrollo, () administracin del sistema, () telecomuni-
caciones, y () creacin y reproduccin de documentos
Capacitacin

37