Este documento presenta una guía metodológica para aplicar la metodología RUP en el desarrollo de sistemas. Describe los siete workflows esenciales del RUP que serán adaptados (modelamiento de negocios, requerimientos, análisis y diseño, implementación, pruebas, despliegue y administración de configuración y cambios), así como los pasos para cada uno. Explica los artefactos clave, niveles de revisión y herramientas que se usarán. El objetivo es proveer una adaptación

1. -1-
RUP/Easy
GUÍA METODOLÓGICA DE DESARROLLO DE
SISTEMAS
Setiembre 2004
TABLA DE CONTENIDO
1 INTRODUCCIÓN ................................................................................................................................................1
2 ADECUACIÓN DE LOS WORKFLOWS ESENCIALES DEL RUP .......................................................2
2.1 WORKFLOWS ESENCIALES DEL RUP .............................................................................................2
2.2 VISTA GENERAL DEL WORKFLOW DEL RUP...............................................................................2
2.3 PROCEDIMIENTOS DE REVISIÓN.......................................................................................................3
3 LA VERSIÓN RUP/E DE LOS WORKFLOWS ESENCIALES DEL RUP.............................................4
3.1 MODELAMIENTO DE NEGOCIOS .......................................................................................................5
3.2 REQUERIMIENTOS ...................................................................................................................................5
3.3 ANÁLISIS Y DISEÑO ................................................................................................................................8
3.4 IMPLEM ENTACIÓN ................................................................................................................................10
3.5 PRUEBAS ....................................................................................................................................................11
3.6 DESPLIEGUE .............................................................................................................................................13
3.7 ADMINISTRACIÓN DE CONFIGURACIÓN Y CAMBIOS ...........................................................15
4 PASOS SIGUIENTES PARA LAS EMPRESAS CLIENTE .....................................................................17
GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS
1 INTRODUCCIÓN
Durante los últimos años, una de las metodologías más populares ha sido el Rational
Unified Process (RUP). RUP, desarrollado por Rational Software Corporation, es un
proceso de ingeniería de software que ofrece un enfoque disciplinado para asignar tareas
y responsabilidades dentro de la organización del desarrollo. RUP captura algunas de
las mejores prácticas de la industria para el desarrollo de software las cuales son para
desarrollar el software en iteraciones, administrar requerimientos, usar arquitecturas
basadas en componentes, verificar la calidad del software, controlar los cambios al
software y modelar el software visualmente usando el Unified Modeling Language
(UML). "El Unified Modeling Language (UML) es un método orientado a objetos y el
lenguaje estándar de la industria para especificar, visualizar, construir y documentar
los artefactos de sistemas de software.".

2. -2-
Este documento presenta los pasos para aplicar correctamente la metodología RUP en el
proceso de desarrollo de software. RUP es muy amplio y la mayoría de proyectos no
necesitan seguir todo lo que está en el RUP. Esta guía presenta la variación hecha en el
RUP denominada RUP/E para su aplicación en las empresas del Perú.
2 ADECUACIÓN DE LOS WORKFLOWS ESENCIALES DEL RUP
Esta sección explica cómo leer la adecuación de los Workflows esenciales del RUP
detallados en la sección 3 de este documento.
2.1 WORKFLOWS ESENCIALES DEL RUP
Esta guía metodológica cubre la adecuación para siete (7) de los nueve (9) workflows :
Modelamiento de Negocios, Requerimientos, Análisis y Diseño, Implementación,
Pruebas, Administración de Configuración y Cambios y Despliegue.
Esta guía metodológica excluye los workflows esenciales del RUP para Administración
de Proyectos y Entorno. Estos workflows, los cuales variarán de acuerdo a las políticas,
procedimientos y operaciones de cada empresa cliente interesada, serán revisados
separadamente.
2.2 VISTA GENERAL DEL WORKFLOW DEL RUP
La Sección 3 da una vista general a cada Workflow esencial del RUP y explica por qué
es importante incluir ése particular Workflow esencial del RUP en su ciclo de vida de
desarrollo de software.. Se presenta cada Workflow de Detalle dentro del Workflow
esencial del RUP y es explicado al igual que los artefactos clave producidos por cada
Workflow de detalle.
Cada workflow descrito en la Sección 3 contiene las siguientes subsecciones:
• Configuración y Notas sobre el Workflow del RUP
• Artefactos
• Reportes
2.2.1 Configuración y Notas sobre el Workflow del RUP
Estas subsecciones detallan los cambios aplicados a la estructura de workflows del RUP
en la variación de la metodología de RUP/E.
2.2.2 Artefactos
Un artefacto es un pedazo de información que es creado, modificado o usado por un
proceso tal como un modelo, un caso de uso, un documento, código fuente o un archivo
ejecutable. Estas subsecciones listan los artefactos que deberían ser producidos por cada
Workflow esencial del RUP en un formato de tabla. RUP provee templates, guías y
ejemplos para todos los artefactos. Si usted no está usando RUP, entonces deberán
desarrollarse los templates que puedan ser usadas en toda su organización para lograr

