Tarea: Revisar la arquitectura
En esta tarea se define cuándo y cómo se realiza la revisión de una arquitectura y cómo se revisan los resultados.
Objetivo
  • Descubrir los riesgos desconocidos o percibidos en la planificación o el presupuesto.
  • Detectar los defectos de diseño de arquitectura. Los defectos de arquitectura son los más difíciles de arreglar y los más perjudiciales a largo plazo.
  • Detectar posibles discrepancias entre los requisitos y la arquitectura: sobrediseño, requisitos no realistas o que faltan. En concreto, la valoración puede examinar algunos aspectos que a menudo se omiten en las áreas de operación, administración y mantenimiento. ¿Cómo está instalado el sistema? ¿Cómo está actualizado? ¿Cómo se realiza la transición de las bases de datos actuales?
  • Evaluar una o varias calidades específicas de la arquitectura: rendimiento, fiabilidad, modificabilidad, seguridad, protección.
  • Identificar oportunidades de reutilización
Relaciones
Pasos
Recomendaciones generales
Objetivo Recomendaciones generales para cada revisión.

A una distancia de 6.000 metros, no hay una gran diferencia entre una valoración de arquitectura de software y cualquier otra valoración o revisión.

No obstante, una característica importante de la arquitectura de software es la falta de medidas específicas para muchos atributos de calidad de arquitectura; sólo unas pocas calidades de arquitectura se pueden medir objetivamente. El rendimiento es un ejemplo donde la medida es posible. Otras calidades son más cualitativas o subjetivas: la integridad conceptual, por ejemplo. Además, a menudo es difícil decidir qué significa una medida en ausencia de otros datos o una referencia para la comparación. Si hay disponible un sistema de referencia comprensible para los destinatarios, se recomienda expresar algunos de los resultados de la revisión relativos a este sistema de referencia. Esto ocurre en aquellos contextos donde el sistema que se está diseñando se puede comparar con un diseño anterior.

El momento del ciclo vital en el que se realiza esta valoración también afecta a su objetivo o utilidad.

Diagrama de iteración del ciclo vital del proyecto

  1. Al final de la fase inicial en un ciclo de desarrollo inicial, normalmente no existe una arquitectura concreta. No obstante, una revisión puede descubrir objetivos no realistas, partes que faltan, oportunidades perdidas de reutilizar los productos existentes, etc.
  2. El momento idóneo para una valoración de arquitectura de software es al final de la fase de elaboración. Esta fase se centra principalmente en la exploración en detalle de los requisitos y en crear líneas base de una arquitectura. RUP obliga a realizar una revisión de arquitectura en este punto. Este es el caso cuando se examina una amplia gama en detalle de calidades de arquitectura.
  3. Durante la fase de construcción se pueden realizar valoraciones más específicas para examinar atributos de calidad concretos como, por ejemplo, el rendimiento o la seguridad, y al final de la fase de construcción se pueden valorar los problemas que perduran y que no permiten que el producto sea idóneo para entregarlo a los usuarios finales.
  4. Al final de las fases de construcción o incluso transición pueden ejecutarse valoraciones de control de daños cuando realmente se hayan producido daños: si la construcción no finaliza, o si aparece un nivel inaceptable de problemas en la base instalada durante la transición.
  5. Por último, la valoración puede tener lugar al final de la fase de transición, en concreto para realizar un inventario de los activos reutilizables para un nuevo producto o ciclo de evolución posterior.

El revisor de "igual" tiene el mismo perfil de personal que el del rol: arquitecto de software, aunque más centrado en los problemas técnicos. El liderazgo, la madurez, el pragmatismo y la orientación hacia los resultados son importantes en menor grado, pero continúan siendo importantes: un revisor puede descubrir defectos de arquitectura que serán impopulares si amenazan a la planificación del proyecto. No obstante, es mejor detectar pronto los problemas graves, cuando todavía se pueden resolver, que seguir a ciegas una planificación que lleve al equipo del proyecto por el camino equivocado. El revisor de arquitectura tiene que equilibrar riesgos y costes, tiendo siempre en cuenta los problemas más generales que afectan al éxito del proyecto. El revisor de arquitectura también tiene que ser un comunicador persuasivo que pueda detectar y analizar asuntos delicados.

Reuniones de revisión recomendadas
Objetivo Definir el ámbito y los objetivos de la revisión.
Definir los enfoques utilizados para cada combinación específica de ámbito y objetivos. 

Para realizar la revisión se pueden utilizar distintos enfoques:

  • controlado por representaciones
  • controlado por la información
  • controlado por casos de ejemplo
Revisión controlada por representaciones

Obtenga (o cree) una representación de la arquitectura y, a continuación, formule preguntas y razónelas basándose en esta representación.

