RUP/Easy guía metodológica

- 1 -
RUP/Easy
GUÍA METODOLÓGICA DE DESARROLLO DE
SISTEMAS
Documento basado en THE ITSC SYSTEM DEVELOPMENT
METHODOLOGY GUIDEBOOK
Prepared by the
Information Technology Support Center
September 2002
Oswaldo Canchumani Grillo, PMP
Marzo del 2006

- 2 -
Histórico de cambios
Fecha Versión Descripción Autor
Setiembre 2004 1.0 Creación del documento Oswaldo Canchumani
Marzo 2006 2.0 Se extendió a todos los procesos Oswaldo Canchumani

- 3 -
RUP/Easy
GUÍA METODOLÓGICA DE DESARROLLO DE
SISTEMAS
Marzo del 2006
TABLA DE CONTENIDO
1 INTRODUCCIÓN.................................................................................................................................5
2 ADECUACIÓN DE LOS WORKFLOWS ESENCIALES DEL RUP.................................................5
2.1 WORKFLOWS ESENCIALES DEL RUP ...................................................................................5
2.2 VISTA GENERAL DEL WORKFLOW DEL RUP ......................................................................5
2.2.1 Configuración y Notas sobre el Workflow del RUP ...............................................................6
2.2.2.1 Explicación de la Tabla Artefacto RUP................................................................................6
2.3 PROCEDIMIENTOS DE REVISIÓN ...........................................................................................7
3 VERSIÓN ADECUADA DE RUP/Easy DE LOS WORKFLOWS ESENCIALES DEL RUP...........8
3.1 MODELAMIENTO DE NEGOCIOS ............................................................................................9
Valorizar el Estado del Negocio.................................................................................................11
Describir el Negocio Actual .......................................................................................................12
Identificar los Procesos del Negocio ..........................................................................................12
Refinar las Definiciones de los Procesos del Negocio................................................................13
Diseñar las Realizaciones de los Procesos del Negocio .............................................................14
Refinar los Roles y las Responsabilidades .................................................................................14
Explorar la Automatización de Procesos....................................................................................15
Desarrollar un Modelo de Dominio............................................................................................15
3.2 REQUERIMIENTOS...................................................................................................................18
3.2.1 Vista general del Workflow de Requerimientos....................................................................18
Analizar el Problema ..................................................................................................................19
Entender las Necesidades del Stakeholder..................................................................................20
Definir el Sistema.......................................................................................................................21
Administrar el Alcance del Sistema ...........................................................................................22
Refinar la Definición del Sistema...............................................................................................23
Administrar los Requerimientos de Cambios .............................................................................24
3.2.2 Configuración y Notas sobre el Workflow de Requerimientos .............................................25
3.2.3 Artefactos de Requerimientos................................................................................................25
3.2.4 Notas sobre los Artefactos de Requerimientos ......................................................................25
3.2.5 Reportes de Requerimientos..................................................................................................26
3.2.6 Notas sobre los Reportes de Requerimientos.........................................................................26
3.3 ANÁLISIS Y DISEÑO ................................................................................................................27
3.3.1 Vista General del Workflow de Análisis y Diseño................................................................27
Definir una Arquitectura candidata ............................................................................................28
Refinar la Arquitectura ...............................................................................................................29
Analizar el Comportamiento.......................................................................................................30
Diseñar los Componentes ...........................................................................................................30
Diseñar la base de Datos (Opcional)...........................................................................................31
3.3.2 Configuración y Notas sobre el Workflow de Análisis y Diseño ..........................................32

- 4 -
3.3.3 Artefactos para Análisis y Diseño .........................................................................................32
3.3.4 Notas sobre los Artefactos para Análisis y Diseño................................................................33
3.3.5 Reportes para Análisis y Diseño............................................................................................34
3.4 IMPLEMENTACIÓN ..................................................................................................................34
3.4.1 Vista general del Workflow de Implementación ...................................................................34
Estructurar el Modelo de Implementación..................................................................................35
Planificar la Integración..............................................................................................................36
Implementar los Componentes ...................................................................................................36
Integrar cada Subsistema............................................................................................................37
Integrar el Sistema......................................................................................................................37
3.4.2 Configuración y Notas sobre el Workflow de Implementación.............................................38
3.4.3 Artefactos para la Implementación........................................................................................38
3.4.4 Notas sobre los Artefactos para la Implementación ..............................................................38
3.4.5 Reportes para la Implementación ..........................................................................................38
3.5 PRUEBAS....................................................................................................................................38
3.5.1 Vista General del Workflow de Pruebas................................................................................39
Planificar las Pruebas..................................................................................................................51
Diseñar las Pruebas.....................................................................................................................52
Implementar las Pruebas.............................................................................................................53
Ejecutar las Pruebas en la etapa de Integración de Pruebas........................................................54
Ejecutar las Pruebas en la etapa de Pruebas del Sistema............................................................54
Evaluar las Pruebas.....................................................................................................................55
3.5.2 Configuración y Notas sobre el Workflow de Pruebas..........................................................56
3.5.3 Artefactos de Pruebas............................................................................................................56
3.5.4 Notas sobre los Artefactos para Pruebas................................................................................56
3.5.5 Reportes para las Pruebas......................................................................................................57
3.6 DESPLIEGUE..............................................................................................................................57
3.6.1 Vista General del Workflow de Despliegue ..........................................................................57
Planificar el Despliegue..............................................................................................................59
Desarrollar Material de Soporte..................................................................................................59
Manejar las Pruebas de Aceptación............................................................................................59
Producir la Unidad de Despliegue ..............................................................................................60
Empaquetar el Producto..............................................................................................................60
Proveer Acceso al Site de Descarga ...........................................................................................61
Producto en Beta.........................................................................................................................61
3.6.2 Configuración y Notas sobre el Workflow de Despliegue ....................................................61
3.6.3 Artefactos para el Despliegue................................................................................................61
3.6.4 Notas sobre los Artefactos para el Despliegue ......................................................................62
3.6.5 Reportes para el Despliegue ..................................................................................................62
3.7 ADMINISTRACIÓN DE CONFIGURACIÓN Y CAMBIOS ....................................................62
3.7.1 Por qué implementar Administración de Configuración y Cambios .....................................62
3.7.2 Vista general del Workflow de Administración de Configuración y Cambios......................64
Planificar la Configuración del Proyecto y el Control de Cambios...........................................74
Crear un Ambiente CM para el Proyecto....................................................................................75
Cambiar y Enviar los Items de la Configuración........................................................................76
Manejar Versiones Congeladas (Baselines) y Liberaciones.......................................................76
Monitorear y Reportar el estado de la Configuración.................................................................77
Administrar los Requerimientos de Cambio...............................................................................77
3.7.3 Notas sobre el Workflow de Administración de Configuración y Cambios..........................78
3.7.4 RUP Artefactos de Administración de Configuración y Cambios.........................................78
3.7.5 Notas sobre los Artefactos para la Administración de Configuración y Cambios.................78
3.7.6 Notas sobre los reportes de Administración de Configuración y Cambios............................79
4 PASOS SIGUIENTES PARA LAS EMPRESAS CLIENTE .............................................................79

- 5 -
RUP / Easy
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.". Un Artefacto es una pieza de información que
es creada, modificada o usada por un proceso tal como un modelo, un Caso de Uso, un
documento, código fuente o archivo ejecutable.
Esta guía documenta 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 demuestra la variación hecha en
el RUP por RUP/Easy 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 los nueve (9) workflows:
Modelamiento de Negocios, Requerimientos, Análisis y Diseño, Implementación,
Pruebas, Administración de Configuración y Cambios, Despliegue.
Esta guía metodológica excluye los workflows esenciales del RUP para
Administración de Proyectos y Ambiente.
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 un Diagrama de Actividades que detalla la
estructura del los workflows esenciales del RUP. Cada Workflow de detalle dentro del
Workflow esencial del RUP es explicado al igual que los artefactos clave producidos
por cada Workflow de detalle. Este documento no describe a los trabajadores durante la
explicación de cada Workflow esencial del RUP.

