rupeasy guia v2

- 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. Comprende las siguientes actividades: • 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.

• 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.



• 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 proveer de una base para medir y mejorar las actividades del negocio.

• 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. Comprende las siguientes actividades: • 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. • 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.



• 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 proveer de una base para medir y mejorar las actividades del negocio.

• 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. Comprende las siguientes actividades:

• 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). Comprende las siguientes actividades: • 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 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. Comprende las siguientes actividades:

• 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. Comprende las siguientes actividades:


• 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. 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.


• Encontrar Trabajadores y Entidades del Negocio. Identificar los roles, entregables y

- 16 -

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.

• 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 El propósito de este Workflow de detalle es: • 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. Comprende las siguientes actividades: • 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. Comprende las siguientes actividades: • Capturar un vocabulario común. Definir un vocabulario común que pueda ser usado






• 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.

• 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.

• 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 El propósito de este Workflow de detalle es: • 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. Comprende las siguientes actividades: • Capturar un vocabulario común. Definir un vocabulario común que pueda ser usado






• 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.


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 propósito de este Workflow de detalle es: • 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. Comprende las siguientes actividades: • 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 El propósito de este Workflow de detalle es: • 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 -

Comprende las siguientes actividades: • 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 El propósito de este Workflow de detalle es: • 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. Comprende las siguientes actividades: • 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

Artefactos Creado / Revisado 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 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 -

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. Es decir, una Lista de Requerimientos del software.

• Algunos de los requerimientos no funcionales que sean esenciales, tales como Sistemas Operativos, Manejador de Base de datos, requerimientos de seguridad, 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

Reportes Herramientas Usadas

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.

Comprende las siguientes actividades: • 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.

Comprende las siguientes actividades: • 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. Comprende las siguientes actividades: • 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 Comprende las siguientes actividades: • 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 Comprende las siguientes actividades: • 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

Artefactos Creado / Revisado Revisar Detalles Herramientas Usadas Incep Elab Const Trans

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

Reportes Herramientas Usadas 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 El propósito de este Workflow de detalle es: • 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 Comprende las siguientes actividades: • 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 El propósito de este Workflow de detalle es: • Planificar cuáles subsistemas van a ser implementados • Definir el orden en el que los subsistemas serán integrados en la iteración actual Comprende las siguientes actividades: • 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 El propósito de este Workflow de detalle es: • 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. Comprende las siguientes actividades: • 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). Comprende las siguientes actividades: • 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 El propósito de este Workflow de detalle es: • 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 -

Comprende las siguientes actividades: • 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 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 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.


• Todas las pruebas planeadas han sido ejecutadas.

- 41 -

• Todos los defectos identificados han sido corregidos.


• 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 .


• Todas las pruebas planeadas han sido ejecutadas. • Todos los defectos identificados han sido corregidos.


• 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

- 42 -

provee al usuario del acceso y navegación apropiados a través de las funciones de la aplicación. Además, las Pruebas de la UI asegura que los objetos dentro de la UI funcionan como se espera.


Verificar lo siguiente:

• La navegación a través de la aplicación refleja las funciones del negocio y los requerimientos apropiadamente, incluyendo ventana a ventana, campo a campo y el uso de los métodos de accceso (teclas Tab, movimientos del mouse, teclas aceleradoras).

• Los objetos de ventana y sus características, tales como menús, tamaño, posición, estado y foco están de acuerdo a los estándares.

Técnica: • Crear / modificar las pruebas para cada ventana para verificar la navegación apropiada y los estados de los objetos para cada ventana y objeto de la aplicación.


• Cada ventana verificada exitosamente para permanecer consistente con la versión benchmark o dentro del estándar aceptable.


Pruebas de Performance Las Pruebas de Performance miden los tiempos de respuesta, ratios de las transacciones y otros requerimientos sensitivos al tiempo. La meta de las Pruebas de Performance es verificar y validad que los requerimientos de performance se hayan alcanzado. Las Pruebas de Performance, usualmente, son ejecutadas varias veces, cada una usando una “carga background” diferente en el sistema. La prueba inicial debe hacerse con una carga nominal, similar a la carga normal experimentada (o anticipada) en el sistema objetivo. Una segunda prueba de performance se ejecuta usando una carga pico. Adicionalmente, las Pruebas de Performance pueden ser usadas para afinar la performance de un sistema en función a ciertas condiciones como carga de trabajo o configuraciones de hardware. Nota: Las Transacciones mencionadas seguidamente se refieren a “transacciones del negocio lógicas”. Estas transacciones son definidas como funciones específicas que un usuario final del sistema espera ejecutar usando la aplicación, tal como añadir o actualizar un registro.


Validar el Tiempo de Respuesta del Sistema para transacciones o funciones del negocio designadas bajo las siguientes condiciones:

- 43 -

• Volumen normal anticipado • Volumen en el peor de los casos

Técnica: • Usar los Procedimientos de Prueba desarrollados para las Pruebas de la Aplicación.

• Modificar los archivos de datos (para aumentar el número de transacciones) o modificar scripts para aumentar el número de veces que cada transacción ocurra.

• Los scripts deben ejecutarse en una máquina (el mejor de los casos para evaluar un solo usuario, una sola transacción) y serán repetidos con múltiples clientes (virtuales o reales).


• Una sola Transacción / Un solo usuario: Finalización exitosa de los scripts de prueba sin ninguna falla y dentro del lapso de tiempo esperado / requerido (por transacción)

• Múltiples transacciones / Múltiples Usuarios: Finalización exitosa de los scripts de pruebas sin ninguna falla y dentro de un lapso de tiempo aceptable.


• Pruebas de Performance comprensivas incluyen el tener una carga en el "background". Hay varios métodos a usar para incluir esto: o "Manejar las transacciones" directamente en el servidor,

usualmente en la forma de llamadas al SQL. o Crear carga del usuario virtuales para simular muchos

clientes (usualmente varios). o Usar múltiples clientes físicos, cada uno corriendo scripts de

prueba para poner una carga en el sistema. • Las Pruebas de Performance deben efectuarse en una máquina

dedicada o en un tiempo dedicado. Esto permite control total y mediciones exactas.

• Las Bases de Datos usadas para las Pruebas de Performance deben ser de tamaño real o escaladas equitativamente.

Pruebas de Carga

Las mediciones de Pruebas de Carga pone a prueba al Sistema con cargas de trabajo variables para evaluar la habilidad del Sistema para continuar funcionando apropiadamente bajo estas diferentes cargas de trabajo. La meta de las Pruebas de carga es determinar y asegurar que el sistema funcione apropiadamente más allá de la carga máxima esperada. Adicionalmente, las Pruebas de Carga evalúan las características de performance (tiempos de respuesta, ratios de transacción y otros asuntos sensitivos al tiempo). Nota: Las Transacciones mencionadas seguidamente se refieren a “transacciones del negocio lógicas”. Estas transacciones son definidas como funciones específicas que un

- 44 -

usuario final del sistema espera ejecutar usando la aplicación, tal como añadir o actualizar un registro.


Verificar el tiempo de respuesta del Sistema para transacciones o casos del negocio designados bajo condiciones variables de carga de trabajo.

Técnica: • Usar los Procedimientos de Prueba desarrollados para las Pruebas de la Aplicación.

• Modificar los archivos de datos (para aumentar el número de transacciones) o modificar scripts para aumentar el número de veces que cada transacción ocurra.


• Múltiples transacciones / Múltiples Usuarios: Finalización exitosa de los scripts de pruebas sin ninguna falla y dentro de un lapso de tiempo aceptable.


• Las Pruebas de Performance deben efectuarse en una máquina dedicada o en un tiempo dedicado. Esto permite control total y mediciones exactas.

• Las Bases de Datos usadas para las Pruebas de Performance deben ser de tamaño real o escaladas equitativamente.

Pruebas de Esfuerzo

Las Pruebas de Esfuerzo tratan de encontrar errores debido a bajos recursos o competencia por recursos. Poca memoria o espacio en disco pueden revelar defectos en el software que no aparecen en condiciones normales. Otros defectos pueden aparecer como resultado de la competencia por los recursos compartidos como locks de Base de Datos o ancho de banda de la red. Las Pruebas de Esfuerzo identifican las cargas pico que el sistema puede manejar. La meta de las Pruebas de Esfuerzo también podría definirse como identificar y documentar las condiciones bajo las cuales el Sistema FALLA en continuar funcionando apropiadamente. Nota: Las Transacciones mencionadas seguidamente se refieren a “transacciones del negocio lógicas”. Estas transacciones son definidas como funciones específicas que un usuario final del sistema espera ejecutar usando la aplicación, tal como añadir o actualizar un registro.


Verificar que el sistema y el software funcionan apropiadamente y sin errores bajo las siguientes condiciones de esfuerzo:

• Poca o nada de memoria disponible en el servidor (RAM y

- 45 -

DASD) • Número máximo (actual o físicamente posibles) de clientes

conectados (o simulados) • Múltiples usuarios ejecutando las mismas transacciones contra

