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