- 6 -
Cada workflow descrito en la Sección 3 contiene las siguientes subsecciones:
• Configuración y Notas sobre el Workflow del RUP
• Artefactos
• Notas sobre los Artefactos
• Reportes
• Notas sobre los 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/Easy.
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 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
Artefactos Created/Revised
Revisar
Detalles
Herramientas
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
artefacto es un entregable del
proceso.
Una referencia al artefacto en el
Rational Unified Process.
Creado / Revisado Califica cómo es usado el
artefacto a través del ciclo de
vida
Una 'X' en una o más de las celdas
Fase, significa que planeamos
congelar ese artefacto en esa fase
particular: Incepción, Elaboración,
Construcción y Transición.

- 7 -
Revisar Detalles Define el nivel de revisión;
procedimientos de revisión que
van a ser aplicados al artefacto.
Decidir el nivel de revisión:
• Formal-Externo
• Formal-Interno
• Informal
• Ninguno
Para detalles vea la Sección 2.3,
Procedimientos de Revisión
Herramientas Usadas Definición de la herramienta (o
herramientas) usadas para
producir el artefacto.
Referencia a los detalles de las
herramientas usadas para desarrollar
y mantener el artefacto.
2.2.3 Notas sobre los Artefactos
RUP viene con una lista de artefactos que se pueden producir en cada Workflow
esencial del RUP. Usar el RUP efectivamente en su organización, podría no ser
necesario que produzca todos los artefactos. La Sección 3 identifica esos artefactos del
RUP que no son producidos en cada Workflow esencial del RUP en la variación de la
metodología de RUP/Easy. Cuando lea esta sección use el glosario para comprender
mejor el propósito de los artefactos listados.
2.2.4 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.2.5 Notas sobre los Reportes
Un reporte extrae información acerca de modelos y elementos de los modelos desde una
herramienta. RUP viene con una lista de reportes que pueden ser producidos para cada
Workflow esencial del RUP. Usar el RUP efectivamente en su organización, podría no
ser necesario que produzca todos los reportes. La Sección 5 identifica esos reportes del
RUP que no son producidos en cada Workflow esencial del RUP en la variación de la
metodología de RUP/Easy..
2.3 PROCEDIMIENTOS DE REVISIÓN
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/Easy ha adoptado los niveles de
revisión indicados en la Tabla 4.

- 8 -
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
un hito específico. Requiere algún
tipo de aprobación del cliente, el
patrocinador o algún otro
stakeholder externo.
Por ejemplo, la Visión y el Caso de Negocio
son artefactos que deberían ser revisados por
stakeholders.
Los resultados de la revisión son manejados en
la configuración junto con el artefacto.
Formal-Interno
El artefacto es revisado
formalmente por el equipo del
proyecto.
Por ejemplo, las interfases de diseño de
subsistemas deberían ser revisados y aprobados
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
aprobado formalmente.
Las Clases de Diseño y los Componentes son
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
revisado ni aprobado.
El artefacto es creado como información de
trabajo. A menudo es un artefacto temporal que
es descartado luego que el proyecto termina.
3 VERSIÓN ADECUADA DE RUP/Easy 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/Easy 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.
• 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 típicamente usan enfoques de administración de proyectos para sus
proyectos de desarrollo de software. 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 Control de Proyectos.

- 9 -
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.
3.1.1 Porqué modelar el negocio
Ya que los negocios están siendo cada vez más automatizados y los sistemas de
computadora están tocando cada aspecto del negocio, la clave para implementar
exitosamente un nuevo sistema de computadora es entender el negocio. También con la
evolución de los negocios existentes y nuevos negocios requiriendo muchas piezas
complejas interconectadas, el modelamiento de negocios provee una vista interna de si
el negocio está haciendo, o no, las cosas correctas y cómo el valor del negocio puede ser
mejorado. El modelo del negocio provee un salto de inicio para capturar los
requerimientos del sistema (Más detalles acerca de capturar los requerimientos se
encuentran en la Sección 3.2.).
3.1.2 Vista general del Workflow de Modelamiento de Negocios
El propósito del Workflow de Modelamiento de Negocios es:
• Entender la estructura y las dinámicas de la organización en la cual un sistema va a
ser desplegado (la organización objetivo).
• Entender los problemas actuales en la organización objetivo e identificar mejoras
potenciales.
• Asegurar que los clientes, usuarios finales y desarrolladores tiene un entendimiento
común de la organización objetivo.
• Derivar los requerimientos necesarios para soportar la organización objetivo.
Los artefactos clave del Workflow de Modelamiento de Negocios son la Visión del
Negocio (Business Vision), Modelo de Caso de Uso del Negocio (Business Use-Case
Model) y el Modelo de Objetos del Negocio (Business Object Model). Otros artefactos
del Workflow de Modelamiento de Negocios son el Reglas del Negocio (Bussines
Rules), Especificaciones Suplementarias del Negocio (Business Supplementary
Specification) y el Glosario del Negocio (Business Glossary).
El Workflow de Modelamiento de Negocios está relacionado a otros Workflows del
RUP, como sigue:
• El Workflow de Requerimientos usa modelos del negocio como un input
importante para entender los requerimientos del sistema.
• Las entidades del negocio son usadas como un input para identificar clases en el

- 10 -
modelo de diseño del Workflow de Análisis y Diseño.
La Figura 1 ilustra las actividades efectuadas durante el Modelamiento de Negocios .
Figura 1. Workflow de Modelamiento de Negocios
El Workflow de Modelamiento de Negocios consiste de los siguientes Workflows de
detalle:
• Valorizar el Estado del Negocio (Assess Business Status)
• Describir el negocio Actual (Describe Current Business)
• Identificar los Procesos del Negocio (Identificar Business Processes)
• Refinar las Definiciones de los Procesos del Negocio (Refine Business Process
Definitions)
• Diseñar las Realizaciones de los Procesos del Negocio (Design Business Process
Realizations)
• Refinar los Roles y las Responsabilidades (Refine Roles y Responsibilities)

- 11 -
• Explorar la Automatización de Procesos (Explore Process Automation)
• Desarrollar un Modelo de Dominio (Workflow de detalle alternativo) (Develop a
Domain Model -alternative Workflow detail-)
Valorizar el Estado del Negocio
El propósito de este Workflow de detalle es:
• Valorizar el estado de la organización en la cual el nuevo sistema va a ser
desplegado (la organización objetivo).
• Entender cómo categorizar el proyecto y cual escenario de Modelamiento de
Negocios, listado a continuación, se adecua más a su proyecto:
− Gráfico de la Organización – un mapa simple de la organización para entender
mejor los requerimientos.
− Modelamiento de Dominio – es usado para construir aplicaciones cuyo
propósito principal es manejar y presentar información.
− Un negocio, muchos sistemas – un modelo del negocio para un sistema grande o
una familia de aplicaciones.
− Modelo de negocios genérico – para una aplicación usada por muchas
organizaciones.
− Negocio nuevo – para una línea completamente nueva de negocios y los sistemas
que la soportan.
− Renovar el negocio existente – para cambiar completamente la forma de hacer
negocios (reingeniería de procesos de negocios)
• Tomar decisiones acerca de cómo continuar trabajando en la iteración actual y
delinear cómo trabajar en iteraciones siguientes con los artefactos de modelamiento
de negocios.
Comprende las siguientes actividades:
• Capturar un Vocabulario de Negocios común. Definir un vocabulario común que
pueda ser usado en todas las descripciones textual el negocio, especialmente en las
descripciones de los Casos de Uso.
• Mantener las Reglas del Negocio. Determinar qué reglas del negocio se van a
considerar en el proyecto. Dar definiciones detalladas a las reglas del negocio.
• Definir la Arquitectura del Negocio. Comprender las fuerzas que afectan al negocio
significativamente. Definir una arquitectura para el negocio. Definir los patrones,
mecanismos clave y convenciones de modelamiento para el negocio.
• Evaluar la Organización Objetivo. Describir es estado actual de la organización la
cual la aplicación va a ser desplegada en términos de sus procesos actuales,
herramientas, competencias de la gente, actitudes de la gente, clientes,
competidores, tendencias técnicas, problemas y áreas de movimiento. Motivar
porqué la organización objetivo debe ser mejorada y; para identificar a los
stakeholders el esfuerzo del modelamiento del negocio.
• Preparar y ajustar los Objetivos. Delimitar el esfuerzo del modelamiento.
Desarrollar una visión de la futura organización objetivo. Ganar acuerdos en los
objetivos del esfuerzo del modelamiento del negocio y; para definir expectativas
realistas de los stakeholders.