3. -3-
consistencia al capturar el mismo tipo de información. La Tabla 2 identifica las
columnas usadas para definir los artefactos producidos por cada workflow del RUP; las
entradas en las columnas son explicadas en la Tabla 1.
Tabla 1. Artefacto RUP
Revisar Herramientas
Artefactos Created/Revised
Detalles Usadas
RUP Artefacto 1 Incep Elab Const Trans
2.2.2.1 Explicación de la Tabla Artefacto RUP
La Tabla 2 da una explicación de las columnas en la Tabla Artefacto RUP mostrada en
la Tabla 1.
Tabla 2. Explicación de la Tabla Artefacto RUP
Nombre de Columna Propósito Contenidos/Comentarios
Artefactos El nombre del artefacto. Un Una referencia al artefacto en el
artefacto es un entregable del Rational Unified Process.
proceso.
Creado / Revisado Califica cómo es usado el Una 'X' en una o más de las celdas
artefacto a través del ciclo de Fase, significa que planeamos
vida congelar ese artefacto en esa fase
particular: Incepción, Elaboración,
Construcción y Transición.
Revisar Detalles Define el nivel de revisión; Decidir el nivel de revisión:
procedimientos de revisión que • Formal-Externo
van a ser aplicados al artefacto. • Formal-Interno
• Informal
• Ninguno
Para detalles vea la Sección 2.3,
Procedimientos de Revisión
Herramientas Usadas Definición de la herramienta (o Referencia a los detalles de las
herramientas) usadas para herramientas usadas para desarrollar
producir el artefacto. y mantener el artefacto.
2.2.3 Reportes
Esta subsección lista los reportes a ser usados por cada Workflow esencial del RUP. La
Tabla 3 muestra el formato que es usado para definir los reportes producidos por cada
Workflow esencial del RUP.
Tabla 3. Tabla de Reportes
Reportes Herramientas usadas
2.3 PROCEDIMIENTOS DE REVISIÓN

4. -4-
Durante el ciclo de vida de un proyecto, una revisión de un artefacto o conjunto de
artefactos es presentada al usuario, cliente u otras partes interesadas para comentarios y
aprobación. Cuando se hacen estas revisiones, usted debe tener en consideración que
las revisiones para el equipo de desarrollo “de casa” son diferentes a las revisiones para
el equipo de desarrollo de un contratista. Si las revisiones son “de casa” mayormente
son informales. Cuando el trabajo lo hace un contratista normalmente se hace una
revisión formal del trabajo del contratista. RUP/E ha adoptado los niveles de revisión
indicados en la Tabla 4.
Tabla 4. Guías de Niveles de Revisión del RUP
Nivel de Revisión Explicación Comentarios
Formal-Externo Este artefacto es un entregable en Por ejemplo, la Visión y el Caso del Negocio
un hito específico. Requiere algún
son artefactos que deberían ser revisados por
tipo de aprobación del cliente, el stakeholders.
patrocinador o algún otro
stakeholder externo. Los resultados de la revisión son manejados en
la configuración junto con el artefacto.
Formal-Interno El artefacto es revisado Por ejemplo, las interfases de diseño de
formalmente por el equipo del
subsistemas deberían ser revisados y aprobados
proyecto. por varios miembros del equipo del proyecto.
Los resultados de la revisión son manejados en
la configuración junto con el artefacto.
Informal El artefacto es revisado; pero no es Las Clases de Diseño y los Componentes son
aprobado formalmente. ejemplos de artefacto que no son aprobados
formalmente. El artefacto es desarrollado y
mantenido. Normalmente no es descartado
luego que el proyecto termina.
Los resultados de la revisión no son manejados
en la configuración con el artefacto.
Ninguno Este artefacto no necesita ser El artefacto es creado como información de
revisado ni aprobado. trabajo. A menudo es un artefacto temporal que
es descartado luego que el proyecto termina.
3 LA VERSIÓN RUP/E DE LOS WORKFLOWS ESENCIALES DEL RUP
La suite de herramientas de Rational (Rational Rose, RequisitePro, Rational Robot,
ClearCase, ClearQuest) y el RUP, desarrollados por Rational Software, fueron
escogidos para demostrar un enfoque iterativo del ciclo de vida de desarrollo de
software. RUP/E usó el marco metodológico del RUP para adecuar los siguientes
Workflows esenciales del RUP :
• Modelamiento de Negocios – Una técnica de análisis para modelar los procesos del
negocio y entender mejor las complejidades de éste.
• Requerimientos – Una condición o capacidad que el sistema debe cumplir.
• Análisis y Diseño - Muestra cómo los casos del uso del sistema se realizarán en la
implementación.
• Implementación – Implementar y probar las clases.

