Contenido TransitionITERACIÓN TRANSICIÓN.....................................................................................................................2

1. RESUMEN (SUMMARY)...........................................................................................................2

2. OBJETIVOS (OBJECTIVES)............................................................................................................3

3. ACTIVIDADES ESENCIALES (ESSENTIAL ACTIVITIES)................................................................4

4. WORK BREAKDOWN STRUCTURE: PATRÓN CAPACIDAD: ITERACIÓN DE TRANSICIÓN.........5

4.1 Prepare Environment for an Iteration................................................................................6

4.2 Ongoing Management and Support...................................................................................7

4.3 Plan Deployment................................................................................................................8

4.4 Fix Defects in Components.................................................................................................9

4.5 Develop Remaining Components [within Scope].............................................................10

4.6 Integrate and Test............................................................................................................11

4.7 Develop Remaining Support Material [within Scope].......................................................14

4.8 Manage Acceptance Test.................................................................................................15

4.9 Beta Test Product.............................................................................................................15

4.10 Create Product to Release................................................................................................16

4.11 Plan for Next Iteration......................................................................................................17

4.12 Close-Out Project.............................................................................................................17

5. CICLO DE VIDA RUP CLÁSICO: FASE TRANSICIÓN (CLASSIC RUP LIFECYCLE: PHASE TRANSITION).....................................................................................................................................................18

6. MODELO DE CICLO DE VIDA DEL NEGOCIO: FASE TRANSICIÓN (BUSINESS MODELING LIFECYLCE: PHASE TRANSITION)...................................................................................................19

7. Work Breakdown Structure: Modelo de ciclo de vida del Negocio: Transición........................20

8. HITO: LANZAMIENTO DEL PRODUCTO (CONCEPT: PRODUCT RELEASE MILESTONE)...............21

8.1 Criterios de Evaluación (Evaluation Criteria)..........................................................................21

8.2 Artefactos (Artifacts)..............................................................................................................21

ITERACIÓN TRANSICIÓNCuarta Fase del RUP, cuyo principal propósito es asegurar que el software esté listo para su entrega a sus usuarios finales.

El objetivo de la fase de transición es asegurar que el software está disponible para sus usuarios finales. La fase de transición puede abarcar varias iteraciones, e incluye las pruebas del producto y la preparación para el lanzamiento, y hacer pequeños ajustes basados en la retroalimentación del usuario. En este punto del ciclo de vida, los comentarios de los usuarios deberían centrarse principalmente en la puesta a punto del producto, configuración, instalación y problemas de usabilidad, todos los problemas estructurales más importantes ya se han resuelto mucho antes en el ciclo de vida del proyecto.

1. RESUMEN (SUMMARY)El objetivo de la fase de transición es asegurar que el software esté disponible para sus usuarios. La fase de transición puede abarcar varias iteraciones, e incluye las pruebas del producto y preparación para el lanzamiento, y hacer pequeños ajustes basados en la retroalimentación del usuario. En este punto del ciclo de vida, los comentarios de los usuarios debería centrarse principalmente en la puesta a punto del producto, configuración, instalación y problemas de usabilidad, todos los problemas estructurales más importantes ya se han resuelto mucho antes en el ciclo de vida del proyecto.

2. OBJETIVOS (OBJECTIVES)Al final de la fase de transición del ciclo de vida deben cumplirse unos objetivos específicos y el proyecto debe estar en condiciones de ser cerrado. En algunos casos, el final del ciclo de vida actual puede coincidir con el comienzo de otro ciclo de vida en el mismo producto, dando lugar a la próxima generación o versión del producto. Para otros proyectos, al final de la transición puede coincidir con una entrega completa de los artefactos a un tercero que puede ser responsable de las operaciones, mantenimiento y mejoras del sistema que se entrega.

Esta fase de transición oscila de ser muy sencillo a extremadamente compleja, dependiendo del tipo de producto. Una nueva versión de un producto de escritorio existente puede ser muy simple, mientras que la sustitución de un sistema nacional de control de tráfico aéreo puede ser extremadamente compleja.

Actividades realizadas durante una iteración en la fase de transición dependerá de la meta propuesta. Por ejemplo, la fijación de los errores, la aplicación y la prueba son generalmente suficientes. Sin embargo, a las nuevas características hay que añadir que la iteración en esta fase es similar a las de análisis de la fase de construcción y diseño que requiere.

La fase de transición se introduce cuando una línea de base es lo suficientemente madura para ser desplegada en el dominio del usuario final. Normalmente, esto requiere que un subconjunto útil del sistema se ha completado con un nivel de calidad aceptable y la documentación de usuario tiene también este nivel, de modo que la transición que se proporcione al usuario obtenga resultados positivos para todas las partes.