los mismos datos / cuentas • El peor de los casos de volumen de transacciones (o mezcla de

transacciones (ver Pruebas de Performance)

Técnica: • Use las pruebas desarrolladas para las Pruebas de Performance. • Para probar recursos limitados, las pruebas deben ejecutarse en

una sola máquina, la RAM en el servidor debería ser reducida (o limitada).

• Para el resto de pruebas de esfuerzo podría usarse muchos clientes, ya sea ejecutando las mismas pruebas o pruebas complementarias para producir el peor de los casos de transacciones de volumen / mezcla.


• Todas las pruebas planeadas han sido ejecutadas y los límites del sistema son alcanzados / excedidos sin que falle el Sistema (o las condiciones en que ocurren las fallas del Sistema están fuera de las condiciones especificadas).


• Forzar la red podría requerir herramientas de red para cargar la red con mensajes / paquetes.

• La RAM usada por el sistema sería reducida temporalmente para restringir el espacio disponible para el crecimiento de la Base de Datos.

• Sincronización de los clientes simultáneos que accesan a los mismos registros / cuentas.

Pruebas de Volumen

Las Pruebas de Volumen someten al software a grandes volúmenes de datos para determinar si se alcanzan los límites que causen que el software falle. Las Pruebas de Volumen también identifican la carga máxima continua que el Sistema puede manejar por un período de tiempo dado. Por ejemplo, si el software está procesando un conjunto de registros de la Base de Datos para generar un reporte, una Prueba de Volumen usaría una gran Base de Datos de prueba y chequearía que el software se comportó normalmente y produjo el reporte correcto.


Verificar que la aplicación / sistema funcionan exitosamente bajo los siguientes escenarios de alto volumen:

• Número máximo de clientes (actuales o físicamente posibles) conectados (o simulados) todos ejecutando la misma función del

- 46 -

negocio y en el peor de los casos (performance) por un período extendido de tiempo.

• Se ha alcanzado el tamaño máximo de Base de Datos (real o escalada) y muchas transacciones de consultas / reportes son ejecutadas simultáneamente.

Técnica: • Usar las pruebas desarrolladas para las Pruebas de Performance. • Se usarán muchos clientes, ya sea ejecutando las mismas

pruebas o pruebas complementarias para producir el peor de los casos de transacciones de volumen / mezcla (ver Pruebas de Esfuerzo) por un período extendido de tiempo.

• Se ha creado una Base de Datos de tamaño máximo (actual, escalada o llenada con datos representativos) y muchos clientes usados para correr transacciones de consultas / reportes simultáneamente por períodos extendidos de tiempo.


• Todas las pruebas planeadas han sido ejecutadas y los límites del sistema son alcanzados / excedidos sin que falle el Sistema (o las condiciones en que ocurren las fallas del Sistema están fuera de las condiciones especificadas).


• Qué período de tiempo será considerado un tiempo aceptable para condicione de alto volumen (como se mencionó arriba)?

Pruebas de Seguridad y Control de Acceso

Las Pruebas de Seguridad y Control de Acceso se enfocan en dos áreas clave: • Seguridad de la Aplicación, incluyendo acceso a los datos • Seguridad del Sistema, incluyendo login local y remoto al sistema La seguridad de la aplicación asegura que, basado en la seguridad deseada, los usuarios sean restringidos a funciones específicas o estén limitados en los datos que están disponibles para ellos. Por ejemplo, los encargados en una tienda están permitidos de ingresar datos y crear nuevas facturas; pero sólo el Gerente Comercial puede generar reportes de Ventas. Si hay seguridad al nivel de datos, las pruebas aseguran que el tipo de usuario uno pueda ver los datos de una factura, sin embargo, sólo el usuario dos puede generar reportes. La seguridad del sistema asegura que sólo aquellos usuarios que tiene permiso para accesar al sistema puedan accesar a las aplicaciones y sólo a través de los controles apropiados.


Seguridad de Función / Datos: Verificar que el usuario sólo puede accesar a aquellas funciones / datos a las que su tipo de usuario se le ha otorgado permiso. Seguridad del Sistema: Verificar que sólo aquellos usuarios con

- 47 -

acceso al sistema y a las aplicaciones puedan accesarlas.

Técnica: • Seguridad de Función / Datos: Identificar y listar cada tipo de usuario y las funciones / datos a los que tiene permiso de acceso.

• Crear pruebas para cada tipo de usuario y verificar sus permisos creando transacciones específicas para cada tipo de usuario.

• Modificar el tipo de usuario y re-ejecutar las pruebas para los mismos usuario. En cada caso verificar que aquellas funciones / datos adicionales estén disponibles o negados apropiadamente.

• Acceso al Sistema.


• Para cada tipo de usuario conocido la función / datos apropiados están disponibles y todas las transacciones funcionan como se espera y corrieron previamente en las Pruebas de la Aplicación.


• El acceso al sistema debe ser revisado / discutido con el administrador de Base de Datos. Estas pruebas podrían no ser requeridas si es que son función del DBMS.

Pruebas de Caídas / Recuperación del Sistema

Las Pruebas de Caídas / Recuperación del Sistema aseguran que una aplicación o el sistema puedan caer y recuperarse exitosamente por una variedad de mal funcionamiento de hardware, software o red, sin pérdida indebida de datos o integridad de datos.

Las Pruebas de Caídas / Recuperación del Sistema aseguran que, para aquellos sistemas que deben mantenerse corriendo, cuando ocurra una condición de caída, los sistemas alternos o de backup se activen apropiadamente sin pérdida de datos o e transacciones. Las Pruebas de Recuperación es un proceso de pruebas antagónico en el cual la aplicación o el sistema son expuestos a condiciones extremas (o condiciones simuladas) tales como fallas de I/O (scanner de código de barras) o punteros / claves inválidas de Base de Datos. Los procesos de recuperación son invocados y la aplicación / sistema es monitoreado y / o inspeccionado para verificar que se ha efectuado la recuperación apropiada de la aplicación / sistema y los datos.


Verificar que los procesos de recuperación (manual o automática) restauraron la Base de Datos, aplicaciones y el sistema apropiadamente a un estado conocido. En las pruebas se deben incluir los siguientes tipos de condiciones:

• Interrupción de poder en el cliente • Interrupción de comunicación en la red

- 48 -

• Ciclos incompletos (interrupción de procesos de filtrado de datos, procesos de sincronía de datos interrumpidos)

• Punteros / claves inválidos de Base de Datos • Elementos de datos inválidos / corruptos en la Base de Datos

Técnica: Las pruebas creadas para las Pruebas de la Aplicación y las Pruebas del Ciclo del Negocio deben usarse para crear una serie de transacciones. Una vez que se ha alcanzado el punto de inicio de la prueba deseada, se debe efectuar (o simular) las siguientes acciones individualmente:

• Interrupción de poder del cliente: apague el PC • Interrupción de comunicación en la red: simular o iniciar

pérdida de comunicación con la red (desconecte físicamente los cables de comunicación o apague los routers del servidor).

Una vez que las condiciones (reales o simuladas) se han alcanzado, se debe ejecutar transacciones adicionales y, al alcanzar este segundo punto de prueba, se debe invocar los procedimientos de recuperación. Las pruebas para ciclos incompletos utilizan la misma técnica descrita líneas arriba excepto que los procesos mismos de Base de datos deben ser abortados o terminados prematuramente. Probar las siguientes condiciones requieren que se alcance un estado conocido en la Base de datos. Varios campos, punteros y claves de la Base de Datos deberán ser corrompidos manualmente (por medio de herramientas de Base de Datos). Transacciones adicionales deberán ser ejecutadas usando las pruebas de Pruebas de la Aplicación y Pruebas del Ciclo del Negocio y se ejecutarán ciclos completos.


• En todos los caso, la aplicación, la Base de Datos y el sistema deben regresar, al completarse el proceso de recuperación, a un estado deseable y conocido. Este estado incluye corrupción de datos limitado a los campos punteros y claves y reportes indicando los procesos o transacciones que no fueron completados debido a las interrupciones.


• Procedimientos para desconectar el cableado (para simular pérdida de poder o de comunicación) podrían no ser deseables o factibles. Se podría requerir métodos alternativos, tales como herramientas de diagnóstico.

• Se requiere recursos de los grupos de Sistemas, Base de Datos y Redes.

• Estas pruebas deben ejecutarse después de las horas de trabajo

- 49 -

en una o más máquinas aisladas.

Pruebas de Configuración

Las Pruebas de Configuración verifican la operación del software en diferentes configuraciones de hardware y software. En la mayoría de ambientes de negocios, las especificaciones particulares de hardware para las estaciones cliente o terminales, las conexiones de red y los servidores de Base de Datos varían. Las estaciones cliente o terminales pueden tener instalados software diferentes (aplicaciones, drivers, etc.) y en cualquier momento muchas combinaciones diferentes pueden estar activas y usando recursos diferentes.


Validar y verificar que la aplicación funciona apropiadamente en las estaciones cliente o terminales prescrito.

Técnica: • Usar los scripts de Pruebas de la Aplicación. • Abrir / cerrar varias aplicaciones PC, ya sea como parte de la

prueba o antes de empezar la prueba. • Ejecutar transacciones seleccionadas para simular actividades

del usuario dentro y fuera de varias aplicaciones PC. • Repetir el proceso arriba indicado minimizando la memoria

convencional disponible en el cliente..


• Por cada combinación de transacciones, que finalicen exitosamente sin fallas.


• Qué aplicaciones PC están disponibles y accesibles en el cliente?

• Qué aplicaciones son usadas típicamente? • Con qué datos están corriendo las aplicaciones (por ejemplo,

hojas electrónicas grandes abiertas en Excel, documentos e 100 páginas en Word).

• También debería documentarse todos los sistemas, servidores de red, Bases de Datos, etc. como parte de esta prueba.

Pruebas de Instalación

Las Pruebas de Instalación tienen dos propósitos. El primero es asegurar puede ser instalado en todas las configuraciones posibles, tales como una instalación nueva, una actualización y una instalación completa o instalación adecuada y, bajo condiciones normales y anormales. Las condiciones anormales incluyen espacio en disco insuficiente, falta de privilegios para crear directorios, etc. El segundo propósito es verificar que, una vez instalado, el software opera correctamente. Esto, usualmente, significa correr un número de pruebas que fueron desarrolladas para las Pruebas de Aplicación.

- 50 -


Verificar y validar que el software cliente se instala apropiadamente en cada cliente bajo las siguientes condiciones:

• Nueva instalación, una nueva máquina en la que nunca se ha instalado.

• Actualizar una máquina en la que, previamente, se ha instalado la misma versión.

• Actualizar una máquina en la que, previamente, se ha instalado una versión antigua.

Técnica: • Manualmente o desarrollar scripts para validar la condición de la máquina objetivo (nueva – nunca instalado, misma versión o versión antigua ya instalada).

• Lanzar / ejecutar la instalación. • Usando un subconjunto de scripts de prueba de las Pruebas de

Integración o Pruebas de la Aplicación, correr las transacciones.


• Las transacciones se ejecutaron exitosamente sin fallas.


• Qué transacciones serán consideradas para tener una prueba de confianza de que la aplicación ha sido instalada exitosamente y que no se ha perdido componentes del software?

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 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

- 51 -

• Diseñar las Pruebas • Implementar las Pruebas • Ejecutar las Pruebas en la etapa de Integración de Pruebas • Ejecutar las Pruebas en la etapa de Pruebas del Sistema • Evaluar las Pruebas

Workflow de Pruebas

Planificar las Pruebas El Workflow de detalle de Planificar las Pruebas es donde la prueba que va a ser implementada y ejecutada es identificada y descrita. Esto es generalmente cumplido cuando el Diseñador de Pruebas genera uno o más Planes de Pruebas que contienen los requerimientos para la prueba y las estrategias de prueba. El Workflow de detalle de Planificar las Pruebas es efectuado de tal manera que las pruebas de esfuerzo puedan ser manejadas y medidas. El propósito de este Workflow de detalle es: • Coleccionar y analizar la información de planificación de las pruebas • Crear el Plan de Pruebas • Hacer pruebas de esfuerzo manejables y medibles

- 52 -

Comprende las siguientes actividades: • Identificar a los Motivadores de las Pruebas. Identificar la lista específica de cosas,

incluyendo eventos y artefactos, que servirán para motivar las pruebas en esta iteración.

• Acordar la Misión. Negociar el uso más efectivo de los recursos de pruebas para cada iteración. Acordar un apropiado y alcanzable conjunto de objetivos y entregables para la iteración.

• Obtener Compromiso de Pruebas. Promover la creación de software que se pueda probar y que soporte las necesidades del esfuerzo de pruebas. Promover y soportar el uso de las técnicas y herramientas automatizadas apropiadas.

• Evaluar y Promover la Calidad. Identificar y abogar por la resolución de los defectos que tengan un impacto serio en detrimento de la calidad del software. Monitorear el progreso de los cambios y soportar la finalización de los cambios que mejoren la calidad del software al nivel requerido. Abogar por la resolución en tiempo de los defectos que impiden o dañan el esfuerzo de las pruebas.

• Evaluar y Mejorar el Esfuerzo de las Pruebas. Hacer una evaluación de la productividad, efectividad y finalización del esfuerzo de las pruebas. Hacer ajustes al esfuerzo de pruebas tanto tácticas como estratégicas y mejorar la efectividad.

• Identificar los Objetivos de las Pruebas. Identificar los elementos individuales del sistema, tanto hardware como software, que necesiten ser probados.

• Definir las Necesidades de Evaluación y Seguimiento. Definir la estrategia de evaluación para el esfuerzo de pruebas. Pata definir los requerimientos de seguimiento y protección.

• Identificar las Ideas de Pruebas. Identificar las ideas de pruebas que podrían ser exploradas para evaluar la calidad aceptable de los elementos objetivo de las pruebas. Identificar un número suficiente de ideas para validar adecuadamente los elementos objetivos de las pruebas contra los Motivadores de las Pruebas.

El principal artefacto producido es el Plan de Pruebas.

Diseñar las Pruebas El Workflow de detalle de Diseñar las Pruebas es donde el Modelo de Pruebas, los Procedimientos de Prueba, y los Casos de Prueba son identificados, descritos y generados por el Diseñador de Pruebas. El Workflow de detalle de Diseñar las Pruebas es efectuado para asegurar que la implementación de las pruebas y los esfuerzos de ejecución están bien organizados y son exitosos. El propósito de este Workflow de detalle es: • Identificar un conjunto de Casos de Prueba verificable para cada Construcción • Identificar el Procedimiento de Pruebas que muestra cómo los Casos de Prueba

serán realizados Comprende las siguientes actividades: • Definir el Enfoque de las Pruebas. Identificar cada técnica específica que será

- 53 -

empleada para posibilitar la prueba deseada. Bosquejar el trabajo de cada técnica incluyendo los tipos de pruebas que soporten. Definir una arquitectura candidata para el sistema automatizado de pruebas.

• Definir las Configuraciones del Ambiente de Pruebas. Definir los requerimientos para los ambientes de evaluación necesarios para el esfuerzo de pruebas.

• Identificar los Mecanismos de Pruebas. Identificar los mecanismos generales de la solución técnica necesaria para facilitar el enfoque de prueba. Bosquejar el alcance general y las características claves de esos mecanismos.

• Definir los Elementos de las Pruebas. Identificar los elementos necesarios para soportar los elementos objetivos de las pruebas. Identificar los elementos físicos de la infraestructura de la implementación de pruebas para permitir probar bajo cada Configuración de Ambiente de Prueba.

• Definir los Detalles de las Pruebas. Definir las condiciones individuales necesarias para realizar una idea de prueba en un contexto específico. Identificar puntos de observación potenciales y controlar los elementos de prueba relacionados. Proveer de recursos consumibles para soportar las pruebas. Desarrollar los Casos de Prueba para cada elemento objetivo de prueba.

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). Implementar las Pruebas El Workflow de detalle de Implementar las Pruebas es donde los Procedimientos de Prueba definidos en el Workflow de detalle de Diseñar las Pruebas son implementados. Aquí, el Diseñador de Pruebas usa el modelo de pruebas y posiblemente otros componentes, para generar los scripts de prueba y asegurar que las funciones de una prueba específica, las cuales no son necesariamente el objetivo de la prueba; pero interactuará con el objetivo de la prueba, estén implementándose y probándose. El propósito de este Workflow de detalle es: • Crear o generar scripts de pruebas reusables • Mantener rastreabilidad de los artefactos de las pruebas de implementación de

