Active Reviews for Intermediate Designs (ARID) - Historial de revisiones

Yoangel jc.scu: Revisión Activa para el Diseño Intermedio trasladada a Active Reviews for Intermediate Designs (ARID)

2011-08-23T14:04:26Z

Revisión Activa para el Diseño Intermedio trasladada a Active Reviews for Intermediate Designs (ARID)

Candelaria2 jc en 21:15 2 jul 2011

2011-07-02T21:15:41Z

Arian.Perez jc en 12:03 30 jun 2011

2011-06-30T12:03:49Z

Arian.Perez jc: Active Reviews for Intermediate Designs (ARID) trasladada a Revisión Activa para el Diseño Intermedio

2011-06-30T12:02:14Z

Active Reviews for Intermediate Designs (ARID) trasladada a Revisión Activa para el Diseño Intermedio

Yoangel jc.scu en 17:42 29 jun 2011

2011-06-29T17:42:35Z

Yoangel jc.scu en 19:46 28 jun 2011

2011-06-28T19:46:57Z

Yoangel jc.scu: Página creada con ' {{Ficha_Software|nombre=Active Reviews for Intermediate Designs(ARID) |imagen=evaluacion_de_arquitectura-de-software-atam.JPG |descripcion=M...'

2011-06-28T19:45:31Z

Página creada con ' {{Ficha_Software|nombre=Active Reviews for Intermediate Designs(ARID) |imagen=evaluacion_de_arquitectura-de-software-atam.JPG |descripcion=M...'

Página nueva

{{Ficha_Software|nombre=Active Reviews for Intermediate Designs(ARID) |imagen=evaluacion_de_arquitectura-de-software-atam.JPG
|descripcion=Método de Evaluación de Arquitectura de Software}}
'''Revisión Activa para el Diseño Intermedio''' (Active Reviews for Intermediate Designs, ARID), método de evaluación arquitectura de software.

==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.

==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 .

[[Category:Ingeniería_de_software]]

← Revisión anterior	Revisión del 14:04 23 ago 2011
(Sin diferencias)

@@ Línea 1: / Línea 1: @@
 {{Ficha_Software|nombre=Active Reviews for Intermediate Designs(ARID) |imagen=evaluacion_de_arquitectura-de-software-atam.JPG
 |descripcion=Método de Evaluación de Arquitectura de Software}}
 '''Revisión Activa para el Diseño Intermedio''' (Active Reviews for Intermediate Designs, ARID),  método de evaluación arquitectura de software.
 ==Descripción==
@@ Línea 8: / Línea 8: @@
 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:
@@ Línea 45: / Línea 49: @@
 Este paso  continúa hasta que ocurra alguno de los siguientes eventos:
-Se agota el tiempo destinado a la revisión.
+*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'''
@@ Línea 56: / Línea 59: @@
 ==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==
-[[Survivable Network Analysis  (SNA)]].
+*[[Architecture Trade-off Analysis Method (ATAM)]].
 ==Fuentes==
-'''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 .
+*'''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 .
 [[Category:Ingeniería_de_software]]

← Revisión anterior	Revisión del 12:02 30 jun 2011
(Sin diferencias)