Anda di halaman 1dari 79

-1-

RUP/Easy
GUA METODOLGICA 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-

Histrico de cambios
Fecha
Setiembre 2004 Marzo 2006

Versin
1.0 2.0

Descripcin
Creacin del documento Se extendi a todos los procesos

Autor
Oswaldo Canchumani Oswaldo Canchumani

-3-

RUP/Easy
GUA METODOLGICA DE DESARROLLO DE SISTEMAS
Marzo del 2006
TABLA DE CONTENIDO
1 INTRODUCCIN ................................................................................................................................. 5 2 ADECUACIN 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 Configuracin y Notas sobre el Workflow del RUP ............................................................... 6 2.2.2.1 Explicacin de la Tabla Artefacto RUP ................................................................................ 6 2.3 PROCEDIMIENTOS DE REVISIN ........................................................................................... 7 3 VERSIN 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 Disear las Realizaciones de los Procesos del Negocio ............................................................. 14 Refinar los Roles y las Responsabilidades ................................................................................. 14 Explorar la Automatizacin 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 Definicin del Sistema ............................................................................................... 23 Administrar los Requerimientos de Cambios ............................................................................. 24 3.2.2 Configuracin 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 ANLISIS Y DISEO ................................................................................................................ 27 3.3.1 Vista General del Workflow de Anlisis y Diseo ................................................................ 27 Definir una Arquitectura candidata ............................................................................................ 28 Refinar la Arquitectura ............................................................................................................... 29 Analizar el Comportamiento....................................................................................................... 30 Disear los Componentes ........................................................................................................... 30 Disear la base de Datos (Opcional)........................................................................................... 31 3.3.2 Configuracin y Notas sobre el Workflow de Anlisis y Diseo .......................................... 32

-43.3.3 Artefactos para Anlisis y Diseo ......................................................................................... 32 3.3.4 Notas sobre los Artefactos para Anlisis y Diseo ................................................................ 33 3.3.5 Reportes para Anlisis y Diseo ............................................................................................ 34 3.4 IMPLEMENTACIN .................................................................................................................. 34 3.4.1 Vista general del Workflow de Implementacin ................................................................... 34 Estructurar el Modelo de Implementacin.................................................................................. 35 Planificar la Integracin.............................................................................................................. 36 Implementar los Componentes ................................................................................................... 36 Integrar cada Subsistema ............................................................................................................ 37 Integrar el Sistema ...................................................................................................................... 37 3.4.2 Configuracin y Notas sobre el Workflow de Implementacin............................................. 38 3.4.3 Artefactos para la Implementacin ........................................................................................ 38 3.4.4 Notas sobre los Artefactos para la Implementacin .............................................................. 38 3.4.5 Reportes para la Implementacin .......................................................................................... 38 3.5 PRUEBAS .................................................................................................................................... 38 3.5.1 Vista General del Workflow de Pruebas................................................................................ 39 Planificar las Pruebas.................................................................................................................. 51 Disear las Pruebas..................................................................................................................... 52 Implementar las Pruebas ............................................................................................................. 53 Ejecutar las Pruebas en la etapa de Integracin de Pruebas ........................................................ 54 Ejecutar las Pruebas en la etapa de Pruebas del Sistema ............................................................ 54 Evaluar las Pruebas..................................................................................................................... 55 3.5.2 Configuracin 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 Aceptacin ............................................................................................ 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 Configuracin 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 ADMINISTRACIN DE CONFIGURACIN Y CAMBIOS .................................................... 62 3.7.1 Por qu implementar Administracin de Configuracin y Cambios ..................................... 62 3.7.2 Vista general del Workflow de Administracin de Configuracin y Cambios...................... 64 Planificar la Configuracin del Proyecto y el Control de Cambios ........................................... 74 Crear un Ambiente CM para el Proyecto.................................................................................... 75 Cambiar y Enviar los Items de la Configuracin ........................................................................ 76 Manejar Versiones Congeladas (Baselines) y Liberaciones ....................................................... 76 Monitorear y Reportar el estado de la Configuracin ................................................................. 77 Administrar los Requerimientos de Cambio ............................................................................... 77 3.7.3 Notas sobre el Workflow de Administracin de Configuracin y Cambios .......................... 78 3.7.4 RUP Artefactos de Administracin de Configuracin y Cambios......................................... 78 3.7.5 Notas sobre los Artefactos para la Administracin de Configuracin y Cambios ................. 78 3.7.6 Notas sobre los reportes de Administracin de Configuracin y Cambios............................ 79 4 PASOS SIGUIENTES PARA LAS EMPRESAS CLIENTE ............................................................. 79

-5-

RUP / Easy GUA METODOLGICA DE DESARROLLO DE SISTEMAS


1 INTRODUCCIN Durante los ltimos aos, una de las metodologas ms populares ha sido el Rational Unified Process (RUP). RUP, desarrollado por Rational Software Corporation, es un proceso de ingeniera de software que ofrece un enfoque disciplinado para asignar tareas y responsabilidades dentro de la organizacin del desarrollo. RUP captura algunas de las mejores prcticas 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 mtodo orientado a objetos y el lenguaje estndar de la industria para especificar, visualizar, construir y documentar los artefactos de sistemas de software.". Un Artefacto es una pieza de informacin que es creada, modificada o usada por un proceso tal como un modelo, un Caso de Uso, un documento, cdigo fuente o archivo ejecutable. Esta gua documenta los pasos para aplicar correctamente la metodologa RUP en el proceso de desarrollo de software. RUP es muy amplio y la mayora de proyectos no necesitan seguir todo lo que est en el RUP. Esta gua demuestra la variacin hecha en el RUP por RUP/Easy para su aplicacin en las empresas del Per. 2 ADECUACIN DE LOS WORKFLOWS ESENCIALES DEL RUP Esta seccin explica cmo leer la adecuacin de los Workflows esenciales del RUP detallados en la seccin 3 de este documento. 2.1 WORKFLOWS ESENCIALES DEL RUP Esta gua metodolgica cubre la adecuacin para los nueve (9) workflows: Modelamiento de Negocios, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Administracin de Configuracin y Cambios, Despliegue. Esta gua metodolgica excluye los workflows esenciales del RUP para Administracin de Proyectos y Ambiente. 2.2 VISTA GENERAL DEL WORKFLOW DEL RUP La Seccin 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 explicacin de cada Workflow esencial del RUP.

-6-

Cada workflow descrito en la Seccin 3 contiene las siguientes subsecciones:


Configuracin y Notas sobre el Workflow del RUP Artefactos Notas sobre los Artefactos Reportes Notas sobre los Reportes

2.2.1 Configuracin y Notas sobre el Workflow del RUP Estas subsecciones detallan los cambios aplicados a la estructura de workflows del RUP en la variacin de la metodologa de RUP/Easy. 2.2.2 Artefactos Un artefacto es un pedazo de informacin que es creado, modificado o usado por un proceso tal como un modelo, un Caso de Uso, un documento, cdigo fuente o un archivo ejecutable. Estas subsecciones listan los artefactos que deberan ser producidos por cada Workflow esencial del RUP en un formato de tabla. RUP provee templates, guas y ejemplos para todos los artefactos. Si usted no est usando RUP, entonces debern desarrollarse los templates que puedan ser usadas en toda su organizacin para lograr consistencia al capturar el mismo tipo de informacin. 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 RUP Artefacto 1 Incep Created/Revised Elab Const Trans Revisar Detalles Herramientas Usadas

2.2.2.1 Explicacin de la Tabla Artefacto RUP La Tabla 2 da una explicacin de las columnas en la Tabla Artefacto RUP mostrada en la Tabla 1. Tabla 2. Explicacin de la Tabla Artefacto RUP
Nombre de Columna Artefactos Propsito El nombre del artefacto. Un artefacto es un entregable del proceso. Califica cmo es usado el artefacto a travs del ciclo de vida Contenidos/Comentarios Una referencia al artefacto en el Rational Unified Process.

Creado / Revisado

Una 'X' en una o ms de las celdas Fase, significa que planeamos congelar ese artefacto en esa fase particular: Incepcin, Elaboracin, Construccin y Transicin.

-7Revisar Detalles Define el nivel de revisin; procedimientos de revisin que van a ser aplicados al artefacto. Decidir el nivel de revisin: Formal-Externo Formal-Interno Informal Ninguno Para detalles vea la Seccin 2.3, Procedimientos de Revisin Referencia a los detalles de las herramientas usadas para desarrollar y mantener el artefacto.

Herramientas Usadas

Definicin de la herramienta (o herramientas) usadas para producir 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 organizacin, podra no ser necesario que produzca todos los artefactos. La Seccin 3 identifica esos artefactos del RUP que no son producidos en cada Workflow esencial del RUP en la variacin de la metodologa de RUP/Easy. Cuando lea esta seccin use el glosario para comprender mejor el propsito de los artefactos listados. 2.2.4 Reportes Esta subseccin 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 informacin 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 organizacin, podra no ser necesario que produzca todos los reportes. La Seccin 5 identifica esos reportes del RUP que no son producidos en cada Workflow esencial del RUP en la variacin de la metodologa de RUP/Easy.. 2.3 PROCEDIMIENTOS DE REVISIN Durante el ciclo de vida de un proyecto, una revisin de un artefacto o conjunto de artefactos es presentada al usuario, cliente u otras partes interesadas para comentarios y aprobacin. Cuando se hacen estas revisiones, usted debe tener en consideracin 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 revisin formal del trabajo del contratista. RUP/Easy ha adoptado los niveles de revisin indicados en la Tabla 4.

-8-

Tabla 4. Guas de Niveles de Revisin del RUP


Nivel de Revisin Formal-Externo Explicacin Este artefacto es un entregable en un hito especfico. Requiere algn tipo de aprobacin del cliente, el patrocinador o algn otro stakeholder externo. El artefacto es revisado formalmente por el equipo del proyecto. Comentarios Por ejemplo, la Visin y el Caso de Negocio son artefactos que deberan ser revisados por stakeholders. Los resultados de la revisin son manejados en la configuracin junto con el artefacto. Por ejemplo, las interfases de diseo de subsistemas deberan ser revisados y aprobados por varios miembros del equipo del proyecto. Los resultados de la revisin son manejados en la configuracin junto con el artefacto. Informal El artefacto es revisado; pero no es aprobado formalmente. Las Clases de Diseo 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 revisin no son manejados en la configuracin con el artefacto. El artefacto es creado como informacin de trabajo. A menudo es un artefacto temporal que es descartado luego que el proyecto termina.

Formal-Interno

Ninguno

Este artefacto no necesita ser revisado ni aprobado.

3 VERSIN 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 metodolgico del RUP para adecuar los siguientes Workflows esenciales del RUP:

Modelamiento de Negocios Una tcnica de anlisis para modelar los procesos del negocio y entender mejor las complejidades de ste. Requerimientos Una condicin o capacidad que el sistema debe cumplir. Anlisis y Diseo - Muestra cmo los casos del uso del sistema se realizarn en la implementacin. Implementacin Implementar y probar las clases. Pruebas Integrar y probar el sistema. Despliegue Asegura una transicin exitosa del sistema desarrollado a sus usuarios. Administracin de la Configuracin y Cambios Identifica, define y estandariza tems; controla las modificaciones y releases de tems.

Las organizaciones tpicamente usan enfoques de administracin de proyectos para sus proyectos de desarrollo de software. Las organizaciones necesitarn incluir administracin de proyectos con RUP y adecuarse segn sea necesario. Un Plan de Iteracin es algo que debe ser producido durante la Control de Proyectos.

-9-

3.1 MODELAMIENTO DE NEGOCIOS El Modelamiento de Negocios se efecta para valorar el negocio para el cual el sistema de informacin se est construyendo y para determinar mejor las necesidades y problemas a ser resueltos por los sistemas de informacin. Los modelos del negocio proveen una base para la comunicacin entre los analistas de sistemas y los desarrolladores para incrementar su entendimiento del negocio y para identificar oportunidades de mejorar el negocio. Tambin, 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 estn siendo cada vez ms automatizados y los sistemas de computadora estn tocando cada aspecto del negocio, la clave para implementar exitosamente un nuevo sistema de computadora es entender el negocio. Tambin con la evolucin 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 cmo el valor del negocio puede ser mejorado. El modelo del negocio provee un salto de inicio para capturar los requerimientos del sistema (Ms detalles acerca de capturar los requerimientos se encuentran en la Seccin 3.2.). 3.1.2 Vista general del Workflow de Modelamiento de Negocios El propsito del Workflow de Modelamiento de Negocios es:

Entender la estructura y las dinmicas de la organizacin en la cual un sistema va a ser desplegado (la organizacin objetivo). Entender los problemas actuales en la organizacin objetivo e identificar mejoras potenciales. Asegurar que los clientes, usuarios finales y desarrolladores tiene un entendimiento comn de la organizacin objetivo. Derivar los requerimientos necesarios para soportar la organizacin objetivo.

Los artefactos clave del Workflow de Modelamiento de Negocios son la Visin 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 diseo del Workflow de Anlisis y Diseo. 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) Disear las Realizaciones de los Procesos del Negocio (Design Business Process Realizations) Refinar los Roles y las Responsabilidades (Refine Roles y Responsibilities)

- 11 -

Explorar la Automatizacin 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 propsito de este Workflow de detalle es:

Valorizar el estado de la organizacin en la cual el nuevo sistema va a ser desplegado (la organizacin objetivo). Entender cmo categorizar el proyecto y cual escenario de Modelamiento de Negocios, listado a continuacin, se adecua ms a su proyecto: Grfico de la Organizacin un mapa simple de la organizacin para entender mejor los requerimientos. Modelamiento de Dominio es usado para construir aplicaciones cuyo propsito principal es manejar y presentar informacin. Un negocio, muchos sistemas un modelo del negocio para un sistema grande o una familia de aplicaciones. Modelo de negocios genrico para una aplicacin usada por muchas organizaciones. Negocio nuevo para una lnea completamente nueva de negocios y los sistemas que la soportan. Renovar el negocio existente para cambiar completamente la forma de hacer negocios (reingeniera de procesos de negocios) Tomar decisiones acerca de cmo continuar trabajando en la iteracin actual y delinear cmo trabajar en iteraciones siguientes con los artefactos de modelamiento de negocios.