- 12 -
• Identificar las Metas del Negocio. Identificar los objetivos con los cuales el negocio
puede ser planeado y manejado. Alinear entre los objetivos a largo plazo y los
objetivos a corto plazo. Trasladar la estrategia del negocio a la acción y; para
proveer de una base para medir y mejorar las actividades del negocio.
El principal artefacto producido es la Visión del Negocio.
Describir el Negocio Actual
El propósito de este Workflow de detalle es entender los procesos y estructura de la
organización para describir la organización objetivo brevemente y priorizar las partes de
la organización objetivo en que se enfocarán por el resto del proyecto.
• Evaluar la Organización Objetivo. Describir el estado actual de la organización la
cual la aplicación va a ser desplegada en términos de sus procesos actuales,
herramientas, competencias de la gente, actitudes de la gente, clientes,
competidores, tendencias técnicas, problemas y áreas de movimiento. Motivar
porqué la organización objetivo debe ser mejorada y; para identificar a los
stakeholders el esfuerzo del modelamiento del negocio.
• Identificar los Objetivos del Negocio. Identificar los objetivos con los cuales el
negocio puede ser planeado y manejado. Alinear entre los objetivos a largo plazo y
los objetivos a corto plazo. Trasladar la estrategia del negocio a la acción y; para
• Encontrar Actores y Casos de Uso del Negocio. Definir las fronteras el negocio a ser
modelado. Definir quién y qué va a interactuar con el negocio. Bosquejar los
procesos en el negocio. Crear diagramas del Modelo de Caso de Uso del Negocio.
Desarrollar un panorama del Modelo de Caso de Uso del Negocio.
• Encontrar Trabajadores y Entidades del Negocio. Identificar los roles, entregables y
eventos en el negocio. Describir cómo las realizaciones de Casos de Uso del
Negocio son efectuadas por los trabajadores y las entidades del negocio.
El principal artefacto producido es una Visión del Negocio refinada.
Identificar los Procesos del Negocio
Dentro del equipo, los miembros deberían llegar a un entendimiento común de las

- 13 -
fronteras del negocio que están modelando. También, necesitan decidir cuáles procesos
dentro de esas fronteras serán descritos en más detalle.
El propósito de este Workflow de detalle es decidir la terminología, delinear el Modelo
de Caso de Uso del Negocio y priorizar cuáles Casos de Uso del Negocio serán
descritos en detalle.
• Identificar los Objetivos del Negocio. Identificar los objetivos con los cuales el
negocio puede ser planeado y manejado. Alinear entre los objetivos a largo plazo y
los objetivos a corto plazo. Trasladar la estrategia del negocio a la acción y; para
• Encontrar Actores y Casos de Uso del Negocio. Definir las fronteras el negocio a ser
modelado. Definir quién y qué va a interactuar con el negocio. Bosquejar los
procesos en el negocio. Crear diagramas del Modelo de Caso de Uso del Negocio.
Desarrollar un panorama del Modelo de Caso de Uso del Negocio.
Los principales artefactos producidos son el Glosario del Negocio y los Casos de Uso
del Negocio del alto nivel.
Refinar las Definiciones de los Procesos del Negocio
Cada Caso de Uso del Negocio será asignado a un miembro del equipo. Esa persona
completará la definición del Caso de Uso del Negocio y liderará una sesión de revisión
para el Caso de Uso del Negocio.
El propósito de este Workflow de detalle es describir los casos de uso del negocio en
detalle y verificar que el Caso de Uso del Negocio refleja correctamente cómo se hace
el negocio.
• Estructurar el Modelo de Caso de Uso del Negocio. Extraer el comportamiento en
los Casos de Uso del Negocio que necesitan ser considerados como Casos de Uso
del Negocio abstractos. Ejemplos de tales comportamientos con comportamientos
comunes, opcionales y comportamientos que van a ser desarrollados en iteraciones

- 14 -
posteriores. Encontrar nuevos actores del negocio que definen roles que son
compartidos por varios actores del negocio.
• Detallar el Caso de Uso del Negocio. Describir en detalle el workflow del Caso de
Uso del Negocio. Asegurar que el Caso de Uso del Negocio soporta la estrategia del
negocio. Asegurar que los clientes, usuarios y stakeholders puedan entender el
workflow del Caso de Uso del Negocio.
• Revisar el Modelo de Caso de Uso del Negocio. Verificar formalmente que los
resultados del modelamiento de Casos de Uso del Negocio estén conforme a los
puntos de vista de los stakeholders.
El principal artefacto producido son los Casos de Uso del Negocio detallados.
Diseñar las Realizaciones de los Procesos del Negocio
El propósito de este Workflow de detalle es identificar los roles, productos, entregables
y eventos en el negocio y describir cómo un Caso de Uso del Negocio en particular es
realizado dentro del Modelo de Objetos del Negocio en términos de objetos
colaboradores (instancias de trabajadores y entidades del negocio).
El principal artefacto producido es el Modelo de Objetos del Negocio.
Refinar los Roles y las Responsabilidades
El propósito de este Workflow de detalle es detallar la definición de una entidad del
negocio para detallar las responsabilidades de un trabajador del negocio y verificar
formalmente que los resultados del modelamiento del objetivo del negocio estén
conforme con la visión que tienen los stakeholders del negocio.
• Detallar a los Trabajadores del Negocio. Describir las responsabilidades de los
trabajadores del negocio. Identificar los requerimientos de competencia de un
trabajador del negocio para que el trabajador del negocio sea capaz de cumplir con
sus responsabilidades.
• Detallar las Entidades del Negocio. Asegurar que la entidad del negocio es capaz de

- 15 -
proveer del comportamiento requerido. Identificar los eventos del negocio
disparados por la entidad del negocio. Evaluar las relaciones estructurales entre las
entidades del negocio.
• Revisar el Modelo de Análisis del Negocio. Verificar formalmente que los
resultados del modelamiento de análisis del negocio estén conforme a los puntos de
vista del negocio de los stakeholders.
Los principales artefactos producidos son los Trabajadores del Negocio y las Entidades
del Negocio, en detalle.
Explorar la Automatización de Procesos
El propósito de este Workflow de detalle es explorar qué partes de los procesos del
negocio serán automatizados, entender cómo los sistemas existentes encajan en la
organización y derivar los requerimientos del sistema.
• Definir los requerimientos de Automatización. Comprender cómo las nuevas
tecnologías pueden ser usadas para hacer que la organización objetivo sea más
eficiente. Determinar el nivel de automatización en la organización objetivo. Derivar
los requerimientos del sistema desde los artefactos de modelamiento del negocio..
El principal artefacto producido es las Especificaciones Suplementarias del Negocio.
Desarrollar un Modelo de Dominio
Usted puede decidir elaborar un Modelo de Objetos del Negocio “incompleto”,
enfocándose en explicar productos, entregables o eventos que son importantes para el
dominio del negocio. Este modelo no incluye las responsabilidades que tiene la gente y
a menudo es referido como un modelo de dominio.
El propósito de este Workflow de detalle alternativo es identificar todos los productos,
entregables y eventos importantes para el dominio del negocio, describir la entidad
negocio en detalle y verificar formalmente que los resultados del modelamiento del
objetivo del negocio estén conforme con la visión que tienen los stakeholders del
negocio.

