Active Reviews for Intermediate Designs (ARID)
| ||||
Revisión Activa para el Diseño Intermedio (Active Reviews for Intermediate Designs, ARID), método de evaluación arquitectura de software.
Sumario
Descripción
De los métodos de evaluación de arquitectura de software existente el ARID, es conveniente para realizar la evaluación de diseños parciales en las etapas tempranas del desarrollo. En ocasiones, es necesario saber si un diseño propuesto es conveniente, desde el punto de vista de otras partes de la arquitectura. ARID es un híbrido entre Revisión Activa del Diseño (Active Design Review, ADR) y ATAM.
Por su parte el ADR es utilizado para la evaluación de diseños detallados de unidades de software como los componentes o módulos. Las preguntas giran en torno a la calidad y completitud de la documentación y la suficiencia, el ajuste y la conveniencia de los servicios que provee el diseño propuesto.
Tanto ADR como ATAM proveen características útiles para el problema de la evaluación de diseños preliminares, dado que ninguno por sí solo es conveniente. En el caso de ADR, los involucrados reciben documentación detallada y completan cuestionarios, cada uno por separado. En el caso de ATAM, está orientado a la evaluación de toda una arquitectura.
Ante esta situación, y la necesidad de evaluación en las fases tempranas del diseño; la utilización de las características que proveen tanto ADR como ATAM por separado. De ADR, resulta conveniente la fidelidad de las respuestas que se obtiene de los involucrados en el desarrollo.
Así mismo, la idea del uso de escenarios generados por los involucrados con el sistema es tomada del ATAM. De la combinación de ambas filosofías surge ARID, para efecto de la evaluación temprana de los diseños de una arquitectura de software.
Funcionamiento
El método ARID consta de los siguientes pasos:
Fase1: Actividades Previas.
1.Identificación de los encargados de la revisión. Los encargados de la revisión son los ingenieros de software que se espera que usen el diseño, y todos los involucrados en el diseño. En este punto, converge el concepto de encargado de revisión de ADR e involucrado del ATAM.
2.Preparar el informe de diseño. El diseñador prepara un informe que explica el diseño. Se incluyen ejemplos del uso del mismo para la resolución de problemas reales. Esto permite al facilitador anticipar el tipo de preguntas posibles, así como identificar áreas en las que la presentación puede ser mejorada.
3.Preparar los escenarios base. El diseñador y el facilitador preparan un conjunto de escenarios base.De forma similar a los escenarios del ATAM y el SAAM, se diseñan para ilustrar el concepto de escenario, que pueden o no ser utilizados para efectos de la evaluación.
4.Preparar los materiales. Se reproducen los materiales preparados para ser presentados en la segunda fase. Se establece la reunión, y los involucrados son invitados.
Fase 2: Revisión.
5.Presentación del ARID. Se explica los pasos del ARID a los participantes.
6.Presentación del diseño. El líder del equipo de diseño realiza una presentación, con ejemplos incluidos. Se propone evitar preguntas que conciernen a la implementación o argumentación, así como alternativas de diseño. El objetivo es verificar que el diseño es conveniente.
7.Lluvia de ideas y establecimiento de prioridad de escenarios. Se establece una sesión para la lluvia de ideas sobre los escenarios y el establecimiento de prioridad de escenarios. Los involucrados proponen escenarios a ser usados en el diseño para resolver problemas que esperan encontrar. Luego, los escenarios son sometidos a votación, y se utilizan los que resultan ganadores para hacer pruebas sobre el diseño.
8.Aplicación de los escenarios. Comenzando con el escenario que contó con más votos, el facilitador solicita el pseudo-código que utiliza el diseño para proveer el servicio, y el diseñador debe ayudar en esta tarea.
Este paso continúa hasta que ocurra alguno de los siguientes eventos:
- Se agota el tiempo destinado a la revisión.
- Se han estudiado los escenarios de más alta prioridad.
El grupo se siente satisfecho con la conclusión alcanzada. Puede suceder que el diseño presentado sea conveniente, con la exitosa aplicación de los escenarios, o por el contrario, no conveniente, cuando el grupo encuentra problemas o deficiencias.
9.Resumen
Al final, el facilitador recuenta la lista de puntos tratados, pide opiniones de los participantes sobre la eficiencia del ejercicio de revisión, y agradece por su participación.
Conclusiones
El ARID, incorpora fuertes cualidades del método ADR y ATAM. Este método evalúa la idoneidad de los diseños arquitectónicos en las primeras fases de definición. Permite reunir las partes interesadas y los diseñadores en las primeras fases de desarrollo del software. Los involucrados generan los escenarios para analizar la capacidad de la arquitectura, mientras que el uso de escenarios genera una lluvia de ideas por parte de los diseñadores, sobre nuevos diseños y evaluaciones. Luego de terminado el proceso de evaluación, se pasa a realizar las adecuaciones pertinentes en el diseño de la arquitectura.
Este método tiene como principal desventaja que sólo analiza los componentes de la arquitectura, sin tener en cuenta las conexiones que se establecen entre ellos. Unido a esto, está el inconveniente de que no contempla ningún atributo de calidad, sino que sólo evalúa la conveniencia del diseño arquitectónico.
Véase También
- Architecture Trade-off Analysis Method (ATAM).
- Análisis de Arquitecturas de Software (SAAM).
- Architecture Level Modifiability Analysis (ALMA).
- Performance Assessment of Software Architecture (PASA).
- Scenario Based Architecture Level Usability Analysis (SALUTA).
- Survivable Network Analysis (SNA).
Fuentes
- Kazman, R, Bass, L y Clements, P. 2003. Software Architecture in Practice. 2da Edición. s.l. : Addison-Wesley Professional, 2003. pág. 560. ISSN: 0321154959 .
- Kazman, R, Clements, Paul y Klain, M. 2005.Evaluating Software Architectures.Methods and case studies. 1ra Edicición. s.l. : Adison-Wesley Professional, 2005. pág. 368. ISSN: 978-0201704822 .