Los objetivos principales de la fase de transición incluyen:

1. Pruebas beta para validar el nuevo sistema frente a las expectativas de los usuarios2. Pruebas beta y el funcionamiento en paralelo con respecto a un sistema heredado que

este sustituyendo3. La conversión de bases de datos operacionales4. Formación de los usuarios y mantenedores.5. Despliegue de las fuerzas de la comercialización, distribución y ventas6. El despliegue específico de la ingeniería, tales como fecha de corte, embalaje comercial y

de producción, las ventas fuera del rodillo, terreno de la formación del personal.7. Afinar las actividades tales como la corrección de errores, la mejora del rendimiento y la

usabilidad.8. Evaluación de la implementación de las líneas de base en contra de la visión completa y los

criterios de aceptación para el producto9. El logro de usuario auto-compatibilidad10. Lograr la concurrencia de interesados que las líneas de base de despliegue están

completas11. Lograr la concurrencia de interesados que las líneas de base de despliegue son

consistentes con los criterios de evaluación de la visión.

3. ACTIVIDADES ESENCIALES (ESSENTIAL ACTIVITIES)

Las actividades esenciales de la fase de transición incluyen:

1. La ejecución de los planes de despliegue2. La finalización de material de soporte al usuario final 3. Probando el producto concreto en el sitio de desarrollo4. La creación de una versión del producto5. Obtener retroalimentación de los usuarios6. Puesta a punto del producto basado en la retroalimentación7. Haciendo que el producto se encuentre a disposición de los usuarios finales

4. WORK BREAKDOWN STRUCTURE: PATRÓN CAPACIDAD: ITERACIÓN DE TRANSICIÓN

Esta es la estructura de desglose de iteración de la fase de transición. Esto incluye las actividades habitualmente realizadas durante una sola iteración en la fase de transición. El objetivo de la fase de transición es asegurar que el software está disponible para los usuarios finales. La fase de transición puede abarcar varias iteraciones, e incluye las pruebas del producto en la preparación para el lanzamiento, y hacer pequeños ajustes basados en la retroalimentación del usuario. En este punto del ciclo de vida, los comentarios de los usuarios deberían centrarse principalmente en

la puesta a punto del producto, configuración, instalación y problemas de usabilidad, todos los problemas estructurales más importantes ya se han resuelto mucho antes en el ciclo de vida del proyecto.

Las actividades que componen el WORK BREAKDOWN STRUCTURE se describen a continuación:

4.1 Prepare Environment for an IterationEsta actividad prepara el entorno de desarrollo para un proyecto para la iteración actual, en el entorno de desarrollo incluye tanto el proceso y las herramientas.

Descripción:

Para cada iteración, esta actividad se centra principalmente en:

Completar el caso de Desarrollo para prepararse para la iteración. Preparar, si es necesario, la personalización de las herramientas que se utilizarán dentro

de la iteración. Verificar que las herramientas han sido correctamente configuradas e instaladas. La preparación de un conjunto de plantillas para proyectos específicos y directrices para

apoyar el desarrollo de los artefactos del proyecto en la iteración. Asegurar que todos los cambios realizados en el entorno del proyecto sean debidamente

comunicados a los miembros del proyecto.

4.2 Ongoing Management and Support

WORK BREAKDOWN STRUCTURE

Descripción:

Esto abarca las diversas actividades de gestión y apoyo que se repiten de manera continua durante todo el proyecto.

Este patrón, o un conjunto de actividades, agrupan a todas las actividades de apoyo y las actividades que se requieren para una iteración en un único patrón. Dado que las actividades individuales en curso y de apoyo no son de particular interés por sí mismas, este modelo de alto nivel los incluye en los planes de iteración haciendo hincapié en el objetivo a alcanzar, pero deja los detalles de las actividades al siguiente nivel de detalle que se necesitan para lograr la meta. Esto permite ver un diagrama de actividades, como un flujo de trabajo de la iteración, para mostrar estas actividades en marcha, sin demasiado desorden en el diagrama.

Actividades:

Las actividades que la componen son:

-Manage iteration

-Monitor and control project

-Manage Changing Requeriments

-Manage Change Requests

- Support Environment During an Iteration

- Change and Deliver Configuration Items

- Manage Baselines & Releases

- Monitor & Report Configuration Status

4.3 Plan Deployment

Esta actividad planifica la implementación del producto. Planificación de implementación debe tener en cuenta cómo y cuándo el producto será puesto a disposición del usuario final.