- 16 -
• Detallar las Entidades del Negocio. Asegurar que la entidad del negocio es capaz de
proveer del comportamiento requerido. Identificar los eventos del negocio
disparados por la entidad del negocio. Evaluar las relaciones estructurales entre las
entidades del negocio.
• Revisar el Modelo de Análisis del Negocio. Verificar formalmente que los
resultados del modelamiento de análisis del negocio estén conforme a los puntos de
vista del negocio de los stakeholders.
El principal artefacto producido es el Modelo de Dominio.
3.1.3 Configuración y Notas sobre el Workflow de Modelamiento de Negocios
RUP/Easy adoptó por el escenario renovar el negocio (reingeniería de procesos de
negocios). Renovar es un escenario de modelamiento de negocios. Es una de las
opciones listadas en la Sección 3.1.2. esta opción fue escogida porque RUP/Easy
típicamente asiste a las organizaciones con reingeniería en sus procesos de negocio para
que provean un mejor servicio a sus clientes.
La variación metodológica de RUP/Easy al Workflow de Modelamiento de Negocios no
incluye las actividades Desarrollar las Realizaciones de Diseño de los Procesos del
Negocio (Develop the Design Business Process Realizations), Refinar los Roles y las
Responsabilidades (Refine Roles y Responsibilities), Desarrollar un Artefacto de
Diseño de Dominio (Develop a Domain Model artefacto) y actividades y artefactos
relativos al Modelo de Objetos del Negocio. La variación metodológica de RUP/Easy
no incluye el desarrollo del Modelo de Objetivo durante el Workflow de
Requerimientos (ver la Sección 3.2).
3.1.4 Artefactos para el Modelamiento de Negocios
Los artefactos para el Modelamiento de Negocios sirven como input a, y referenciados
por, los requerimientos del sistema. La Tabla 5 identifica los artefactos que deberían ser
desarrollados cuando se hace modelamiento de negocios.
Tabla 5. Artefactos para el Modelamiento de Negocios
Artefactos Creado / Revisado Revisar Detalles Herramientas Usadas
Incep Elab Const Trans
Actor del Negocio X Formal - Interno Rational Rose
Glosario del Negocio X Formal - Externo Requisite Pro, MS Word
Reglas del Negocio X Formal - Externo Requisite Pro, MS Word
Caso de Uso del Negocio X Formal - Externo Requisite Pro, MS Word
Modelo de Casos de Uso
del Negocio X
Formal - Externo Rational Rose
Visión del Negocio X
Formal - Externo Requisite Pro, MS Word

- 17 -
Unidad de la
Organización
X
Rational Rose
Especificación
Suplementaria del
Negocio
X
Formal -Externo Requisite Pro, MS Word
Valorización de la
Organización Objetivo
X
Formal -Externo Requisite Pro, MS Word
3.1.5 Notas sobre los Artefactos para el Modelamiento de Negocios
La variación metodológica de RUP/Easy no incluye la creación de estos Artefactos para
el Modelamiento de Negocios: Documento de Arquitectura del Negocio (Business
Architecture Document), Entidad del Negocio (Business Entity), Modelo de Objetos del
Negocio (Business Object Model), Realización del Caso de Uso del Negocio (Business
Use-Case Realization) y Trabajador del Negocio (Business Worker). El artefacto
Unidad de la Organización (Organization Unit) no necesita incluir a las Entidades del
Negocio y a los Trabajadores del Negocio.
3.1.6 Reportes para el Modelamiento de Negocios
La Tabla 6 identifica los reportes que la metodología de RUP/Easy recomienda que sean
elaborados durante el Modelamiento de Negocios.
Tabla 6. Reportes para el Workflow de Modelamiento de Negocios
Reportes Herramientas Usadas
Panorama del Modelo de Casos de
Uso del Negocio
Rational SoDA, MS Word
3.1.7 Notas sobre los Reportes para el Modelamiento de Negocios
La variación metodológica de RUP/Easy no incluye la creación de estos Reportes para
el Modelamiento de Negocios: Entidad del Negocio (Business Entity), Caso de Uso del
Negocio (Business Use-Case), Realización del Caso de Uso del Negocio (Business Use-
Case Model Realization) y Trabajador del Negocio (Bussines Worker). En RUP/Easy
creemos que el Panorama del Modelo de Caso de Uso del Negocio (Business Use-Case
Model Survey) cubre todo acerca del esfuerzo para el Modelamiento de Negocios.
3.1.8 Sumario
El Modelamiento del Negocio debería hacerse antes del desarrollo de software para
obtener un buen entendimiento de sus procesos del negocio. Si los arquitectos y los
desarrolladores no entienden los procesos del negocio, ellos no podrán construir el
sistema apropiado. El Modelamiento de Negocios con UML permite a los analistas
modelar los procesos del negocio usando los mismos símbolos, diagramas y otras
formas de notación que los equipos de desarrollo de software utilizan para modelar los
sistemas para crear o automatizar los procesos del negocio. La habilidad de trabajar
usando un lenguaje común permite algo que antes no era posible en el desarrollo de
software: comunicación entre la gente del negocio y la gente de sistemas.

- 18 -
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/Easy no recomienda que usted
empiece con un modelamiento del negocio. En ese caso, RUP/Easy 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)
• 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 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á Requerimientos de
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 Configuración y Cambios provee los

- 19 -
mecanismos de control de cambios para los requerimientos.
Los workflows de Requerimientos consisten de los siguientes workflows de detalle:
• Analizar el Problema
• Entender las Necesidades del Stakeholder
• Definir el Sistema
• Administrar el Alcance del Sistema
• Refinar la Definición del Sistema
• Administrar los Requerimientos de Cambios
Workflow de Requerimientos
Analizar el Problema
• Obtener control y acuerdos sobre el problema que se va a resolver
• Identificar a los stakeholders, quienes son las personas que pueden ser afectadas
materialmente por la implementación de un sistema o aplicación y, a los usuarios
• Definir las fronteras del sistema, las cuales son los bordes entre la solución del
problema y el mundo real que rodea a la solución.
• Identificar las restricciones impuestas al sistema tales como horarios y recursos,
decisiones técnicas, restricciones económicas, etc.
El primer paso es asegurarse que todas las partes involucradas acuerdan en el problema

- 20 -
que están tratando de resolver con el nuevo sistema. Para evitar malos entendidos, un
glosario es creado para proveer de una terminología común, el cual será utilizado
durante todo el proyecto. Este glosario será mantenido durante todo el ciclo de vida del
proyecto. Para entender completamente los problemas que están siendo considerados, es
importante que conozca a sus stakeholders. Los Actores en sus Casos de Uso
representarán a algunos de los stakeholders – los usuarios del sistema.
• Capturar un vocabulario común. Definir un vocabulario común que pueda ser usado
en todas las descripciones textuales del sistema, especialmente en las descripciones
de los Casos de Uso.
• Desarrollar el Plan de Administración de Requerimientos. Desarrollar un plan para
documentar los requerimientos, sus atributos y guías para rastreabilidad y
administración de los requerimientos el producto.
• Encontrar Actores y Casos de Uso. Definir el alcance del sistema, es decir, qué será
manejado por el sistema y qué será manejado fuera del sistema. Definir quién y qué
va a interactuar con el sistema. Bosquejar la funcionalidad del sistema.
• Asignar los Casos de Uso a los Analistas para que describan en detalle los más
importantes. Los menos importantes serán revisados en las fases posteriores. No
olvidar que los Casos de Uso menos importantes, no necesariamente deben ser
descritos en detalle pues, podría bastar con la descripción inicial.
• Desarrollar la Visión. Obtener un acuerdo sobre qué problemas necesitan ser
resueltos. Identificar a los stakeholders del sistema. Definir las fronteras del sistema.
Describir las características primarias del sistema.
La Visión debe dejar en claro a los stakeholders lo siguiente:
− Los beneficios y las oportunidades que obtendrán desarrollando el sistema.
− El (Los) problema(s) que resolverá el sistema.
− Se define a los usuarios objetivo?.
− A muy alto nivel, se define lo que hará el sistema expresado en términos muy
generales o explicando unos pocos casos de uso importantes.
− Algunos de los requerimientos no funcionales que sean esenciales, tales como
Sistemas Operativos, Manejador de Base de datos, requerimientos de seguridad,
escalabilidad y calidad.
− Licenciamiento y precios, si es aplicable.
La Visión debe estar completa y estable al finalizar la Fase de Incepción; sin
embargo, se puede afinar durante la Fase de Elaboración.
Este documento debe ser enviado a todos los stakeholder y usuarios principales, de
tal manera que ninguno pueda decir que no lo conocía o no sabía nada.
El documento Visión es el principal artefacto en el cual el análisis del problema es
documentado.
Entender las Necesidades del Stakeholder
El propósito de este Workflow de detalle es coleccionar y obtener la información de los
stakeholders para entender cuáles son sus necesidades.
La actividad clave es obtener los requerimientos de los stakeholder usando input tales