5. -5-
• Pruebas – Integrar y probar el sistema.
• Despliegue – Asegura una transición exitosa del sistema desarrollado a sus usuarios.
• Administración de la Configuración y Cambios –Identifica, define y estandariza
ítems; controla las modificaciones y releases de ítems.
Las organizaciones necesitarán incluir administración de proyectos con RUP y
adecuarse según sea necesario. Un Plan de Iteración es algo que debe ser producido
durante la administración del proyecto.
3.1 MODELAMIENTO DE NEGOCIOS
El Modelamiento de Negocios se efectúa para valorar el negocio para el cual el sistema
de información se está construyendo y para determinar mejor las necesidades y
problemas a ser resueltos por los sistemas de información. Los modelos del negocio
proveen una base para la comunicación entre los analistas de sistemas y los
desarrolladores para incrementar su entendimiento del negocio y para identificar
oportunidades de mejorar el negocio. También, los gerentes de proyecto usan los
modelos del negocio para ayudarse a estimar los costos del proyecto.
El Modelamiento del Negocio debería hacerse antes del desarrollo de software para
obtener un buen entendimiento de sus procesos del negocio. Sin embargo, el
Modelamiento del Negocio sólo debe ser efectuado si se está cambiando la manera en
que se hace negocio. Si sólo se está añadiendo una nueva característica a un sistema
existente, entonces RUP/E no recomienda que usted empiece con un modelamiento del
negocio. En ese caso, RUP/E recomienda que usted empiece con la Sección 3.2,
Requerimientos.
3.2 REQUERIMIENTOS
Se debería manejar las generaciones (versiones) de requerimientos y su documentación.
La Administración de Requerimientos incorpora la identificación, organización y
documentación de los cambios a los requerimientos en un proyecto. Es una parte
integral de la actividad de desarrollo de software. La Administración de Requerimientos
establece un entendimiento común y acuerdo entre el cliente y el equipo del proyecto
acerca de los requerimientos del cliente. Una Administración de Requerimientos
efectiva incluye el mantener requerimientos claros. Mantener atributos acerca de los
requerimientos (tales como estado, prioridad), proveer seguimiento a otros
requerimientos y componentes y, proveer de los recursos adecuados y fondos para
administrar los requerimientos.
3.2.1 Vista general del Workflow de Requerimientos
El propósito del Workflow de Requerimientos es :
• Establecer y mantener acuerdos con los clientes y otros stakeholders acerca de lo
que el sistema debe hacer
• Proveer a los desarrolladores del sistema con un mejor entendimientos de los
requerimientos del sistema
• Definir las fronteras del sistema (delimitarlo)

6. -6-
• Proveer de una base para planificar el contenido técnico de la iteraciones
• Proveer de una base para estimar el costo y el tiempo para desarrollar el sistema
• Definirle al sistema una interfase para el usuario enfocándose en las necesidades y
objetivos de los usuarios
Los artefactos clave a desarrollar son : Visión, Modelo de Casos de Uso, Casos de Uso
y Especificaciones Suplementarias. Estos artefactos describen lo que el sistema debe
hacer.
El Workflow de Requerimientos está relacionado a otros workflows del RUP :
• El Workflow de Modelamiento de Negocios (no considerado en la presente guía)
provee las reglas del negocio y un modelo de caso de uso del negocio.
• El input principal para el Workflow de Análisis y Diseño son el Modelo de Casos de
Uso y el Glosario creados durante el Workflow de Requerimientos. Por las fallas
que se descubran en el Modelo de Casos de Uso, se generará r querimientos de
e
cambio.
• El Workflow de Pruebas prueba el sistema para verificar el código contra el Modelo
de Casos de Uso, los Casos de Uso y las Especificaciones Suplementarias.
• El Workflow de Administración de la Configuración y Cambios provee los
mecanismos de control de cambios para los requerimientos.
Los workflows de Requerimientos consisten de los siguientes workflows de detalle :
Analizar el Problema
El documento Visión es el principal artefacto en el cual el análisis del problema es
documentado.
Entender las Necesidades del Stakeholder
El artefacto principal es un documento refinado de la Visión. También los
requerimientos son discutidos y expresados en términos de Casos de Uso y Actores. Los
requerimientos no funcionales, que no caen fácilmente en el Modelo de Casos de Uso
deberán ser documentados en los documentos de Especificaciones Suplementarias.
Definir el Sistema
En Definir el Sistema, se enfoca en identificar a los actores y los casos de uso más
completamente y expandir los requerimientos no funcionales definidos en los
documentos de especificaciones suplementarias.
Administrar el Alcance del Sistema
El alcance del proyecto es definido por el conjunto de requerimientos definidos para
éste. La clave para manejar un proyecto exitoso es administrar el alcance del proyecto
para cumpliendo con los recursos disponibles tales como el tiempo, la gente y el dinero.
Los atributos de requerimientos, tales como prioridad, esfuerzo y riesgo, son una técnica
útil para manejar el alcance del proyecto.