Descripción:

Planificación de implementación requiere un alto grado de colaboración con el cliente y la preparación. Una conclusión exitosa de un proyecto de software puede estar seriamente afectada por factores fuera del alcance del desarrollo de software tales como la construcción, la infraestructura de hardware no está en su lugar, y el personal mal preparado para el cambio al nuevo sistema.

Para garantizar la implementación exitosa y la transición al nuevo sistema y las formas de hacer negocios, el plan de implementación debe abordar no sólo el software de entrega, sino también el desarrollo de material didáctico y material de apoyo del sistema para garantizar que los usuarios finales pueden utilizar con éxito el producto de software entregado.

4.1 Fix Defects in Components

Esta actividad completa una parte de la aplicación de manera que se puede enviar a la integración.

Descripción:

En esta actividad, los ejecutores de escribir código fuente, adaptan la fuente código existente , compilan, enlazan y realizan las pruebas unitarias, ya que implementan los elementos en el modelo de diseño. Si los defectos en el diseño se descubren, el ejecutor presenta información sobre la reelaboración de diseño.

Los encargados de la ejecución también corrigen defectos de código y realizan las pruebas unitarias para verificar los cambios. Finalmente, el código es revisado para evaluar la calidad y el cumplimiento de las directrices de programación.

4.1 Develop Remaining Components [within Scope]

WORK BREAKDOWN STRUCTURE

Descripción:

Esto incluye las actividades necesarias para desarrollar los componentes dentro del ámbito definido en el plan de iteración.

Este patrón, o un conjunto de actividades, normalmente se repite en cada proyecto de construcción, en una iteración. La frecuencia de la producción de construcción varía de proyecto a proyecto. Algunos proyectos se basan en una base diaria, mientras que otros producen una acumulación por iteración.

[dentro del alcance] en el nombre de este patrón indica que las actividades dentro de este patrón están limitadas por un alcance particular, como un componente en particular, por ejemplo. Este patrón está destinado a ser usado varias veces, una para cada caso "alcance". Por ejemplo, una vez para cada componente en una iteración.

Actividades

Las actividades que la componen son:

- Analyze Behavior

- Design Components

- Design the Database

- Design Services

- Implement Components

4.1 Integrate and Test

WORK BREAKDOWN STRUCTURE

Esto incluye las actividades necesarias para integrar plenamente y probar el producto. Incluye todos los diferentes ámbitos de la prueba, incluyendo a todos los niveles y tipos de pruebas previstas para la iteración, más limitadas a los porciones de el sistema apropiado para la prueba.

Descripción:

Este patrón, o un conjunto de actividades, encapsula la integración completa, construcción y pruebas del sistema.

Actividades

Las actividades que la componen son:

- Verify Test Approach

- Integrate and Validate Build: Con un flujo de actividades como se muestra a continuación:

Work breakdown structure

- Test and Evaluate [within Scope]: Con un flujo de actividades como se muestra a continuación:

Work breakdown structure

4.1 Develop Remaining Support Material [within Scope]WORK BREAKDOWN STRUCTURE

Descripción:

Esto abarca las actividades necesarias para desarrollar material de apoyo, tales como tutoriales, documentación de productos, muestras, dentro del ámbito de aplicación determinado en el plan de iteración.

Este patrón, o un conjunto de actividades, normalmente se repite en cada iteración.

[dentro del alcance] en el nombre de este patrón indica que las actividades dentro de este patrón están limitadas por un alcance particular, como un manual de usuario en particular, por ejemplo. Este patrón está destinado a ser usado varias veces, una para cada caso "alcance". Por ejemplo, una vez por cada documento de usuario, o parte de un documento, previsto para una iteración.

Actividades

Las actividades que la componen son:

- Develop Support Material

- Test and Evaluate

4.1 Manage Acceptance TestDescripción:

Esta actividad asegura que el producto se considera aceptable para el cliente antes de su lanzamiento general.

El Gestor de despliegue organiza la instalación del producto en una o más configuraciones de entorno de prueba que representa un entorno adecuado para el cliente como se especifica en el Plan de aceptación del producto.

En algunos casos, el proceso de instalación en sí puede estar sujeto a una prueba de aceptación, al igual que cualquier actualización de hardware y configuraciones anteriores.

Una vez instalado, el probador normalmente se ejecuta a través de un conjunto preseleccionado de las pruebas, basadas generalmente en un subconjunto seleccionado de los bancos de pruebas existentes, y determina los resultados de la prueba. El Gestor de despliegue y otras partes interesadas revisan los resultados de la prueba en busca de anomalías. Si hay "hallazgos stoppers", el gestor de despliegue eleva solicitudes de cambio que requieren atención inmediata y la resolución, y puede retrasar o posponer sus planes posteriores para el despliegue de una base de usuarios más amplia.

