Consideraciones Para Adaptar Rup

Material de soporte: Process Essentials

Page 1 of 5

Process Essentials This page introduces the essential elements of RUP and certain guidelines for tailoring the process to best fit your project's specific needs. This is key to achieving the delicate balance between delivering quality software and delivering it quickly (the software paradox!).

Expandir todas las secciones

Contraer todas las secciones

Descripción principal

Introducción La clave para alcanzar el delicado equilibrio entre proporcionar un software de calidad y proporcionarlo con rapidez (la paradoja del software) es comprender los elementos esenciales del proceso y seguir ciertas directrices para adaptar el proceso a las necesidades específicas del usuario. Esta adaptación debería hacerse en el momento de adherirse a las recomendaciones demostradas en la industria para que los proyectos de desarrollo de software concluyan de manera satisfactoria. A continuación se describen los principios fundamentales de un proceso de software eficaz.

1. Visión: desarrollar una visión Desarrollar una visión clara es fundamental para desarrollar un producto que cumpla las necesidades reales de los interesados. En RUP, el artefacto visión captura restricciones de diseño y requisitos de muy alto nivel a fin de que el lector comprenda el sistema que se va a desarrollar. Proporciona entrada al proceso de aprobación del proyecto y, por lo tanto, está estrechamente relacionado con el caso de negocio. Comunica los "qué y porqué" fundamentales para el proyecto y es un indicador contra el que deberían validarse todas las decisiones futuras. El contenido de la visión, junto con otros artefactos de requisito relacionados, debería responder a las preguntas siguientes, que podrían desglosarse para separar los artefactos según sea necesario:








¿Cuáles son los términos clave? (Glosario) ¿Qué problema estamos intentando resolver? (Sentencia del problema) ¿Quiénes son los interesados? ¿Quiénes son los usuarios? ¿Qué necesidades tienen? ¿Cuáles son las características del producto? ¿Cuáles son los requisitos funcionales? (Casos de uso ) ¿Cuáles son los requisitos no funcionales? ¿Cuáles son las restricciones de diseño?

Desarrollar una visión clara y un conjunto comprensible de requisitos es la base para la disciplina de requisitos, y el principio de equilibrio de prioridades del interesado que entran en conflicto. Esto implica el análisis del problema, la comprensión de las necesidades del interesado, la definición del sistema y la gestión de los requisitos a medida que van cambiando.

2. Plan: gestionar para confeccionar un plan "El producto es tan bueno como el plan que se haya diseñado" ( FIS96 ). La concepción de un proyecto nuevo, la evaluación del ámbito y el riesgo, la supervisión y el control del proyecto, la planificación y la evaluación de cada iteración y fase son los aspectos fundamentales de la disciplina de gestión de proyectos.

file://C:\cp\JABAD\sitios\RUP\RUP-GP\RUP-GP\rup\guidances\supportingmaterials\pro... 2009-08-01

Material de soporte: Process Essentials

Page 2 of 5

Un plan de desarrollo de software recopila la información que se necesita para gestionar el proyecto. Se utiliza para planear la planificación de proyectos y las necesidades de recursos, y para realizar un seguimiento del progreso de acuerdo con la planificación. Trata áreas como: organización de proyecto, planificación, presupuesto y recursos. También puede incluir planes sobre la gestión de requisitos, gestión de la configuración, resolución de problemas, garantía de calidad, evaluación y prueba, y aceptación del producto. En un proyecto sencillo, muchos de estos temas pueden describirse con una o dos frases cada uno. Por ejemplo, en la planificación de la gestión de la configuración podría anotarse lo siguiente: "Al final del día, el contenido de la estructura de directorios del proyecto se comprimirá, se copiará en un disco zip con etiqueta, que se marcará con un número de versión y se colocará en un archivador central." El formato de los artefactos de planificación no es tan importante como las actividades de planificación y la reflexión que conllevan. La apariencia del plan no importa ni tampoco las herramientas que utilice para construirlo. Como dijo Dwight D. Eisenhower: "El plan no es nada, pero la planificación lo es todo."

3. Riesgos: mitigar riesgos y realizar un seguimiento de asuntos relacionados Es fundamental identificar y atender los elementos de más riesgo en las primeras fases del proyecto y realizar un seguimiento de éstos y de otros temas relacionados. La Lista de riesgos sirve para capturar los riesgos percibidos para el éxito del proyecto. Identifica, en orden decreciente de prioridad, los sucesos que pueden llevar a un resultado negativo significativo. Para cada riesgo debería crearse un plan que lo reduzca. Sirve como punto focal para planificar las actividades de proyecto y es la base alrededor de la cual se organizan las iteraciones.