Existe una amplia gama de situaciones, desde las organizaciones que tienen una gran cultura en arquitectura y proporcionarán descripciones inteligibles desde el principio, a organizaciones donde deberá identificar quién es el arquitecto de software (que puede estar oculto incluso bajo otro nombre) y extraer la información de esa persona, o aquellas en las que la arquitectura de software es un concepto totalmente desconocido. Este proceso se denomina "minar la arquitectura" y, a la práctica, es bastante literal: cavar y extraer el software o su documentación a pico y pala, teniendo en cuenta el código fuente, las interfaces, los datos de configuración, etc.

Un modelo que se puede utilizar para organizar la representación se encuentra en el formato de las vistas de la arquitectura presentadas en el Documento de arquitectura de software: la vista lógica organiza las principales clases (el modelo de objeto), la vista de proceso describe las principales hebras de control y cómo se comunican, la vista de desarrollo muestra los distintos subsistemas y sus dependencias, y la vista física describe la correlación de elementos de las otras vistas en una o varias configuraciones físicas. Organice los temas según las distintas vistas.

Revisión controlada por la información

Establezca la lista de información (datos, medidas) necesaria para razonar, obtener la información y compararla con los requisitos o con algún estándar de referencia aceptado. Esta revisión está especialmente indicada para investigar determinados atributos de calidad como, por ejemplo, el rendimiento o la fuerza.

Revisión controlada por casos de ejemplo

Este es el enfoque sistemático de "qué ocurre si". Transforme las preguntas generales que se están realizando en un conjunto de casos prácticos que debe pasar el sistema y formule preguntas basadas en los casos de ejemplo. Estos casos de ejemplo son, por ejemplo:

  • El sistema se ejecuta en las plataformas X e Y. (El atributo de calidad real probado es la portabilidad).
  • El sistema ejecuta esta función F (adicional). (El atributo de calidad real es la capacidad de ampliación).
  • El sistema procesa 200 solicitudes por hora. (El atributo de calidad real es la escalabilidad).
  • El sistema está siendo instalado en este tipo de sitio por el usuario. (El atributo de calidad real es la completitud o la utilización).

La ventaja de este tipo de enfoque es que coloca la tarea en una perspectiva muy concreta, comprensible para todas las partes. También permite probar omisiones o defectos en los requisitos, especialmente cuando los requisitos son informales, no se han escrito o son muy generales y ligeros. La desventaja es que no engloba la arquitectura como el objeto que se está revisando, sino que toma el sistema como una caja negra a la que sólo se envían algunas pruebas.

En la práctica, los enfoques no están separados tan claramente y al final se acaban combinando.

Identificar problemas

El descubrimiento de problemas potenciales se realiza principalmente según el juicio humano, basándose en los conocimientos y la experiencia. Algunos patrones de anomalía se repiten de un proyecto a otro, o de una organización a otra. Se puede utilizar la heurística para descubrir áreas de problemas. Las listas de comprobación pueden ser muy útiles (más adelante se proponen algunas muy genéricas), así como los resultados de las revisiones anteriores, si existen.

Capture los problemas potenciales a medida que aparezcan y descríbalos con un tono neutro, sin juicios acusatorios ni 'catastrofismos'. Puede utilizar pequeñas tarjetas de cartulina como hacen los revisores de AT&T, o como hacemos nosotros con las tarjetas CRC, para la priorización, organización y eliminación.

Posteriormente, ordene los problemas candidatos en orden de ámbito o impacto decreciente y, si hay muchos, aborde primero los que estén relacionados directamente con la pregunta específica y deje para después las "otras sugerencias", si tiene tiempo para ellas. A continuación, valore la realidad del problema: muchas veces podemos percibir un problema, pero luego no existe. Puede que no hayamos hablado con la persona correcta o que no hayamos encontrado la información adecuada. Vuelva a ordenarlos. Asegúrese de tener múltiples coordenadas para verificar la realidad de un problema. (Los evaluadores inexpertos tienden a centrarse en una única hebra).

Cuando el problema se haya confirmado, examine rápidamente qué puede eliminarlo, sin que necesariamente se tenga que realizar el rediseño dinámico del sistema. Escriba posibles simplificaciones, reutilizaciones y alternativas (por ejemplo, comprar en lugar de construir).

Asignar responsabilidades de resolución de defectos
Objetivo Realizar acciones en los defectos identificados. 

Después de la revisión, asigne una responsabilidad a cada defecto identificado. La "responsabilidad" en este caso puede que no sea solucionar el defecto, sino coordinar la investigación adicional de alternativas, o coordinar la resolución del defecto si tiene un ámbito amplio o inabarcable.



Propiedades
Varias apariciones
Condicionado por sucesos
Continuo
Opcional
Planeado
Se puede repetir
Más información