- 21 -
como reglas del negocio, requerimientos de mejora, entrevistas y workshops de
requerimientos.
• Obtener los Requerimientos de los Stakeholders. Comprender quienes son los
stakeholders del proyecto. Recolectar los requerimientos de qué necesidades el
sistema debe cubrir. Priorizar los requerimientos de los stakeholders.
• Asignar los Casos de Uso a los Analistas para que describan en detalle los más
• Manejar las Dependencias. Usar atributos y rastreabilidad de los requerimientos del
proyecto para asistir en la administración del alcance del proyecto y administración
de cambios en los requerimientos.
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
• Alinear al equipo del proyecto en su comprensión del nuevo sistema.

- 22 -
• Efectuar un análisis de alto nivel a los resultados de los requerimientos recolectados
a los stakeholder.
• Refinar el documento Visión para incluir todas las características el nuevo sistema.
• Refinar el Modelo de Caso de Uso y incluir los casos de uso bosquejados.
• Documentar formalmente los resultados en modelo s y documentos.
Asignar los Casos de Uso a los Analistas para que describan en detalle los más
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
• Priorizar y refinar la selección de características y requerimientos que van a ser
incluidos en la iteración actual.

- 23 -
• Definir el conjunto de Casos de Uso (o Escenarios) que representan la funcionalidad
central.
• Definir cuáles atributos de requerimientos y características de rastreo serán
mantenidos.
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.
• Priorizar los Casos de Uso. Definir el input a la selección o al conjunto de
escenarios y Casos de Uso que van a ser analizados en la iteración actual. Definir el
conjunto de escenarios y casos de Uso que representan alguna funcionalidad central
y significativa. Definir el conjunto de escenarios y Casos de Uso que tienen una
cobertura arquitectural sustancial (que ejercitan muchos elementos arquitecturales) o
que realzan o ilustran un punto específico, delicado de la arquitectura.
Refinar la Definición del Sistema
• Refinar aún más los requerimientos para describir el flujo de eventos de los Casos
de Uso en detalle, detallar las Especificaciones Suplementarias, desarrollar una
Especificación de requerimientos de Software, si se necesita más detalle
• Modelar y prototipear la interfase con el usuario.

- 24 -
• Detallar los Casos de uso. Describir uno o más de los flujos de eventos de los casos
de uso en suficiente detalle para permitir que empiece el desarrollo de software en
él. Describir la especificación de Caso de Uso para el entendimiento y satisfacción
del actor representativo o cliente.
• Detallar los Requerimientos de Software. Coleccionar, detallar y organizar el
conjunto (paquete) de artefactos que describen completamente los requerimientos de
software del sistema o subsistema.
Refinar la Definición del Sistema comienza con detallar los Casos de Uso, describiendo
los Actores y profundizar el entendimiento del alcance del proyecto. 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
• Evaluar los requerimientos de cambio enviados para determinar su impacto en los
requerimientos existentes
• Construir el Modelo de Casos de Uso
• Desarrollar la relación entre los atributos y la rastreabilidad de los requerimientos.
• Verificar que los resultados del Workflow de Requerimientos estén conforme con la
visión del sistema que tiene el usuario.
• Estructurar el Modelo de Caso de Uso. Extraer el comportamiento en los Casos de
Uso que necesitan ser considerados como Casos de Uso abstractos. Ejemplos de
tales comportamientos con comportamientos comunes, opcionales y
comportamientos que van a ser desarrollados en iteraciones posteriores. Encontrar
nuevos actores que definen roles que son compartidos por varios actores.
El Modelo de Caso de Uso es un modelo de las funciones del sistema y su
ambiente; sirve como un contrato entre el cliente y los desarrolladores. El Modelo
de Caso de Uso es usado como un input esencial para las actividades de análisis,
diseño y pruebas.
• Revisar los requerimientos. Verificar formalmente que los resultados de los
requerimientos estén conforme con el punto de vista que los clientes tienen del
sistema.
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

- 25 -
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
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
X X
Formal-Externo Rational Rose; Requisite
Pro; MS Word
Modelo de Caso de Uso X X Formal-Externo Rational Rose
Vision Formal-Externo Requisite Pro; MS Word
3.2.4 Notas sobre los Artefactos de Requerimientos
La Lista de Riesgos es un artefacto independiente; pero en un proyecto pequeño se
puede incluir en el Plan de Desarrollo de Software con todo el detalle correspondiente:
. Magnitud del Riesgo o Ranking
. Descripción
. Impactos
. Indicadores
. Estrategia de Mitigación
. Plan de Contingencia
La Lista de Riesgos se va actualizando a los largo del proyecto según los riesgos se
vayan eliminando o, aparezcan nuevos riesgos. Tomar en cuenta lo siguiente:
• Actualizarla al término de una iteración.
• Mayormente un requerimiento de cambio implica un riesgo el cual deberá incluirse
en la Lista de Riesgos.
• Conforme avanza el proyecto se van eliminando los riesgos, es necesario actualizar la
lista para indicarlo.

- 26 -
• Los beneficios y las oportunidades que obtendrán desarrollando el sistema.
• El (Los) problema(s) que resolverá el sistema.
• Se define a los usuarios objetivo?.
• A muy alto nivel, se define lo que hará el sistema expresado en términos muy
generales o explicando unos pocos casos de uso importantes. Es decir, una Lista de
Requerimientos del software.
• Algunos de los requerimientos no funcionales que sean esenciales, tales como
escalabilidad y calidad. Esto es, equivalente a los artefactos Infraestructura de
Desarrollo (Development Infraestructura) y Herramientas (Tools).
• Licenciamiento y precios, si es aplicable.
La Visión contiene los requerimientos generales; pero los requerimientos detallados del
software se encuentran definidos en el Documento de Arquitectura del Software. La
Visión debe estar completa y estable al finalizar esta Fase de Inicio; sin embargo, se
puede afinar durante la Fase de Elaboración. Este documento debe ser enviado a todos
los stakeholder y usuarios principales, de tal manera que ninguno pueda decir que no lo
conocía o no sabía nada.
La variación metodológica de RUP/Easy no incluye la creación de estos Artefactos de
Requerimientos: Clase Frontera (Boundary Class), Storyboard de Casos de Uso (Use-
Case Storyboard) y Prototipo de la Interfase con el Usuario (User-Interfase Prototype).
Tampoco incluye: Atributos de Requerimientos (Requeriment Attributes), Plan de
Administración de Requerimientos (Requeriment Management Plan), Requerimientos
del Stakeholder (Stakeholder Requeriments), Paquete de Caso de Uso (Use-Case
Package), Especificación de Requerimientos de Software (Software Requeriments
Specification). Este último no es necesario debido a que los requerimientos globales se
definen en la Visión y los requerimientos del software se definen en el Documento de
Arquitectura del Software.
3.2.5 Reportes de Requerimientos
La variación metodológica de RUP/Easy 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.
Tabla 8. Reportes para el Workflow de Requerimientos
Panorama del Modelo de Caso de Uso Rational SoDA; MS Word
3.2.6 Notas sobre los Reportes de Requerimientos