regreso a los Casos de Prueba y Casos de Uso asociados o a los requerimientos para la prueba

Comprende las siguientes actividades: • Implementar la Suite de Pruebas. Ensamblar colecciones de pruebas a ser ejecutadas

juntas para capturar los logs de pruebas de valor. Facilitar la apropiada amplitud y profundidad de las pruebas por medio de probar combinaciones interesantes de pruebas.

• Implementar la Prueba. Implementar uno o más artefactos de prueba que permita la validación del producto de software a través de la ejecución física. Desarrollar las pruebas que puedan ser ejecutadas en conjunto con otras pruebas como parte de una infraestructura de pruebas más grande.

- 54 -

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 Las Pruebas de Ejecución en el Workflow de detalle de Etapa de Integración de Pruebas es donde el testeador ejecuta las pruebas de integración varias veces hasta que se determina que el sistema completo, en términos de la iteración actual, ha sido integrado exitosamente. El propósito de este Workflow de detalle es asegurar que: • El ensamblado de la colaboración de los componentes del sistema se ha conseguido • Se ha probado apropiadamente la funcionalidad añadida después de la última

Construcción • Se ha efectuado las pruebas de regresión apropiadas a la funcionalidad que existía

en Construcciones previas

Comprende las siguientes actividades: • Ejecutar la Suite de Pruebas. Ejecutar las colecciones apropiadas de pruebas

requeridas para evaluar la calidad del producto. Capturar los resultados de las pruebas que faciliten la evaluación exitosa del producto.

• Analizar las fallas en las Pruebas. Investigar los detalles del Log de Pruebas y analizar las fallas que ocurrieron durante la implementación y ejecución. Corregir fallas que resulten de errores en el procedimiento de prueba. Registrar los hallazgos importantes apropiadamente.

• Definir los Detalles de las Pruebas. Definir las condiciones individuales necesarias para realizar una idea de prueba en un contexto específico. Identificar puntos de observación potenciales y controlar los elementos de prueba relacionados. Proveer de recursos consumibles para soportar las pruebas. Desarrollar los Casos de Prueba para cada elemento objetivo de prueba.

• Determinar los Resultados de las Pruebas. Hacer evaluaciones sumarias de la calidad percibida del producto. Identificar y capturar los Resultados de las pruebas detallados. Proponer las acciones correctivas apropiadas para resolver las fallas en la calidad.


El principal artefacto producido es el documento Resultado de Pruebas. Ejecutar las Pruebas en la etapa de Pruebas del Sistema Ejecutar las Pruebas en el Workflow de detalle de Etapa de Pruebas del Sistema es donde el probador ejecuta las pruebas del sistema varias veces hasta que se determina que el sistema completo, en términos de la iteración actual, funciona apropiadamente y

- 55 -

cumple con los criterios de fin exitoso de las pruebas El propósito de este Workflow de detalle es asegurar que: • El sistema completo funciona como se esperaba

• La funcionalidad añadida después de la última Construcción trabaja como se esperaba

• La funcionalidad que existía en Construcciones previas aún trabaja como se esperaba

