Professional Documents
Culture Documents
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!).
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.
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:
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.
"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."
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.
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.
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
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.
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.
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."
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.
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
file://C:\cp\JABAD\sitios\RUP\RUP-GP\RUP-GP\rup\guidances\supportingmaterials\pro... 2009-08-01