- 27 -
La variación metodológica de RUP/Easy no incluye la creación del reporte Storyboard
de Casos de Uso.
Tampoco incluye Los reportes de Actores y Casos de Uso.
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 y el documento de Arquitectura del Software
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 y el documento de
Arquitectura del Software 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 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 siguientes workflows de detalle:
• Definir una Arquitectura candidata
• Refinar la Arquitectura
• Analizar el Comportamiento
• Diseñar los Componentes
• Diseñar la Base de Datos (opcional) - es efectuado durante cualquier iteración que
requiere la demostración de datos persistentes

- 28 -
Workflow de Análisis y Diseño
Definir una Arquitectura candidata
Este workflow es efectuado durante las iteraciones de las fases de Incepción y al inicio
de la Elaboración. El propósito de este Workflow de detalle es:
• Definir las fronteras arquitecturales a ser usada durante el análisis
• Definir los mecanismos de análisis que serán importantes para el sistema (por
ejemplo, persistencia, distribución, seguridad)
• Definir cualquier Patrón de Arquitectura a ser usado. Esto proveerá de una
arquitectura organizacional desde la cual los subsistemas, sus responsabilidades y
sus relaciones con otros subsistemas pueden ser definidos.
• Análisis Arquitectural. Definir una arquitectura candidata para el sistema basada en
la experiencia ganada de sistemas similares o dominios de problemas similares.
Definir los patrones arquitecturales, mecanismos clave y convenciones de

- 29 -
modelamiento para el sistema.
• Análisis de Casos de Uso. Identificar las clases que efectúan el flujo de eventos de
un Caso de Uso. Distribuir el comportamiento del Caso de Uso a esas clases, usando
realizaciones de Caso de Uso. Identificar las responsabilidades, atributos y
asociaciones de las clases. Notar el uso de los mecanismos arquitecturales.
Refinar la Arquitectura
Este workflow es efectuado durante las iteraciones del final de la fase de Elaboración y
la fase de Construcción. El propósito de este Workflow de detalle es:
• Identificar e incorporar elementos de diseño
− Identificar clases de diseño y subsistemas.
− Definir mecanismos de diseño e inventariar los mecanismos de implementación.
− Refinar la arquitectura incorporando la reusabilidad siempre que sea posible.
− Identificar interfases, clases de diseño y subsistemas de diseño.
− Actualizar la arquitectura basado en los hallazgos en el modelo de diseño.
• Describir la arquitectura de run-time y su distribución
− Identificar y diseñar los procesos (ambiente de ejecución en el cual las clases y
subsistemas residen y corren) y threads (ejecuciones computacionales
independientes dentro del ambiente de ejecución).
− Modelar procesos para el Plan de implementación de la configuración de la red
por medio de identificar qué parte o partes del sistema serán ejecutados en nodos
específicos o procesadores de cómputo.
− Modelar la configuración de la red para describir la comunicación y el flujo de
procesos entre los nodos. Identificar todos los recursos disponibles para correr el
sistema.
− Definir y modelar cómo, los procesos, pueden ser distribuidos en la
configuración de la red para alcanzar los requerimientos tales como performance
del sistema y disponibilidad.
• Identificar los Mecanismos de Diseño. Refinar los mecanismos de análisis en
mecanismos de diseño basados en las restricciones impuestas por el ambiente de
implementación.
• Identificar los Elementos de Diseño. Analizar las interacciones de las clases de
análisis para identificar los elementos del modelo de diseño.
• Incorporar los Elementos de Diseño existentes. Analizar las interacciones de las
clases de análisis para encontrar interfases, clases de diseño y subsistemas de diseño.
Refinar la arquitectura, incorporar el reuso donde sea posible. Identificar soluciones
comunes encontradas durante los problemas. Incluir arquitecturalmente elementos
significativos del modelo de diseño en la sección Vista Lógica del Documentos de
Arquitectura de Software.
• Estructurar el Modelo de Implementación (desde la Implementación). Establecer la
estructura en la cual la implementación residirá. Asignar responsabilidades para la

- 30 -
implementación de los Subsistemas y sus contenidos.
• Describir la Arquitectura de Run-Time. Analizar requerimientos de concurrencia,
identificar procesos, identificar mecanismos de comunicación entre procesos, separa
recursos de coordinación entre procesos, identificar ciclos de vida de procesos y
distribuir elementos del modelo entre los procesos.
• Describir la Distribución. Describir cómo la funcionalidad des sistema es distribuida
entre los nodos físicos. Esta actividad se aplica sólo a los sistemas distribuidos.
Analizar el Comportamiento
Este workflow es efectuado durante las iteraciones en las fases de Incepción,
Elaboración y Construcción. El propósito de este Workflow de detalle es:
• Identificar las Clases de Análisis desde los Diagramas de Caso de Uso y las
especificaciones de Caso de Uso.
• Crear Diagramas de Interacción que modelen el comportamiento de los Casos de
Uso.
• Crear el Diagrama de Clases
• Describir las relaciones y dependencias entre las Clases.
• Análisis de Casos de Uso. Identificar las clases que efectúan el flujo de eventos de
un Caso de Uso. Distribuir el comportamiento del Caso de Uso a esas clases, usando
realizaciones de Caso de Uso. Identificar las responsabilidades, atributos y
asociaciones de las clases. Notar el uso de los mecanismos arquitecturales.
• Identificar los Elementos de Diseño. Analizar las interacciones de las clases de
análisis para identificar los elementos del modelo de diseño.
• Revisar el Diseño. Verificar que el modelo de diseño cumple con los requerimientos
del sistema y que sirve como una buena base para su implementación. Asegurar que
el modelo de diseño es consistente con respecto a las guías de diseño general.
Asegurar que las guías de diseño cumplen sus objetivos.
• Diseñar la Interfase con el Usuario. Producir un diseño de la interfase con el usuario
que soporte el razonamiento y las mejoras de su usabilidad.
• Prototipear la Interfase con el Usuario. Prototipear la interfase con el usuario en un
intento de validar el diseño de la interfase con el usuario contra los requerimientos
funcionales y de uso.
Diseñar los Componentes
Este workflow es efectuado durante las iteraciones en las fases de Incepción,
Elaboración y Construcción. Durante las iteraciones iniciales este workflow se enfocará
más en los comportamientos significativos de la arquitectura. En las iteraciones de la
fase de Construcción, el enfoque se mueve hacia completar y diseñar la consistencia de
todos los comportamientos. El propósito de este Workflow de detalle es:
• Refinar los Diagramas de Diseño usando subsistemas
• Describir el comportamiento relativo a la persistencia
• Unificar clases y subsistemas para posible reuso
• Definir y distribuir el comportamiento y las dependencia de los subsistemas