Comprende las siguientes actividades: Capturar un Vocabulario de Negocios comn. Definir un vocabulario comn 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 Organizacin Objetivo. Describir es estado actual de la organizacin la cual la aplicacin va a ser desplegada en trminos de sus procesos actuales, herramientas, competencias de la gente, actitudes de la gente, clientes, competidores, tendencias tcnicas, problemas y reas de movimiento. Motivar porqu la organizacin 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 visin de la futura organizacin 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 accin y; para proveer de una base para medir y mejorar las actividades del negocio.

El principal artefacto producido es la Visin del Negocio. Describir el Negocio Actual El propsito de este Workflow de detalle es entender los procesos y estructura de la organizacin para describir la organizacin objetivo brevemente y priorizar las partes de la organizacin objetivo en que se enfocarn por el resto del proyecto. Comprende las siguientes actividades: Evaluar la Organizacin Objetivo. Describir el estado actual de la organizacin la cual la aplicacin va a ser desplegada en trminos de sus procesos actuales, herramientas, competencias de la gente, actitudes de la gente, clientes, competidores, tendencias tcnicas, problemas y reas de movimiento. Motivar porqu la organizacin objetivo debe ser mejorada y; para identificar a los stakeholders el esfuerzo del modelamiento del negocio. Capturar un Vocabulario de Negocios comn. Definir un vocabulario comn que pueda ser usado en todas las descripciones textual el negocio, especialmente en las descripciones de los Casos de Uso. 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. 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. 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 accin 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 quin 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. Preparar y ajustar los Objetivos. Delimitar el esfuerzo del modelamiento. Desarrollar una visin de la futura organizacin objetivo. Ganar acuerdos en los objetivos del esfuerzo del modelamiento del negocio y; para definir expectativas realistas de los stakeholders. Encontrar Trabajadores y Entidades del Negocio. Identificar los roles, entregables y eventos en el negocio. Describir cmo las realizaciones de Casos de Uso del Negocio son efectuadas por los trabajadores y las entidades del negocio.

El principal artefacto producido es una Visin del Negocio refinada. Identificar los Procesos del Negocio Dentro del equipo, los miembros deberan llegar a un entendimiento comn de las

- 13 -

fronteras del negocio que estn modelando. Tambin, necesitan decidir cules procesos dentro de esas fronteras sern descritos en ms detalle. El propsito de este Workflow de detalle es decidir la terminologa, delinear el Modelo de Caso de Uso del Negocio y priorizar cules Casos de Uso del Negocio sern 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 visin de la futura organizacin objetivo. Ganar acuerdos en los objetivos del esfuerzo del modelamiento del negocio y; para definir expectativas realistas de los stakeholders. 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. Capturar un Vocabulario de Negocios comn. Definir un vocabulario comn 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 accin 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 quin 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 definicin del Caso de Uso del Negocio y liderar una sesin de revisin para el Caso de Uso del Negocio. El propsito 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 cmo 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 estn conforme a los puntos de vista de los stakeholders.

El principal artefacto producido son los Casos de Uso del Negocio detallados. Disear las Realizaciones de los Procesos del Negocio El propsito de este Workflow de detalle es identificar los roles, productos, entregables y eventos en el negocio y describir cmo un Caso de Uso del Negocio en particular es realizado dentro del Modelo de Objetos del Negocio en trminos 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 cmo las realizaciones de Casos de Uso del Negocio son efectuadas por los trabajadores y las entidades del negocio. Capturar un Vocabulario de Negocios comn. Definir un vocabulario comn 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.

El principal artefacto producido es el Modelo de Objetos del Negocio. Refinar los Roles y las Responsabilidades El propsito de este Workflow de detalle es detallar la definicin 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 estn conforme con la visin 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 Anlisis del Negocio. Verificar formalmente que los resultados del modelamiento de anlisis del negocio estn 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 Automatizacin de Procesos El propsito de este Workflow de detalle es explorar qu partes de los procesos del negocio sern automatizados, entender cmo los sistemas existentes encajan en la organizacin y derivar los requerimientos del sistema. Comprende las siguientes actividades: Preparar y ajustar los Objetivos. Delimitar el esfuerzo del modelamiento. Desarrollar una visin de la futura organizacin objetivo. Ganar acuerdos en los objetivos del esfuerzo del modelamiento del negocio y; para definir expectativas realistas de los stakeholders. Definir los requerimientos de Automatizacin. Comprender cmo las nuevas tecnologas pueden ser usadas para hacer que la organizacin objetivo sea ms eficiente. Determinar el nivel de automatizacin en la organizacin 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, enfocndose 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 propsito 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 estn conforme con la visin que tienen los stakeholders del negocio. Comprende las siguientes actividades: Capturar un Vocabulario de Negocios comn. Definir un vocabulario comn 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. Encontrar Trabajadores y Entidades del Negocio. Identificar los roles, entregables y

- 16 -

eventos en el negocio. Describir cmo 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 Anlisis del Negocio. Verificar formalmente que los resultados del modelamiento de anlisis del negocio estn conforme a los puntos de vista del negocio de los stakeholders.

