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.