7. -7-
Refinar la Definición del Sistema
El output de este Workflow del RUP es una comprensión más profunda de la
funcionalidad del sistema expresada en Casos de Uso detallados y documentos de
Especificaciones Suplementarias detallados. Si es necesario, una Especificación de
Requerimientos de Software formal puede ser desarrollado, además de los documentos
detallados de Casos de Uso y Especificaciones Suplementarias.
Administrar los Requerimientos de Cambios
Los cambios a los requerimientos impactan los modelos producidos en el Workflow de
Análisis y Diseño, el modelo de pruebas creado en el Workflow de Pruebas y el material
de soporte al usuario final del Workflow de Despliegue. Las relaciones de rastreabilidad
son establecidas para identificar las relaciones entre los requerimientos y otros
artefactos. Las relaciones de rastreabilidad son la clave para entender el impacto del
cambio de los requerimientos.
3.2.2 Configuración y Notas sobre el Workflow de Requerimientos
Cada actividad en el Workflow de Requerimientos es esencial para una implementación
exitosa. Ninguna actividad debe ser removida del Workflow de Requerimientos.
3.2.3 Artefactos de Requerimientos
Los Artefactos de Requerimientos capturan y presentan información usada en definir las
capacidades requeridas por el sistema. La Tabla 7 identifica los artefactos que debe ser
desarrollados cuando se captura los requerimientos del sistema.
Tabla 7. Artefactos para el Workflow de Requerimientos
Artefactos Creado / Revisaedo Revisar Detalles Herramientas Usadas
Incep Elab Const Trans
Actor X X Informal Rational Rose
Glosario X X Formal-Externo Requisite Pro; MS Word
Lista de Riesgos X Formal-Externo Requisite Pro
Especificación Suplementaria X X Formal-Externo Requisite Pro; MS Word
Caso de Uso Formal-Externo Rational Rose; Requisite
X X Pro; MS Word
Modelo de Caso de Uso X X Formal-Externo Rational Rose
Vision Formal-Externo Requisite Pro; MS Word
3.2.4 Reportes de Requerimientos
La variación metodológica de RUP/E considera opcionales todos los reportes de
requerimientos; sin embargo, si van a usarse, la Tabla 8 identifica los reportes que
deben ser producidos durante el Workflow de Requerimientos. El Panorama del Modelo
de Casos de Uso (Use-Case Model Survey) es muy comprensible y cubre la mayoría de
la información contenida en los reportes de Actores y Casos de Uso.

8. -8-
Tabla 8. Reportes para el Workflow de Requerimientos
Reportes Herramientas Usadas
Panorama del Modelo de Caso de Uso Rational SoDA; MS Word
3.3 ANÁLISIS Y DISEÑO
El propósito del Workflow de Análisis y Diseño es empezar a realizar los casos de uso
desarrollados durante el Workflow de Requerimientos. Es decir, tomar el Modelo de
Casos de Uso, el Glosario y las Especificaciones Suplementarias creadas en el
Workflow de Requerimientos y generar un modelo de diseño que pueda ser usado por
los desarrolladores durante el Workflow de Implementación. El Análisis se enfoca en
trasladar los requerimientos funcionales a conceptos de software.
3.3.1 Vista General del Workflow de Análisis y Diseño
El propósito del Workflow de Análisis y Diseño es:
• Transformar los requerimientos en un diseño del sistema a crear
• Definir una arquitectura robusta para el sistema
• Adaptar el diseño para que funcione en el ambiente de implementación diseñándolo
para obtener buena performance
El Workflow de Análisis y Diseño toma los casos de uso documentados del Workflow
de Requerimientos y del Workflow de Modelamiento de Negocios y los traslada a
elementos de diseño que serán usados para construir el sistema. Por medio de usar
varias actividades y modelos el Workflow de Análisis y Diseño busca destilar la
información recogida de los stakeholders en información que los programadores podrán
usar. Al final, un Modelo de Diseño, el documento de Arquitectura del Software, el
Modelo de Despliegue y una Realización de Casos de Uso por cada Caso de Uso
describirán el sistema. El Workflow de Análisis y Diseño está relacionado a otros
workflow del RUP como sigue :
• El Workflow de Implementación usará el Modelo de Diseño, el Modelo de
Despliegue, el documento de Arquitectura del Software y las Realizaciones de
Casos de Uso como inputs en la construcción e implementación del sistema.
• El Workflow de Pruebas usará las realizaciones de casos de Uso y el documento de
Arquitectura del Software para probar la funcionalidad y la compatibilidad de los
componentes.
• El Modelo de Despliegue y el documento de Arquitectura del Software será usado
por el Workflow de Despliegue para desplegar el sistema final.
El Workflow de Análisis y Diseño consiste de los siguiente workflows de detalle:

9. -9-
Definir una Arquitectura candidata
Refinar la Arquitectura
Analizar el Comportamiento
Diseñar la base de Datos (Opcional)
3.3.2 Configuración y Notas sobre el Workflow de Análisis y Diseño
El Workflow de detalle Refinar la Arquitectura puede ser saltado si hay relativamente
pocos riesgos arquitecturales. Esto es, el diseño, la implementación y la distribución del
sistema no producen problemas arquitecturales significativos o el arquitecto de software
tiene suficiente experiencia para manejar tales hechos.
El Workflow de detalle Efectuar Síntesis Arquitectural puede ser saltado. Este
Workflow de detalle puede ser efectuado si es que se necesita profundizar los
conceptos.
Los workflows de detalle Diseñar Componente de Tiempo Real y Diseñar Componente
[No – Tiempo Real] son similares con la excepción de que el primero se enfoca en
componentes que son para sistemas en tiempo real y el otro para sistemas reactivos.
3.3.3 Artefactos para Análisis y Diseño
Los Artefactos para Análisis y Diseño capturan y presentan información relativa a la
solución de los problemas planteados durante el Workflow de Requerimientos. La Tabla
9 identifica los artefactos que deberán producirse durante el Workflow de Análisis y
Diseño.
Tabla 9. Artefactos para el Workflow de Análisis y Diseño
Artefactos Creado / Revisado Revisar Detalles Herramientas Usadas
Incep Elab Const Trans
Modelo de Diseño X X X Formal - Externo Rational Rose
Modelo de Datos X X Informal - Interno Rational Rose
Documento de X X X Formal - Externo RequistePro; MS Word
Arquitectura del Software
3.3.4 Reportes para Análisis y Diseño
La variación metodológica de RUP/E considera opcionales todos los reportes de
requerimientos; sin embargo, si van a usarse, la Tabla 10 identifica los siguientes
reportes opcionales :
Tabla 10. Reportes para el Workflow de Análisis y Diseño
Reportes Herramientas Usadas
Clase Rational SODA
Panorama del Modelo de Diseño Rational SODA

10. - 10 -
3.4 IMPLEMENTACIÓN
La Implementación es donde empieza el código El Modelo de Diseño del Workflow de
Análisis y Diseño es mapeado con el Modelo de Implementación y entonces se escribe
el código en un lenguaje de programación tal como Java, C++ o Visual Basic.
Un Plan de Integración de Construcciones define el Caso de Uso a ser diseñado y las
clases a implementar, al igual que el orden en el que las clases son implementadas.
3.4.1 Vista general del Workflow de Implementación
El propósito del Workflow de Implementación es:
• Definir la organización del código, en términos de Subsistemas de Implementación.
Define the organization of the code, in terms of Subsistema de Implementación. Los
Subsistemas de Implementación son colecciones de componentes y otros modelos
de implementación usados para estructurar el modelo de implementación.
• Implementar las clases y objetos definidos en el modelo de diseño en la forma de
componentes de software tales como archivos fuente, binarios o ejecutables
• Probar los componentes desarrollados como unidades
• Crear un sistema ejecutable
El Workflow de Implementación está relacionado a otros workflows del RUP como
sigue:
• Requerimientos: Este workflow del RUP captura los requerimientos que deberían
ser cumplidos durante la Implementación.
• Análisis y Diseño: El modelo de diseño desarrollado durante este workflow
representa el intento de la implementación y es el input principal para el Workflow
de Implementación.
• Pruebas: Este workflow describe cómo probar cada Construcción durante la
integración del sistema.
Para cada iteración, empezando en la fase de Elaboración, se efectúan los siguientes
workflows de detalle :
Estructurar el Modelo de Implementación
El artefacto principal producido es el Modelo de Implementación.
Planificar la Integración
El artefacto principal producido es el Plan de Integración de Construcciones. Según la
arquitectura y el diseño evolucionan, el Plan de Integración de Construcciones es
examinado y actualizado para asegurar que no quede obsoleto debido a los cambios en
la arquitectura o en el diseño del nuevo sistema.