Comprende las mismas actividades que el workflow de detalle anterior: “Ejecutar las Pruebas en la etapa de Integración de Pruebas”. El principal artefacto producido es el documento Resultado de Pruebas. Evaluar las Pruebas El Workflow de detalle de Evaluación de las Pruebas es donde el Diseñador de Pruebas revisará y valorizará la calidad de los objetivos de prueba deseados y el proceso de pruebas como un todo. El Sumario de Evaluación de Pruebas es generado luego de que el Diseñador de Pruebas revisa y valoriza los resultados de las pruebas, identifica y registra los requerimientos de cambio y calcula las mediciones de prueba claves in términos de métricas de cobertura y calidad. En la mayoría de los casos, esto significa enfocarse en el esfuerzo de apoyar al equipo del proyecto a alcanzar los objetivos del Plan de iteración que se aplica al ciclo de pruebas actual. El propósito de este Workflow de detalle es: • Evaluar los resultados de las pruebas y registrar los Requerimiento de Cambios • Calcular y enviar las mediciones clave de las pruebas • Generar el Sumario de Evaluación de Pruebas Comprende las siguientes actividades: • Evaluar y Mejorar el Esfuerzo de las Pruebas. Hacer una evaluación de la

productividad, efectividad y finalización del esfuerzo de las pruebas. Hacer ajustes al esfuerzo de pruebas tanto tácticas como estratégicas y mejorar la efectividad.


• Identificar las Ideas de Pruebas. Identificar las ideas de pruebas que podrían ser exploradas para evaluar la calidad aceptable de los elementos objetivo de las pruebas. Identificar un número suficiente de ideas para validar adecuadamente los elementos objetivos de las pruebas contra los Motivadores de las Pruebas.

• Determinar los Resultados de las Pruebas. Hacer evaluaciones sumarias de la

- 56 -

calidad percibida del producto. Identificar y capturar los Resultados de las pruebas detallados. Proponer las acciones correctivas apropiadas para resolver las fallas en la calidad.

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


Caso de Prueba X X Informal - Interno Test Manager

Plan de Pruebas/ Procedimientos

X X Formal - Externo o Prueba Interna Manager

Resultados de las Pruebas

X X Formal - Interno Test Manager

Script de Pruebas X X X Informal - Interno Robot, Manual Test

3.5.4 Notas sobre los Artefactos para Pruebas La metodología de RUP/Easy siguiere que los siguientes artefactos no sean desarrollados: Modelo de Pruebas (Test Model), Paquete de Pruebas (Test Package), Subsistema de Pruebas (Test Subsystem) y Documento de Análisis de Carga de Trabajo (Workload Analysis Document). El Modelo de Pruebas es excluido porque es simplemente una acumulación de diferentes tipos de otros artefactos de pruebas. En su lugar el Modelo de Pruebas puede ser visto como los Casos de Prueba, los Procedimientos de Prueba, los Scripts de Prueba y el Plan de Pruebas. De manera similar, ya que el Paquete de Pruebas es esencialmente una adición al Modelo de Pruebas, no será producido. El Subsistema de Pruebas es un artefacto que sería útil como una herramienta organizacional en proyectos grandes. La distinción entre los Subsistemas de Pruebas no es una necesidad en proyectos de tamaño promedio. Igualmente, el Documento de Análisis de Carga de Trabajo sería útil para pruebas de performance antes del despliegue en proyectos grandes,; pero no es una necesidad en proyecto de tamaño promedio. Los artefactos Plan de Pruebas y Procedimiento de Pruebas han sido combinados para

- 57 -

adelgazar los artefactos producidos por el Workflow de Pruebas. La información cubierta por estos dos artefactos individualmente puede ser representada casi completamente en el Plan de Pruebas. Las instrucciones para preparación, ejecución y evaluación de las pruebas simplemente puede ser añadida al Plan de Pruebas para formar un agregado de ambos el Plan de Pruebas y el Procedimiento de Pruebas. Tampoco incluye: Clase de Prueba (Test Class), Prueba de Componentes (Component Class), Sumario de Evaluación de Pruebas (Test Evaluation Summary). El Script de las Pruebas es opcional debido a que no siempre se efectúan pruebas automatizadas. 3.5.5 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 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: • El Workflow de Requerimientos produce las Especificaciones de Requerimientos

de Software (Software Requirements Specification) las cuales son input clave para desarrollar el Material de Soporte el Usuario Final (End-User Support Materials) y el Material e Entrenamiento (Training Materials).

• Los artefactos Modelo de Pruebas y Resultado de Pruebas producidos durante el Workflow de Pruebas son esenciales para el Workflow de Despliegue.

• El Workflow de Administración de Configuración y Cambios es usado para

- 58 -

manejar los requerimientos de cambio que son generados como resultado de las pruebas Beta y las pruebas de aceptación

El Workflow de Despliegue consiste de los siguientes Workflows de detalle: • Planificar el Despliegue • Desarrollar Material de Soporte • Manejar las Pruebas de Aceptación • Producir la Unidad de Despliegue • Empaquetar el Producto • Poveer acceso al Site de Despliegue • Producto en Beta

Workflow de Despliegue

- 59 -

Planificar el Despliegue El propósito de este workflow del RUP es: • Planificar cómo y cuándo el producto estará disponible para el usuario final • Dirigir el desarrollo de software que se pueda enviar, desarrollo de material de

entrenamiento y material de soporte al sistema. Comprende las siguientes actividades: • Desarrollar el Plan de Despliegue. Los deseos del usuario final para usar el producto

es la marca de su éxito. El Plan de Despliegue documenta cómo y cuándo el producto va a estar disponible para la comunidad de usuarios.

• Definir la Lista de Materiales. Crear una lisa completa de artefactos que va a componer la construcción/producto. La lista incluye ítems de configuración del software, documentos y scripts de instalación. En el caso de productos empacados la Lista de Materiales necesitará identificar las partes de trabajo de arte e ítems de empaquetamiento que maquillarán al producto final.

Desarrollar Material de Soporte El propósito de este workflow del RUP es: • Producir los ítems necesarios para desplegar efectivamente el producto a los

usuarios finales. • Producir 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.

Comprende las siguientes actividades: • Desarrollar el Material de Entrenamiento. Producir el material necesario para

entrenar a los usuarios en el uso del producto como slides, workshops, tutores on- line, etc.

• Desarrollar el Material de Soporte. Desarrollar el material de soporte para el usuario final como ayudas y/o sitios web.

Manejar las Pruebas de Aceptación El propósito de este Workflow de detalle es asegurar que el producto haya sido probado adecuadamente antes de su liberación. Es identificado y confirmado que el producto cumple con los requerimientos. El producto es instalado en la plataforma de pruebas y se le efectúan las pruebas para generar resultados de las pruebas. Si los resultados de las pruebas muestran anomalías, se levantan requerimientos de cambio por su inmediata atención y resolución. Una vez que el producto ha sido probado en el ambiente de desarrollo y es exitoso, el producto es instalado en el site objetivo para empezar las pruebas Beta. Comprende las siguientes actividades:

- 60 -

• Soporte al Desarrollo. Dar soporte técnico al desarrollo con software y hardware. • Ejecutar la Suite de Pruebas. Ejecutar las colecciones de pruebas apropiadas

requeridas para evaluar la calidad del producto. Capturar los resultados de las pruebas que faciliten las evaluaciones que se le hacen al producto.

• Manejar las Pruebas de Aceptación. Asegurar que el producto desarrollado cumpla los criterios de aceptación tanto en el ambiente de desarrollo como en el ambiente de instalación final.

• Determinar los Resultados de las Pruebas. Hacer evaluaciones sumarias de la calidad percibida del producto. Identificar y capturar los Resultados de las pruebas detallados. Proponer las acciones correctivas apropiadas para resolver las fallas en la calidad.

Producir la Unidad de Despliegue El propósito de este Workflow de detalle es crear una unidad de despliegue que consiste el software junto con el material de soporte requerido para instalarlo y usarlo efectivamente. Comprende las siguientes actividades: • Escribir las Notas del Release. Describir la principales características nuevas y

cambios en el release. Las Notas del release también deben describir las fallas conocidas y limitaciones del producto.

• Desarrollar los Artefactos de Instalación. Producir todo el software requerido para instalar y desinstalar el producto rápidamente, fácilmente y seguramente sin afectar a otras aplicaciones o características del sistema.

• Crear la Unidad de Despliegue (desde la Administración de Configuración). Una Unidad de Despliegue consiste de una Construcción (una colección de componentes ejecutables), documentos (material de soporte para el usuario final y las Notas del Release) y los artefactos de instalación. El propósito de esta actividad es crear una Unidad de Despliegue que sea lo suficientemente completa para que sea descargable, instalable y ejecutada en un nodo como un grupo.

Empaquetar el Producto El propósito de este Workflow de detalle es describir las actividades necesarias para crear el “instalador” y poner la unidad de despliegue, los scripts de instalación y el manual del usuario en un paquete para distribución masiva. Comprende las siguientes actividades: • Liberar para Manufactura. Producir en masa una versión compresa del producto de

software. • Verificar el Producto Manufacturado. Asegurar que el producto manufacturado esté

completo y usable. Esta actividad, es a veces, referida como la “inspección del primer artículo”. Sirve como una actividad de control de calidad para asegurar que el producto a ofrecer tiene todos los atributos y artefactos requeridos.

• Crear el Arte para el Producto. El propósito de crear un trabajo de arte para el producto es publicarlo directamente en un medio magnético o en la web. El trabajo de arte deberá reforzar los estándares de marca del producto establecido por el grupo

- 61 -

de mercadeo de la compañía, para crear el mensaje apropiado para el consumidor. Proveer Acceso al Site de Descarga El propósito de este Workflow de detalle es poner el producto disponible para descargarlo desde la Internet al igual que poner el producto disponible para la compra y envío según la demanda. Comprende las siguientes actividades: • Dar acceso al Site de Descarga. Asegurar que el producto está disponible para la

compra y bajarlo desde Internet. Producto en Beta El propósito de este Workflow de detalle es crear una prueba Beta para solicitar retroalimentación al producto de parte de un grupo de usuarios finales y revisar esta retroalimentación e las pruebas Beta. Las pruebas Beta también son conocidas como Pruebas de Aceptación del Usuario (PAU). Las PAU se hacen cuando la audiencia prueba el software en el ambiente del “mundo real”. Comprende las siguientes actividades: • Manejar las Pruebas Beta. Las pruebas Beta son unas pruebas al pre-release en la