4.1 Beta Test Product

Descripción:

Esta actividad solicita retroalimentación en el producto de un subconjunto de los usuarios previstos, mientras que todavía está bajo desarrollo activo.

Una prueba beta obtiene el producto de forma controlada, en el mundo real la prueba, se retroalimenta por los comentarios de los usuarios potenciales que pueden utilizarla para dar forma al producto final. También proporciona una vista previa de la próxima versión para los clientes interesados.

Es más adecuado en situaciones en las que el producto se está construyendo no tiene precedentes, o cuando el producto será empaquetado y disponible para la venta comercial.

Retroalimentación del Programa Beta se trata como solicitudes de las partes interesadas y se tiene en cuenta las características del producto en desarrollo en posteriores iteraciones.

4.1 Create Product to ReleaseWORK BREAKDOWN STRUCTURE

Descripción:

Esto incluye las actividades necesarias para construir y empaquetar el producto para su liberación.

Actividades

Las actividades que la componen son:

- Produce Deployment Unit

- Package Product

- Provide Access to Download Site

4.2 Plan for Next Iteration

Descripción:

Esta actividad crea un Plan de Iteración, un plan de grano fino para guiar a la siguiente iteración.

El Plan de Iteración debe ser revisado por el cliente y otras partes interesadas y, si es satisfactoria, debe ser aprobado a través de la Revisión del Plan de Iteración. Esta revisión también ofrece la visibilidad de las expectativas de los clientes del proyecto de participación de los clientes y los recursos, sobre todo si la iteración tiene la intención de proporcionar los artefactos o implementar el software, por lo que el cliente puede hacer los planes adecuados. En el Rational Unified Process, se recomienda encarecidamente que el alcance y los recursos de una iteración se gestionan activamente para cumplir con la fecha de finalización prevista, es decir, se utiliza un enfoque Timeboxing. Esto significa que el plan de iteración puede ser cambiado durante una iteración, ya que surgen Problemas en el cronograma que se rectifican en la ejecución.

4.3 Close-Out ProjectDescripción:

En esta actividad, el director de proyecto prepara el proyecto para la terminación.

Una evaluación del estado final se prepara para la Revisión de Aceptación del Proyecto, que, si tiene éxito, marca el punto en el que el cliente acepta formalmente la propiedad del producto de software. El director del proyecto completa entonces la entrega final del proyecto mediante la cesión de los activos restantes y reasignar el resto del personal.

5. CICLO DE VIDA RUP CLÁSICO: FASE TRANSICIÓN (CLASSIC RUP LIFECYCLE: PHASE TRANSITION)

Estas son las actividades para el proceso general que propone el RUP:

a. Actividad: Preparar el Ambiente para una iteración: Esta actividad se encarga de preparar el entorno de desarrollo para la(s) iteración (es) necesarias de transición, en el entorno de desarrollo se debe tener en cuenta tanto el proceso y las herramientas a utilizar.

b. Actividad: Gestión y Soporte Continuó: Esto abarca las diversas actividades de gestión y apoyo que se repiten de manera continua en todo el proyecto.

c. Actividad: Plan de Despliegue: Esta actividad se planifica la implementación del producto. Planificación de implementación debe tener en cuenta cómo y cuándo el producto será puesto a disposición del usuario final.

d. Actividad: corregir defectos en los componentes: Esta actividad completa una parte de la aplicación de manera que se puede liberar para la integración.

e. Actividad: Desarrollo de componentes restantes [dentro del alcance]: Esto incluye las actividades necesarias para desarrollar los componentes dentro del alcance que se definen en el plan de transición.

f. Actividad: Integrar y probar: Esta incluye las actividades necesarias para integrar plenamente y probar el producto. Incluye todos los diferentes ámbitos de la prueba, incluyendo a todos los niveles y tipos de pruebas previstas para la iteración, más limitadas a las partes de un sistema adecuado para la prueba.

g. Actividad: Desarrollo de Material de apoyo restante: Esto abarca las actividades necesarias para desarrollar material de apoyo, tales como tutoriales, documentación de productos, muestras, dentro del ámbito de aplicación determinado en el plan de iteración de la transición.

h. Actividad: Gestión de Pruebas de Aceptación: Esta actividad asegura que el producto se considera aceptable para el cliente antes de su lanzamiento en producción e integración.