4. Caso de negocio: examinar el caso de negocio El caso de negocio proporciona la información necesaria, desde un punto de vista empresarial, para determinar si vale la pena invertir en este proyecto o no. El objetivo principal del caso de negocio es desarrollar un plan económico para realizar la visión del proyecto. Una vez desarrollado, el caso de negocio se utiliza para realizar una evaluación precisa del rendimiento de capital invertido (ROI) proporcionado por el proyecto. Proporciona la justificación del proyecto y establece las restricciones económicas. Ofrece información a las personas que toman las decisiones económicas sobre el valor del proyecto y se utiliza para determinar si el proyecto debe continuar. La descripción no debe entrar en detalles sobre aspectos específicos del problema, sino que debe crear un argumento convincente de por qué se necesita el producto. Debe ser breve para que todos los miembros del equipo del proyecto puedan entenderlo y recordarlo. En los hitos críticos, el caso de negocio se vuelve a examinar para ver si las estimaciones de rendimiento y coste esperado siguen siendo precisas, y si el proyecto se debe continuar.

5. Arquitectura: diseñar una arquitectura de componente En Rational Unified Process (RUP), la arquitectura de un sistema de software (en un punto determinado) es la organización o la estructura de los componentes importantes del sistema que interactúan mediante interfaces, con componentes compuestos de interfaces y componentes cada vez más pequeños. ¿Cuáles son las partes más importantes? ¿Cómo encajan entre sí? ¿Disponemos de una infraestructura a la que puede añadirse el resto del software? Para poder hablar y razonar sobre la arquitectura de software, antes debe definir una representación arquitectónica, una manera de describir aspectos importantes de una arquitectura. Esta descripción se captura en el Documento de arquitectura de software, que presenta la arquitectura en varias vistas.

file://C:\cp\JABAD\sitios\RUP\RUP-GP\RUP-GP\rup\guidances\supportingmaterials\pro... 2009-08-01

Material de soporte: Process Essentials

Page 3 of 5

Cada vista de la arquitectura trata un conjunto concreto de problemas, específico de interesados en el proceso de desarrollo: usuarios, diseñadores, gestores, ingenieros de sistemas, mantenedores, etc. Sirve como medio de comunicación entre el arquitecto de software y otros miembros del equipo de proyectos respecto a las decisiones significativas para la arquitectura que se llevan a cabo en el proyecto. Definir una arquitectura de candidato, redefinir la arquitectura, analizar el comportamiento y diseñar los componentes del sistema es la "esencia" de la disciplina de análisis y diseño, y del principio elevar nivel de abstracción.

6. Prototipo: construir de forma incremental y probar el producto RUP es un enfoque iterativo para la construcción, prueba y evaluación de versiones ejecutables del producto con el fin de desechar problemas y resolver riesgos y otros aspectos lo antes posible. Construir de forma incremental y probar los componentes del sistema es la "esencia" de las disciplinas de implementación y prueba y del principio Demostrar valor de forma iterativa.

7. Evaluación: valorar de forma regular los resultados Una comunicación abierta continua con datos objetivos derivados directamente de actividades continuas y de las configuraciones de producto que evolucionan son importantes en cualquier proyecto. La valoración de estado regular proporciona un mecanismo para dirigir, comunicar y resolver problemas de gestión, problemas técnicos y riesgos de proyecto. Además de identificar los problemas, a cada uno debe asignársele una fecha de vencimiento, con una persona responsable de la resolución,de la que se debe realizar un seguimiento y actualizar según se precise. Estas instantáneas del proyecto proporcionan la base para la atención de la gestión. Aunque el período puede variar, la función de forzar necesita capturar la historia del proyecto e intentar eliminar los cuellos de botella que impidan el progreso. La valoración de iteración captura el resultado de una iteración, el grado hasta el cual se cumplen los criterios de evaluación, las lecciones aprendidas y los cambios que se deben realizar. La valoración de iteración es un artefacto fundamental del enfoque iterativo. En función del ámbito y riesgo del proyecto y de la naturaleza de la iteración, puede variar desde el simple registro de demostración y resultados a un registro de revisión de prueba formal completa. La clave consiste en centrarse en problemas de proceso y de producto: "Cuanto antes se retrase, más tiempo dispondrá para ponerse al día."