cual un ejemplo de audiencia intenta con el producto. Las Pruebas Beta sirven para dos propósitos. Primero le da al producto una prueba controlada en el mundo real y, segundo, da un preview del siguiente release. El jede de despliegue necesita manejar el programa de pruebas Beta del producto para asegurar que ambos propósitos se han alcanzado.

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 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


Relación de Materiales X X Informal MS Word

Plan de Despliegue X X X Informal MS Word

Producto X Formal-Externo MS Word

- 62 -

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 Notas sobre los Artefactos para el Despliegue No es necesario desarrollar el artefacto Arte del Producto (Arte del Producto). Este artefacto es usado para marcar el producto de tal manera que sea distinguible y atractivo para el cliente. Tampoco incluye: Unidad de Despliegue (Deployment Unit), Material de Soporte al Usuario Final (Final User Support Materials), Artefactos de Instalación (Installation Artifacts). 3.6.5 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 los 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 3.7.1 Por qué implementar Administración de Configuración y Cambios La Administración de Configuración y Cambios incluye las siguientes funciones principales:

- 63 -

• Administración de la Configuración (Configuration Management -CM-)

• Administración de Requerimientos de Cambio (Requerimiento de Cambio Management -CRM-)

Administración de la Configuración (Configuration Management -CM-)

La Administración de la Configuración (CM) controla los numerosos artefactos producidos por los miembros del equipo del proyecto. RUP/Easy recomienda traer bajo CM sólo aquellos artefactos que no pueden ser derivados fácilmente desde otros artefactos administrados y versionados; pero es más seguro errar en el lado controlado. Cuando un artefacto es puesto bajo Administración de la Configuración su versión actual, sus dependencias, las herramientas usadas para trabajarlo, quien lo creó, cuándo y porqué son todos registrados en su historia de cambios. Más tarde cuando el artefacto es cambiado, las dependencias del artefacto deben ser revisadas. CM maneja este proceso. CM es usado a través del ciclo de vida del proyecto después de la fase de Incepción. Usualmente, la última versión de un artefacto es la mejor para usar; pero no siempre. CM provee la habilidad de hacer uso de una copia de la versión específica de un artefacto que no es la última versión. CM también provee la habilidad de reconstruir el proyecto tal como existía en muchos puntos históricos en el tiempo. En teoría, CM puede ser hecho manualmente, sin una herramienta especializada; pero este enfoque no es practico. Herramientas automatizadas para soportar rangos de CM desde sistemas de control de versiones, tal como Visual Source Safe, a productos más escalables y avanzados tal como el Rational ClearCase, es cual está basado en actividades y capaz de automatizar varios aspectos de CM. Administración de Control de Cambios (Change Request Management -CRM-)

La Administración de Control de Cambios (CRM) es la captura y administración de los requerimientos de cambio y el impacto potencial e los cambios. "Un requerimiento de

cambio es una propuesta documentada de un cambio a uno o más artefactos. Los

requerimientos de cambio pueden ser hechos por una variedad de razones: para

corregir un defecto, para mejorar la calidad del producto (tales como usabilidad o

performance), para añadir un requerimiento o simplemente para documentar el delta

entre una iteración y la siguiente.". Un Requerimiento de Cambio es creado por un Originador, quien provee un motivo raíz o razón para el cambio tal como arreglar una falla, un requerimiento de mejora o posiblemente un hecho de una regla del negocio que necesita ser resuelto. Seguidamente, el requerimiento de cambio es evaluado por un equipo de revisión que puede incluir: • Un representante del usuario o experto en el tema que conoce la Visión del proyecto • Un representante del fundador quien es un familiar con restricciones de presupuesto

o financieras • Un representante técnico quien es versado en la tecnología usada

- 64 -

Este equipo combina los requerimientos duplicados, clarifica detalles según sea necesario y valoriza los impactos técnicos, funcionales y económicos de los requerimientos de cambio. El equipo es responsable de aprobar o rechazar cada Requerimiento de Cambio. Para los Requerimientos de Cambio que son aprobados, el equipo también es responsable de asignar las prioridades y seguir el estado de los Requerimientos de Cambio. Luego que el desarrollador hace los cambios requeridos y completa exitosamente las pruebas de integración, el desarrollador debe enviar los cambios al Equipo de Pruebas, el cual debe confirmar que los cambios fueron implementados sin causar efectos colaterales no deseados. Si ocurren problemas durante las pruebas, éstos son retornados al desarrollador para que los siga trabajando. RUP/Easy recomienda usar CRM en todas las fases 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.2 Vista general del Workflow de Administración de Configuración y Cambios A continuación se muestra una Convención para la Administración de Configuración. Definir las Prácticas de Identificación de la Configuración Tiene como propósito identificar y almacenar los artefactos en un repositorio seguro. La identificación de la Configuración es una pieza clave de la administración de la configuración y es definida como "un elemento de la administración de la administración de la configuración que consiste en seleccionar las características físicas en la documentación técnica ". En términos de administración de la configuración de software, identificación de la configuración significa ser capaz de encontrar e identificar la versión correcta del cualquier artefacto del proyecto rápida y fácilmente. El impacto negativo de tener un sistema de identificación de configuración inefectivo es medido en términos de tiempo perdido y calidad. Definir las Convenciones de Etiquetado de los Artefactos Las etiquetas (labels) identifican las versiones específicas de los artefactos. El conjunto de artefactos que constituyen una versión de un subsistema son, colectivamente e individualmente, identificables por una versión particular y una etiqueta. Las etiquetas son, por lo tanto, útiles en reusar o referenciar a los conjuntos originales de artefactos versionados.

- 65 -

