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.
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.
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.
|