- 31 -
• Implementar los elementos de diseño como componentes
• Diseñar las Cápsulas. Elaborar y refinar las descripciones de una cápsula.
• Diseñar los Casos de Uso. Refinar las Realizaciones de Casos de Uso en términos de
interacciones. Refinar los requerimientos para las operaciones de las clases de
diseño. Refinar los requerimientos para las operaciones de diseño de subsistemas y/o
sus interfases. Refinar los requerimientos para las operaciones de las cápsulas.
• Diseñar las Clases. Asegurar que las clases proveen el comportamiento que
requieren las realizaciones de Casos de Uso. Asegurar que se tiene la suficiente
información para implementar la clase sin ambigüedad. Manejar los requerimientos
no funcionales relativos a la clase. Incorporar los mecanismos de diseño usados por
la clase.
• Diseñar los Elementos de Pruebas. Diseñar la funcionalidad específica para las
pruebas.
• Diseñar los Subsistemas. Definir los comportamientos especificados en las
interfases del subsistema en términos de colaboraciones de elementos de diseño
contenidos y subsistemas o interfases externas. Documentar la estructura interna del
subsistema. Definir las realizaciones entre las interfases de los subsistemas y las
clases contenidas.
• Definir los Elementos de Pruebas. Definir los elementos necesarios para soportar los
ítems de prueba objetivo. Identificar los elementos físicos de la infraestructura de
implementación de las pruebas requeridos para posibilitar las pruebas bajo cada
Configuración de Ambiente de Pruebas. Definir los requerimientos de software que
serán necesarios para lograr que el software sea físicamente probado.
Diseñar la base de Datos (Opcional)
Este workflow del RUP es efectuado durante cualquier iteración que requiere la
demostración de datos persistentes. El propósito de este Workflow de detalle es:
• Crear el modelo de datos
• Mapear las clases de diseño que contienen datos que van a ser persistentes,
almacenados por más tiempo que la ejecución actual del sistema, con el modelo de
datos
• Distribuir el comportamiento de clase a la base de datos
• Diseñar las Clases. Asegurar que las clases proveen el comportamiento que
requieren las realizaciones de Casos de Uso. Asegurar que se tiene la suficiente
información para implementar la clase sin ambigüedad. Manejar los requerimientos
no funcionales relativos a la clase. Incorporar los mecanismos de diseño usados por
la clase.

- 32 -
• Diseñar la Base de Datos. Asegurar que los datos persistentes estén almacenados
consistentemente y eficientemente. Definir el comportamiento que debe ser
implementado en la base de datos.
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
Clase de Análisis X X Informal - Interno Rational Rose
Modelo de Análisis y
Diseño
X X X Formal - Externo Rational Rose
Modelo de Despliegue X X Formal - Externo RequistePro; MS Word
Modelo de Datos X X Informal - Interno Rational Rose
Clase de Diseño X X Informal - Interno Rational Rose
Paquete de Diseño X X Informal - Interno Rational Rose
Subsistema de Diseño X X Informal - Interno Rational Rose
Documento de
Arquitectura del Software
X X X Formal - Externo RequistePro; MS Word
Realización de Caso de
Uso
X X Informal - Interno RequistePro; MS Word;
Rational Rose

- 33 -
3.3.4 Notas sobre los Artefactos para Análisis y Diseño
El Modelo de Análisis y Diseño puede ser mantenido como dos modelos separados,
donde el modelo de análisis muestra sólo nombres de clases de análisis y, el modelo de
diseño muestra clases de análisis detalladas y clases de diseño arquitectural. Mantener
los modelos por separado se convierte en una tarea más retadora conforme avanza el
desarrollo del sistema. Usar un solo modelo y “evolucionarlo” durante las iteraciones es
una práctica aceptable para reducir la tarea de mantener dos modelos separados.
El Modelo de Diseño comprende los siguientes artefactos:
• Protocolo
• Cápsula
• Realización de Caso de Uso
• Signal
• Evento
• Subsistema de Diseño
• Paquete de Diseño
• Interfase
• Clase de Diseño. Entre las clases se considera también, las Interfases con otros
componentes o subsistemas.
• Clase de Pruebas
• Diseño de Prueba
Los artefactos de diseño Cápsula (Capsule), Evento (Event), Interfase (Interfase),
Protocolo (Protocol) y Señal (Signal) ayudan en un mayor detalle de los
comportamientos específicos del sistema tales como una ocurrencia particular a la cual
el sistema debe responder o un comportamiento particular que debe realizar una clase.
Estos ítems pueden ser mostrados en los diagramas de clases y el modelo de diseño. A
menos que haya una buena razón para detallarlos separadamente, estos pueden ser
saltados en la variación metodológica de RUP/Easy.
El Documento de Arquitectura del Software hace mucho uso de los diagramas de UML.
Comprende los siguientes artefactos:
• Introducción
• Representación Arquitectural
• Metas Arquitecturales y Restricciones. Aquí considerar los requerimientos
detallados del software.
• Vista de Caso de Uso
• Vista Lógica
• Vista de Proceso
• Vista de Despliegue
• Vista de Implementación
• Tamaño y Performance
• Calidad
Una Arquitectura de Referencia (Reference Architecture) es un patrón predefinido o

- 34 -
conjunto de patrones previamente desarrollados y disponible para reusar. El propósito
de una Arquitectura de Referencia es servir como un punto de partida para desarrollar el
sistema propuesto. Una Arquitectura de Referencia puede incluir modelos de diseño
usados en proyectos exitosos previos. También puede incluir notas o obstáculos
resueltos o evitados en proyectos previos. La Arquitectura de Referencia puede incluir
soluciones útiles que pueden ser aplicadas ampliamente al sistema propuesto o
simplemente que sea aplicable a un problema específico. Este es un artefacto opcional;
si no existe una arquitectura previa entonces se puede saltar.
3.3.5 Reportes para Análisis y Diseño
La variación metodológica de RUP/Easy considera opcionales todos los reportes de
Análisis y Diseño; 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
Clase Rational SoDA
Panorama del Modelo de Diseño Rational SoDA
Paquete de Diseño/Subsistema Rational SoDA
Realización de Caso de Uso Rational SoDA
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.
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.

- 35 -
• 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
• Planificar la Integración
• Implementar los Componentes
• Integrar cada Subsistema
• Integrar el Sistema
Workflow de Implementación
Estructurar el Modelo de Implementación
• Asegurar que el modelo de implementación está bien organizado para prevenir
problemas en la administración de la configuración
• Permitir que cada versión operacional el sistema sea construido según sea necesario

- 36 -
hasta que el producto final sea obtenido
• Estructurar el Modelo de Implementación. Establecer la estructura en la cual la
implementación va a residir. Asignar responsabilidades para los Subsistemas de
Implementación y sus contenidos.
El artefacto principal producido es el Modelo de Implementación.
Planificar la Integración
• Planificar cuáles subsistemas van a ser implementados
• Definir el orden en el que los subsistemas serán integrados en la iteración actual
• Planificar la Integración del Sistema. Definir el conjunto de la Construcción y
evaluar el Plan de Integración de Construcciones.
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.
Implementar los Componentes
• Desarrollar el código fuente
• Adaptar los componentes existentes para que trabajen con los nuevos componentes
creados
• Compilar, linkeditar y efectuar las pruebas unitarias
• Evaluar el código fuente contra las guías de programación identificadas en el
proyecto
• Identificar los defectos en el diseño y retroalimentar el trabajo en el diseño
• Corregir los defectos del código identificados durante el diseño
• Efectuar las pruebas unitarias en ítems retrabajados para:
− Verificar que los cambios fueron implementados correctamente
− Asegurarse que los cambios no causan que otros ítems tengan defectos
La Implementación debería estar unida muy de cerca al Diseño.
• Implementar los Elementos de Diseño. Producir una implementación por parte del
diseño (tal como una Clase de Diseño, Subsistema de Diseño o Realización de Caso
de Uso) o corregir uno o más defectos. El resultado es el código fuente o
actualizaciones al código fuente en la forma de Elementos de Implementación.