El principal artefacto producido es el Modelo de Dominio. 3.1.3 Configuracin y Notas sobre el Workflow de Modelamiento de Negocios RUP/Easy adopt por el escenario renovar el negocio (reingeniera de procesos de negocios). Renovar es un escenario de modelamiento de negocios. Es una de las opciones listadas en la Seccin 3.1.2. esta opcin fue escogida porque RUP/Easy tpicamente asiste a las organizaciones con reingeniera en sus procesos de negocio para que provean un mejor servicio a sus clientes. La variacin metodolgica de RUP/Easy al Workflow de Modelamiento de Negocios no incluye las actividades Desarrollar las Realizaciones de Diseo 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 Diseo de Dominio (Develop a Domain Model artefacto) y actividades y artefactos relativos al Modelo de Objetos del Negocio. La variacin metodolgica de RUP/Easy no incluye el desarrollo del Modelo de Objetivo durante el Workflow de Requerimientos (ver la Seccin 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 deberan ser desarrollados cuando se hace modelamiento de negocios. Tabla 5. Artefactos para el Modelamiento de Negocios
Artefactos
Incep

Creado / Revisado
Elab Const Trans

Revisar Detalles
Formal - Interno Formal - Externo Formal - Externo Formal - Externo Formal - Externo Formal - Externo

Herramientas Usadas
Rational Rose Requisite Pro, MS Word Requisite Pro, MS Word Requisite Pro, MS Word Rational Rose Requisite Pro, MS Word

Actor del Negocio Glosario del Negocio Reglas del Negocio Caso de Uso del Negocio Modelo de Casos de Uso del Negocio Visin del Negocio

X X X X X X

- 17 Unidad de la Organizacin Especificacin Suplementaria del Negocio Valorizacin de la Organizacin Objetivo


Rational Rose Formal -Externo Requisite Pro, MS Word

X X X
Formal -Externo

Requisite Pro, MS Word

3.1.5 Notas sobre los Artefactos para el Modelamiento de Negocios La variacin metodolgica de RUP/Easy no incluye la creacin 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), Realizacin del Caso de Uso del Negocio (Business Use-Case Realization) y Trabajador del Negocio (Business Worker). El artefacto Unidad de la Organizacin (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 metodologa de RUP/Easy recomienda que sean elaborados durante el Modelamiento de Negocios. Tabla 6. Reportes para el Workflow de Modelamiento de Negocios
Reportes Panorama del Modelo de Casos de Uso del Negocio Herramientas Usadas Rational SoDA, MS Word

3.1.7 Notas sobre los Reportes para el Modelamiento de Negocios La variacin metodolgica de RUP/Easy no incluye la creacin de estos Reportes para el Modelamiento de Negocios: Entidad del Negocio (Business Entity), Caso de Uso del Negocio (Business Use-Case), Realizacin del Caso de Uso del Negocio (Business UseCase 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 debera 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 podrn construir el sistema apropiado. El Modelamiento de Negocios con UML permite a los analistas modelar los procesos del negocio usando los mismos smbolos, diagramas y otras formas de notacin 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 comn permite algo que antes no era posible en el desarrollo de software: comunicacin entre la gente del negocio y la gente de sistemas.

- 18 -

Sin embargo, el Modelamiento del Negocio slo debe ser efectuado si se est cambiando la manera en que se hace negocio. Si slo se est aadiendo una nueva caracterstica 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 Seccin 3.2, Requerimientos. 3.2 REQUERIMIENTOS Se debera manejar las generaciones (versiones) de requerimientos y su documentacin. La Administracin de Requerimientos incorpora la identificacin, organizacin y documentacin de los cambios a los requerimientos en un proyecto. Es una parte integral de la actividad de desarrollo de software. La Administracin de Requerimientos establece un entendimiento comn y acuerdo entre el cliente y el equipo del proyecto acerca de los requerimientos del cliente. Una Administracin 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 propsito 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 tcnico 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 enfocndose en las necesidades y objetivos de los usuarios

Los artefactos clave a desarrollar son: Visin, 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 Anlisis y Diseo 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 cdigo contra el Modelo de Casos de Uso, los Casos de Uso y las Especificaciones Suplementarias. El Workflow de Administracin de Configuracin 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 Definicin del Sistema Administrar los Requerimientos de Cambios

Workflow de Requerimientos Analizar el Problema El propsito 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 implementacin de un sistema o aplicacin y, a los usuarios Definir las fronteras del sistema, las cuales son los bordes entre la solucin del problema y el mundo real que rodea a la solucin. Identificar las restricciones impuestas al sistema tales como horarios y recursos, decisiones tcnicas, restricciones econmicas, etc.

El primer paso es asegurarse que todas las partes involucradas acuerdan en el problema

- 20 -

que estn tratando de resolver con el nuevo sistema. Para evitar malos entendidos, un glosario es creado para proveer de una terminologa comn, 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 estn siendo considerados, es importante que conozca a sus stakeholders. Los Actores en sus Casos de Uso representarn a algunos de los stakeholders los usuarios del sistema. Comprende las siguientes actividades: Capturar un vocabulario comn. Definir un vocabulario comn que pueda ser usado en todas las descripciones textuales del sistema, especialmente en las descripciones de los Casos de Uso. Desarrollar el Plan de Administracin de Requerimientos. Desarrollar un plan para documentar los requerimientos, sus atributos y guas para rastreabilidad y administracin 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 quin 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 ms importantes. Los menos importantes sern revisados en las fases posteriores. No olvidar que los Casos de Uso menos importantes, no necesariamente deben ser descritos en detalle pues, podra bastar con la descripcin inicial. Desarrollar la Visin. Obtener un acuerdo sobre qu problemas necesitan ser resueltos. Identificar a los stakeholders del sistema. Definir las fronteras del sistema. Describir las caractersticas primarias del sistema. La Visin debe dejar en claro a los stakeholders lo siguiente: Los beneficios y las oportunidades que obtendrn 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 trminos 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 Visin debe estar completa y estable al finalizar la Fase de Incepcin; sin embargo, se puede afinar durante la Fase de Elaboracin. Este documento debe ser enviado a todos los stakeholder y usuarios principales, de tal manera que ninguno pueda decir que no lo conoca o no saba nada.

El documento Visin es el principal artefacto en el cual el anlisis del problema es documentado. Entender las Necesidades del Stakeholder El propsito de este Workflow de detalle es coleccionar y obtener la informacin de los stakeholders para entender cules 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 comn. Definir un vocabulario comn que pueda ser usado en todas las descripciones textuales del sistema, especialmente en las descripciones de los Casos de Uso. Desarrollar la Visin. Obtener un acuerdo sobre qu problemas necesitan ser resueltos. Identificar a los stakeholders del sistema. Definir las fronteras del sistema. Describir las caractersticas primarias del sistema. La Visin debe dejar en claro a los stakeholders lo siguiente: Los beneficios y las oportunidades que obtendrn 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 trminos 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 Visin debe estar completa y estable al finalizar la Fase de Incepcin; sin embargo, se puede afinar durante la Fase de Elaboracin. Este documento debe ser enviado a todos los stakeholder y usuarios principales, de tal manera que ninguno pueda decir que no lo conoca o no saba nada. 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 quin 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 ms importantes. Los menos importantes sern revisados en las fases posteriores. No olvidar que los Casos de Uso menos importantes, no necesariamente deben ser descritos en detalle pues, podra bastar con la descripcin inicial. Manejar las Dependencias. Usar atributos y rastreabilidad de los requerimientos del proyecto para asistir en la administracin del alcance del proyecto y administracin de cambios en los requerimientos.

El artefacto principal es un documento refinado de la Visin. Tambin los requerimientos son discutidos y expresados en trminos de Casos de Uso y Actores. Los requerimientos no funcionales, que no caen fcilmente en el Modelo de Casos de Uso debern ser documentados en los documentos de Especificaciones Suplementarias. Definir el Sistema El propsito de este Workflow de detalle es:

Alinear al equipo del proyecto en su comprensin del nuevo sistema.

- 22 -

Efectuar un anlisis de alto nivel a los resultados de los requerimientos recolectados a los stakeholder. Refinar el documento Visin para incluir todas las caractersticas 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 comn. Definir un vocabulario comn que pueda ser usado en todas las descripciones textuales del sistema, especialmente en las descripciones de los Casos de Uso. Desarrollar la Visin. Obtener un acuerdo sobre qu problemas necesitan ser resueltos. Identificar a los stakeholders del sistema. Definir las fronteras del sistema. Describir las caractersticas primarias del sistema. La Visin debe dejar en claro a los stakeholders lo siguiente: Los beneficios y las oportunidades que obtendrn 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 trminos 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 Visin debe estar completa y estable al finalizar la Fase de Incepcin; sin embargo, se puede afinar durante la Fase de Elaboracin. Este documento debe ser enviado a todos los stakeholder y usuarios principales, de tal manera que ninguno pueda decir que no lo conoca o no saba nada. 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 quin 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 ms importantes. Los menos importantes sern revisados en las fases posteriores. No olvidar que los Casos de Uso menos importantes, no necesariamente deben ser descritos en detalle pues, podra bastar con la descripcin inicial. Manejar las Dependencias. Usar atributos y rastreabilidad de los requerimientos del proyecto para asistir en la administracin del alcance del proyecto y administracin de cambios en los requerimientos.

En Definir el Sistema, se enfoca en identificar a los actores y los casos de uso ms completamente y expandir los requerimientos no funcionales definidos en los documentos de especificaciones suplementarias. Administrar el Alcance del Sistema El propsito de este Workflow de detalle es:

Priorizar y refinar la seleccin de caractersticas y requerimientos que van a ser incluidos en la iteracin actual.

- 23 -

Definir el conjunto de Casos de Uso (o Escenarios) que representan la funcionalidad central. Definir cules atributos de requerimientos y caractersticas de rastreo sern 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 tcnica til para manejar el alcance del proyecto. Comprende las siguientes actividades: Priorizar los Casos de Uso. Definir el input a la seleccin o al conjunto de escenarios y Casos de Uso que van a ser analizados en la iteracin 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 especfico, delicado de la arquitectura. Desarrollar la Visin. Obtener un acuerdo sobre qu problemas necesitan ser resueltos. Identificar a los stakeholders del sistema. Definir las fronteras del sistema. Describir las caractersticas primarias del sistema. La Visin debe dejar en claro a los stakeholders lo siguiente: Los beneficios y las oportunidades que obtendrn 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 trminos 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 Visin debe estar completa y estable al finalizar la Fase de Incepcin; sin embargo, se puede afinar durante la Fase de Elaboracin. Este documento debe ser enviado a todos los stakeholder y usuarios principales, de tal manera que ninguno pueda decir que no lo conoca o no saba nada. Manejar las Dependencias. Usar atributos y rastreabilidad de los requerimientos del proyecto para asistir en la administracin del alcance del proyecto y administracin de cambios en los requerimientos. Refinar la Definicin del Sistema El propsito de este Workflow de detalle es:

Refinar an ms los requerimientos para describir el flujo de eventos de los Casos de Uso en detalle, detallar las Especificaciones Suplementarias, desarrollar una Especificacin de requerimientos de Software, si se necesita ms detalle Modelar y prototipear la interfase con el usuario.

- 24 -

Comprende las siguientes actividades: Detallar los Casos de uso. Describir uno o ms 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 especificacin de Caso de Uso para el entendimiento y satisfaccin 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 Definicin 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 comprensin ms profunda de la funcionalidad del sistema expresada en Casos de Uso detallados y documentos de Especificaciones Suplementarias detallados. Si es necesario, una Especificacin de Requerimientos de Software formal puede ser desarrollado, adems de los documentos detallados de Casos de Uso y Especificaciones Suplementarias. Administrar los Requerimientos de Cambios El propsito 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 relacin entre los atributos y la rastreabilidad de los requerimientos. Verificar que los resultados del Workflow de Requerimientos estn conforme con la visin 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 anlisis, diseo y pruebas. Manejar las Dependencias. Usar atributos y rastreabilidad de los requerimientos del proyecto para asistir en la administracin del alcance del proyecto y administracin de cambios en los requerimientos. Revisar los requerimientos. Verificar formalmente que los resultados de los requerimientos estn 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 Anlisis y Diseo, 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 Configuracin y Notas sobre el Workflow de Requerimientos Cada actividad en el Workflow de Requerimientos es esencial para una implementacin exitosa. Ninguna actividad debe ser removida del Workflow de Requerimientos. 3.2.3 Artefactos de Requerimientos Los Artefactos de Requerimientos capturan y presentan informacin 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
Incep Actor Glosario Lista de Riesgos Especificacin Suplementaria Caso de Uso Modelo de Caso de Uso Vision

Creado / Revisado
Elab X X X X X X X X X Const X X Trans

Revisar Detalles
Informal Formal-Externo Formal-Externo Formal-Externo Formal-Externo Formal-Externo Formal-Externo

Herramientas Usadas
Rational Rose Requisite Pro; MS Word Requisite Pro Requisite Pro; MS Word Rational Rose; Requisite Pro; MS Word Rational Rose 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 pequeo se puede incluir en el Plan de Desarrollo de Software con todo el detalle correspondiente: . . . . . . Magnitud del Riesgo o Ranking Descripcin Impactos Indicadores Estrategia de Mitigacin Plan de Contingencia

La Lista de Riesgos se va actualizando a los largo del proyecto segn los riesgos se vayan eliminando o, aparezcan nuevos riesgos. Tomar en cuenta lo siguiente: Actualizarla al trmino de una iteracin. 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 Visin debe dejar en claro a los stakeholders lo siguiente: Los beneficios y las oportunidades que obtendrn 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 trminos 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 Visin contiene los requerimientos generales; pero los requerimientos detallados del software se encuentran definidos en el Documento de Arquitectura del Software. La Visin debe estar completa y estable al finalizar esta Fase de Inicio; sin embargo, se puede afinar durante la Fase de Elaboracin. Este documento debe ser enviado a todos los stakeholder y usuarios principales, de tal manera que ninguno pueda decir que no lo conoca o no saba nada. La variacin metodolgica de RUP/Easy no incluye la creacin de estos Artefactos de Requerimientos: Clase Frontera (Boundary Class), Storyboard de Casos de Uso (UseCase Storyboard) y Prototipo de la Interfase con el Usuario (User-Interfase Prototype). Tampoco incluye: Atributos de Requerimientos (Requeriment Attributes), Plan de Administracin de Requerimientos (Requeriment Management Plan), Requerimientos del Stakeholder (Stakeholder Requeriments), Paquete de Caso de Uso (Use-Case Package), Especificacin de Requerimientos de Software (Software Requeriments Specification). Este ltimo no es necesario debido a que los requerimientos globales se definen en la Visin y los requerimientos del software se definen en el Documento de Arquitectura del Software. 3.2.5 Reportes de Requerimientos La variacin metodolgica 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 mayora de la informacin contenida en los reportes de Actores y Casos de Uso. Tabla 8. Reportes para el Workflow de Requerimientos
Reportes Panorama del Modelo de Caso de Uso Herramientas Usadas Rational SoDA; MS Word

3.2.6 Notas sobre los Reportes de Requerimientos

- 27 -

La variacin metodolgica de RUP/Easy no incluye la creacin del reporte Storyboard de Casos de Uso. Tampoco incluye Los reportes de Actores y Casos de Uso. 3.3 ANLISIS Y DISEO El propsito del Workflow de Anlisis y Diseo 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 diseo que pueda ser usado por los desarrolladores durante el Workflow de Implementacin. El Anlisis se enfoca en trasladar los requerimientos funcionales a conceptos de software. 3.3.1 Vista General del Workflow de Anlisis y Diseo El propsito del Workflow de Anlisis y Diseo es:

Transformar los requerimientos en un diseo del sistema a crear Definir una arquitectura robusta para el sistema Adaptar el diseo para que funcione en el ambiente de implementacin disendolo para obtener buena performance

El Workflow de Anlisis y Diseo toma los casos de uso documentados del Workflow de Requerimientos y del Workflow de Modelamiento de Negocios y los traslada a elementos de diseo que sern usados para construir el sistema. Por medio de usar varias actividades y modelos el Workflow de Anlisis y Diseo busca destilar la informacin recogida de los stakeholders en informacin que los programadores podrn usar. Al final, un Modelo de Diseo y el documento de Arquitectura del Software describirn el sistema. El Workflow de Anlisis y Diseo est relacionado a otros workflow del RUP como sigue:

El Workflow de Implementacin usar el Modelo de Diseo y el documento de Arquitectura del Software como inputs en la construccin e implementacin 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 Anlisis y Diseo consiste de los siguientes workflows de detalle:


Definir una Arquitectura candidata Refinar la Arquitectura Analizar el Comportamiento Disear los Componentes Disear la Base de Datos (opcional) - es efectuado durante cualquier iteracin que requiere la demostracin de datos persistentes

- 28 -

Workflow de Anlisis y Diseo Definir una Arquitectura candidata Este workflow es efectuado durante las iteraciones de las fases de Incepcin y al inicio de la Elaboracin. El propsito de este Workflow de detalle es: Definir las fronteras arquitecturales a ser usada durante el anlisis Definir los mecanismos de anlisis que sern importantes para el sistema (por ejemplo, persistencia, distribucin, seguridad) Definir cualquier Patrn 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: Anlisis 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. Anlisis de Casos de Uso. Identificar las clases que efectan 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 Elaboracin y la fase de Construccin. El propsito de este Workflow de detalle es: Identificar e incorporar elementos de diseo Identificar clases de diseo y subsistemas. Definir mecanismos de diseo e inventariar los mecanismos de implementacin. Refinar la arquitectura incorporando la reusabilidad siempre que sea posible. Identificar interfases, clases de diseo y subsistemas de diseo. Actualizar la arquitectura basado en los hallazgos en el modelo de diseo.

Describir la arquitectura de run-time y su distribucin Identificar y disear los procesos (ambiente de ejecucin en el cual las clases y subsistemas residen y corren) y threads (ejecuciones computacionales independientes dentro del ambiente de ejecucin). Modelar procesos para el Plan de implementacin de la configuracin de la red por medio de identificar qu parte o partes del sistema sern ejecutados en nodos especficos o procesadores de cmputo. Modelar la configuracin de la red para describir la comunicacin y el flujo de procesos entre los nodos. Identificar todos los recursos disponibles para correr el sistema. Definir y modelar cmo, los procesos, pueden ser distribuidos en la configuracin de la red para alcanzar los requerimientos tales como performance del sistema y disponibilidad.

Comprende las siguientes actividades: Identificar los Mecanismos de Diseo. Refinar los mecanismos de anlisis en mecanismos de diseo basados en las restricciones impuestas por el ambiente de implementacin. Identificar los Elementos de Diseo. Analizar las interacciones de las clases de anlisis para identificar los elementos del modelo de diseo. Incorporar los Elementos de Diseo existentes. Analizar las interacciones de las clases de anlisis para encontrar interfases, clases de diseo y subsistemas de diseo. Refinar la arquitectura, incorporar el reuso donde sea posible. Identificar soluciones comunes encontradas durante los problemas. Incluir arquitecturalmente elementos significativos del modelo de diseo en la seccin Vista Lgica del Documentos de Arquitectura de Software. Estructurar el Modelo de Implementacin (desde la Implementacin). Establecer la estructura en la cual la implementacin residir. Asignar responsabilidades para la

- 30 -

implementacin de los Subsistemas y sus contenidos. Describir la Arquitectura de Run-Time. Analizar requerimientos de concurrencia, identificar procesos, identificar mecanismos de comunicacin entre procesos, separa recursos de coordinacin entre procesos, identificar ciclos de vida de procesos y distribuir elementos del modelo entre los procesos. Describir la Distribucin. Describir cmo la funcionalidad des sistema es distribuida entre los nodos fsicos. Esta actividad se aplica slo a los sistemas distribuidos.

Analizar el Comportamiento Este workflow es efectuado durante las iteraciones en las fases de Incepcin, Elaboracin y Construccin. El propsito de este Workflow de detalle es:

Identificar las Clases de Anlisis desde los Diagramas de Caso de Uso y las especificaciones de Caso de Uso. Crear Diagramas de Interaccin 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: Anlisis de Casos de Uso. Identificar las clases que efectan 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 Diseo. Analizar las interacciones de las clases de anlisis para identificar los elementos del modelo de diseo. Revisar el Diseo. Verificar que el modelo de diseo cumple con los requerimientos del sistema y que sirve como una buena base para su implementacin. Asegurar que el modelo de diseo es consistente con respecto a las guas de diseo general. Asegurar que las guas de diseo cumplen sus objetivos. Disear la Interfase con el Usuario. Producir un diseo 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 diseo de la interfase con el usuario contra los requerimientos funcionales y de uso.

Disear los Componentes Este workflow es efectuado durante las iteraciones en las fases de Incepcin, Elaboracin y Construccin. Durante las iteraciones iniciales este workflow se enfocar ms en los comportamientos significativos de la arquitectura. En las iteraciones de la fase de Construccin, el enfoque se mueve hacia completar y disear la consistencia de todos los comportamientos. El propsito de este Workflow de detalle es:

Refinar los Diagramas de Diseo 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 diseo como componentes

Comprende las siguientes actividades: Disear las Cpsulas. Elaborar y refinar las descripciones de una cpsula. Disear los Casos de Uso. Refinar las Realizaciones de Casos de Uso en trminos de interacciones. Refinar los requerimientos para las operaciones de las clases de diseo. Refinar los requerimientos para las operaciones de diseo de subsistemas y/o sus interfases. Refinar los requerimientos para las operaciones de las cpsulas. Disear las Clases. Asegurar que las clases proveen el comportamiento que requieren las realizaciones de Casos de Uso. Asegurar que se tiene la suficiente informacin para implementar la clase sin ambigedad. Manejar los requerimientos no funcionales relativos a la clase. Incorporar los mecanismos de diseo usados por la clase. Disear los Elementos de Pruebas. Disear la funcionalidad especfica para las pruebas. Disear los Subsistemas. Definir los comportamientos especificados en las interfases del subsistema en trminos de colaboraciones de elementos de diseo 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. Revisar el Diseo. Verificar que el modelo de diseo cumple con los requerimientos del sistema y que sirve como una buena base para su implementacin. Asegurar que el modelo de diseo es consistente con respecto a las guas de diseo general. Asegurar que las guas de diseo cumplen sus objetivos. Definir los Elementos de Pruebas. Definir los elementos necesarios para soportar los tems de prueba objetivo. Identificar los elementos fsicos de la infraestructura de implementacin de las pruebas requeridos para posibilitar las pruebas bajo cada Configuracin de Ambiente de Pruebas. Definir los requerimientos de software que sern necesarios para lograr que el software sea fsicamente probado.

Disear la base de Datos (Opcional) Este workflow del RUP es efectuado durante cualquier iteracin que requiere la demostracin de datos persistentes. El propsito de este Workflow de detalle es:

Crear el modelo de datos Mapear las clases de diseo que contienen datos que van a ser persistentes, almacenados por ms tiempo que la ejecucin actual del sistema, con el modelo de datos Distribuir el comportamiento de clase a la base de datos

Comprende las siguientes actividades: Disear las Clases. Asegurar que las clases proveen el comportamiento que requieren las realizaciones de Casos de Uso. Asegurar que se tiene la suficiente informacin para implementar la clase sin ambigedad. Manejar los requerimientos no funcionales relativos a la clase. Incorporar los mecanismos de diseo usados por la clase.

- 32 -

Disear la Base de Datos. Asegurar que los datos persistentes estn almacenados consistentemente y eficientemente. Definir el comportamiento que debe ser implementado en la base de datos. Revisar el Diseo. Verificar que el modelo de diseo cumple con los requerimientos del sistema y que sirve como una buena base para su implementacin. Asegurar que el modelo de diseo es consistente con respecto a las guas de diseo general. Asegurar que las guas de diseo cumplen sus objetivos.

3.3.2 Configuracin y Notas sobre el Workflow de Anlisis y Diseo El Workflow de detalle Refinar la Arquitectura puede ser saltado si hay relativamente pocos riesgos arquitecturales. Esto es, el diseo, la implementacin y la distribucin del sistema no producen problemas arquitecturales significativos o el arquitecto de software tiene suficiente experiencia para manejar tales hechos. El Workflow de detalle Efectuar Sntesis Arquitectural puede ser saltado. Este Workflow de detalle puede ser efectuado si es que se necesita profundizar los conceptos. Los workflows de detalle Disear Componente de Tiempo Real y Disear Componente [No Tiempo Real] son similares con la excepcin 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 Anlisis y Diseo Los Artefactos para Anlisis y Diseo capturan y presentan informacin relativa a la solucin de los problemas planteados durante el Workflow de Requerimientos. La Tabla 9 identifica los artefactos que debern producirse durante el Workflow de Anlisis y Diseo. Tabla 9. Artefactos para el Workflow de Anlisis y Diseo
Artefactos
Incep Clase de Anlisis Modelo de Anlisis y Diseo Modelo de Despliegue Modelo de Datos Clase de Diseo Paquete de Diseo Subsistema de Diseo Documento de Arquitectura del Software Realizacin de Caso de Uso X X X X

Creado / Revisado
Elab X X X X X X X X X X X X X X X Const X Trans

Revisar Detalles
Informal - Interno

Herramientas Usadas
Rational Rose Rational Rose RequistePro; MS Word Rational Rose Rational Rose Rational Rose Rational Rose RequistePro; MS Word RequistePro; MS Rational Rose Word;

Formal - Externo Formal - Externo


Informal - Interno Informal - Interno Informal - Interno Informal - Interno

Formal - Externo
Informal - Interno

- 33 -

3.3.4 Notas sobre los Artefactos para Anlisis y Diseo El Modelo de Anlisis y Diseo puede ser mantenido como dos modelos separados, donde el modelo de anlisis muestra slo nombres de clases de anlisis y, el modelo de diseo muestra clases de anlisis detalladas y clases de diseo arquitectural. Mantener los modelos por separado se convierte en una tarea ms retadora conforme avanza el desarrollo del sistema. Usar un solo modelo y evolucionarlo durante las iteraciones es una prctica aceptable para reducir la tarea de mantener dos modelos separados. El Modelo de Diseo comprende los siguientes artefactos: Protocolo Cpsula Realizacin de Caso de Uso Signal Evento Subsistema de Diseo Paquete de Diseo Interfase Clase de Diseo. Entre las clases se considera tambin, las Interfases con otros componentes o subsistemas. Clase de Pruebas Diseo de Prueba Los artefactos de diseo Cpsula (Capsule), Evento (Event), Interfase (Interfase), Protocolo (Protocol) y Seal (Signal) ayudan en un mayor detalle de los comportamientos especficos 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 diseo. A menos que haya una buena razn para detallarlos separadamente, estos pueden ser saltados en la variacin metodolgica de RUP/Easy. El Documento de Arquitectura del Software hace mucho uso de los diagramas de UML. Comprende los siguientes artefactos: Introduccin Representacin Arquitectural Metas Arquitecturales y Restricciones. Aqu considerar los requerimientos detallados del software. Vista de Caso de Uso Vista Lgica Vista de Proceso Vista de Despliegue Vista de Implementacin Tamao y Performance Calidad

Una Arquitectura de Referencia (Reference Architecture) es un patrn predefinido o

- 34 -

conjunto de patrones previamente desarrollados y disponible para reusar. El propsito 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 diseo usados en proyectos exitosos previos. Tambin puede incluir notas o obstculos 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 especfico. Este es un artefacto opcional; si no existe una arquitectura previa entonces se puede saltar. 3.3.5 Reportes para Anlisis y Diseo La variacin metodolgica de RUP/Easy considera opcionales todos los reportes de Anlisis y Diseo; sin embargo, si van a usarse, la Tabla 10 identifica los siguientes reportes opcionales: Tabla 10. Reportes para el Workflow de Anlisis y Diseo
Reportes
Clase Panorama del Modelo de Diseo Paquete de Diseo/Subsistema Realizacin de Caso de Uso

Herramientas Usadas
Rational SoDA Rational SoDA Rational SoDA Rational SoDA

3.4 IMPLEMENTACIN La Implementacin es donde empieza el cdigo. El Modelo de Diseo del Workflow de Anlisis y Diseo es mapeado con el Modelo de Implementacin y entonces se escribe el cdigo en un lenguaje de programacin tal como Java, C++ o Visual Basic. Un Plan de Integracin de Construcciones define el Caso de Uso a ser diseado 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 Implementacin El propsito del Workflow de Implementacin es:

Definir la organizacin del cdigo, en trminos de Subsistemas de Implementacin. Los Subsistemas de Implementacin son colecciones de componentes y otros modelos de implementacin usados para estructurar el modelo de implementacin. Implementar las clases y objetos definidos en el modelo de diseo 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 Implementacin est relacionado a otros workflows del RUP como sigue:

Requerimientos: Este workflow del RUP captura los requerimientos que deberan ser cumplidos durante la Implementacin.

- 35 -

Anlisis y Diseo: El modelo de diseo desarrollado durante este workflow representa el intento de la implementacin y es el input principal para el Workflow de Implementacin. Pruebas: Este workflow describe cmo probar cada Construccin durante la integracin del sistema.

Para cada iteracin, empezando en la fase de Elaboracin, se efectan los siguientes workflows de detalle:

Estructurar el Modelo de Implementacin Planificar la Integracin Implementar los Componentes Integrar cada Subsistema Integrar el Sistema

Workflow de Implementacin Estructurar el Modelo de Implementacin El propsito de este Workflow de detalle es:

Asegurar que el modelo de implementacin est bien organizado para prevenir problemas en la administracin de la configuracin Permitir que cada versin operacional el sistema sea construido segn sea necesario

- 36 -

hasta que el producto final sea obtenido Comprende las siguientes actividades: Estructurar el Modelo de Implementacin. Establecer la estructura en la cual la implementacin va a residir. Asignar responsabilidades para los Subsistemas de Implementacin y sus contenidos.

El artefacto principal producido es el Modelo de Implementacin. Planificar la Integracin El propsito de este Workflow de detalle es:

Planificar cules subsistemas van a ser implementados Definir el orden en el que los subsistemas sern integrados en la iteracin actual

Comprende las siguientes actividades: Planificar la Integracin del Sistema. Definir el conjunto de la Construccin y evaluar el Plan de Integracin de Construcciones.

El artefacto principal producido es el Plan de Integracin de Construcciones. Segn la arquitectura y el diseo evolucionan, el Plan de Integracin de Construcciones es examinado y actualizado para asegurar que no quede obsoleto debido a los cambios en la arquitectura o en el diseo del nuevo sistema. Implementar los Componentes El propsito de este Workflow de detalle es:

Desarrollar el cdigo fuente Adaptar los componentes existentes para que trabajen con los nuevos componentes creados Compilar, linkeditar y efectuar las pruebas unitarias Evaluar el cdigo fuente contra las guas de programacin identificadas en el proyecto Identificar los defectos en el diseo y retroalimentar el trabajo en el diseo Corregir los defectos del cdigo identificados durante el diseo 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 Implementacin debera estar unida muy de cerca al Diseo. Comprende las siguientes actividades: Implementar los Elementos de Diseo. Producir una implementacin por parte del diseo (tal como una Clase de Diseo, Subsistema de Diseo o Realizacin de Caso de Uso) o corregir uno o ms defectos. El resultado es el cdigo fuente o actualizaciones al cdigo fuente en la forma de Elementos de Implementacin.

- 37 -

Analizar el Comportamiento en Run-time. Comprender el comportamiento de un componente durante su ejecucin. Identificar comportamientos anmalos y cualquier accin correctiva requerida. Implementar los Elementos de Pruebas. Implementar la funcionalidad especializada para soportar los requerimientos especficos de pruebas. Implementar las Pruebas del Desarrollador. Implementar una o ms pruebas que permitan la validacin de los componentes individuales a travs de su ejecucin fsica. Desarrollar las pruebas que puedan ser ejecutadas junto con otras pruebas como parte de una infraestructura de pruebas ms grande. Ejecutar las Pruebas del Desarrollador. Verificar la especificacin de una unidad. Verificar la estructura interna de una unidad. Revisar el Cdigo. Verificar la implementacin. Planificar la Integracin de los Subsistemas. Planificar el orden en el cual los elementos contenidos en un subsistema de implementacin debern ser integrados.

El artefacto principal producido es el Componente. Integrar cada Subsistema El propsito de este Workflow de detalle es integrar los componentes nuevos y modificados en la nueva versin del subsistema de implementacin. La integracin consiste de Construcciones mltiples. Cada Construccin pasa por las Pruebas de Integracin. Luego de las pruebas, el subsistema de implementacin est listo para la integracin del subsistema (ver detalles abajo). Comprende las siguientes actividades: Implementar las Pruebas del Desarrollador. Implementar una o ms pruebas que permitan la validacin de los componentes individuales a travs de su ejecucin fsica. Desarrollar las pruebas que puedan ser ejecutadas junto con otras pruebas como parte de una infraestructura de pruebas ms grande. Ejecutar las Pruebas del Desarrollador. Verificar la especificacin de una unidad. Verificar la estructura interna de una unidad. Integrar los Subsistemas. Integrar los elementos en un subsistema de implementacin, luego enviarlo para su integracin en el sistema.

Los principales artefactos producidos son la Construccin y el Subsistema de Implementacin. Integrar el Sistema El propsito de este Workflow de detalle es:

Integrar el sistema, de acuerdo al Plan de Integracin de Construcciones, aadiendo los subsistemas de implementacin. Crear Construcciones del nuevo sistema Efectuar las pruebas de integracin del nuevo sistema

La Integracin a menudo envuelve un alto grado de automatizacin, 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 implementacin por pedazos en una construccin (build).

El artefacto principal producido es la Construccin. 3.4.2 Configuracin y Notas sobre el Workflow de Implementacin Cada actividad en el Workflow de Implementacin es esencial para una implementacin exitosa. Ninguna actividad debe removerse del Workflow de Implementacin. 3.4.3 Artefactos para la Implementacin Los Artefactos para la Implementacin capturan y presentan la realizacin de la solucin presentada en el Workflow de Anlisis y Diseo. La Tabla 11 identifica los artefactos que deben producirse durante el Workflow de Implementacin. Tabla 11. Artefactos para el Workflow de Implementacin
Artefactos
Incep Construccin

Creado/Revisado
Elab X Const X Trans X

Revisar Detalles
Formal - Externo

Herramientas Usadas
Rational Rose

Por este artefacto se entiende al Prototipo o Producto, segn la fase en que se encuentre el proyecto, resultante de cada iteracin. 3.4.4 Notas sobre los Artefactos para la Implementacin Cuando la Construccin 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 debern ser comprados. No incluye: Componente (Component), Modelo de Implementacin (Implementation Model), Subsistema de Implementacin (Implementation Subsystem), Plan de Integracin de Construcciones (Build Integration Plan). 3.4.5 Reportes para la Implementacin Ningn reporte ser producido durante el Workflow de Implementacin. Sin embargo, se efectuarn revisiones informales del cdigo. 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 validacin de los supuestos hechos en las especificaciones de diseo y los requerimientos a travs de demostraciones concretas Validando las funciones del producto de software segn sean diseadas 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 travs del uso de un proceso iterativo y de herramientas. Un enfoque iterativo para probar permite a la organizacin tratar las pruebas casi de la misma forma que el desarrollo de software es enfocado. Cada Construccin de software es un objetivo para las pruebas. Segn se vayan produciendo nuevas Construcciones, el cuerpo de pruebas ser aadido y refinado. Eventualmente, todas las pruebas en el cuerpo de pruebas sern acumuladas de tal manera que pueden ser usadas para las posteriores pruebas de regresin en el ciclo de vida del desarrollo de software. Este enfoque permite a una organizacin identificar posibles riesgos al inicio de un proyecto, reducir el costo de corregir fallas enfocando los recursos cuando y donde tendrn 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 segn va progresando el proyecto. Estrategia de Pruebas La Estrategia de Pruebas presenta el enfoque recomendado para las Pruebas de la Aplicacin, es decir, describe el cmo ser probado los requerimientos funcionales y no funcionales del sistema. Las consideraciones principales para la estrategia de pruebas son la tcnicas a usarse y los criterios para saber cundo las pruebas estn completas. Adems de las consideraciones que describimos a continuacin, provistas para cada tipo de prueba, las pruebas slo 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 debern ser probados como sistemas separados. Estos sistemas debern ser probados sin las aplicaciones (como la interfase a los datos). Se deber hacer una investigacin adicional en el DBMS para identificar las herramientas y tcnicas que puedan existir para soportar las pruebas identificadas a continuacin:

Objetivo de la Asegurar que los mtodos de acceso y los procedimientos de Base

- 40 -

Prueba: Tcnica:

de Datos funcionan apropiadamente y sin corrupcin de datos.


Invocar a cada mtodo de acceso y procedimiento de Base de Datos con datos vlidos e invlidos (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 ledo los datos correctos (por las razones correctas) Todos los mtodos de acceso y procedimientos de Base de Datos funcionan tal como fueron diseados y que no hay corrupcin de datos. 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 debern ser invocados manualmente. Deber usarse Bases de Datos pequeas (con un nmero de limitado de registros) para mejorar la visibilidad de cualquier evento que no sea aceptable.

Criterios de Finalizacin: Consideraciones Especiales:

Pruebas de la Aplicacin Las pruebas a la aplicacin 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 aceptacin, procesamiento y lectura apropiada de los datos y la implementacin apropiada de las reglas del negocio. Este tipo de pruebas se basan en pruebas de caja negra, es decir, verificando la aplicacin (y sus procesamientos internos) por medio de interactuar con la aplicacin va el GUI y analizando el output (resultados). A continuacin identificamos un bosquejo de las pruebas recomendadas para cada aplicacin: Objetivo de la Asegurar la navegacin de la aplicacin, entrada de datos, Prueba: procesamiento y lectura apropiados. Tcnica:

Ejecutar cada Caso de Uso, flujo de Caso de Uso o funcin usando datos vlidos e invlidos para verificar lo siguiente: o Los resultados esperados ocurren cuando se usa datos vlidos. o El error o mensaje de advertencia apropiado es mostrado cuando se usa datos invlidos. o Cada regla del negocio est aplicada apropiadamente. Todas las pruebas planeadas han sido ejecutadas.

Criterios de Finalizacin:

- 41 -

Todos los defectos identificados han sido corregidos. Para ejecutar estas pruebas podra ser necesario el acceso a las instalaciones de los stakeholders.

Consideraciones Especiales:

Pruebas del Ciclo del Negocio Las Pruebas del Ciclo del Negocio deben emular las actividades en el sistema en algn momento. Se debe identificar un perodo de tiempo, tal como un mes y se deben ejecutar las transacciones y actividades que ocurriran durante ese mes. Esto incluye todo los ciclos y eventos diarios, semanales y mensuales que son sensitivos a las fechas. Objectivo de la Asegurar que los procesos de la aplicacin y de background Prueba: funcionan de acuerdo a los plazos y modelos del negocio requeridos. Tcnica:

Las pruebas simularn varios ciclos del negocio por medio de efectuar lo siguiente: o Las pruebas usadas para probar las funciones de la aplicacin debern ser modificadas / mejoradas para incrementar el nmero de veces que cada funcin es ejecutada para simular varios usuarios diferentes durante un perodo especfico de tiempo. o Todas las funciones sensitivas a fechas y horas sern ejecutadas usando perodos de fechas y horas vlidos e invlidos. o Todas las funciones que ocurren en un horario peridico sern ejecutadas / lanzadas en el momento apropiado. Las pruebas se efectuarn usando daos vlidos e invlidos para verificar lo siguiente: o Los resultados esperados ocurren cuando se usa datos vlidos o El error o mensaje de advertencia apropiado es mostrado cuando se usa datos invlidos . Todas las pruebas planeadas han sido ejecutadas. Todos los defectos identificados han sido corregidos. Eventos basados en fechas del sistema podran requerir actividades especiales de soporte.

Criterios de Finalizacin: Consideraciones Especiales:

Pruebas de Interfase con el Usuario Las Pruebas de Interfase con el Usuario verifican una interaccin 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 navegacin apropiados a travs de las funciones de la aplicacin. Adems, las Pruebas de la UI asegura que los objetos dentro de la UI funcionan como se espera. Objetivo de la Verificar lo siguiente: Prueba: La navegacin a travs de la aplicacin refleja las funciones del negocio y los requerimientos apropiadamente, incluyendo ventana a ventana, campo a campo y el uso de los mtodos de accceso (teclas Tab, movimientos del mouse, teclas aceleradoras). Los objetos de ventana y sus caractersticas, tales como mens, tamao, posicin, estado y foco estn de acuerdo a los estndares. Tcnica: Crear / modificar las pruebas para cada ventana para verificar la navegacin apropiada y los estados de los objetos para cada ventana y objeto de la aplicacin. Cada ventana verificada exitosamente para permanecer consistente con la versin benchmark o dentro del estndar aceptable.

Criterios de Finalizacin: Consideraciones Especiales:

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 funcin a ciertas condiciones como carga de trabajo o configuraciones de hardware. Nota: Las Transacciones mencionadas seguidamente se refieren a transacciones del negocio lgicas. Estas transacciones son definidas como funciones especficas que un usuario final del sistema espera ejecutar usando la aplicacin, tal como aadir o actualizar un registro. Objetivo de la Validar el Tiempo de Respuesta del Sistema para transacciones o Prueba: funciones del negocio designadas bajo las siguientes condiciones:

- 43 -

Tcnica:

Volumen normal anticipado Volumen en el peor de los casos Usar los Procedimientos de Prueba desarrollados para las Pruebas de la Aplicacin. Modificar los archivos de datos (para aumentar el nmero de transacciones) o modificar scripts para aumentar el nmero de veces que cada transaccin ocurra. Los scripts deben ejecutarse en una mquina (el mejor de los casos para evaluar un solo usuario, una sola transaccin) y sern repetidos con mltiples clientes (virtuales o reales). Una sola Transaccin / Un solo usuario: Finalizacin exitosa de los scripts de prueba sin ninguna falla y dentro del lapso de tiempo esperado / requerido (por transaccin) Mltiples transacciones / Mltiples Usuarios: Finalizacin 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 mtodos 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 mltiples clientes fsicos, cada uno corriendo scripts de prueba para poner una carga en el sistema. Las Pruebas de Performance deben efectuarse en una mquina 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 tamao real o escaladas equitativamente.

Criterios de Finalizacin:

Consideraciones Especiales:

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 ms all de la carga mxima esperada. Adicionalmente, las Pruebas de Carga evalan las caractersticas de performance (tiempos de respuesta, ratios de transaccin y otros asuntos sensitivos al tiempo). Nota: Las Transacciones mencionadas seguidamente se refieren a transacciones del negocio lgicas. Estas transacciones son definidas como funciones especficas que un

- 44 -

usuario final del sistema espera ejecutar usando la aplicacin, tal como aadir o actualizar un registro. Objetivo de la Verificar el tiempo de respuesta del Sistema para transacciones o Prueba: casos del negocio designados bajo condiciones variables de carga de trabajo. Tcnica:

Usar los Procedimientos de Prueba desarrollados para las Pruebas de la Aplicacin. Modificar los archivos de datos (para aumentar el nmero de transacciones) o modificar scripts para aumentar el nmero de veces que cada transaccin ocurra. Mltiples transacciones / Mltiples Usuarios: Finalizacin 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 mquina 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 tamao real o escaladas equitativamente.

Criterios de Finalizacin:

Consideraciones Especiales:

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 tambin podra 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 lgicas. Estas transacciones son definidas como funciones especficas que un usuario final del sistema espera ejecutar usando la aplicacin, tal como aadir o actualizar un registro. Objetivo de la Verificar que el sistema y el software funcionan apropiadamente y Prueba: sin errores bajo las siguientes condiciones de esfuerzo:

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

- 45 -

DASD) Nmero mximo (actual o fsicamente posibles) de clientes conectados (o simulados) Mltiples 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) Use las pruebas desarrolladas para las Pruebas de Performance. Para probar recursos limitados, las pruebas deben ejecutarse en una sola mquina, la RAM en el servidor debera ser reducida (o limitada). Para el resto de pruebas de esfuerzo podra 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 lmites del sistema son alcanzados / excedidos sin que falle el Sistema (o las condiciones en que ocurren las fallas del Sistema estn fuera de las condiciones especificadas). Forzar la red podra requerir herramientas de red para cargar la red con mensajes / paquetes. La RAM usada por el sistema sera reducida temporalmente para restringir el espacio disponible para el crecimiento de la Base de Datos. Sincronizacin de los clientes simultneos que accesan a los mismos registros / cuentas.

Tcnica:

Criterios de Finalizacin:

Consideraciones Especiales:

Pruebas de Volumen Las Pruebas de Volumen someten al software a grandes volmenes de datos para determinar si se alcanzan los lmites que causen que el software falle. Las Pruebas de Volumen tambin identifican la carga mxima continua que el Sistema puede manejar por un perodo 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 usara una gran Base de Datos de prueba y chequeara que el software se comport normalmente y produjo el reporte correcto.

Objetivo de la Verificar que la aplicacin / sistema funcionan exitosamente bajo Prueba: los siguientes escenarios de alto volumen:

Nmero mximo de clientes (actuales o fsicamente posibles) conectados (o simulados) todos ejecutando la misma funcin del

- 46 -

negocio y en el peor de los casos (performance) por un perodo extendido de tiempo. Se ha alcanzado el tamao mximo de Base de Datos (real o escalada) y muchas transacciones de consultas / reportes son ejecutadas simultneamente. Usar las pruebas desarrolladas para las Pruebas de Performance. Se usarn 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 perodo extendido de tiempo. Se ha creado una Base de Datos de tamao mximo (actual, escalada o llenada con datos representativos) y muchos clientes usados para correr transacciones de consultas / reportes simultneamente por perodos extendidos de tiempo. Todas las pruebas planeadas han sido ejecutadas y los lmites del sistema son alcanzados / excedidos sin que falle el Sistema (o las condiciones en que ocurren las fallas del Sistema estn fuera de las condiciones especificadas). Qu perodo de tiempo ser considerado un tiempo aceptable para condicione de alto volumen (como se mencion arriba)?

Tcnica:

Criterios de Finalizacin:

Consideraciones Especiales:

Pruebas de Seguridad y Control de Acceso Las Pruebas de Seguridad y Control de Acceso se enfocan en dos reas clave: Seguridad de la Aplicacin, incluyendo acceso a los datos Seguridad del Sistema, incluyendo login local y remoto al sistema La seguridad de la aplicacin asegura que, basado en la seguridad deseada, los usuarios sean restringidos a funciones especficas o estn limitados en los datos que estn disponibles para ellos. Por ejemplo, los encargados en una tienda estn permitidos de ingresar datos y crear nuevas facturas; pero slo 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, slo el usuario dos puede generar reportes. La seguridad del sistema asegura que slo aquellos usuarios que tiene permiso para accesar al sistema puedan accesar a las aplicaciones y slo a travs de los controles apropiados. Objetivo de la Seguridad de Funcin / Datos: Verificar que el usuario slo puede Prueba: accesar a aquellas funciones / datos a las que su tipo de usuario se le ha otorgado permiso. Seguridad del Sistema: Verificar que slo aquellos usuarios con

- 47 -

acceso al sistema y a las aplicaciones puedan accesarlas. Tcnica:

Seguridad de Funcin / 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 especficas 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 estn disponibles o negados apropiadamente. Acceso al Sistema. Para cada tipo de usuario conocido la funcin / datos apropiados estn disponibles y todas las transacciones funcionan como se espera y corrieron previamente en las Pruebas de la Aplicacin. El acceso al sistema debe ser revisado / discutido con el administrador de Base de Datos. Estas pruebas podran no ser requeridas si es que son funcin del DBMS.

Criterios de Finalizacin:

Consideraciones Especiales:

Pruebas de Cadas / Recuperacin del Sistema Las Pruebas de Cadas / Recuperacin del Sistema aseguran que una aplicacin o el sistema puedan caer y recuperarse exitosamente por una variedad de mal funcionamiento de hardware, software o red, sin prdida indebida de datos o integridad de datos. Las Pruebas de Cadas / Recuperacin del Sistema aseguran que, para aquellos sistemas que deben mantenerse corriendo, cuando ocurra una condicin de cada, los sistemas alternos o de backup se activen apropiadamente sin prdida de datos o e transacciones. Las Pruebas de Recuperacin es un proceso de pruebas antagnico en el cual la aplicacin o el sistema son expuestos a condiciones extremas (o condiciones simuladas) tales como fallas de I/O (scanner de cdigo de barras) o punteros / claves invlidas de Base de Datos. Los procesos de recuperacin son invocados y la aplicacin / sistema es monitoreado y / o inspeccionado para verificar que se ha efectuado la recuperacin apropiada de la aplicacin / sistema y los datos. Objetivo de la Verificar que los procesos de recuperacin (manual o automtica) restauraron la Base de Datos, aplicaciones y el sistema Prueba: apropiadamente a un estado conocido. En las pruebas se deben incluir los siguientes tipos de condiciones:

Interrupcin de poder en el cliente Interrupcin de comunicacin en la red

- 48 -

Ciclos incompletos (interrupcin de procesos de filtrado de datos, procesos de sincrona de datos interrumpidos) Punteros / claves invlidos de Base de Datos Elementos de datos invlidos / corruptos en la Base de Datos

Tcnica:

Las pruebas creadas para las Pruebas de la Aplicacin 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:

Interrupcin de poder del cliente: apague el PC Interrupcin de comunicacin en la red: simular o iniciar prdida de comunicacin con la red (desconecte fsicamente los cables de comunicacin 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 recuperacin. Las pruebas para ciclos incompletos utilizan la misma tcnica descrita lneas 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 debern ser corrompidos manualmente (por medio de herramientas de Base de Datos). Transacciones adicionales debern ser ejecutadas usando las pruebas de Pruebas de la Aplicacin y Pruebas del Ciclo del Negocio y se ejecutarn ciclos completos. Criterios de Finalizacin: En todos los caso, la aplicacin, la Base de Datos y el sistema deben regresar, al completarse el proceso de recuperacin, a un estado deseable y conocido. Este estado incluye corrupcin 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 prdida de poder o de comunicacin) podran no ser deseables o factibles. Se podra requerir mtodos alternativos, tales como herramientas de diagnstico. Se requiere recursos de los grupos de Sistemas, Base de Datos y Redes. Estas pruebas deben ejecutarse despus de las horas de trabajo

Consideraciones Especiales:

- 49 -

en una o ms mquinas aisladas.

Pruebas de Configuracin Las Pruebas de Configuracin verifican la operacin del software en diferentes configuraciones de hardware y software. En la mayora 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 varan. 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. Objetivo de la Validar y verificar que la aplicacin funciona apropiadamente en Prueba: las estaciones cliente o terminales prescrito. Tcnica:

Usar los scripts de Pruebas de la Aplicacin. 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 combinacin de transacciones, que finalicen exitosamente sin fallas. Qu aplicaciones PC estn disponibles y accesibles en el cliente? Qu aplicaciones son usadas tpicamente? Con qu datos estn corriendo las aplicaciones (por ejemplo, hojas electrnicas grandes abiertas en Excel, documentos e 100 pginas en Word). Tambin debera documentarse todos los sistemas, servidores de red, Bases de Datos, etc. como parte de esta prueba.

Criterios de Finalizacin: Consideraciones Especiales:


Pruebas de Instalacin Las Pruebas de Instalacin tienen dos propsitos. El primero es asegurar puede ser instalado en todas las configuraciones posibles, tales como una instalacin nueva, una actualizacin y una instalacin completa o instalacin adecuada y, bajo condiciones normales y anormales. Las condiciones anormales incluyen espacio en disco insuficiente, falta de privilegios para crear directorios, etc. El segundo propsito es verificar que, una vez instalado, el software opera correctamente. Esto, usualmente, significa correr un nmero de pruebas que fueron desarrolladas para las Pruebas de Aplicacin.

- 50 -

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

Nueva instalacin, una nueva mquina en la que nunca se ha instalado. Actualizar una mquina en la que, previamente, se ha instalado la misma versin. Actualizar una mquina en la que, previamente, se ha instalado una versin antigua. Manualmente o desarrollar scripts para validar la condicin de la mquina objetivo (nueva nunca instalado, misma versin o versin antigua ya instalada). Lanzar / ejecutar la instalacin. Usando un subconjunto de scripts de prueba de las Pruebas de Integracin o Pruebas de la Aplicacin, correr las transacciones. Las transacciones se ejecutaron exitosamente sin fallas. Qu transacciones sern consideradas para tener una prueba de confianza de que la aplicacin ha sido instalada exitosamente y que no se ha perdido componentes del software?

Tcnica:

Criterios de Finalizacin: Consideraciones Especiales:

El propsito de este workflow del RUP es:


Verificar la interaccin entre objetos Verificar la interaccin 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 Anlisis y Diseo captura el input principal para identificar cuales pruebas efectuar describiendo cmo desarrollar un diseo. El Workflow de Implementacin produce las Construcciones de software del modelo de implementacin que es probado por medio del Workflow de Pruebas. Dentro de una iteracin, 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 -

Disear las Pruebas Implementar las Pruebas Ejecutar las Pruebas en la etapa de Integracin 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 Diseador de Pruebas genera uno o ms 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 propsito de este Workflow de detalle es:

Coleccionar y analizar la informacin de planificacin 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 especfica de cosas, incluyendo eventos y artefactos, que servirn para motivar las pruebas en esta iteracin. Acordar la Misin. Negociar el uso ms efectivo de los recursos de pruebas para cada iteracin. Acordar un apropiado y alcanzable conjunto de objetivos y entregables para la iteracin. Obtener Compromiso de Pruebas. Promover la creacin de software que se pueda probar y que soporte las necesidades del esfuerzo de pruebas. Promover y soportar el uso de las tcnicas y herramientas automatizadas apropiadas. Evaluar y Promover la Calidad. Identificar y abogar por la resolucin de los defectos que tengan un impacto serio en detrimento de la calidad del software. Monitorear el progreso de los cambios y soportar la finalizacin de los cambios que mejoren la calidad del software al nivel requerido. Abogar por la resolucin en tiempo de los defectos que impiden o daan el esfuerzo de las pruebas. Evaluar y Mejorar el Esfuerzo de las Pruebas. Hacer una evaluacin de la productividad, efectividad y finalizacin del esfuerzo de las pruebas. Hacer ajustes al esfuerzo de pruebas tanto tcticas como estratgicas 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 Evaluacin y Seguimiento. Definir la estrategia de evaluacin para el esfuerzo de pruebas. Pata definir los requerimientos de seguimiento y proteccin. Identificar las Ideas de Pruebas. Identificar las ideas de pruebas que podran ser exploradas para evaluar la calidad aceptable de los elementos objetivo de las pruebas. Identificar un nmero 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. Disear las Pruebas El Workflow de detalle de Disear las Pruebas es donde el Modelo de Pruebas, los Procedimientos de Prueba, y los Casos de Prueba son identificados, descritos y generados por el Diseador de Pruebas. El Workflow de detalle de Disear las Pruebas es efectuado para asegurar que la implementacin de las pruebas y los esfuerzos de ejecucin estn bien organizados y son exitosos. El propsito de este Workflow de detalle es:

Identificar un conjunto de Casos de Prueba verificable para cada Construccin Identificar el Procedimiento de Pruebas que muestra cmo los Casos de Prueba sern realizados

Comprende las siguientes actividades: Definir el Enfoque de las Pruebas. Identificar cada tcnica especfica que ser

- 53 -

empleada para posibilitar la prueba deseada. Bosquejar el trabajo de cada tcnica 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 evaluacin necesarios para el esfuerzo de pruebas. Identificar los Mecanismos de Pruebas. Identificar los mecanismos generales de la solucin tcnica necesaria para facilitar el enfoque de prueba. Bosquejar el alcance general y las caractersticas 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 fsicos de la infraestructura de la implementacin de pruebas para permitir probar bajo cada Configuracin de Ambiente de Prueba. Definir los Detalles de las Pruebas. Definir las condiciones individuales necesarias para realizar una idea de prueba en un contexto especfico. Identificar puntos de observacin 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 Anlisis 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 Disear las Pruebas son implementados. Aqu, el Diseador 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 especfica, las cuales no son necesariamente el objetivo de la prueba; pero interactuar con el objetivo de la prueba, estn implementndose y probndose. El propsito de este Workflow de detalle es:

Crear o generar scripts de pruebas reusables Mantener rastreabilidad de los artefactos de las pruebas de implementacin 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 ms artefactos de prueba que permita la validacin del producto de software a travs de la ejecucin fsica. Desarrollar las pruebas que puedan ser ejecutadas en conjunto con otras pruebas como parte de una infraestructura de pruebas ms 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 Integracin de Pruebas Las Pruebas de Ejecucin en el Workflow de detalle de Etapa de Integracin de Pruebas es donde el testeador ejecuta las pruebas de integracin varias veces hasta que se determina que el sistema completo, en trminos de la iteracin actual, ha sido integrado exitosamente. El propsito de este Workflow de detalle es asegurar que:

El ensamblado de la colaboracin de los componentes del sistema se ha conseguido Se ha probado apropiadamente la funcionalidad aadida despus de la ltima Construccin Se ha efectuado las pruebas de regresin apropiadas a la funcionalidad que exista 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 evaluacin exitosa del producto. Analizar las fallas en las Pruebas. Investigar los detalles del Log de Pruebas y analizar las fallas que ocurrieron durante la implementacin y ejecucin. 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 especfico. Identificar puntos de observacin 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. Evaluar y Promover la Calidad. Identificar y abogar por la resolucin de los defectos que tengan un impacto serio en detrimento de la calidad del software. Monitorear el progreso de los cambios y soportar la finalizacin de los cambios que mejoren la calidad del software al nivel requerido. Abogar por la resolucin en tiempo de los defectos que impiden o daan el esfuerzo de las pruebas.

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 trminos de la iteracin actual, funciona apropiadamente y

- 55 -

cumple con los criterios de fin exitoso de las pruebas El propsito de este Workflow de detalle es asegurar que:

El sistema completo funciona como se esperaba La funcionalidad aadida despus de la ltima Construccin trabaja como se esperaba La funcionalidad que exista en Construcciones previas an trabaja como se esperaba

Comprende las mismas actividades que el workflow de detalle anterior: Ejecutar las Pruebas en la etapa de Integracin de Pruebas. El principal artefacto producido es el documento Resultado de Pruebas. Evaluar las Pruebas El Workflow de detalle de Evaluacin de las Pruebas es donde el Diseador de Pruebas revisar y valorizar la calidad de los objetivos de prueba deseados y el proceso de pruebas como un todo. El Sumario de Evaluacin de Pruebas es generado luego de que el Diseador 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 trminos de mtricas de cobertura y calidad. En la mayora de los casos, esto significa enfocarse en el esfuerzo de apoyar al equipo del proyecto a alcanzar los objetivos del Plan de iteracin que se aplica al ciclo de pruebas actual. El propsito 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 Evaluacin de Pruebas

Comprende las siguientes actividades: Evaluar y Mejorar el Esfuerzo de las Pruebas. Hacer una evaluacin de la productividad, efectividad y finalizacin del esfuerzo de las pruebas. Hacer ajustes al esfuerzo de pruebas tanto tcticas como estratgicas y mejorar la efectividad. Evaluar y Promover la Calidad. Identificar y abogar por la resolucin de los defectos que tengan un impacto serio en detrimento de la calidad del software. Monitorear el progreso de los cambios y soportar la finalizacin de los cambios que mejoren la calidad del software al nivel requerido. Abogar por la resolucin en tiempo de los defectos que impiden o daan el esfuerzo de las pruebas. Identificar las Ideas de Pruebas. Identificar las ideas de pruebas que podran ser exploradas para evaluar la calidad aceptable de los elementos objetivo de las pruebas. Identificar un nmero 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 Evaluacin de Pruebas (Test Evaluation Summary) y los Requerimientos de Cambio (Change Request). 3.5.2 Configuracin 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 informacin 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
Incep Caso de Prueba Plan de Pruebas/ Procedimientos Resultados de Pruebas Script de Pruebas las X

Creado / Revisado
Elab X X Const Trans

Revisar Detalles
Informal - Interno Formal - Externo o Prueba Interna X X Formal - Interno Informal - Interno

Herramientas Usadas
Test Manager Manager Test Manager Robot, Manual Test

X
X X X

3.5.4 Notas sobre los Artefactos para Pruebas La metodologa 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 Anlisis de Carga de Trabajo (Workload Analysis Document). El Modelo de Pruebas es excluido porque es simplemente una acumulacin 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 adicin al Modelo de Pruebas, no ser producido. El Subsistema de Pruebas es un artefacto que sera til como una herramienta organizacional en proyectos grandes. La distincin entre los Subsistemas de Pruebas no es una necesidad en proyectos de tamao promedio. Igualmente, el Documento de Anlisis de Carga de Trabajo sera til para pruebas de performance antes del despliegue en proyectos grandes,; pero no es una necesidad en proyecto de tamao 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 informacin cubierta por estos dos artefactos individualmente puede ser representada casi completamente en el Plan de Pruebas. Las instrucciones para preparacin, ejecucin y evaluacin de las pruebas simplemente puede ser aadida 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 Evaluacin de Pruebas (Test Evaluation Summary). El Script de las Pruebas es opcional debido a que no siempre se efectan pruebas automatizadas. 3.5.5 Reportes para las Pruebas Ningn reporte ser producido durante Workflow de Despliegue. Los artefactos producen la necesaria informacin 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 propsito 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 instalacin en el cliente Se entrega un instalador (generado con algn producto de compresin e instalacin) Accesar al software por la Internet

Cualquiera que sea el mtodo 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 Administracin de Configuracin y Cambios es usado para

- 58 -

manejar los requerimientos de cambio que son generados como resultado de las pruebas Beta y las pruebas de aceptacin El Workflow de Despliegue consiste de los siguientes Workflows de detalle: Planificar el Despliegue Desarrollar Material de Soporte Manejar las Pruebas de Aceptacin 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 propsito de este workflow del RUP es:

Planificar cmo y cundo 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 cmo y cundo 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 construccin/producto. La lista incluye tems de configuracin del software, documentos y scripts de instalacin. En el caso de productos empacados la Lista de Materiales necesitar identificar las partes de trabajo de arte e tems de empaquetamiento que maquillarn al producto final.

Desarrollar Material de Soporte El propsito 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 instalacin, operacin y mantenimiento para el sistema desplegado. Tambin 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 online, 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 Aceptacin El propsito de este Workflow de detalle es asegurar que el producto haya sido probado adecuadamente antes de su liberacin. Es identificado y confirmado que el producto cumple con los requerimientos. El producto es instalado en la plataforma de pruebas y se le efectan las pruebas para generar resultados de las pruebas. Si los resultados de las pruebas muestran anomalas, se levantan requerimientos de cambio por su inmediata atencin y resolucin. 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 tcnico 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 Aceptacin. Asegurar que el producto desarrollado cumpla los criterios de aceptacin tanto en el ambiente de desarrollo como en el ambiente de instalacin 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 propsito 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 caractersticas nuevas y cambios en el release. Las Notas del release tambin deben describir las fallas conocidas y limitaciones del producto. Desarrollar los Artefactos de Instalacin. Producir todo el software requerido para instalar y desinstalar el producto rpidamente, fcilmente y seguramente sin afectar a otras aplicaciones o caractersticas del sistema. Crear la Unidad de Despliegue (desde la Administracin de Configuracin). Una Unidad de Despliegue consiste de una Construccin (una coleccin de componentes ejecutables), documentos (material de soporte para el usuario final y las Notas del Release) y los artefactos de instalacin. El propsito 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 propsito de este Workflow de detalle es describir las actividades necesarias para crear el instalador y poner la unidad de despliegue, los scripts de instalacin y el manual del usuario en un paquete para distribucin masiva. Comprende las siguientes actividades: Liberar para Manufactura. Producir en masa una versin 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 inspeccin del primer artculo. 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 propsito de crear un trabajo de arte para el producto es publicarlo directamente en un medio magntico o en la web. El trabajo de arte deber reforzar los estndares de marca del producto establecido por el grupo

- 61 -

de mercadeo de la compaa, para crear el mensaje apropiado para el consumidor. Proveer Acceso al Site de Descarga El propsito 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 envo segn 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 propsito de este Workflow de detalle es crear una prueba Beta para solicitar retroalimentacin al producto de parte de un grupo de usuarios finales y revisar esta retroalimentacin e las pruebas Beta. Las pruebas Beta tambin son conocidas como Pruebas de Aceptacin 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 propsitos. 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 propsitos se han alcanzado.

3.6.2 Configuracin 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 mayora no necesita efectuar estos workflows de detalle. 3.6.3 Artefactos para el Despliegue Los artefactos de Despliegue capturan y presentan informacin relativa a posicionar el sistema, presentado en el Workflow de Implementacin, dentro del ambiente de produccin. La Tabla 14 identifica los artefactos que deben ser producidos durante el Workflow de Despliegue. Tabla 14. Artefactos para el Workflow de Despliegue
Artefactos
Incep Relacin de Materiales Plan de Despliegue Producto X

Creado/Revisado
Elab Const X X Trans X X X

Revisar Detalles
Informal Informal Formal-Externo

Herramientas Usadas
MS Word MS Word MS Word

- 62 X X X X Formal - Interno Formal - Externo MS Word MS Word

Notas del Release Materiales de Entrenamiento

Por Materiales de Entrenamiento, se entender el Manual del Usuario y el Manual Tcnico. 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 Instalacin (Installation Artifacts). 3.6.5 Reportes para el Despliegue Ningn reporte ser producido durante Workflow de Despliegue. Los artefactos producen la necesaria informacin workflow del RUP. 3.7 ADMINISTRACIN DE CONFIGURACIN Y CAMBIOS La mayora 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 fcil de cambiar, un proyecto est continuamente vulnerable a la introduccin inadvertida de incompatibilidades (errores de regresin) y fallas resultantes de la aplicacin a menos que una disciplina constante sea aplicada. El control de versiones, sin embargo, es slo un componente de la Administracin de Configuracin y Cambios (Configuration & Change Management -CCM-). Un buen sentido de ordenamiento es provisto por esta lista de las mejores prcticas 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 geogrficamente) 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 Administracin de Configuracin y Cambios La Administracin de Configuracin y Cambios incluye las siguientes funciones principales:

- 63 -

Administracin de la Configuracin (Configuration Management -CM-) Administracin de Requerimientos de Cambio (Requerimiento de Cambio Management -CRM-)

Administracin de la Configuracin (Configuration Management -CM-) La Administracin de la Configuracin (CM) controla los numerosos artefactos producidos por los miembros del equipo del proyecto. RUP/Easy recomienda traer bajo CM slo aquellos artefactos que no pueden ser derivados fcilmente desde otros artefactos administrados y versionados; pero es ms seguro errar en el lado controlado. Cuando un artefacto es puesto bajo Administracin de la Configuracin su versin actual, sus dependencias, las herramientas usadas para trabajarlo, quien lo cre, cundo y porqu son todos registrados en su historia de cambios. Ms tarde cuando el artefacto es cambiado, las dependencias del artefacto deben ser revisadas. CM maneja este proceso. CM es usado a travs del ciclo de vida del proyecto despus de la fase de Incepcin. Usualmente, la ltima versin de un artefacto es la mejor para usar; pero no siempre. CM provee la habilidad de hacer uso de una copia de la versin especfica de un artefacto que no es la ltima versin. CM tambin provee la habilidad de reconstruir el proyecto tal como exista en muchos puntos histricos en el tiempo. En teora, 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 ms escalables y avanzados tal como el Rational ClearCase, es cual est basado en actividades y capaz de automatizar varios aspectos de CM. Administracin de Control de Cambios (Change Request Management -CRM-) La Administracin de Control de Cambios (CRM) es la captura y administracin 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 ms 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 aadir un requerimiento o simplemente para documentar el delta entre una iteracin y la siguiente.". Un Requerimiento de Cambio es creado por un Originador, quien provee un motivo raz o razn 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 revisin que puede incluir:

Un representante del usuario o experto en el tema que conoce la Visin del proyecto Un representante del fundador quien es un familiar con restricciones de presupuesto o financieras Un representante tcnico quien es versado en la tecnologa usada

- 64 -

Este equipo combina los requerimientos duplicados, clarifica detalles segn sea necesario y valoriza los impactos tcnicos, funcionales y econmicos 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 tambin 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 integracin, 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 despus de la Incepcin. 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 nmero de excelente herramientas de CRM. ClearQuest de Rational es una buena opcin si planea integrarse con otras herramientas de Rational. Adems de automatizar, lo que muchos consideran un proceso tedioso, una herramienta CRM manejada con una base de datos tambin provee otro gran beneficio: la habilidad de extraer informacin fcilmente acerca del progreso del proyecto, especialmente en las fases de Construccin y posteriores. Una buena herramienta de CRM permite que se pueda crear consultas ad-hoc fcilmente. 3.7.2 Vista general del Workflow de Administracin de Configuracin y Cambios A continuacin se muestra una Convencin para la Administracin de Configuracin. Definir las Prcticas de Identificacin de la Configuracin Tiene como propsito identificar y almacenar los artefactos en un repositorio seguro. La identificacin de la Configuracin es una pieza clave de la administracin de la configuracin y es definida como "un elemento de la administracin de la administracin de la configuracin que consiste en seleccionar las caractersticas fsicas en la documentacin tcnica ". En trminos de administracin de la configuracin de software, identificacin de la configuracin significa ser capaz de encontrar e identificar la versin correcta del cualquier artefacto del proyecto rpida y fcilmente. El impacto negativo de tener un sistema de identificacin de configuracin inefectivo es medido en trminos de tiempo perdido y calidad. Definir las Convenciones de Etiquetado de los Artefactos Las etiquetas (labels) identifican las versiones especficas de los artefactos. El conjunto de artefactos que constituyen una versin de un subsistema son, colectivamente e individualmente, identificables por una versin 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 convencin 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 A Identifica al Sistema Corresponde a un acrnimo de tres letras para los diversos artefactos usados en la creacin del Sistema o Subsistema. De acuerdo con la Tabla de Valores de <A> ms adelante. Corresponde a Release, Alpha o Beta Entero, corresponde al release principal (p. e. 1) Entero (opcional), corresponde al release menor Entero (opcional), corresponde a un release alternativo (patches, ports, etc.) Corresponde al nivel base (un release interno) Entero, para releases internos Tabla de Valores de <A> PLN REQ CAU MOD SRC INT TST DOC BIN Planes del Proyecto Archivos de Requerimientos Casos de Uso Archivos del Modelo Archivos de Cdigo Fuente Interfases Pblicas Scripts de Prueba y Resultados Documentacin (Usuario, Notas del Release) Ejecutables