11. - 11 -
Implementar los Componentes
La Implementación debería estar unida muy de cerca al Diseño. El artefacto principal
producido es el Componente.
Integrar cada Subsistema
Los principales artefactos producidos son la Construcción y el Subsistema de
Implementación.
Integrar el Sistema
La Integración a menudo envuelve un alto grado de automatización, experiencia en
sistemas operativos o lenguajes script y herramientas como 'make' (en Unix). El
artefacto principal producido es la Construcción.
3.4.2 Configuración y Notas sobre el Workflow de Implementación
Cada actividad en el Workflow de Implementación es esencial p una implementación
ara
exitosa. Ninguna actividad debe removerse del Workflow de Implementación.
3.4.3 Artefactos para la Implementación
Los Artefactos para la Implementación capturan y presentan la realización de la
solución presentada en el Workflow de Análisis y Diseño. La Tabla 11 identifica los
artefactos que deben producirse durante el Workflow de Implementación.
Tabla 11. Artefactos para el Workflow de Implementación
Artefactos Creado/Revisado Revisar Detalles Herramientas Usadas
Incep Elab Const Trans
Construcción X X X Formal - Externo Rational Rose
Por este artefacto se entiende al Prototipo o Producto, según la fase en que se encuentre
el proyecto, resultante de cada iteración.
3.4.4 Reportes para la Implementación
Ningún reporte será producido durante el Workflow de Implementación. Sin embargo,
se efectuarán revisiones informales del código.
3.5 PRUEBAS
Rational ofrece su enfoque de pruebas usando el RUP para valorar la calidad del
software por medio de:
• Encontrar y documentar los defectos en la calidad del software
• Aconsejando acerca de la calidad percibida en el software
• Proveyendo la validación de los supuestos hechos en las especificaciones de diseño
y los requerimientos a través de demostraciones concretas
• Validando las funciones del producto de software según sean diseñadas

12. - 12 -
• Validando que los requerimientos hayan sido implementados apropiadamente
3.5.1 Vista General del Workflow de Pruebas
El propósito de este workflow del RUP es:
• Verificar la interacción entre objetos
• Verificar la interacción apropiada de todos los componentes del software
• Verificar que todos los requerimientos hayan sido implementados correctamente
• Identificar y asegurar que los defectos se hayan atendido y resuelto antes del
despliegue del software
En el RUP, las pruebas son enfocadas a través del uso de un proceso iterativo y de
herramientas. Un enfoque iterativo para probar permite a la organización tratar las
pruebas casi de la misma forma que el desarrollo de software es enfocado. Cada
Construcción de software es un objetivo para las pruebas. Según se vayan produciendo
nuevas Construcciones, el cuerpo de pruebas será añadido y refinado. Eventualmente,
todas las pruebas en el cuerpo de pruebas serán acumuladas de tal manera que pueden
ser usadas para las posteriores pruebas de regresión en el ciclo de vida del desarrollo de
software. Este enfoque permite a una organización identificar posibles riesgos al inicio
de un proyecto, reducir el costo de corregir fallas enfocando los recursos cuando y
donde tendrán el mayor impacto, acercarse a los gaps de calidad tempranamente en el
proceso de desarrollo y maximizar la efectividad por medio de adaptar el enfoque, el
proceso o el presupuesto según va progresando el proyecto.
Este workflow del RUP está relacionado a otros workflows del RUP como sigue:
• El Workflow de Requerimientos captura el input principal para identificar cuales
pruebas efectuar en la forma de requerimientos en un modelo de caso de uso.
• El Workflow de Análisis y Diseño captura el input principal para identificar cuales
pruebas efectuar describiendo cómo desarrollar un diseño.
• El Workflow de Implementación produce las Construcciones de software del
modelo de implementación que es probado por medio del Workflow de Pruebas.
Dentro de una iteración, hay varias construcciones probadas: la primera cuando el
sistema es integrado y la última para probar todo el sistema.
El Workflow de Pruebas consiste de los siguientes Workflows de detalle:
Planificar las Pruebas
El principal artefacto producido es el Plan de Pruebas.
Diseñar las Pruebas
Los principales artefactos producidos son el Modelo de Pruebas (Test Model), los Casos
de Prueba (Test Case), los Procedimientos de Prueba (Test Procedures) y el documento
de Análisis de Carga de Trabajo (Workload Analysis Document).