- 37 -
• Analizar el Comportamiento en Run-time. Comprender el comportamiento de un
componente durante su ejecución. Identificar comportamientos anómalos y
cualquier acción correctiva requerida.
• Implementar los Elementos de Pruebas. Implementar la funcionalidad especializada
para soportar los requerimientos específicos de pruebas.
• Implementar las Pruebas del Desarrollador. Implementar una o más pruebas que
permitan la validación de los componentes individuales a través de su ejecución
física. Desarrollar las pruebas que puedan ser ejecutadas junto con otras pruebas
como parte de una infraestructura de pruebas más grande.
• Ejecutar las Pruebas del Desarrollador. Verificar la especificación de una unidad.
Verificar la estructura interna de una unidad.
• Revisar el Código. Verificar la implementación.
• Planificar la Integración de los Subsistemas. Planificar el orden en el cual los
elementos contenidos en un subsistema de implementación deberán ser integrados.
El artefacto principal producido es el Componente.
Integrar cada Subsistema
El propósito de este Workflow de detalle es integrar los componentes nuevos y
modificados en la nueva versión del subsistema de implementación. La integración
consiste de Construcciones múltiples. Cada Construcción pasa por las Pruebas de
Integración. Luego de las pruebas, el subsistema de implementación está listo para la
integración del subsistema (ver detalles abajo).
• Implementar las Pruebas del Desarrollador. Implementar una o más pruebas que
permitan la validación de los componentes individuales a través de su ejecución
física. Desarrollar las pruebas que puedan ser ejecutadas junto con otras pruebas
como parte de una infraestructura de pruebas más grande.
• Ejecutar las Pruebas del Desarrollador. Verificar la especificación de una unidad.
Verificar la estructura interna de una unidad.
• Integrar los Subsistemas. Integrar los elementos en un subsistema de
implementación, luego enviarlo para su integración en el sistema.
Los principales artefactos producidos son la Construcción y el Subsistema de
Implementación.
Integrar el Sistema
• Integrar el sistema, de acuerdo al Plan de Integración de Construcciones, añadiendo
los subsistemas de implementación.
• Crear Construcciones del nuevo sistema
• Efectuar las pruebas de integración del nuevo 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).

- 38 -
• Integrar el Sistema. Integrar los subsistemas de implementación por pedazos en una
construcción (build).
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 para una implementación
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
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 Notas sobre los Artefactos para la Implementación
Cuando la Construcción es un prototipo inicial debe contener la interfase con el usuario;
esto permite visualizar el flujo de eventos asegurando que los usuarios y otros
stakeholders entiendan y aprueben el flujo de eventos. Este prototipo funcional
permitirá identificar algunos componentes clave en la arquitectura incluyendo aquellos
que deberán ser comprados.
No incluye: Componente (Component), Modelo de Implementación (Implementation
Model), Subsistema de Implementación (Implementation Subsystem), Plan de
Integración de Construcciones (Build Integration Plan).
3.4.5 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

- 39 -
• 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
• Validando que los requerimientos hayan sido implementados apropiadamente
3.5.1 Vista General del Workflow de Pruebas
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.
Estrategia de Pruebas
La Estrategia de Pruebas presenta el enfoque recomendado para las Pruebas de la
Aplicación, es decir, describe el cómo será probado los requerimientos funcionales y no
funcionales del sistema.
Las consideraciones principales para la estrategia de pruebas son la técnicas a usarse y
los criterios para saber cuándo las pruebas están completas.
Además de las consideraciones que describimos a continuación, provistas para cada
tipo de prueba, las pruebas sólo deben efectuarse usando Bases de Datos conocidas y
controladas en ambientes seguros.
La siguiente estrategia de pruebas es por cada tipo de prueba existente y se va a aplicar
a los requerimientos del sistema.
Pruebas de Integridad de Datos y Base de Datos
La Base de Datos y los procesos de Base de Datos deberán ser probados como sistemas
separados. Estos sistemas deberán ser probados sin las aplicaciones (como la interfase a
los datos). Se deberá hacer una investigación adicional en el DBMS para identificar las
herramientas y técnicas que puedan existir para soportar las pruebas identificadas a
continuación:
Objetivo de la Asegurar que los métodos de acceso y los procedimientos de Base

- 40 -
Prueba: de Datos funcionan apropiadamente y sin corrupción de datos.
Técnica: • Invocar a cada método de acceso y procedimiento de Base de
Datos con datos válidos e inválidos (o que pidan los datos).
• Inspeccionar la Base de Datos para asegurarse que los datos han
sido cargados como se deseaba, que todos los eventos de Base
de Datos ocurrieron apropiadamente o revisar los datos de
retorno para asegurarse que se ha leído los datos correctos (por
las razones correctas)
Criterios de
Finalización:
• Todos los métodos de acceso y procedimientos de Base de
Datos funcionan tal como fueron diseñados y que no hay
corrupción de datos.
Consideraciones
Especiales:
• Las pruebas pueden requerir un ambiente de desarrollo del
DBMS o drivers para ingresar o modificar datos directamente
en la Base de Datos.
• Los procesos deberán ser invocados manualmente.
• Deberá usarse Bases de Datos pequeñas (con un número de
limitado de registros) para mejorar la visibilidad de cualquier
evento que no sea aceptable.
Pruebas de la Aplicación
Las pruebas a la aplicación deben enfocarse en cualquier requerimiento objetivo que
pueda ser rastreado directamente a los casos de uso (o funciones del negocio) y reglas
del negocio. Las metas de estas pruebas son verificar la aceptación, procesamiento y
lectura apropiada de los datos y la implementación apropiada de las reglas del negocio.
Este tipo de pruebas se basan en pruebas de “caja negra”, es decir, verificando la
aplicación (y sus procesamientos internos) por medio de interactuar con la aplicación
vía el GUI y analizando el output (resultados). A continuación identificamos un
bosquejo de las pruebas recomendadas para cada aplicación:
Objetivo de la
Prueba:
Asegurar la navegación de la aplicación, entrada de datos,
procesamiento y lectura apropiados.
Técnica: • Ejecutar cada Caso de Uso, flujo de Caso de Uso o función
usando datos válidos e inválidos para verificar lo siguiente:
o Los resultados esperados ocurren cuando se usa datos
válidos.
o El error o mensaje de advertencia apropiado es mostrado
cuando se usa datos inválidos.
o Cada regla del negocio está aplicada apropiadamente.
Criterios de
Finalización:
• Todas las pruebas planeadas han sido ejecutadas.

- 41 -
• Todos los defectos identificados han sido corregidos.
Consideraciones
Especiales:
• Para ejecutar estas pruebas podría ser necesario el acceso a las
instalaciones de los stakeholders.
Pruebas del Ciclo del Negocio
Las Pruebas del Ciclo del Negocio deben emular las actividades en el sistema en algún
momento. Se debe identificar un período de tiempo, tal como un mes y se deben
ejecutar las transacciones y actividades que ocurrirían durante ese mes. Esto incluye
todo los ciclos y eventos diarios, semanales y mensuales que son sensitivos a las fechas.
Objectivo de la
Prueba:
Asegurar que los procesos de la aplicación y de background
funcionan de acuerdo a los plazos y modelos del negocio
requeridos.
Técnica: • Las pruebas simularán varios ciclos del negocio por medio de
efectuar lo siguiente:
o Las pruebas usadas para probar las funciones de la
aplicación deberán ser modificadas / mejoradas para
incrementar el número de veces que cada función es
ejecutada para simular varios usuarios diferentes durante un
período específico de tiempo.
o Todas las funciones sensitivas a fechas y horas serán
ejecutadas usando períodos de fechas y horas válidos e
inválidos.
o Todas las funciones que ocurren en un horario periódico
serán ejecutadas / lanzadas en el momento apropiado.
• Las pruebas se efectuarán usando daos válidos e inválidos para
verificar lo siguiente:
o Los resultados esperados ocurren cuando se usa datos
válidos
o El error o mensaje de advertencia apropiado es mostrado
cuando se usa datos inválidos .
Criterios de
Finalización:
• Todas las pruebas planeadas han sido ejecutadas.
• Todos los defectos identificados han sido corregidos.
Consideraciones
Especiales:
• Eventos basados en fechas del sistema podrían requerir
actividades especiales de soporte.
Pruebas de Interfase con el Usuario
Las Pruebas de Interfase con el Usuario verifican una interacción del usuario con el
software. La meta de las Prueba de la UI es asegurar que la interfase con el usuario

RUP/Easy guía metodológica

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a RUP/Easy guía metodológica

Similar a RUP/Easy guía metodológica (20)

Último

Último (20)

RUP/Easy guía metodológica