SUBSISTEMA Identifica a cada Subsistema del Sistema

R|A|B <X> <Y> <Z> BL #

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 T2K_R2.0.BL16 T2K_R1.0.5 Release Beta 1.1 del sistema Thorn 2000 Baseline de sistema interno #16 del sistema Thorn 2000 planeado para crear el release 2 Release de mantenimiento del sistema Thorn 2000

Definir las Prcticas 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 gua en la prctica. 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 distincin 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 versin de todos los archivos y directorios en todos los subsistemas.

Como una gua general, se facilitar la administracin del release si se crea Sistemas Congelados en los hitos mayores y menores y Subsistemas Congelados segn sea requerido o con una frecuencia ms 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 Prcticas de Archivamiento El propsito 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 guas 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 informacin adicional cuando el medio actual va a ser almacenado. Por ejemplo: NMERO DE SERIE VOLUMEN 123456789 1 de 3

- 67 -

BVEDA FECHA DE ALMACENAMIENTO

B5 21-Junio-99

Toda la informacin relativa al producto debera ser mantenida en una base de datos para facilitar la liberacin 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, Distribucin y Contadores y de Construccin Mensual Reportes de Tendencia, Distribucin y Contadores y de Construccin Por Iteracin Reportes de Tendencia, Distribucin y Contadores y de Construccin y Descriptores de Versiones Por Fase Reportes de Tendencia, Distribucin y Contadores y de Construccin y Descriptores de Versiones Al finalizar el Proyecto Reportes de Tendencia, Distribucin y Contadores y de Construccin y Descriptores de Versiones

