Decida qué productos de trabajo utilizar y cómo utilizar cada uno de ellos. En la tabla siguiente se describen los
productos de trabajo obligatorios y los productos de trabajo que sólo se utilizan en casos concretos. Para obtener
información más detallada sobre cómo personalizar cada producto de trabajo, y una discusión de las ventajas y
desventajas de este producto de trabajo específico, lea la sección titulada "Personalización" de cada producto de
trabajo.
Para cada producto de trabajo, decida cómo debe utilizarse el producto de trabajo: Debe, Debería, Puede o No puede.
Para obtener más detalles, consulte el apartado Técnica: Clasificación de productos de trabajo.
Producto de trabajo
|
Objetivo
|
Personalización (Opcional, recomendada)
|
Modelo de análisis (Clase de análisis)
|
Un modelo de análisis es útil para comprender mejor los requisitos antes de tomar decisiones de diseño.
En sistemas complejos se puede mantener para proporcionar una visión general conceptual del sistema.
|
Opcional
En muchos proyectos, se utiliza un modelo de diseño inicial en lugar del modelo de análisis.
En proyectos que crean un modelo de análisis, por lo general es un artefacto temporal que
evoluciona en un modelo de diseño.
|
Mapa de navegación, Prototipo de interfaz de usuario
|
Los proyectos con una interfaz de usuario grande y compleja deben considerar el diseño de la interfaz
de usuario.
|
Opcional
Es posible que el diseño de una interfaz de usuario más informal sea suficiente en los esfuerzos de
desarrollo de menor tamaño.
|
Modelo de diseño
|
La mayoría de sistemas, incluso los sistemas más pequeños, se deben diseñar antes de su implementación
a fin de evitar con el objeto de evitar revisiones costosas debido a errores de diseño. Los modelos
visuales simplifican la comunicación del diseño. Las herramientas para revertir y aplicar la ingeniería
pueden garantizar la coherencia con el modelo de implementación, así como el ahorro de esfuerzo.
|
Recomendada para la mayoría de proyectos.
En proyectos más pequeños, la utilización de herramientas automatizadas no es crítica, pero puede
tener ventajas de productividad a largo plazo.
|
Clase de diseño; Paquete de diseños
|
Las clases y los paquetes son una parte básica de cualquier diseño orientado a objetos. El diseño
orientado a objetos es la propuesta de diseño estándar utilizada en la mayoría de proyectos.
|
Recomendada para la mayoría de proyectos.
Las cuestiones de personalización más importantes están en decidir los estereotipos que utilizar
(se puede capturar en las Directrices de diseño).
|
Ejecución de guiones de uso
|
Proporciona el puente de los guiones de uso al diseño.
|
Recomendada para la mayoría de proyectos.
|
Interfaz
|
Por lo general, las interfaces se utilizan para definir comportamiento, independientemente de los
componentes de mayor granularidad que realizan el comportamiento.
|
Recomendada para la mayoría de proyectos.
El diseño basado en componentes se está convirtiendo en una propuesta de diseño estándar.
|
Subsistema de diseño
|
Los subsistemas de diseño se utilizan para encapsular comportamiento en un componente que proporciona
interfaces. Se utiliza para encapsular las interacciones de clases y otros subsistemas.
|
Recomendada para la mayoría de proyectos.
Con frecuencia, los subsistemas resultan útiles para elevar el nivel de abstracción de diseño.
Simplifican la comprensión de los sistemas.
|
Suceso
|
Puede resultar útil para sistemas que responden a numerosos sucesos externos.
|
Recomendada para sistemas de tiempo real.
|
Protocolo
|
Obligatorio para sistemas de tiempo real.
|
Recomendada para sistemas de tiempo real.
|
Señal
|
Puede resultar útil para sistemas que requieren concurrencia y que están dirigidos por sucesos.
Obligatorio para sistemas de tiempo real.
|
Puede resultar útil para sistemas que requieren concurrencia y que están dirigidos por sucesos.
Recomendada para sistemas de tiempo real.
|
Cápsula
|
Para sistemas de tiempo real, pero puede resultar útil para modelar y diseñar cualquier sistema que
tengan un alto grado de concurrencia.
|
Recomendada para sistemas de tiempo real.
|
Modelo de datos
|
Se utiliza para describir la estructura lógica y, posiblemente, física de la información persistente.
|
Recomendada para proyectos que utilizan una base de datos.
|
Modelo de despliegue
|
Muestra la configuración de los nodos de proceso en tiempo de ejecución, los enlaces de comunicación
entre estos y los objetos e instancias de componentes que residen en los mismos.
|
Opcional.
Muchos sistemas tienen varios nodos de proceso y, por consiguiente, deben tratar el modelo de
despliegue. No obstante, se puede capturar como una sección del Documento de arquitectura de
software, y no es necesario que exista como un artefacto identificado por separado.
|
Arquitectura de prueba de concepto
|
Se utiliza para determinar si existe una solución que satisfaga los requisitos importantes
arquitectónicamente.
|
Recomendada para la mayoría de proyectos.
Muchos proyectos utilizan un concepto de Arquitectura de prueba de concepto para determinar la
viabilidad de los requisitos. Puede tener varios formatos, por ejemplo:
-
una lista de tecnologías conocidas que parecen adecuadas para la solución
-
un esbozo de un modelo conceptual de una solución
-
una simulación de una solución
-
un prototipo ejecutable.
|
Arquitectura de referencia
|
Las arquitecturas de referencia aceleran el desarrollo y reducen los riesgos por medio de la
reutilización de soluciones probadas.
|
Recomendada para la mayoría de proyectos.
Si existe material de Arquitectura de referencia adecuado, puede acelerar considerablemente el
desarrollo y reducir el riesgo.
|
Documento de arquitectura de software (SAD)
|
El Documento de arquitectura de software se utiliza para facilitar una visión general arquitectónica
completa del sistema. Esta visión general resulta útil tanto para comprender el sistema, como para
capturar decisiones arquitectónicas claves.
|
Recomendada para la mayoría de proyectos.
Una visión general de alto nivel de la arquitectura de software es útil en todos los sistemas,
incluidos casi los más pequeños. Por lo general, los sistemas complejos requieren un mayor nivel de
detalle y más vistas que los proyectos más pequeños.
|
Prototipo de interfaz de usuario
|
Se utiliza para exponer y probar la funcionalidad y la utilización antes de que se inicie el desarrollo
real. Es un medio eficaz de validar el diseño antes de perder demasiado tiempo.
|
Recomendada para la mayoría de proyectos.
|
Personalice cada producto de trabajo para que se adecue a las necesidades del proyecto. Para consideraciones sobre la
personalización, consulte el apartado de Personalización de la página de descripción de los productos de trabajo, o
bien, los pasos que se describen debajo de la cabecera "Personalizar productos de trabajo por disciplina" en Tarea: Desarrollar guión de desarrollo.
La decisión sobre los informes que utilizar depende de las herramientas de informe disponibles para el proyecto. Si hay
herramientas de generación de informes disponibles, se recomienda generar informes para productos de trabajo orientados
a modelo como, por ejemplo, Clases de diseño o Ejecuciones de guiones de uso. Los informes existentes de la
configuración de RUP están disponibles en las páginas de descripción de productos de trabajo o agrupados en el producto
de trabajo pertinente del navegador de árbol.
Decida el nivel de revisión para cada producto de trabajo y captúrelo en el guión de desarrollo, si dispone de uno.
Para obtener más detalles, consulte el apartado Directriz: Niveles
de revisión. Decida cómo revisar y aprobar los resultados de Análisis y diseño, y hasta qué punto desea revisar los
resultados.
Las ventajas de una revisión de diseño son las siguientes:
-
Detecta problemas que son imposibles o muy difíciles de detectar durante la prueba. Por ejemplo, cuestiones de
estilo y diseño.
-
Es un modo de reforzar un estilo de modelado común, y una oportunidad para que las personas aprendan entre
sí.
-
Detecta los defectos que, de otro modo, no se detectarían hasta más adelante en el proyecto durante las pruebas.
Las desventajas de una revisión de diseño son las siguientes:
-
Requiere tiempo y recursos.
-
Si no se gestiona de modo adecuado, es fácil no utilizarlo correctamente.
Los factores que se pueden alterar son el ámbito, los recursos y las técnicas de revisión. Lo siguiente son ejemplos
sobre las decisiones que puede tomar con respecto al proyecto:
-
Decidir que los cambios locales en un subsistema los realice sólo un igual, que dirija una inspección y entregue
los resultados en papel.
-
Decidir las partes del diseño que no se van a revisar en absoluto como, por ejemplo, revisar sólo algunas clases de
cada miembro del proyecto y esperar que así se garantice que el estilo sea de una calidad similar al resto de los
resultados.
-
Decidir si el cliente va a revisar el Documento de arquitectura de software durante una reunión separada.
-
Decidir el uso de reuniones de revisión formales para cambios en interfaces importantes, es decir, las interfaces
que afectan al trabajo de varios miembros del proyecto.
Para obtener más información sobre la revisión y los distintos tipos de revisiones, consulte Directriz: Revisiones.
El procedimiento que utiliza para diseñar varía en función de si genera código a partir del modelo de diseño o no. Si
genera código, el diseño debe ser muy detallado. Por otra parte, si no genera código a partir del diseño, no es
necesario que el diseño sea muy detallado. Al contrario, los detalles del diseño se deben sincronizar manualmente con
el código.
|