La siguiente es una convención sugerida para etiquetar los artefactos que puede ser usada para etiquetar los paths y los artefactos de la Estructura de Directorio del Producto. <SISTEMA>[<A>]_[<SUBSISTEMA>]_[<A>]_[R|A|B]<X>[.<Y>.<Z>][.BL<#>] Donde:

SISTEMA Identifica al Sistema

SUBSISTEMA Identifica a cada Subsistema del Sistema

A Corresponde a un acrónimo de tres letras para los diversos artefactos usados en la creación del Sistema o Subsistema. De acuerdo con la Tabla de Valores de <A> más adelante.

R|A|B Corresponde a Release, Alpha o Beta

<X> Entero, corresponde al release principal (p. e. 1)

<Y> Entero (opcional), corresponde al release menor

<Z> Entero (opcional), corresponde a un release alternativo (patches, ports, etc.)

BL Corresponde al nivel base (un release interno)

# Entero, para releases internos

Tabla de Valores de <A>

PLN Planes del Proyecto

REQ Archivos de Requerimientos

CAU Casos de Uso

MOD Archivos del Modelo

SRC Archivos de Código Fuente

INT Interfases Públicas

TST Scripts de Prueba y Resultados

DOC Documentación (Usuario, Notas del Release)

BIN Ejecutables

Aquí hay algunos ejemplos:

T2K_R1.0 Release 1 del sistema Thorn 2000

T2K_GUI_R2.0.BL5 Release interno del sistema GUI planeado para

- 66 -

liberar en el Release 2

T2K_B1.1 Release Beta 1.1 del sistema Thorn 2000

T2K_R2.0.BL16 Baseline de sistema interno #16 del sistema Thorn 2000 planeado para crear el release 2

T2K_R1.0.5 Release de mantenimiento del sistema Thorn 2000

Definir las Prácticas de Congelamiento (Baselining) Un congelado (baseline) provee de un punto estable y una foto de los artefactos del proyecto . El Congelamiento describe cuando en el ciclo de vida del proyecto se necesita crear las versiones congeladas. Este paso provee una guía en la práctica. Los congelados identifican juegos fijos de versiones de archivos y directorios y que son creados en hitos dados del proyecto. Los congelados pueden ser creados para un subsistema o para el sistema completo. Los congelados deben ser identificados de acuerdo con el esquema bosquejado en el paso anterior (Definir las Convenciones de Etiquetado de los Artefactos). Una distinción que se deberá hacer al momento de crear un congelado o si va a crearlo:

• Un ‘Subsistema Congelado’ con TODAS las versiones de archivos y directorios que han sido modificados en el subsistema o subsistemas

o;

• Un ‘Sistema Congelado’ con UNA sola versión de todos los archivos y directorios en todos los subsistemas.

Como una guía general, se facilitará la administración del release si se crea Sistemas Congelados en los hitos mayores y menores y Subsistemas Congelados según sea requerido o con una frecuencia más alta. Como una “regla del pulgar” es una buena idea crear un congelado si se ha cambiado hasta un 30 % de un subsistema. Definir las Prácticas de Archivamiento El propósito de este paso es asegurar que el software del proyecto y sus activos relacionados (documentos maestros) sean protegidos, catalogados y transferidos a sitios de almacenamiento designados. Los archivos muestran su valor en los momentos de reuso o de desastre. Como tales, los archivos necesitan hacerse regularmente y en los hitos mayores y menores. Las guías de etiquetado descritas anteriormente bajo el paso ‘Definir las Convenciones de Etiquetado de los Artefactos’ pueden ser usadas cuando se crea las etiquetas de los archivos. Sin embargo, se puede requerir información adicional cuando el medio actual va a ser almacenado. Por ejemplo:

NÚMERO DE SERIE 123456789

VOLUMEN 1 de 3

- 67 -

BÓVEDA B5

FECHA DE ALMACENAMIENTO 21-Junio-99

Toda la información relativa al producto debería ser mantenida en una base de datos para facilitar la liberación y el reuso. Definir la Frecuencia de los Reportes Asegurarse que los reportes sean recibidos en la frecuencia correcta para proveer de input significativo para la toma de decisiones. Los reportes puede ser requeridos en las siguientes frecuencias:

• Diaria – es poco probable que los reportes sean requeridos en esta frecuencia • Semanal – Reportes de Tendencia, Distribución y Contadores y de Construcción • Mensual – Reportes de Tendencia, Distribución y Contadores y de Construcción • Por Iteración – Reportes de Tendencia, Distribución y Contadores y de Construcción

y Descriptores de Versiones • Por Fase – Reportes de Tendencia, Distribución y Contadores y de Construcción y

Descriptores de Versiones • Al finalizar el Proyecto – Reportes de Tendencia, Distribución y Contadores y de

Construcción y Descriptores de Versiones A continuación se muestra un Procedimiento de Control de Cambios basado en ClearQuest de Rational aplicable a proyectos grandes y, al final se muestra un formato para este fin si es que el proceso se efectúa de forma manual. Definiciones • Requerimiento de Cambio (RC) – Un artefacto enviado formalmente que se utiliza

para hacer seguimiento a todos los requerimientos de los stakeholders (incluyendo características nuevas, requerimientos de mejoras, defectos, cambios a los requerimientos, etc.) junto con información relativa al estado durante el ciclo de vida del proyecto. Todo el historial del cambio deberá ser mantenido con el Requerimiento de Cambio, incluyendo todos los estados del cambio junto con fechas y motivos para el cambio. Esta información estará disponible para cualquier revisión y para el cierre final.

• Tablero de Control de Cambios (o Configuración) (TCC) – El tablero que vigila el proceso de cambio consistente de representantes de todas las partes interesadas, incluyendo clientes, desarrolladores y usuarios. En un proyecto pequeño, un equipo de un solo miembro tal como el jefe del Proyecto o el Arquitecto de Software, puede jugar este rol. En el RUP, éste es conocido como el rol de Administrador de Control de Cambios.

• Reunión de Revisión del TCC – La función de esta reunión es revisar los Requerimientos de Cambio enviados. Una revisión inicial del contenido del Requerimiento de Cambio es efectuada en la reunión para determinar si es un requerimiento válido. Si lo es, entonces se determina si el cambio está dentro o fuera del alcance del(os) release(s) actual(es), basándose en la prioridad, cronograma,

- 68 -

recursos, nivel del esfuerzo, riesgo, severidad y cualquier otro criterio relevante según sea determinado por el grupo. Esta reunión se hace, típicamente, una vez por semana. Si el volumen de requerimientos de Cambio se incrementa sustancialmente o, según se vaya acercando el fin del ciclo del release, la reunión se puede hacer tan frecuentemente cono sea necesario, inclusive diariamente. Los miembros típicos de la Reunión de Revisión del TCC son el Jefe de Pruebas, el Jefe de Desarrollo (Analista de Sistemas o Arquitecto de Software) y un representante de los stakeholders. Participantes adicionales podrían ser considerados en base a las necesidades específicas de los temas a tratar.

• Formulario de Envío de Requerimientos de Cambio – Este formulario es mostrado cuando el Requerimiento de Cambio está siendo enviado por primera vez. Sólo los campos necesarios que el emisor debe llenar son mostrados en el formulario.

• Formulario de Requerimiento de Cambio Combinado – Este formulario es mostrado cuando usted está revisando un Requerimiento de Cambio que ya ha sido enviado. Contiene todos los campos necesarios para describir el Requerimiento de Cambio.

Actividades para la Administración de los Requerimientos de Cambio. En el siguiente cuadro se muestran las actividades que debe adoptar un proyecto para administrar los Requerimiento de Cambio (RC) durante su ciclo de vida.

Emisor Tablero de Control de Cambios Desarrollador Testeador 1. Enviar el RC:

nuevo. 2. Actualizar el

RC: actualizado con más información solicitada.

3. Revisar el RC: evalúa prioridad, cronograma, recursos, nivel de esfuerzo, riesgo, severidad. Si no es prioritario pone al RC en estado de Pospuesto.

4. Cronogramar y Asignar el Trabajo: Si es prioritario pone al RC en estado de Abierto y cronograma y asigna el trabajo a un Desarrollador.

5. Confirmar Duplicado o Rechazado: Si es un RC duplicado o ya ha sido rechazado, le pone el estado de Mas

Info y lo envía al Emisor por más información.

6. Aplicar los Cambios: aplica los cambios y le pone el estado de Resuelto al RC y lo envía a Pruebas.

7. Verificar los Cambios en la Construcción de Prueba: Prueba el cambio. Si falla le pone el estado de Falla en

Prueba y lo retorna al Desarrollador. Si pasa las pruebas le pone el estado de Verificado y lo retorna al Tablero de Control de Cambios

8. Verificar los Cambios en la Construcción de Release: verifica que los cambios hayan sido aplicados en la construcción y Cierra el RC.

En un proyecto pequeño, en vez de un Tablero de Control de Cambios, un equipo de un solo miembro tal como el jefe del Proyecto o el Arquitecto de Software, puede jugar este rol. En el RUP, éste es conocido como el rol de Administrador de Control de Cambios. Note que este procedimiento, requiere de tres (3) workspaces: • el workspace de desarrollo, para aplicar los cambios • el workspace de pruebas, en el ambiente de pruebas, para verificar los cambios en

- 69 -

la construcción de prueba y; • el workspace de integración para verificar los cambios en la construcción de release En un proyecto pequeño, se podría aplicar los cambios sólo en el de desarrollo y en del release. Descripción de las actividades del proceso de Administración de requerimientos de Cambio.

Actividad Descripción Responsabilidad Enviar el RC Cualquier stakeholder en el proyecto puede enviar un Requerimiento

de Cambio (RC). El Requerimiento de Cambio ingresado en el Sistema de Seguimiento de Requerimientos de Cambio (p. e. Rational ClearQuest) y es puesto en la cola de la Revisión del TCC poniendo el Requerimiento de Cambio en estado de Enviado.

Emisor

Revisar el RC La función de esta reunión es revisar los Requerimientos de Cambio enviados. Una revisión inicial del contenido del Requerimiento de Cambio es efectuada en la reunión para determinar si es un requerimiento válido. Si lo es, entonces se determina si el cambio está dentro o fuera del alcance del(os) release(s) actual(es), basándose en la prioridad, cronograma, recursos, nivel del esfuerzo, riesgo, severidad y cualquier otro criterio relevante según sea determinado por el grupo.

TCC

Confirmar Duplicado o Rechazado

Si se sospecha que un Requerimiento de Cambio está Duplicado o Rechazado como un requerimiento inválido ( p. e. error del operador, no reproducible, la manera en que trabaja, etc.) se asigna un delegado del TCC para confirmar el Requerimiento de Cambio duplicado o rechazado y para obtener más información del emisor , si fuera necesario.

Delegado del TCC

Actualizar el RC

Si se necesita más información (Mas Info) para evaluar un Requerimiento de Cambio o si un Requerimiento de Cambio está rechazado en cualquier punto del proceso (p. e. Confirmado como Duplicado, Rechazado, etc.) del emisor es notificado y puede actualizar el Requerimiento de Cambio con nueva información. El Requerimiento de Cambio es, entonces, reenviado a la cola de Revisión del TCC para consideración de los nuevos datos.

Emisor

Cronogramar y Asignar el Trabajo

Una vez que un Requerimiento de Cambio está Abierto, el Jefe del Proyecto asignará el trabajo al miembro del equipo apropiado (dependiendo del tipo de requerimientos – p. e. mejora, defecto, cambio en la documentación, defecto de prueba, etc.- podría ser un analista, un desarrollador, un testeador, un documentado técnico, etc.) y hace las actualizaciones necesarias en el cronograma del proyecto.

Jefe del Proyecto

Aplicar los Cambios

El miembro del equipo asignado efectúa las actividades apropiadas definidas dentro del workflow apropiado del proceso (p. e. requerimientos, análisis y diseño, implementación, pruebas, despliegue) para hacer los cambios requeridos. Estas actividades incluirán todas las revisiones normales y actividades de pruebas de la Unidad tal como se describe en el proceso de desarrollo normal. El Requerimiento de Cambio, entonces, es marcado como Resuelto.

Miembro del Equipo Asignado

Verificar los Cambios en la Construcción de Prueba

Luego que los cambios están Resueltos por el miembro del equipo asignado (analista, desarrollador, testeador, documentado técnico, etc.), los cambios son puestos en una cola de pruebas para que sean asignados a un testeador y Verificado en una construcción de prueba del producto.

Testeador

- 70 -

Verificar los Cambios en la Construcción de Release

Una vez que los cambios resueltos han sido Verificados en una construcción de prueba del producto, el Requerimiento de Cambio es puesto en una cola de releases para que sean verificados contra una construcción de release del producto, producir las notas del release, etc. y Cerrar el Requerimiento de Cambio.

Delegado del TCC

Estados y Transiciones para un Requerimiento de Cambio. Estado Definición Control de Acceso

Enviado Este estado ocurre como resultado de 1) envío de un nuevo Requerimiento de Cambio, 2) actualización den un Requerimiento de Cambio existente o; 3) consideración de un Requerimiento de Cambio Pospuesto para un nuevo ciclo del release. Los Requerimientos de Cambio son puestos en la cola de Revisión del TCC. No se asigna a un propietario como resultado de esta acción.

• Todos los Usuarios

Pospuesto El Requerimiento de Cambio es determinado como válido; pero fuera del alcance del(os) release(s) actual(es). El Requerimiento de Cambio en el estado de Pospuesto será manejado y reconsiderado para releases futuros. Un release objetivo puede ser asignado para indicar el momento en que el Requerimiento de Cambio puede ser Enviado para que reingrese a la cola de Revisión del TCC.