A continuacin 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 efecta 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 caractersticas nuevas, requerimientos de mejoras, defectos, cambios a los requerimientos, etc.) junto con informacin 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 informacin estar disponible para cualquier revisin y para el cierre final. Tablero de Control de Cambios (o Configuracin) (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 pequeo, 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. Reunin de Revisin del TCC La funcin de esta reunin es revisar los Requerimientos de Cambio enviados. Una revisin inicial del contenido del Requerimiento de Cambio es efectuada en la reunin para determinar si es un requerimiento vlido. Si lo es, entonces se determina si el cambio est dentro o fuera del alcance del(os) release(s) actual(es), basndose en la prioridad, cronograma,

- 68 -

recursos, nivel del esfuerzo, riesgo, severidad y cualquier otro criterio relevante segn sea determinado por el grupo. Esta reunin se hace, tpicamente, una vez por semana. Si el volumen de requerimientos de Cambio se incrementa sustancialmente o, segn se vaya acercando el fin del ciclo del release, la reunin se puede hacer tan frecuentemente cono sea necesario, inclusive diariamente. Los miembros tpicos de la Reunin de Revisin 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 podran ser considerados en base a las necesidades especficas de los temas a tratar. Formulario de Envo de Requerimientos de Cambio Este formulario es mostrado cuando el Requerimiento de Cambio est siendo enviado por primera vez. Slo 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 Administracin 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: 3.Revisar el RC: evala prioridad, 6. Aplicar los 7. Verificar los Cambios nuevo. cronograma, recursos, nivel de Cambios: aplica en la Construccin de los cambios y le Prueba: Prueba el 2. Actualizar el esfuerzo, riesgo, severidad. Si no es RC: actualizado prioritario pone al RC en estado de pone el estado de cambio. Si falla le pone con ms Pospuesto. Resuelto al RC y el estado de Falla en informacin lo enva a Prueba y lo retorna al 4.Cronogramar y Asignar el solicitada. Trabajo: Si es prioritario pone al RC Pruebas. Desarrollador. Si pasa en estado de Abierto y cronograma y las pruebas le pone el asigna el trabajo a un Desarrollador. estado de Verificado y lo retorna al Tablero de 5.Confirmar Duplicado o Rechazado: Si es un RC duplicado o ya ha sido Control de Cambios rechazado, le pone el estado de Mas Info y lo enva al Emisor por ms informacin. 8.Verificar los Cambios en la Construccin de Release: verifica que los cambios hayan sido aplicados en la construccin y Cierra el RC.

En un proyecto pequeo, 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 construccin de prueba y; el workspace de integracin para verificar los cambios en la construccin de release

En un proyecto pequeo, se podra aplicar los cambios slo en el de desarrollo y en del release. Descripcin de las actividades del proceso de Administracin de requerimientos de Cambio.
Actividad
Enviar el RC

Descripcin

Responsabilidad
Emisor

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 Revisin del TCC poniendo el Requerimiento de Cambio en estado de Enviado. La funcin de esta reunin es revisar los Requerimientos de Cambio Revisar el RC enviados. Una revisin inicial del contenido del Requerimiento de Cambio es efectuada en la reunin para determinar si es un requerimiento vlido. Si lo es, entonces se determina si el cambio est dentro o fuera del alcance del(os) release(s) actual(es), basndose en la prioridad, cronograma, recursos, nivel del esfuerzo, riesgo, severidad y cualquier otro criterio relevante segn sea determinado por el grupo. Si se sospecha que un Requerimiento de Cambio est Duplicado o Confirmar Rechazado como un requerimiento invlido ( p. e. error del Duplicado o operador, no reproducible, la manera en que trabaja, etc.) se asigna Rechazado un delegado del TCC para confirmar el Requerimiento de Cambio duplicado o rechazado y para obtener ms informacin del emisor , si fuera necesario. Si se necesita ms informacin (Mas Info) para evaluar un Actualizar el Requerimiento de Cambio o si un Requerimiento de Cambio est RC 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 informacin. El Requerimiento de Cambio es, entonces, reenviado a la cola de Revisin del TCC para consideracin de los nuevos datos. Cronogramar y Una vez que un Requerimiento de Cambio est Abierto, el Jefe del Proyecto asignar el trabajo al miembro del equipo apropiado Asignar el (dependiendo del tipo de requerimientos p. e. mejora, defecto, Trabajo cambio en la documentacin, defecto de prueba, etc.- podra ser un analista, un desarrollador, un testeador, un documentado tcnico, etc.) y hace las actualizaciones necesarias en el cronograma del proyecto. El miembro del equipo asignado efecta las actividades apropiadas Aplicar los definidas dentro del workflow apropiado del proceso (p. e. Cambios requerimientos, anlisis y diseo, implementacin, pruebas, despliegue) para hacer los cambios requeridos. Estas actividades incluirn 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. Luego que los cambios estn Resueltos por el miembro del equipo Verificar los asignado (analista, desarrollador, testeador, documentado tcnico, Cambios en la Construccin de etc.), los cambios son puestos en una cola de pruebas para que sean asignados a un testeador y Verificado en una construccin de prueba Prueba del producto.

TCC

Delegado del TCC

Emisor

Jefe del Proyecto

Miembro del Equipo Asignado

Testeador

- 70 -

Verificar los Cambios en la Construccin de Release

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

Estados y Transiciones para un Requerimiento de Cambio.


Estado
Enviado

Definicin
Este estado ocurre como resultado de 1) envo de un nuevo Requerimiento de Cambio, 2) actualizacin den un Requerimiento de Cambio existente o; 3) consideracin de un Requerimiento de Cambio Pospuesto para un nuevo ciclo del release. Los Requerimientos de Cambio son puestos en la cola de Revisin del TCC. No se asigna a un propietario como resultado de esta accin. El Requerimiento de Cambio es determinado como vlido; 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 Revisin del TCC. 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 Revisin del TCC o por el miembro de equipo asignado para resolverlo. Cuando el Requerimiento de Cambio es puesto en estado de Duplicado el nmero del Requerimiento de Cambio que est duplicando ser registrado (en el tab Attachments en ClearQuest). Un emisor inicialmente debera consultar la base de datos de Requerimientos de Cambio, para consultar por duplicados. Antes de enviarlo. Esto evitar pasos del proceso de revisin y por lo tanto ahorrar bastante tiempo. Los emisores de Requerimientos de Cambio duplicados deberan ser aadidos a la lista de notificacin del Requerimiento de Cambio original para notificaciones futuras respecto de la resolucin. Un Requerimiento de Cambio en este estado es determinado por la Reunin de Revisin del TCC o por el miembro del equipo asignado como un requerimiento invlido o se necesita ms informacin del emisor. Si ya est asignado (Abierto) el Requerimiento de Cambio es removido de la cola de resolucin y ser revisado de nuevo. Una autoridad designada por el TCC es asignada para que lo confirme. No se necesita ninguna accin 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 Reunin de Revisin del TCC considerando cualquier nueva informacin. Si se confirma invlido, el Requerimiento de Cambio ser Cerrado por el TCC y el emisor ser notificado. Existe datos insuficientes para confirmar la validez de un Requerimiento de Cambio Rechazado o Duplicado. El propietario automticamente es cambiado al emisor quien es notificado para proveer ms datos.

Control de Acceso
Todos los Usuarios

Pospuesto

Administrador Jefe del Proyecto

Duplicado

