Directriz: Decisiones importantes de análisis y diseño
En esta directriz se describen cuestiones importantes a tener en cuenta cuando se personalizan los aspectos del Análisis y el Diseño del proceso.
Relaciones
Descripción principal

Decidir cómo utilizar los productos de trabajo

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.

Decidir qué informes utilizar

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.

Decidir cómo revisar

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.

Decidir si se debe generar código

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.