Decidir cómo realizar cada disciplina
Una parte de la personalización de la estructura de RUP que se utilizará en un proyecto específico consiste en decidir
qué disciplinas deben introducirse. Tal como se describe en el apartado Tarea:
Personalizar el proceso de desarrollo para el proyecto, debe evitar utilizar todo el producto RUP en un único
proyecto. Y si su proyecto es muy nuevo para las prácticas descritas en RUP, debe concentrarse en limitar el número de
factores desconocidos a unos pocos con el fin de facilitar la transición de los equipos a una nueva plataforma de
proceso.
Una vez que haya decidido qué disciplinas debe introducir, decida lo siguiente para cada una de ellas:
-
Cómo llevar a cabo el flujo de trabajo.
-
Qué partes del flujo de trabajo deben utilizarse.
-
Cuándo, a lo largo del ciclo de vida del proyecto, se deben introducir los flujos de trabajo y sus
componentes.
Para ayudarle en su toma de decisión, para cada disciplina se han desarrollado unas directrices denominadas "Decisiones
importantes en la <disciplina X>. En estas directrices, hay una sección llamada "Decida cómo llevar a cabo el
flujo de trabajo". Consulte las directrices adjuntas para ver las disciplinas incluidas en esta configuración.
Cuando se plantee introducir una determinada disciplina, o una parte de ella, tenga en cuenta lo siguiente:
-
Aplicabilidad. ¿Es aplicable para el proyecto? ¿Realmente añade valor introducirla?
-
Problemas y causas raíz que se tratan. ¿Trata alguno de los problemas percibidos y sus causas raíz?
-
Soporte de herramientas. ¿Qué soporte de herramientas se necesita?
-
Temporización. ¿Cuándo durante el ciclo de vida del proyecto debe introducirse? Consulte el apartado Concepto: Implementación de un proceso en un proyecto para obtener más
información.
-
Coste de la implementación. ¿Cuál es el coste de implementarla en el proyecto? El coste incluye:
-
Coste de formación de los miembros del proyecto.
-
Coste de instalación de las herramientas de soporte.
-
Coste de desarrollo de directrices y plantillas.
|
Personalizar artefactos por disciplina
Seleccione el conjunto correcto de productos de trabajo que debe producir el proyecto. Si no puede justificar
claramente por qué debe producirse el producto de trabajo, por ejemplo si ningún interesado externo lo ha solicitado,
considere la posibilidad de excluirlo.
Es una práctica recomendada utilizar el guión de desarrollo para documentar las desviaciones del proceso subyacente, de
modo que se pueda justificar y documentar la exclusión de algún producto de trabajo.
Efectúe los pasos siguientes:
-
Decida cómo debe utilizarse el producto de trabajo (elemento de modelado o documento). Para obtener
información sobre un esquema de clasificación para documentar la importancia de los productos de trabajo
individuales y si se van a utilizar o no, consulte Directriz: Clasificación de productos de trabajo.
-
Decida el nivel de revisión para cada producto de trabajo y captúrelo en los "Detalles de la revisión". Para
obtener información detallada, consulte el apartado Directrices:
Niveles de revisión. Decida cómo va a revisar cada producto de trabajo; es decir, qué procedimientos de
revisión utilizará.
-
Decida cómo se van a capturar los resultados finales de una disciplina. ¿Necesita almacenar los resultados en
papel? Si es así, debe decidirse por uno o varios informes que extraigan los resultados de las herramientas y
capturar los resultados en papel.
-
Decida qué herramientas desea utilizar para desarrollar y mantener el producto de trabajo.
-
Decida qué propiedades va a utilizar y cómo va a utilizarlas. Consulte la tabla Propiedades de cada producto de
trabajo y la sección titulada "Personalización" de cada producto de trabajo.
-
Cuando corresponda, decida qué estereotipos va a utilizar. Para cada producto de trabajo, consulte la sección
titulada "Personalización".
-
Decida un esquema para los productos de trabajo del documento. Para el producto de trabajo respectivo, consulte la
parte "Esquema breve" de la descripción principal.
Además de estos pasos, también debe realizar lo siguiente:
-
Decida qué informes va a utilizar. Decida si necesita que algún informe de trabajo extraiga información de los
modelos y, a continuación, documente la información sobre papel para las revisiones. Estos informes de trabajo
normalmente se tratan informalmente ya que son temporales y se descartan una vez que ha finalizado la revisión. Es
posible que necesite personalizar el esquema.
Hay más cosas que debe decidir para cada disciplina. Para obtener más detalles, consulte las directrices de "decisiones
importantes en <nombre de la disciplina>" para cada disciplina.
|
Personalizar tareas por disciplina
Estudie el conjunto modificado de productos de trabajo y las tareas que utilizan, crean y actualizan estos productos de
trabajo. Decida si debe modificar o simplificar estas tareas. Tenga en cuenta que para cada tarea se indican productos
de trabajo de entrada y salida. Asegúrese de suprimir los pasos o tareas innecesarios. Considere lo siguiente:
-
Introduzca nuevos pasos y posiblemente nuevas tareas que reflejen los productos de trabajo, informes y documentos
que haya tenido que añadir.
-
Examine cómo las herramientas utilizadas pueden facilitar, automatizar o incluso suprimir algunos de los pasos.
-
Introduzca en las tareas las directrices y reglas específicas heredadas a partir de la experiencia de la
organización. Pueden añadirse como puntos de orientación, listas de comprobación, elementos de revisión o dejarse
como documentos independientes a los que se puede hacer referencia.
-
Una vez que se conocen las tareas, revise los flujos de trabajo asociados con cada disciplina que muestran cómo
interaccionan las tareas, eliminando o añadiendo tareas según sea necesario.
-
Pueden omitirse o crearse disciplinas enteras.
-
Es posible que tenga que introducir algunos roles adicionales para las tareas especiales que requieren habilidades
específicas.
Describa los cambios en el guión de desarrollo.
|
Elegir el modelo de ciclo de vida
Elija el tipo de modelo de ciclo de vida que debe utilizar el proyecto. Perfeccione el modelo de RUP y ajuste los
objetivos y los criterios de evaluación de los objetivos, si es necesario. Incluso puede decidir omitir una o varias de
las fases, o bien añadir o eliminar objetivos. Consulte los apartados Concepto:
Fase y Concepto:
Iteración para obtener más información e ideas. Documente el modelo de ciclo de vida del proyecto en la sección
"Visión general del guión de desarrollo" del guión de desarrollo.
Además de seleccionar el modelo de ciclo de vida general, también es importante decidir cómo se deben
ejecutar los flujos de trabajo de la disciplina (qué actividades se deben realizar y en qué orden), así como decidir
cuándo, a lo largo del ciclo de vida de ese proyecto, se debe introducir cada parte del flujo de trabajo de
las disciplinas. Para obtener información sobre cómo personalizar el flujo de trabajo de cada una de las
disciplinas de RUP, consulte las notas de uso de los flujos de trabajo de referencia que se proporcionan con cada
disciplina de RUP. Documente las decisiones del flujo de trabajo de la disciplina en el guión de desarrollo.
|
Describir iteraciones de ejemplo
Describa como mínimo una iteración de ejemplo (lo más probable es que describa varias) para cada fase. Estas
descripciones de iteraciones describen cómo funcionará el proyecto en diferentes iteraciones y fases del proyecto.
Consulte las diferentes descripciones de fases en la página Ciclo de vida de
RUP para ver ejemplos detallados.
El objetivo de describir iteraciones de ejemplo en el guión de desarrollo es comunicar a los equipos del proyecto qué
tareas realizará el proyecto y en qué orden. Como tal, puede servir como un plan de iteración más detallado. La
descripción de las iteraciones de ejemplo debe ser breve. No incluya detalles que pertenezcan a las tareas, productos
de trabajo y directrices. Puede elegir describir las iteraciones de ejemplo en términos de tareas o actividades. Las
descripciones basadas en actividades pueden ser más fáciles de utilizar para la planificación y control a nivel de
gestión, pero las descripciones basadas en tareas son preferibles cuando se utilizan a nivel de usuario.
En la mayoría de casos, debe describir como mínimo una iteración de ejemplo por fase. Describa las iteraciones de
ejemplo según se vayan necesitando; no hay ningún motivo para describir cómo trabajar durante la fase de transición al
principio de un proyecto. Empiece definiendo cómo funcionará el proyecto en la fase inicial.
|
Identificar los interesados
El rol Interesado representa todos los posibles interesados de un proyecto.
Debe identificar y describir los diferentes tipos de interesados, sus necesidades y sus responsabilidades. Ejemplos de
diferentes interesados son el representante del cliente, el inversor, el gestor de producción y el comprador.
Describa los diferentes interesados y sus necesidades en el guión de desarrollo, en la sección "Roles".
|
Correlacionar roles con posiciones de trabajo
En algunas organizaciones de desarrollo se definen posiciones de trabajo. Si estas posiciones de trabajo se utilizan
habitualmente y tienen una amplia aceptación dentro de la organización, quizás valga la pena realizar una correlación
entre los roles de RUP y las posiciones de trabajo de la organización. La correlación de posiciones de trabajo con
roles puede facilitar que las personas de la organización entiendan mejor cómo emplear RUP. La correlación también
puede ayudar a las personas a comprender que los roles no son posiciones de trabajo, lo cual es una creencia errónea
muy extendida. Documente esta correlación en el guión de desarrollo, en la sección "Roles".
|
Documentar el guión de desarrollo
Describa el guión de desarrollo. Consulte la sección "Opciones de representación", así como cualquier guía asociada
(p.e., plantillas y/o ejemplos).
|
Mantener el guión de desarrollo
Muchas de las decisiones deben tomarse antes de iniciar el proyecto. Después de cada iteración en el proyecto de
desarrollo de software, debe evaluar el proceso y reconsiderar las decisiones que ha tomado. Si sale una nueva versión
de la configuración subyacente, debe actualizar el guión de desarrollo.
|
|