Administrador Jefe del Proyecto Jefe de Aseguramiento de la Calidad Jefe de Desarrollo

Rechazado

Administrador Jefe del Proyecto Jefe de Desarrollo Jefe de Pruebas

Ms Info

Administrador

- 71 -

Abierto

Asignado

Resuelto

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 resolucin antes de que se llegue a un hito. Se define como que est en cola de asignacin. Los miembros de la reunin son la nica autoridad para abrir un Requerimiento de Cambio en la cola de resolucin. Si un Requerimiento de Cambio de prioridad 2 o ms es encontrado, el Jefe de Aseguramiento de la Calidad o el Jefe de Desarrollo le deben prestar inmediata atencin. En este punto ellos pueden decidir convocar a una Reunin de Revisin del TCC de emergencia o simplemente abrir el Requerimiento de Cambio en la cola de resolucin instneamente. Un Requerimiento de Cambio Abierto debe ser asignado, por el Jefe del Proyecto, basndose en el tipo de Requerimiento de Cambio y actualizar el cronograma, si es apropiado. Significa que la resolucin de este Requerimiento de Cambio est completa y ya est listo para verificacin. Si el emisor fue un miembro del Departamento de Aseguramiento de la Calidad, el propietario automticamente es cambiado al miembro de Aseguramiento de la Calidad emisor, si no, cambia al Jefe de Aseguramiento de la Calidad para resasignacin manual. Un Requerimiento de Cambio que falla las pruebas ya sea en una construccin de prueba o una construccin de release es puesto en este estado. El propietario automticamente es cambiado al miembro del equipo que resolvi el Requerimiento de Cambio. Un Requerimiento de Cambio en este estado ha sido Verificado en una constriccin reprueba y est listo para ser incluido en un release.

Administrador Jefe del Proyecto Jefe de Desarrollo Jefe de Aseguramiento de la Calidad

Jefe del Proyecto

Administrador Jefe del Proyecto Jefe de Desarrollo Jefe de Aseguramiento de la Calidad Departamento de Desarrollo Administrador Departamento Aseguramiento Calidad Administrador Departamento Aseguramiento Calidad de la

Fall Prueba

de

Verificado

de

de la

Cerrado

El Requerimiento de Cambio ya no requiere atencin. Este es Administrador el estado final que se le puede asignar a un Requerimiento de Cambio. Slo el Administrador en la Revisin del TCC tiene la autoridad para cerrar un Requerimiento de Cambio. Cuando un Requerimiento de Cambio es Cerrado, el emisor recibir una notificacin por e-mail con la disposicin final del Requerimiento de Cambio. Un Requerimiento de Cambio puede ser Cerrado: 1) despus de que es Verificado en una construccin 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 aadido a ese Requerimiento de Cambio para futuras notificaciones (ver las definiciones de los estados "Rechazado" y "Duplicado" para ms detalles). Si el emisor quiere rebatir el cierre, el Requerimiento de Cambio debe ser actualizado y reenviado para Revisin del TCC.

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 -

continuacin. 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 informacin: Aplicacin Base de Datos Software Base Hardware Manuales
SOLICITUD DE CAMBIOS FECHA PROPONENTE
Nombre y cargo del proponente del cambio

DESCRIPCIN DEL CAMBIO PROPUESTO VALORACIN


Describir brevemente a qu componentes podra afectar y cmo.

IMPACTO
D, F o M. Con una explicacin adicional si es necesario.

ESFUERZO
Lo pone el equipo de desarrollo. Debido a que algunas caractersticas requieren ms tiempo y recursos que otra, estimar das hombre, lneas de cdigo 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 perodo de tiempo. Se usa para el alcance de la administracin y para determinar la prioridad del desarrollo.

RIESGO
Lo pone el equipo de desarrollo basndose 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 ms 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 carcter+istica cambiar o de que el entendimiento del equipo, sobre esta caracterstica, cambie. Se usa para ayudar a establecer las prioridades y determinar los items para los que investigacin adicional es el siguiente paso apropiado.

APROBADO FECHA FIRMAS PROPONENTE

SI o NO dd/mm/aaaa

APLICADO FECHA

SI o NO dd/mm/aaaa

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 nmero til de reportes basados en requerimientos de Cambio. Bajo la categora de antigedad, los reportes pueden ser solicitados en trminos de nmero de Requerimientos de Cambio en un perodo de tiempo o de una semana o meses basndose en los siguientes criterios: Enviados Asignados Resueltos Prioridad

Listar los problemas por estado puede ayudar a determinar qu tan cerca de la finalizacin del proyecto se puede estar. Por ejemplo, si muchos de los problemas han sido resueltos entonces la terminacin est ms cerca que si estos problemas se encontrarn en el estado de Enviados. Bajo la categora de distribucin, se puede requerir reportes para responder a las siguientes preguntas: Quin est encontrando qu tipos de defectos y en qu parte del proyecto? A quienes se est asignando los problemas? Cuntos problemas estn abiertos bajo un mismo desarrollador? Qu tan severos son los problemas que se estn encontrando? En qu parte del proceso se estn encontrando los problemas (causa raz)? Cundo se estn resolviendo los problemas? Cuntos defectos hay? Qu tan severos son estos problemas pendientes? Estas mtricas pueden ayudar en el anlisis de la carga de trabajo, quin est trabajando en los problemas ms crticos y qu tan rpido estn siendo cerrados los problemas. Bajo la categora de tendencia, se puede requerir reportes que contesten los siguientes tipos de preguntas: Cuntos defectos estn abiertos este da, semana o mes? Cuntos defectos han sido cerrados este da, semana o mes?

Estos datos son tiles para evaluar los ratios de correcciones y puede proveer indicaciones de la eficiencia de la ingeniera. El propsito de este workflow del RUP es:

Soportar mtodos 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 polticas del proyecto Proveer pistas de auditoria de cambios a los artefactos registrando por qu, cundo y por quin

- 74 -

El Workflow de Administracin de Configuracin y Cambios est relacionado a todos los workflows esenciales del RUPs (Modelamiento de Negocios, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Despliegue) porque sirve como un repositorio para los artefactos producidos durante esos workflows del RUPs. Los artefactos clave son el Plan de Administracin de Configuracin (Configuration Management Plan) y los Requerimientos de Cambio (Change Request) Los siguientes Workflows de detalle de Administracin de Configuracin y Cambios son efectuados:

Planificar la Configuracin del Proyecto y el Control de Cambios Crear un Ambiente CM para el Proyecto Cambiar y Enviar los Items de la Configuracin Manejar Versiones Congeladas (Baselines) y Liberaciones Monitorear y Reportar el estado de la Configuracin Administrar los Requerimientos de Cambio

Workflow de Administracin de Configuracin y Cambios Planificar la Configuracin del Proyecto y el Control de Cambios El propsito de este Workflow de detalle es establecer las polticas de administracin de configuracin del proyecto, establecer polticas y procesos para controlar los cambios al

- 75 -

producto y documentar las polticas y procesos en el Plan de Administracin de la Configuracin (Plan CM). El Plan CM describe todas las actividades a efectuarse durante el curso del ciclo de vida del proyecto. El Plan CM documenta cmo se planifica, implementa, controla y organiza las actividades relativas al CM del producto. Comprende las siguientes actividades: Establecer las Polticas de Administracin de Configuracin (CM). Las polticas de Administracin de Configuracin son usadas para monitorear y salvaguardar los activos del proyecto y reforzar las prcticas de desarrollo de software. Las polticas del proyecto deben mejorar la comunicacin entre los miembros del equipo y minimizar los problemas encontrados cuando integran su trabajo. Escribir el Plan de Administracin de Configuracin (CM). Describir todas las actividades relativas a Administracin de Configuracin a efectuarse durante el curso del ciclo de vida del producto/proyecto. Documentar cmo las actividades de Administracin de Configuracin relativas al producto van a ser planeadas, implementadas, controladas y organizadas. El Plan de Administracin de Configuracin describe las actividades de Administracin de Configuracin y de Control de Cambios que se efectuarn 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 propsito 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 propsito de este Workflow de detalle es crear una ambiente de trabajo donde todos los artefactos de desarrollo estn disponibles y dnde 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 mquina (servidores y espacio en disco) e instalar las herramientas de administracin de configuracin; tambin 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 Integracin. Similar a los workspaces de los implementadotes, en los que los individuos pueden desarrollar y cambiar el cdigo, existe la nocin de Workspace de Integracin. 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 Configuracin El propsito 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 versin requerida de cualquier artefacto dado que puedan necesitar para hacer su trabajo. Las polticas del proyecto determinan cuales artefactos son visibles o modificables y por quin. Hacer cambios. Esta es una actividad genrica 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 propsito de enviar los cambios de un workspace de Desarrollo a un workspace de Integracin es hacer que el conjunto de artefactos cambiado, en un workspaces privado de trabajo, est disponible al proyecto para su integracin. Actualizar los workspaces. Asegurar que los miembros del equipo estn trabajando con las versiones ms 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 propsito de este Workflow de detalle es asegurar que los subsistemas, cuando alcancen un nivel de maduracin especfico sean congelados. RUP define Versin Congelada como un 'snapshot' en el tiempo de una versin de cada artefacto en el repositorio del proyecto. Los artefactos congelados estn disponibles para liberarlos o reusarlos en iteraciones subsecuentes y en otros proyectos. Comprende las siguientes actividades: Crear la Unidad de Despliegue (desde la Administracin de Configuracin). Una Unidad de Despliegue consiste de una Construccin (una coleccin de componentes ejecutables), documentos (material de soporte para el usuario final y las Notas del Release) y los artefactos de instalacin. El propsito 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 propsito 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 maduracin del software , estabilidad y calidad que puedan haber alcanzado. La versin congelada apropiadamente etiquetada, entonces est disponible para liberarse o para un mayor desarrollo en iteraciones subsiguientes.

Monitorear y Reportar el estado de la Configuracin El propsito de este Workflow de detalle es:


Determinar que el producto cumple con todos los requerimientos funcionales y fsicos. Determinar que los artefactos son almacenados en una librera controlada. Asegurar que todos los artefactos y artefactos congelados estn disponibles Soportar actividades de Contabilizacin del Estado de la Configuracin del proyecto que estn basadas en un registro formalizado. Reportar el estado de los cambios propuestos y el estado de la implementacin de los cambios propuestos. Facilitar la revisin del producto por medio de actividades de seguimiento de defectos y reporte. Asegurar que la data es acumulada y reportada para los propsitos de seguimiento del progreso y tendencias.

Comprende las siguientes actividades: Reportar el Estado de la Configuracin. Para soportar actividades de Contabilizacin del estado de la Configuracin que son basadas en un registro formalizado y reportado en el estado de cambios propuestos y el estado de la implementacin de los cambios propuestos. Facilitar la revisin del producto por medio de seguimiento de defectos y reporte de actividades. Asegurar que la data se est acumulando y se est reporteando para propsitos de seguimiento del progreso y tendencias. Efectuar la Auditora de la Configuracin. Determinar que una versin congelada contiene todos los artefactos. Determinar que un versin congelada cumple con los requerimientos. Se efecta, tpicamente, despus de las pruebas del sistema y antes de las pruebas de Aceptacin.

Administrar los Requerimientos de Cambio El propsito 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 caractersticas 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 dueo asignado de un requerimiento de cambio puede hacer actualizaciones al formulario de Requerimiento de Cambio para indicar su estado presente y cualquier otra informacin relevante. Revisar el Requerimiento de Cambio. Determinar si el requerimiento de cambio ser aceptado o rechazado. Para los requerimientos de cambio aceptados, se les evala 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 invlido o duplicado. Verificar los Cambios en la Construccin (desde el workflow de Pruebas). Esta actividad confirma que un requerimiento de cambio ha sido completado, tpicamente conduciendo subconjuntos de pruebas en uno o ms construcciones (builds).

3.7.3 Notas sobre el Workflow de Administracin de Configuracin y Cambios Cada actividad en el Workflow de Administracin de Configuracin y Cambios es esencial para una administracin de configuracin exitosa. Ninguna actividad debe ser removida del Workflow de Administracin de Configuracin y Cambios. 3.7.4 RUP Artefactos de Administracin de Configuracin y Cambios Los artefactos de Administracin de Configuracin y Cambios capturan y presentan informacin relativa a las actividades CM. La Tabla 15 identifica los artefactos que deben ser producidos durante el Workflow de Administracin de Configuracin y Cambios. Tabla 15. Artefactos para la Administracin de Configuracin y Cambios
Artefactos
Incep Requerimiento de Cambio Repositorio del Proyecto Workspace

Creado/Revisado
Elab X X X Const X X X Trans X X X

Revisar Detalles
Informal Ninguno Ninguno

Herramientas Usadas
Rational ClearQuest

Rational ClearCase Rational ClearCase

3.7.5 Notas sobre los Artefactos para la Administracin de Configuracin y Cambios El Repositorio del Proyecto contiene el documento de Visin, acuerdos entre desarrolladores y usuarios, scripts de base de datos (ejemplos de los datos de origen), scripts del lenguaje de definicin 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 Configuracin (Configuration Audit Findings), Plan de Administracin de la Configuracin (Configuration Management

- 79 -

Plan). 3.7.6 Notas sobre los reportes de Administracin de Configuracin y Cambios Ningn reporte CM es provisto con el RUP para capturar el estado de los cambios propuestos y el estado de la implementacin de los cambios propuestos. Sin embargo, una buena herramienta de CRM proveer de un generador de reportes con muchos reportes ya hechos y que adems, permita adecuarlos a sus necesidades especficas. 4 PASOS SIGUIENTES PARA LAS EMPRESAS CLIENTE La Seccin 3 da una versin adecuada genrica del RUP usando la suite de herramientas de Rational; sin embargo, esto puede no cubrir las necesidades de cada empresa. Las empresas debern hacer lo siguiente:

Evaluar sus organizaciones para determinar cmo 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 metodologa de parte de la Administracin Obtener el entrenamiento apropiado en el software usado Decidir si se desarrollar otros artefactos adicionales a los indicados en la Seccin 3 Incluir un enfoque de administracin de proyectos para: manejar riesgos planificar proyectos identificar mtricas monitorear el progreso del proyecto y; manejar recursos, presupuestos y contratos con proveedores y clientes

Anda mungkin juga menyukai