13. - 13 -
Implementar las Pruebas
Los principales artefactos producidos son el Script de la Prueba y el Componente de la
Prueba.
Ejecutar las Pruebas en la etapa de Integración de Pruebas
El principal artefacto producido es el documento Resultado de Pruebas.
Ejecutar las Pruebas en la etapa de Pruebas del Sistema
El principal artefacto producido es el documento Resultado de Pruebas.
Evaluar las Pruebas
Los principales artefactos producidos son el Sumario de Evaluación de Pruebas (Test
Evaluation Summary) y los Requerimientos de Cambio (Change Request).
3.5.2 Configuración y Notas sobre el Workflow de Pruebas
Cada actividad en el Workflow de Pruebas es esencial para probar exitosamente.
Ninguna actividad debe ser removida del Workflow de Pruebas.
3.5.3 Artefactos de Pruebas
Los artefactos presentados en la siguiente tabla son productos finales e intermedio que
son producidos y usados durante el Workflow de Pruebas de un proyecto. Loas
artefactos de Pruebas capturan y comunican información de pruebas y pueden tomar la
forma de un documento, un modelo o un elemento de modelo. La Tabla 12 identifica los
artefactos que deben ser desarrollados en el Workflow de Pruebas.
Tabla 12. Artefactos para el Workflow de Pruebas
Artefactos Creado / Revisado Revisar Detalles Herramientas Usadas
Incep Elab Const Trans
Caso de Prueba X Informal - Interno Test Manager
Plan de Pruebas/ X X Formal - Externo o
Manager
Procedimientos Prueba Interna
Resultados de las X X Formal - Interno Test Manager
Pruebas
Script de Pruebas X X X Informal - Interno Robot, Manual Test
3.5.4 Reportes para las Pruebas
Ningún reporte será producido durante Workflow de Despliegue. Los artefactos
producen la necesaria información workflow del RUP.
3.6 DESPLIEGUE
Una vez que el producto de software ha siso implementado y probado exitosamente, es

14. - 14 -
momento de llevar el producto al cliente. El propósito de este workflow del RUP es
producir releases del producto y llevar el software a los usuarios finales.
3.6.1 Vista General del Workflow de Despliegue
El Workflow de Despliegue implica probar el software en su ambiente operacional
final, empacar el software para la entrega, distribuir el software, instalar el software,
entrenar a los usuarios finales y convertirlas bases de datos anteriores para la carga de
datos.
Hay tres maneras de proveer del producto al usuario final:
• La instalación en el cliente
• Se entrega un “instalador” (generado con algún producto de compresión e
instalación)
• Accesar al software por la Internet
Cualquiera que sea el método escogido para entregar al cliente, la prueba del producto
ocurre en el site de desarrollo seguido por la prueba Beta y finalmente liberando el
producto al cliente.
El Workflow de Despliegue está relacionado a otros workflows del RUP, como sigue:
Planificar el Despliegue
Desarrollar Material de Soporte
Produce el material de soporte, el cual incluye instrucciones para instalación, operación
y mantenimiento para el sistema desplegado. También incluye el material de
entrenamiento para las diversas posiciones requeridas para usar el sistema
efectivamente.
Manejar las Pruebas de Aceptación
Producir la Unidad de Despliegue
Empaquetar el Producto
Proveer Acceso al Site de Descarga
Producto en Beta
3.6.2 Configuración y Notas sobre el Workflow de Despliegue
Las organizaciones grandes pueden empacar el producto y dar acceso a un site de
descarga; sin embargo, la mayoría no necesita efectuar estos workflows de detalle.
3.6.3 Artefactos para el Despliegue
Los artefactos de Despliegue capturan y presentan información relativa a posicionar el

15. - 15 -
sistema, presentado en el Workflow de Implementación, dentro del ambiente de
producción. La Tabla 14 identifica los artefactos que deben ser producidos durante el
Workflow de Despliegue.
Tabla 14. Artefactos para el Workflow de Despliegue
Artefactos Creado/Revisado Revisar Detalles Herramientas Usadas
Incep Elab Const Trans
Relación de Materiales X X Informal MS Word
Plan de Despliegue X X X Informal MS Word
Producto X Formal-Externo MS Word
Notas del Release X Formal - Interno MS Word
Materiales de Entrenamiento X X X Formal - Externo MS Word
Por Materiales de Entrenamiento, se entenderá el Manual del Usuario y el Manual
Técnico.
3.6.4 Reportes para el Despliegue
Ningún reporte será producido durante Workflow de Despliegue. Los artefactos
producen la necesaria información workflow del RUP.
3.7 ADMINISTRACIÓN DE CONFIGURACIÓN Y CAMBIOS
La mayoría de equipos de desarrollo de software experimentados reconocen la
necesidad del control de versiones de los artefactos del software. Parcialmente, a causa
de que el software es tan fácil de cambiar, un proyecto está continuamente vulnerable a
la introducción inadvertida de incompatibilidades (errores de regresión) y fallas
resultantes de la aplicación a menos que una disciplina constante sea aplicada. El
control de versiones, sin embargo, es sólo un componente de la Administración de
Configuración y Cambios (Configuration & Change Management -CCM-). Un buen
sentido de ordenamiento es provisto por esta lista de las mejores prácticas de CCM :
• Identificar y almacenar los artefactos en un repositorio seguro
• Controlar y auditar loa cambios a los artefactos
• Organizar los artefactos en componentes versionados
• Crear versiones congeladas (baselines) en los hitos del proyecto
• Registrar y rastrear los requerimientos de cambio
• Organizar e integrar juegos consistentes de versiones (algunas veces llamados
“actividades”)
• Mantener áreas de trabajo estables y consistentes (inclusive sobre sites distribuidos
geográficamente)
• Soportar cambios concurrentes a los artefactos y componentes
• Integrar tempranamente y a menudo
• Asegurar que las Construcciones de software sean reproducibles
RUP/E recomienda usar CRM (Change Requeriment Management) en todas las fases

