Estas clasificaciones pueden utilizarse para describir cómo utilizar productos de trabajo (e informes) al personalizar
el proceso de desarrollo. Estos valores se pueden complementar con
un clasificador separado para definir los procedimientos de revisión del producto de trabajo. Si desea más información
sobre los niveles de revisión para productos de trabajo, consulte la Directriz: Niveles
de revisión.
Clasificación
|
Explicación
|
Debe tener
|
Debe utilizar este producto de trabajo. Es un producto de trabajo clave y puede provocar problemas más
adelante en el desarrollo si no se produce.
|
Debería tener
|
Debería tener este producto de trabajo, si es posible, pero es negociable. Si no produce este producto
de trabajo, debería poder justificar por que no.
|
Puede tener
|
Puede tener significa que no es necesario producir este producto de trabajo. Sólo se produce si añade
valor y si hay tiempo suficiente.
|
No tendrá
|
Significa que no utilizará este producto de trabajo. Esto se puede producir cuando un producto de
trabajo de Rational Unified Process se reemplaza con un producto de trabajo local.
|
Este esquema de clasificación puede ampliarse o personalizarse para reflejar la cultura individual de la empresa.
Un ejemplo de cuándo debe ajustarse esta clasificación depende del nivel de personalización que se esté llevando a
cabo. Por ejemplo, cuando se personaliza un proceso para un proyecto específico, la decisión de si un producto de
trabajo específico debe usarse o no se toma como parte del esfuerzo de personalización. En tales casos, el esquema de
clasificación anterior puede reducirse a "Necesario" y "No necesario". En otros casos, por ejemplo cuando
está personalización un proceso para una empresa y se ha previsto más personalización para los proyectos individuales,
se hace importante disponer de un esquema de clasificación más extenso, como el descrito en la tabla anterior. Si
desea más información sobre los distintos niveles de personalización, consulte Concepto:
Personalización de RUP.
Impacto de clasificación
Todos los productos de trabajo clasificados como Debe tener o Debería tener deben tener procedimientos de
revisión, herramientas, plantillas y prácticas de gestión de la configuración definidas.
La especificación de estos procedimientos es opcional para productos de trabajo clasificados como Puede tener.
Estas decisiones se pueden dejar a los desarrolladores o a los proyectos que deciden producir estos productos de
trabajo.
Todos los productos de trabajo clasificados como No tendrá deben justificar la omisión.
La ventaja principal de la adopción de este esquema de clasificación es que denota claramente cómo se ha personalizado
el proceso, y dónde se encuentran las opciones de negociación y de la toma de decisiones locales.
Una forma de pensar sobre el esquema de clasificación de un producto de trabajo es que establece las restricciones
sobre cómo se utilizan los elementos del proceso.
Por ejemplo, si decide que el proyecto puede tener un modelo de análisis, entonces una mayor personalización podría
ajustar estos valores decidiendo que el proyecto cumplirá uno de los criterios siguientes:
-
Tendrá un modelo de análisis
-
No tendrá un modelo de análisis
-
Seguirá en su estado actual (el modelo de análisis es opcional)
El esquema de clasificación se puede utilizar de forma dinámica permitiendo que el estado del producto de trabajo
cambie dependiendo de la fase del proyecto en que se encuentre.
En la tabla siguiente se muestran diferentes modos de tratar el modelo de análisis. La columna Utilización
define cómo se utiliza el producto de trabajo en cada una de las fases.
Producto de trabajo
|
Utilización
|
Comentario
|
Inicial
|
Elab
|
Const
|
Trans
|
Modelo de análisis
|
No tendrá
|
No tendrá
|
No tendrá
|
No tendrá
|
No se desarrolla ningún modelo de análisis
|
Modelo de análisis
|
Puede tener
|
Puede tener
|
Puede tener
|
Puede tener
|
Normal
|
Modelo de análisis
|
Puede tener
|
Debería
|
No tendrá
|
No tendrá
|
Un enfoque evolutivo donde el modelo de análisis se reemplaza con el modelo de diseño
|
Modelo de análisis
|
Debe
|
No tendrá
|
No tendrá
|
No tendrá
|
Un enfoque evolutivo donde el modelo de análisis es obligatorio durante la fase inicial para ayudar
en el ámbito del proyecto pero que se reemplaza con el modelo de diseño durante la elaboración
|
Modelo de análisis
|
Debería
|
Debe
|
Debe
|
Debe
|
Un proceso formal donde el modelo de análisis es un producto de trabajo obligatorio y preservado
que es opcional en la fase inicial
|
|