¿Cuál es un buen método para hacer una evaluación de arquitectura ligera?

Estoy familiarizado con los métodos de evaluación de la arquitectura, como el Método de Análisis de Arquitectura de Comercio (ATAM) y el Método de Análisis de Beneficios de Costos (CBAM) más orientado a los negocios . Sin embargo, estos métodos son bastante grandes: prescriben varias sesiones de lluvia de ideas, presentaciones, desarrollo de una serie de escenarios que describen las compensaciones, etc. Si bien son útiles para proyectos de cierto tamaño, son demasiado grandes para proyectos internos o aplicaciones de escritorio que generalmente son desarrollado por un puñado de desarrolladores (o menos), que a pesar de ser pequeños, tienen algunas restricciones de calidad bastante pronunciadas (rendimiento, escalabilidad, adaptabilidad).

Una práctica típica que he usado en el pasado es tener un desarrollador (o el arquitecto si un equipo tiene uno) para elaborar una arquitectura general para la aplicación y luego discutirla en una pizarra con el resto del equipo, generalmente usando alguna notación pseudo-UML que es fácil de dibujar y entender. Esto generalmente lleva a comentarios y algunas iteraciones sobre la arquitectura. Pero tiende a ser demasiado informal, causando todo tipo de suposiciones que luego pueden convertirse en decisiones equivocadas.

Los métodos como ATAM generalmente obligan a todas las partes interesadas a pensar profundamente sobre la arquitectura, lo que lleva a discusiones hasta que al menos todos estén de acuerdo en qué es exactamente la arquitectura .

¿Alguien tiene experiencia con la evaluación de arquitectura inicial ligera? Si es así, ¿cuáles son las buenas prácticas?

La clave para la evaluación ligera es evaluar las cosas correctas en el momento correcto. Hay dos maneras que conozco para hacer esto de manera efectiva. Con la evaluación basada en escenarios, utiliza escenarios de atributos de calidad y casos de uso para impulsar la evaluación centrándose solo en los atributos de calidad de alta prioridad. Con la evaluación basada en el riesgo, identifica los riesgos y deja que los riesgos identificados dirijan sus actividades de diseño de arquitectura.

Hay dos libros que puedo recomendar que exploran estos dos enfoques (algo relacionados).

El software de arquitectura de sistemas intensivos de Anthony Lattanze presenta la metodología de diseño centrado en la arquitectura y cubre evaluaciones basadas en escenarios livianos. Puede reconocer a Lattanze del Taller de Atributos de Calidad de SEI y hay ideas similares involucradas.

Arquitectura de software suficiente: un enfoque basado en el riesgo por George Fairbanks introduce, bueno, un enfoque basado en el riesgo para diseñar y evaluar la arquitectura de un sistema de software. También hay algunos capítulos gratuitos disponibles en su sitio web si desea una vista previa. Si bien los principios de este libro son inmediatamente aplicables, el enfoque no viene con un método específico, por lo que deberá combinar ideas de otras áreas. Recomiendo encarecidamente el enfoque de gestión continua de riesgos de SEI para identificar / priorizar riesgos.

La idea básica detrás de estos enfoques es que reduce el costo de evaluación (y diseño) evaluando a medida que avanza en lugar de esperar hasta el final. Si bien esto es ciertamente un poco más pesado que hablar alrededor de una pizarra, no es tan costoso como un ATAM completo. Y si se siente cómodo, puede elegir prácticas para satisfacer sus necesidades específicas.

No importa qué enfoque use para conducir la evaluación, la idea general será la misma ...

Antes de que empieces:

• Escenarios o riesgos de atributos de calidad, priorizados (puede ser informal si eso es todo lo que tiene)
• Definición clara para la decisión de ir / no ir (¿cómo sabe que la arquitectura es "suficientemente buena")
• Corte más reciente de la descripción de la arquitectura (el artefacto que está evaluando)

Siéntate para una sesión de evaluación:

• Arquitecto presenta una visión general de la arquitectura.
• Recorre una vista, muestra cómo se satisface el escenario o el riesgo
• Los problemas se registran para ser solucionados más tarde
• Los roles y el procedimiento general son similares a los utilizados para una inspección de Fagan (arquitecto o autor, moderador, registrador).
• La sesión puede tomar tan poco como una o dos horas, dependiendo del tamaño de su sistema.

Una vez que termine la sesión:

• Revise los problemas identificados y determine si se cumplen los criterios de ir / no ir. En general, se necesitan alrededor de 3 revisiones para que todo funcione. Si no se cumple, siga refinando y experimentando (o mitigando los riesgos de la arquitectura).
• Esta no es una evaluación de "todo o nada": diferentes partes de su arquitectura podrían "pasar" mientras que otras aún necesitan refinamiento.

Para ayudarlo a tener una idea de cómo podría ser el enfoque basado en escenarios, hay documentación pública de un proyecto final en el que trabajé en la escuela de posgrado. La documentación es un poco aproximada, pero podría ayudar a dar algunos ejemplos del enfoque basado en escenarios dentro del contexto de ACDM. Éramos un equipo de 5 y creamos una aplicación típica basada en la web, alrededor de 35 KLOC Java / GWT.

Para empezar, me gustan las discusiones informales de pizarra. Me gusta escribir solo la parte de la aplicación que se necesita hoy y luego dejar que la arquitectura emerja gradualmente durante la implementación. Es más como "encontrar la arquitectura", en lugar de tratar de inventarla de antemano. Este enfoque no requiere mucha evaluación inicial y ayuda a mantener su enfoque en lo que es importante (entregar software de trabajo).

Por supuesto, si sus requisitos no funcionales lo requieren (restricciones de memoria, tiempos de respuesta, número de usuarios concurrentes, etc.), debe tenerlo en cuenta al implementar el sistema.