16. - 16 -
del ciclo de vida después de la Incepción. Aunque CRM puede ser hecho manualmente,
sus mayores beneficios se obtienen cuando se usa una herramienta automatizado para
hacer uso de una base de datos. Existe un número de excelente herramientas de CRM.
ClearQuest de Rational es una buena opción si planea integrarse con otras herramientas
de Rational.
Además de automatizar, lo que muchos consideran un proceso tedioso, una herramienta
CRM manejada con una base de datos también provee otro gran beneficio : la habilidad
de extraer información fácilmente acerca del progreso del proyecto, especialmente en
las fases de Construcción y posteriores. Una buena herramienta de CRM permite que se
pueda crear consultas ad-hoc fácilmente.
3.7.1 Vista general del Workflow de Administración de Configuración y Cambios
El propósito de este workflow del RUP es:
• Soportar métodos de desarrollo
• Mantener la integridad del producto
• Asegurar que el producto configurado esté completo y correcto
• Proveer de un ambiente estable dentro del cual se desarrolla el producto
• Restringir los cambios a los artefactos basados en las políticas del proyecto
• Proveer pistas de auditoria de cambios a los artefactos registrando por qué, cuándo y
por quién
El Workflow de Administración de Configuración y Cambios está relacionado a otros
workflows esenciales del RUPs (Modelamiento de Negocios, Requerimientos, Análisis
y Diseño, Implementación, Pruebas, Despliegue) porque sirve como un repositorio para
los artefactos producidos durante esos workflows del RUPs.
Los artefactos clave son el Plan de Administración de Configuración (Configuration
Management Plan) y los Requerimientos de Cambio (Change Request)
Los siguientes Workflows de detalle de Administración de Configuración y Cambios
son efectuados:
Planificar la Configuración del Proyecto y el Control de Cambios
El Plan CM describe todas las actividades a efectuarse durante el curso del ciclo de vida
del proyecto. El Plan CM documenta cómo se planifica, implementa, controla y
organiza las actividades relativas al CM del producto.
Crear un Ambiente CM para el Proyecto
Los desarrolladores e integradores son provistos de espacios de trabajo privados y
compartidos donde puedan construir e integrar el software.

17. - 17 -
Cambiar y Enviar los Items de la Configuración
Manejar Versiones Congeladas (Baselines) y Liberacioness
Monitorear y Reportar el estado de la Configuración
Administrar los Requerimientos de Cambio
3.7.2 Notas sobre el Workflow de Administración de Configuración y Cambios
Cada actividad en el Workflow de Administración de Configuración y Cambios es
esencial para una administración de configuración exitosa. Ninguna actividad debe ser
removida del Workflow de Administración de Configuración y Cambios.
3.7.3 Artefactos RUP de Administración de Configuración y Cambios
Los artefactos e Administración de Configuración y Cambios capturan y presentan
información relativa a las actividades CM. La Tabla 15 identifica los artefactos que
deben ser producidos durante el Workflow de Administración de Configuración y
Cambios.
Tabla 15. Artefactos para la Administración de Configuración y Cambios
Artefactos Creado/Revisado Revisar Detalles Herramientas Usadas
Incep Elab Const Trans
Requerimiento de Cambio X X X Informal Rational ClearQuest
Repositorio del Proyecto X X X Ninguno Rational ClearCase
Workspace X X X Ninguno Rational ClearCase
4 PASOS SIGUIENTES PARA LAS EMPRESAS CLIENTE
La Sección 3 da una versión adecuada genérica del RUP usando la suite de herramientas
de Rational; sin embargo, esto puede no cubrir las necesidades de cada empresa. Las
empresas deberán hacer lo siguiente :
• Evaluar sus organizaciones para determinar cómo proveer del ambiente de
desarrollo de software necesario para soportar a su equipo de desarrollo; este
ambiente puede incluir las herramientas de la Suite de Rational u otras herramientas
• Comprar nuevo software, si es necesario
• Lograr la disponibilidad de usar la metodología de parte de la Administración
• Obtener el entrenamiento apropiado en el software usado
• Decidir si se desarrollará otros artefactos adicionales a los indicados en la Sección 3
• Incluir un enfoque de administración de proyectos para :
− manejar riesgos
− planificar proyectos
− identificar métricas
− monitorear el progreso del proyecto y;
− manejar recursos, presupuestos y contratos con proveedores y clientes