i. Actividad: Beta de prueba del producto: Permite la retroalimentación en el producto de un subconjunto de los usuarios previstos que realizan pruebas sobre el mismo, mientras que todavía está bajo desarrollo activo.

j. Actividad: Creación de versión para producción del producto: Esto incluye las actividades necesarias para construir y empaquetar el producto para su liberación.

k. Actividad: Plan para la siguiente iteración: Esta actividad crea un Plan de Iteración, un plan de grano fino para guiar a la siguiente iteración.

l. Actividad: Cierre de Proyecto: En esta actividad, el director de proyecto prepara el proyecto para la terminación.

6. MODELO DE CICLO DE VIDA DEL NEGOCIO: FASE TRANSICIÓN (BUSINESS MODELING LIFECYLCE: PHASE TRANSITION)

El objetivo de la fase de transición enfocado en el modelo del negocio es dar una visión previa de los sistemas que serán desarrollados o adquiridos, y pueda proporcionar un primer corte de los modelos de casos de uso y análisis para cada sistema.

Además de las actividades expuestas en el aparatado del Ciclo de Vida de Rup clásico, se deben considerar las siguientes actividades adicionales como parte de los procesos de entrega enfocado en el modelo del negocio:

a) Actividad: Desarrollo de visiones iniciales del sistema: Esto incluye las actividades necesarias para desarrollar la visión inicial del proyecto.

b) Actividad: Definir Ajustes del Negocio: Esta actividad abarca el trabajo en torno a la definición del deber ser del negocio.

c) Actividad: Explora como ajustar la Automatización de procesos: Esta actividad abarca el trabajo en torno a la exploración de las posibilidades de automatización para los procesos de negocio que se tienen considerados en el negocio.

d) Actividad: Refinar Visiones del sistema: Esto incluye las actividades necesarias para refinar la visión inicial del proyecto.

7. Work Breakdown Structure: Modelo de ciclo de vida del Negocio: Transición

8. HITO: LANZAMIENTO DEL PRODUCTO (CONCEPT: PRODUCT RELEASE MILESTONE)

Hito de lanzamiento del producto es donde se decide si los objetivos del proyecto se cumplieron, y si usted debe comenzar un nuevo ciclo de desarrollo.

Ahora se explica los criterios de evaluación para el hito de lanzamiento del producto al final de la fase de transición. El estado de los artefactos esenciales también se describe.

Al final de la fase de transición se produce el cuarto hito importante proyecto, el hito de lanzamiento del producto. En este punto, usted decide si los objetivos se cumplieron, y si usted debe comenzar un nuevo ciclo de desarrollo. En algunos casos este hito puede coincidir con el final de la fase inicial para el siguiente ciclo. El hito de lanzamiento del producto es el resultado de que el cliente dé el visto bueno a la revisión y aceptación de los entregables del proyecto.

8.1 Criterios de Evaluación (Evaluation Criteria)Los criterios de evaluación primarios para la fase de transición implican las respuestas a estas preguntas:

¿Está el usuario satisfecho?

¿Son los gastos de los recursos reales en comparación con los gastos previstos aceptable?

En el hito de lanzamiento del producto, el producto está en producción y comienza el ciclo de mantenimiento posterior a la liberación. Esto puede implicar comenzar un nuevo ciclo, o alguna versión de mantenimiento adicional.

8.2 Artefactos (Artifacts)

1. El producto: El producto es el objetivo! El esfuerzo de todo el proyecto está orientado a la creación de un producto que proporciona un beneficio a la comunidad de usuarios. El éxito de un producto reside en su uso.

2. Material de apoyo del usuario: Este artefacto se compone de materiales que ayudan al usuario final en el aprendizaje, uso, operación y mantenimiento del producto. El propósito

de este producto de trabajo, es guiar y apoyar al usuario en la forma de utilizar el producto.

3. Implementación de Elementos: Estos artefactos son las partes físicas que componen una aplicación, incluyendo los archivos y directorios. Estos incluyen los archivos de software de código (fuente, binario o ejecutable), archivos de datos y archivos de documentación, tales como archivos de ayuda en línea. Los elementos de implementación son parte de una implementación de bajo nivel, en particular las unidades de nivel de la composición física, la sustitución, control de versiones y gestión de la configuración.

4. Test Suite (Opcional): Este artefacto define un conjunto de pruebas relacionadas con el desarrollo del producto de software. Los objetivos de este artefacto son:- Administrar y ejecutar la secuencia de las pruebas planeadas.- Proveer un conjunto de información a través de log de resultados de las pruebas para determinar mejoras al software.