• Administrador • Jefe del Proyecto

Duplicado Un Requerimiento de Cambio es este estado se cree que es duplicado u otro Requerimiento de Cambio que ya ha sido enviado. Los Requerimientos de Cambio pueden ser puestos en este estado por el Administrados en la Revisión del TCC o por el miembro de equipo asignado para resolverlo. Cuando el Requerimiento de Cambio es puesto en estado de Duplicado el número del Requerimiento de Cambio que está duplicando será registrado (en el tab Attachments en ClearQuest). Un emisor inicialmente debería consultar la base de datos de Requerimientos de Cambio, para consultar por duplicados. Antes de enviarlo. Esto evitará pasos del proceso de revisión y por lo tanto ahorrará bastante tiempo. Los emisores de Requerimientos de Cambio duplicados deberían ser añadidos a la lista de notificación del Requerimiento de Cambio original para notificaciones futuras respecto de la resolución.

• Administrador • Jefe del Proyecto • Jefe de Aseguramiento de

la Calidad • Jefe de Desarrollo

Rechazado Un Requerimiento de Cambio en este estado es determinado por la Reunión de Revisión del TCC o por el miembro del equipo asignado como un requerimiento inválido o se necesita más información del emisor. Si ya está asignado (Abierto) el Requerimiento de Cambio es removido de la cola de resolución y será revisado de nuevo. Una autoridad designada por el TCC es asignada para que lo confirme. No se necesita ninguna acción de parte del emisor a menos que se estime necesario, en cuyo caso el estado del Requerimiento de Cambio es cambiado a Mas Info. El Requerimiento de Cambio será revisado de nuevo en la Reunión de Revisión del TCC considerando cualquier nueva información. Si se confirma inválido, el Requerimiento de Cambio será Cerrado por el TCC y el emisor será notificado.

• Administrador • Jefe del Proyecto • Jefe de Desarrollo • Jefe de Pruebas

Más Info Existe datos insuficientes para confirmar la validez de un Requerimiento de Cambio Rechazado o Duplicado. El propietario automáticamente es cambiado al emisor quien es notificado para proveer más datos.

• Administrador

- 71 -

Abierto Un Requerimiento de Cambio en este estado ha sido determinado como que está dentro del alcance del release actual y está esperando que sea resuelto. Ha sido puesto para resolución antes de que se llegue a un hito. Se define como que “está en cola de asignación”. Los miembros de la reunión son la única autoridad para abrir un Requerimiento de Cambio en la cola de resolución. Si un Requerimiento de Cambio de prioridad 2 o más es encontrado, el Jefe de Aseguramiento de la Calidad o el Jefe de Desarrollo le deben prestar inmediata atención. En este punto ellos pueden decidir convocar a una Reunión de Revisión del TCC de emergencia o simplemente abrir el Requerimiento de Cambio en la cola de resolución instáneamente.

• Administrador • Jefe del Proyecto • Jefe de Desarrollo • Jefe de Aseguramiento de

la Calidad

Asignado Un Requerimiento de Cambio Abierto debe ser asignado, por el Jefe del Proyecto, basándose en el tipo de Requerimiento de Cambio y actualizar el cronograma, si es apropiado.

• Jefe del Proyecto

Resuelto Significa que la resolución de este Requerimiento de Cambio está completa y ya está listo para verificación. Si el emisor fue un miembro del Departamento de Aseguramiento de la Calidad, el propietario automáticamente es cambiado al miembro de Aseguramiento de la Calidad emisor, si no, cambia al Jefe de Aseguramiento de la Calidad para resasignación manual.

• Administrador • Jefe del Proyecto • Jefe de Desarrollo • Jefe de Aseguramiento de

la Calidad • Departamento de

Desarrollo

Falló Prueba Un Requerimiento de Cambio que falla las pruebas ya sea en una construcción de prueba o una construcción de release es puesto en este estado. El propietario automáticamente es cambiado al miembro del equipo que resolvió el Requerimiento de Cambio.

• Administrador • Departamento de

Aseguramiento de la Calidad

Verificado Un Requerimiento de Cambio en este estado ha sido Verificado en una constricción reprueba y está listo para ser incluido en un release.

• Administrador • Departamento de

Aseguramiento de la Calidad

Cerrado El Requerimiento de Cambio ya no requiere atención. Este es el estado final que se le puede asignar a un Requerimiento de Cambio. Sólo el Administrador en la Revisión del TCC tiene la autoridad para cerrar un Requerimiento de Cambio. Cuando un Requerimiento de Cambio es Cerrado, el emisor recibirá una notificación por e-mail con la disposición final del Requerimiento de Cambio. Un Requerimiento de Cambio puede ser Cerrado: 1) después de que es Verificado en una construcción de release, 2) cuando el estado de Rechazado es confirmado o; 3) cuando es confirmado como un Duplicado de un Requerimiento de Cambio existente. En el último caso, el emisor será informado del Requerimiento de Cambio duplicado y será añadido a ese Requerimiento de Cambio para futuras notificaciones (ver las definiciones de los estados "Rechazado" y "Duplicado" para más detalles). Si el emisor quiere rebatir el cierre, el Requerimiento de Cambio debe ser actualizado y reenviado para Revisión del TCC.

• Administrador

Formato de la Solicitud de Cambios Aunque lo recomendable es utilizar una herramienta automatizada para el proceso de Control de Cambios, en caso de que esto no fuera posible y, el proceso se deberá efectuar de forma manual se puede utilizar un formato en MS Word como se muestra a

- 72 -

continuación. Este formato es llenado por el usuario y enviado por e-mail al TCC para que ingrese al procedimiento explicado. Se puede requerir los cambios a los siguientes componentes de un sistema de información: • Aplicación • Base de Datos • Software Base • Hardware • Manuales

SOLICITUD DE CAMBIOS FECHA PROPONENTE Nombre y cargo del proponente del cambio

DESCRIPCIÓN DEL CAMBIO PROPUESTO

VALORACIÓN Describirá brevemente a qué componentes podría afectar y cómo.

IMPACTO D, F o M. Con una explicación adicional si es necesario.

ESFUERZO Lo pone el equipo de desarrollo. Debido a que algunas características requieren más tiempo y recursos que

otra, estimar días hombre, líneas de código requeridas o funciones, por ejemplo, es la mejor manera de evitar

complejdad y definir las expectativas de lo que puede y no puede cumplirse en un período de tiempo. Se usa

para el alcance de la administración y para determinar la prioridad del desarrollo.

RIESGO Lo pone el equipo de desarrollo basándose en la probabilidad de que el proyecto experimente eventos

indeseables como sobrecostos, demoras de tiempo o cancelaciones. Categorize los riesgos como Altos, Medios

y Bajos pero; se puede considerar graduaciones más detalladas. El riesgo se puede determinar indirectamente

midiendo el rango de incertidumbre del esquedul estimado por el equipo del proyecto.

ESTABILIDAD Lo pone el analista y el equipo de desarrollo. Está basado en la probabilidad de que la carácter+istica

cambiará o de que el entendimiento del equipo, sobre esta característica, cambie. Se usa para ayudar a

establecer las prioridades y determinar los items para los que investigación adicional es el siguiente paso

apropiado.

APROBADO SI o NO APLICADO SI o NO

FECHA dd/mm/aaaa FECHA dd/mm/aaaa

FIRMAS PROPONENTE MIEMBRO COMITÉ MIEMBRO COMITE

- 73 -

Reportes basados en Requerimientos de Cambio

Aquí se puede seleccionar reportes que pueden ser derivados de los Requerimientos de Cambio enviados al proyecto. Hay un número útil de reportes basados en requerimientos de Cambio.

Bajo la categoría de antigüedad, los reportes pueden ser solicitados en términos de número de Requerimientos de Cambio en un período de tiempo o de una semana o meses basándose en los siguientes criterios:

• Enviados • Asignados • Resueltos • Prioridad

Listar los problemas por estado puede ayudar a determinar qué tan cerca de la finalización del proyecto se puede estar. Por ejemplo, si muchos de los problemas han sido resueltos entonces la terminación está más cerca que si estos problemas se encontrarán en el estado de Enviados.

Bajo la categoría de distribución, se puede requerir reportes para responder a las siguientes preguntas: • Quién está encontrando qué tipos de defectos y en qué parte del proyecto? • A quienes se está asignando los problemas? • Cuántos problemas están abiertos bajo un mismo desarrollador? • Qué tan severos son los problemas que se están encontrando? • En qué parte del proceso se están encontrando los problemas (causa raíz)? • Cuándo se están resolviendo los problemas? • Cuántos defectos hay? • Qué tan severos son estos problemas pendientes?

Estas métricas pueden ayudar en el análisis de la carga de trabajo, quién está trabajando en los problemas más críticos y qué tan rápido están siendo cerrados los problemas.

Bajo la categoría de tendencia, se puede requerir reportes que contesten los siguientes tipos de preguntas:

• Cuántos defectos están abiertos este día, semana o mes? • Cuántos defectos han sido cerrados este día, semana o mes?

Estos datos son útiles para evaluar los ratios de correcciones y puede proveer indicaciones de la eficiencia de la ingeniería.

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

- 74 -

El Workflow de Administración de Configuración y Cambios está relacionado a todos los 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 • Crear un Ambiente CM para el Proyecto • Cambiar y Enviar los Items de la Configuración • Manejar Versiones Congeladas (Baselines) y Liberaciones • Monitorear y Reportar el estado de la Configuración • Administrar los Requerimientos de Cambio

Workflow de Administración de Configuración y Cambios

Planificar la Configuración del Proyecto y el Control de Cambios El propósito de este Workflow de detalle es establecer las políticas de administración de configuración del proyecto, establecer políticas y procesos para controlar los cambios al