8. Solicitudes de cambio: gestionar y controlar cambios En cuanto los usuarios disponen del primer prototipo (y muchas veces antes de eso), se solicitan cambios. Siempre sucede. Para controlar estos cambios y gestionar de manera eficaz el ámbito del proyecto y las expectativas de los interesados, es importante que todos los cambios que se realicen en artefactos de desarrollo se propongan a través de Solicitudes de cambio y se gestionen con un proceso coherente. Las solicitudes de cambio se utilizan para documentar y realizar un seguimiento de los defectos, solicitudes de mejora y cualquier otro tipo de solicitud de un cambio en el producto. Las solicitudes de cambio tienen la ventaja de que proporcionan un registro de decisiones y, debido a su proceso de valoración, se garantiza que los miembros del equipo de proyecto comprendan el impacto del cambio potencial. Las solicitudes de cambio son fundamentales para gestionar el ámbito del proyecto así como para valorar el impacto de los cambios propuestos. Gestionar y controlar el ámbito del proyecto, a media que se realizan cambios durante el ciclo vital del

file://C:\cp\JABAD\sitios\RUP\RUP-GP\RUP-GP\rup\guidances\supportingmaterials\pro... 2009-08-01

Material de soporte: Process Essentials

Page 4 of 5

proyecto, y mantener el objetivo de considerar y cumplir las necesidades de todos los interesados: ésta es la "esencia" de la disciplina de Gestión de cambios y configuración y de Material de soporte: Controlar cambios.

9. Soporte para el usuario: desplegar un producto que se pueda utilizar El objetivo del proceso es crear un producto que se pueda utilizar. Todos los aspectos del proceso deben adaptarse con este objetivo en mente. El producto es más que el software. Cómo mínimo, debe haber una guía del usuario, tal vez implementada a través de una ayuda en línea. También puede incluir una guía de instalación y notas del release. En función de la complejidad del producto, puede que sea necesario incluir materiales de formación, además de una lista de materiales con el paquete del producto. Las actividades asociadas forman la disciplina de despliegue.

10. Proceso: adoptar un proceso que se ajuste al proyecto Es fundamental que el proceso que se elija sea el adecuado para el tipo de producto que se va a desarrollar. Incluso después de haber elegido un proceso, no debe seguirse ciegamente; aplique el sentido común y la experiencia para configurar el proceso y las herramientas con el fin de ajustarse a las necesidades de la empresa y del proyecto. Adaptar un proceso al proyecto es una parte clave de la disciplina de entorno. Para obtener más información sobre cómo adaptar RUP a su proyecto y empresa, consulte Concepto: Personalización de RUP.

Conclusión Los principios fundamentales descritos proporcionan un medio para valorar rápidamente un proceso e identificar las áreas que necesitan mejorarse. Es importante considerar qué ocurriría si alguno de estos principios fundamentales se pasara por alto. Por ejemplo:















No tiene una visión: puede desviar su objetivo y perder el tiempo con distracciones irrelevantes. No tiene un proceso: sin un proceso común, puede haber malentendidos en el equipo sobre lo que se va a hacer y cuándo. No tiene un plan: no podrá realizar un seguimiento del progreso. No tiene lista de riesgos: puede que se esté centrando en aspectos inadecuados, lo cual puede tener consecuencias muy graves al cabo de unos meses. No tiene un caso de negocio: puede perder tiempo y dinero en el proyecto. Podría cancelarse o declararse en bancarrota. No tiene una arquitectura: no podrá encargarse de los problemas de comunicación, sincronización y acceso de datos cuando éstos se produzcan; también puede tener problemas de escala y rendimiento. No tiene un producto (prototipo): presente un producto al cliente lo antes posible. Acumular documentación no le asegura ni a usted ni al cliente que el producto sea correcto; sólo aumenta el riesgo de desbordamiento de presupuestos y programación o el fallo total del producto. No tiene evaluación: no rehúya los problemas. Es importante enfrentarse a la verdad. ¿Está cerca la fecha límite? ¿Ha cumplido los objetivos de calidad o de presupuesto? ¿Se está realizando un seguimiento adecuado de todos los aspectos? No tiene solicitudes de cambios: ¿Cómo realiza el seguimiento de las solicitudes de los interesados? ¿Cómo las prioriza? ¿Cómo se conservan las que tienen poca prioridad? No tiene soporte para el usuario: ¿qué ocurre cuando un usuario tiene una pregunta o no sabe cómo utilizar el producto? ¿Es fácil obtener ayuda?

Estos principios fundamentales proporcionan además una introducción a cada Agrupación de disciplinas: Disciplinas de RUP y soporte para sus disciplinas clave. Volver al inicio

file://C:\cp\JABAD\sitios\RUP\RUP-GP\RUP-GP\rup\guidances\supportingmaterials\pro... 2009-08-01

Material de soporte: Process Essentials

Page 5 of 5

© Copyright IBM Corp. 1987, 2006. Reservados todos los derechos.

file://C:\cp\JABAD\sitios\RUP\RUP-GP\RUP-GP\rup\guidances\supportingmaterials\pro... 2009-08-01