Directriz: Personalización de RUP
Esta directriz proporciona recomendaciones para la personalización de RUP para una empresa o proyecto.
Descripción principal

En estas directrices se describen algunos aspectos a considerar a la hora de personalizar RUP. 

Si desea obtener un descripción del proceso global de personalización de RUP, consulte Concepto: Personalización de RUP

Si desea obtener un descripción de algunas recomendaciones generales relacionadas con la personalización de procesos, consulte Directriz: Prácticas del proceso de personalización.

Definición del ámbito del esfuerzo de personalización

La definición del ámbito del esfuerzo de personalización es donde debe identificar lo que desea cambiar y la forma en que desea cambiarlo.

Para definir el ámbito de forma eficaz, es importante que se familiarice con RUP.  Para obtener más información, consulte Introducción a RUP.

La parte del proyecto que decida personalizar, así como el nivel de personalización que decida llevar a cabo, dependen de ciertos factores. Estos factores se describen en la Directriz: Discriminadores del proceso.   

Elementos variables en los procesos de ingeniería de software

En esta sección se revisan las partes constitutivas de un proceso que es probable que se modifiquen, personalice, añadan o eliminen como parte de un esfuerzo de personalización de RUP.

  • Disciplinas
    Es muy poco frecuente que un proyecto de software se salte por completo alguna de las disciplinas, como análisis y diseño, implementación, etc. En casos excepcionales, algunas disciplinas, como los requisitos o el despliegue, pueden haber sido ejecutadas por otras empresas. Sin embargo, es más probable que se modifiquen los flujos de trabajo de una o varias disciplinas.  
  • Productos de trabajo
    Es mucho más probable que los proyectos difieran por los productos de trabajo que tienen que producir, actualizar y entregar. En un extremo del rango, imagine un proyecto sin un solo papel que se limita a mantener un pequeño número de productos de trabajo, y está soportado por herramientas como las hojas de cálculo, las herramientas de diseño, de programación y de prueba, y sólo entrega software y documentación electrónicamente en disco, CD o a través de la World Wide Web. En el otro extremo, hay proyectos que deben producir y mantener un conjunto mucho mayor de documentos por razones contractuales, normativas y organizativas. En algunos casos, pueden omitirse los modelos completos.
  • Tareas
    Las tareas pueden variar por al menos dos razones. Las tareas que utilizan productos de trabajo como entradas y producen, o actualizan, productos de trabajo como salida se ven afectadas por la modificación de estos productos de trabajo; en particular, si algún producto de trabajo, o elemento de información de un producto de trabajo, deja de ser necesario, los pasos correspondientes pueden suprimirse o modificarse significativamente. Las tareas también se modifican para introducir técnicas, herramientas y métodos específicos que pertenecen al dominio de la aplicación específica o a la especialidad de desarrollo, como los pasos de diseño, los lenguajes de programación, las herramientas de generación automática de código, las técnicas de medición, etc.

A un nivel más detallado, otros elementos de método pueden modificarse, añadirse o eliminarse:

  • Roles
  • Pasos de tareas
  • Directrices y guías para tareas
  • Notaciones, como el uso de subconjuntos de UML o el uso de estereotipos para tratar alguna necesidad específica de algunos modelos, o de todos.
  • Listas de comprobación para revisiones
  • Soporte de herramientas para automatizar algunas tareas
  • Cambios en la terminología, para adaptar el proceso al contexto de la empresa, por ejemplo

En resumen, el ingeniero de proceso debe tomar un amplio abanico de decisiones a la hora de personalización RUP. Es posible que haya que ajustar RUP para que se beneficie de ciertas prácticas y estándares bien establecidos en la empresa, como los documentos, la terminología, etc.



 

Casos de ejemplo de personalización difícil

Ciertos casos de ejemplo de personalización son difíciles de implementar y debe considerarse con mucha prudencia. Por ejemplo:

  • Cambio en la arquitectura dei proceso
    Un reempaquetado de amplio alcance de las tareas en otro conjunto de disciplinas para hacerlas coincidir con un proceso o empresa existente puede acarrear un gran esfuerzo a cambio de muy poco. A menudo, es más práctico establecer simplemente una correlación para valorar si RUP cubre todos los aspectos. No olvide que las disciplinas no son fases que se ejecuten de forma secuencial (son contenedores de tareas), y se ejecutan una y otra vez en cada iteración y a menudo de forma simultánea dentro de una iteración.
  • Cambios en la terminología
    Aunque sustituir una palabra por otra puede parecer un acto trivial en un procesador de textos, tales cambios deben considerarse con mucha cautela. En el ámbito de la ingeniería de software, las empresas suelen utilizar la misma palabra con significados ligeramente distintos, o palabras distintas que significan lo mismo. Realizar cambios aislados en RUP puede llevar a un proceso que sea muy difícil de comprender. Una solución es crear una "tabla de conversión" para la terminología en la que se ofrece la traducción entre la terminología de RUP y la de la empresa.

Algunos ejemplos de palabras delicadas son: sistema, fase, rol, actividad, tarea, modelo y documento.

Si los resultados del proceso se capturan en un idioma distinto del inglés, las cuestiones terminológicas son complejas, pues deberá traducir las descripciones de los productos de trabajo, los documentos, los informes y posiblemente otras partes de RUP a ese idioma.