- 75 -

producto y documentar las políticas y procesos en el Plan de Administración de la Configuración (Plan CM). 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. Comprende las siguientes actividades: • Establecer las Políticas de Administración de Configuración (CM). Las políticas de

Administración de Configuración son usadas para monitorear y salvaguardar los activos del proyecto y reforzar las prácticas de desarrollo de software. Las políticas del proyecto deben mejorar la comunicación entre los miembros del equipo y minimizar los problemas encontrados cuando integran su trabajo.

• Escribir el Plan de Administración de Configuración (CM). Describir todas las actividades relativas a Administración de Configuración a efectuarse durante el curso del ciclo de vida del producto/proyecto. Documentar cómo las actividades de Administración de Configuración relativas al producto van a ser planeadas, implementadas, controladas y organizadas. El Plan de Administración de Configuración describe las actividades de Administración de Configuración y de Control de Cambios que se efectuarán durante el proyecto. Detalla el cronograma de actividades, las responsabilidades asignadas y los recursos requeridos, incluyendo el staff, las herramientas y las facilidades de hardware.

• Establecer el Proceso de Control de Cambios (CC). El propósito de tener procesos de Control de Cambios estandarizados y documentados es asegurarse que los cambios sean hechos dentro del proyecto de una manera consistente y que los stakeholders apropiados sean informados del estado del producto, sus cambios y el impacto al costo y al cronograma de estos cambios.

Crear un Ambiente CM para el Proyecto El propósito de este Workflow de detalle es crear una ambiente de trabajo donde todos los artefactos de desarrollo estén disponibles y dónde el producto puede ser desarrollado, implementado y archivado para subsecuentes mantenimiento y reuso. Los desarrolladores e integradores son provistos de espacios de trabajo privados y compartidos donde puedan construir e integrar el software. Comprende las siguientes actividades: • Preparar el ambiente de CM. Establecer un ambiente donde el producto pueda ser

desarrollado y construido. Esto se hace en dos partes, primero preparando el ambiente de hardware y luego estableciendo el ambiente de desarrollo. Preparar el ambiente de CM envuelve separa recursos de máquina (servidores y espacio en disco) e instalar las herramientas de administración de configuración; también se debe crear los repositorios, preparar la estructura de directorios e importar cualquier archivo existente. El ambiente inicial sirve como una base para el desarrollo del trabajo posterior.

• Crear los Workspaces de Integración. Similar a los workspaces de los implementadotes, en los que los individuos pueden desarrollar y cambiar el código, existe la noción de Workspace de Integración. Este espacio de trabajo es donde los

- 76 -

integradores unen los subsistemas y los sistemas y se convencen a sí mismos de que todos esos componentes trabajan correctamente como un todo.

Cambiar y Enviar los Items de la Configuración El propósito de este Workflow de detalle es proveer al trabajador con el espacio de trabajo necesario para accesar los artefactos del proyecto, hacer cambios a esos artefactos y enviar los cambios para que se incluyan en todo el producto. Comprende las siguientes actividades: • Crear los workspaces de Desarrollo. Un workspace de Desarrollo es un área de

trabajo privada en la cual un miembro del equipo puede hacer cambios a los artefactos sin que los cambios sean visibles inmediatamente a los otros miembros del equipo. Parte de los workspaces es una vista que está configurada para asegurar que cualquier miembro del equipo pueda “tomar” la versión requerida de cualquier artefacto dado que puedan necesitar para hacer su trabajo. Las políticas del proyecto determinan cuales artefactos son visibles o modificables y por quién.

• Hacer cambios. Esta es una actividad genérica para acomodar las necesidades de los miembros del equipo para acceder al conjunto de artefactos a ser cambiados (conjunto de cambios) para cumplir (por medio de hacer varias actividades) con los requerimientos de su Orden de Trabajo.

• Enviar los cambios. El propósito de enviar los cambios de un workspace de Desarrollo a un workspace de Integración es hacer que el conjunto de artefactos cambiado, en un workspaces privado de trabajo, esté disponible al proyecto para su integración.

• Actualizar los workspaces. Asegurar que los miembros del equipo están trabajando con las versiones más recientes de los archivos del proyecto. La idea es actualizar los archivos mostrados en su workspaces de desarrollo con aquellos en la base recomendada.

Manejar Versiones Congeladas (Baselines) y Liberaciones El propósito de este Workflow de detalle es asegurar que los subsistemas, cuando alcancen un nivel de maduración específico sean congelados. RUP define Versión Congelada como un 'snapshot' en el tiempo de una versión de cada artefacto en el repositorio del proyecto. Los artefactos congelados están disponibles para liberarlos o reusarlos en iteraciones subsecuentes y en otros proyectos. Comprende las siguientes actividades: • Crear la Unidad de Despliegue (desde la Administración de Configuración). Una

Unidad de Despliegue consiste de una Construcción (una colección de componentes ejecutables), documentos (material de soporte para el usuario final y las Notas del Release) y los artefactos de instalación. El propósito de esta actividad es crear una Unidad de Despliegue que sea lo suficientemente completa para que sea descargable, instalable y ejecutada en un nodo como un grupo.

• Crear las Versiones Congeladas. Para asegurar que todos los artefactos desarrollados son capturados y archivados, en puntos dados del tiempo, como una base para posterior desarrollo del producto.

- 77 -

• Promover el Congelamiento. El propósito de esta actividad es asegurar que las versiones congeladas (componentes probados individualmente por varios implementadotes y equipos de desarrolladores, combinados juntos para trabajar juntos como un producto) son etiquetados para reflejar el nivel de maduración del software , estabilidad y calidad que puedan haber alcanzado. La versión congelada apropiadamente etiquetada, entonces está disponible para liberarse o para un mayor desarrollo en iteraciones subsiguientes.

Monitorear y Reportar el estado de la Configuración El propósito de este Workflow de detalle es: • Determinar que el producto cumple con todos los requerimientos funcionales y

físicos. • Determinar que los artefactos son almacenados en una librería controlada. • Asegurar que todos los artefactos y artefactos congelados estén disponibles • Soportar actividades de Contabilización del Estado de la Configuración del proyecto

que estén basadas en un registro formalizado. • Reportar el estado de los cambios propuestos y el estado de la implementación de

los cambios propuestos. • Facilitar la revisión del producto por medio de actividades de seguimiento de

defectos y reporte. • Asegurar que la data es acumulada y reportada para los propósitos de seguimiento

del progreso y tendencias. Comprende las siguientes actividades: • Reportar el Estado de la Configuración. Para soportar actividades de

Contabilización del estado de la Configuración que son basadas en un registro formalizado y reportado en el estado de cambios propuestos y el estado de la implementación de los cambios propuestos. Facilitar la revisión del producto por medio de seguimiento de defectos y reporte de actividades. Asegurar que la data se está acumulando y se está reporteando para propósitos de seguimiento del progreso y tendencias.

• Efectuar la Auditoría de la Configuración. Determinar que una versión congelada contiene todos los artefactos. Determinar que un versión congelada cumple con los requerimientos. Se efectúa, típicamente, después de las pruebas del sistema y antes de las pruebas de Aceptación.

Administrar los Requerimientos de Cambio El propósito de este Workflow de detalle es asegurar que los cambios sean hechos de una manera consistente y que los stakeholders apropiados sean informados del estado del producto, los cambios que se le hicieron y el impacto de estos cambios en el costo y en el cronograma. Comprende las siguientes actividades: • Enviar el Requerimiento de Cambio. El Requerimiento de Cambio puede incluir

requerimientos por características nuevas, mejoras, correcciones, requerimientos

- 78 -

cambiados, etc. Cualquier rol puede enviar un Requerimiento de Cambio como parte de cualquier actividad durante el ciclo de vida del proyecto.

• Actualizar el Requerimiento de Cambio. Un Jefe de Control de Cambios designado o el dueño asignado de un requerimiento de cambio puede hacer actualizaciones al formulario de Requerimiento de Cambio para indicar su estado presente y cualquier otra información relevante.

• Revisar el Requerimiento de Cambio. Determinar si el requerimiento de cambio será aceptado o rechazado. Para los requerimientos de cambio aceptados, se les evalúa prioridad, esfuerzo, cronograma, etc. para determinar si el cambio está dentro del alcance del release actual.

• Confirmar un Requerimiento de Cambio Duplicado. El Jefe de Control de cambios o un responsable designado, deberá confirmar un requerimiento de cambio inválido o duplicado.

• Verificar los Cambios en la Construcción (desde el workflow de Pruebas). Esta actividad confirma que un requerimiento de cambio ha sido completado, típicamente conduciendo subconjuntos de pruebas en uno o más construcciones (builds).

3.7.3 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.4 RUP Artefactos de Administración de Configuración y Cambios Los artefactos de 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


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

3.7.5 Notas sobre los Artefactos para la Administración de Configuración y Cambios El Repositorio del Proyecto contiene el documento de Visión, acuerdos entre desarrolladores y usuarios, scripts de base de datos (ejemplos de los datos de origen), scripts del lenguaje de definición de datos, scripts procedimentales, incluyendo procedimientos almacenados y batch, base de datos de requerimientos, correspondencia entre los desarrolladores y los usuarios y backups de la base de datos. Tampoco incluye: Hallazgos de Auditoria de la Configuración (Configuration Audit Findings), Plan de Administración de la Configuración (Configuration Management

- 79 -

Plan). 3.7.6 Notas sobre los reportes de Administración de Configuración y Cambios Ningún reporte CM es provisto con el RUP para capturar el estado de los cambios propuestos y el estado de la implementación de los cambios propuestos. Sin embargo, una buena herramienta de CRM proveerá de un generador de reportes con muchos reportes ya hechos y que además, permita adecuarlos a sus necesidades específicas. 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