1. Gestión de Software
Evaluación de Arquitecturas de
Software
Grupo 10

2. - Índice -
Los puntos a tratar en esta presentación son
los siguientes:
Introducción
Evaluación de Arquitecturas de Software
SAMM
ATAM
ARID
Conclusiones
Evaluación de Arquitecturas de Software - Grupo 10

3. - Introducción -
Definición de una Arquitectura de Software:
La Arquitectura de Software de un programa o
sistema de computación es la estructura o las
estructuras del sistema, que contienen
componentes de software, las propiedades
externamente visibles de dichos componentes
y las relaciones entre ellos.
Bass, 98
Evaluación de Arquitecturas de Software - Grupo 10

4. - Introducción -
Implicancias de la definición:
La arquitectura es una abstracción de un
sistema o sistemas
Como la arquitectura es abstracta, esta
elimina la información local, los detalles de
componentes privados no son arquitectónicos
Los sistemas están compuestos por muchas
estructuras (comúnmente llamadas vistas)
Evaluación de Arquitecturas de Software - Grupo 10

5. - Evaluación de una
Arquitectura de Software -
¿Cómo puedo estar seguro que la
arquitectura elegida es la correcta
para mi software?
Evaluación de Arquitecturas de Software - Grupo 10

6. - Evaluación de una
Arquitectura de Software -
Si las decisiones arquitectónicas
determinan los atributos de calidad
del sistema, entonces es posible
evaluar las decisiones
arquitectónicas con respecto a su
impacto sobre dichos atributos.
Evaluación de Arquitecturas de Software - Grupo 10

7. - Evaluación de una
Arquitectura de Software -
¿Cómo determinamos que forma parte de una
Arquitectura?
Debe ser un componente, relación entre
componentes, o una propiedad (de
componentes o relaciones) que necesita ser
externamente visible, con el objetivo de
razonar sobre la habilidad del sistema de
alcanzar sus requerimientos de calidad, o de
soportar la descomposición del sistema en
partes independientemente implementables
Evaluación de Arquitecturas de Software - Grupo 10

8. - Evaluación de una
Arquitectura de Software -
¿Por qué evaluar una Arquitectura?
Cuanto más temprano se encuentre un
problema en un proyecto de software, mejor
Realizar una evaluación de la arquitectura
es la manera más económica de evitar
desastres
Evaluación de Arquitecturas de Software - Grupo 10

9. - Evaluación de una
Arquitectura de Software -
¿Cuándo una Arquitectura puede ser
evaluada?
Evaluación temprana
Evaluación tardía
Evaluación de Arquitecturas de Software - Grupo 10

10. - Evaluación de una
Arquitectura de Software -
¿Quiénes están involucrados?
Equipo de evaluación
Stakeholders
Evaluación de Arquitecturas de Software - Grupo 10

11. - Evaluación de una
Arquitectura de Software -
¿Qué resultado produce la evaluación de una
Arquitectura?
La evaluación de una arquitectura no
produce resultados cuantitativos
La evaluación ayuda a encontrar debilidades
Evaluación de Arquitecturas de Software - Grupo 10

12. - Evaluación de una
Arquitectura de Software -
¿Por qué cualidades puede ser evaluada una
Arquitectura?
Performance
Availability
Security
Modifiability
Evaluación de Arquitecturas de Software - Grupo 10

13. - Evaluación de una
Arquitectura de Software -
¿Por qué los atributos de calidad son
demasiados imprecisos para el análisis?
El sistema debe ser robusto
El sistema debe ser modificable
El sistema debe ser seguro
El sistema debe tener una performance
aceptable
Evaluación de Arquitecturas de Software - Grupo 10

14. - Evaluación de una
Arquitectura de Software -
¿Cuáles son las salidas de una evaluación
arquitectónica?
Lista priorizada de los atributos de calidad
requeridos para la arquitectura que está
siendo evaluada.
Riesgos y no riesgos
Evaluación de Arquitecturas de Software - Grupo 10

15. - Evaluación de una
Arquitectura de Software -
¿Cuáles son los costos y beneficios de realizar
una evaluación arquitectónica?
Reúne a los stakeholders
Fuerza una articulación en las metas
específicas de calidad
Fuerza una explicación clara de la
arquitectura
Evaluación de Arquitecturas de Software - Grupo 10

16. - SAAM
 Propósito
 Contexto y escenarios
 Roles
 Método de análisis
 Fortalezas
 Debilidades
Evaluación de Arquitecturas de Software - Grupo 10

17. - SAAM Propósito
 Basado en escenarios
 Foco modificabilidad
 Evaluar una arquitectura o
evaluar y comparar varias
Evaluación de Arquitecturas de Software - Grupo 10

18. - SAAM Contexto y escenarios
 Atributos de calidad complejos y
amorfos para evaluarse simplemente
 Dependientes del contexto
 Escenario. Interacción entre un
interesado y el sistema
 Escenario directo. El sistema no debe
ser modificado para soportarlo
 Escenario indirecto
 Interacción de escenarios. Dos o más
escenarios
escenarios indirectos requieren
cambios sobre el mismo componente
Evaluación de Arquitecturas de Software - Grupo 10

19. - SAAM Roles
 Interesados externos (Organización
cliente, usuarios finales,
administradores del sistema, etc.)
 Interesados internos (Arquitectos de
Software, analistas de
requerimientos)
 Equipo SAAM (Líder, expertos en el
dominio de la aplicación, expertos
externos en arquitectura y secretario)
Evaluación de Arquitecturas de Software - Grupo 10

20. - SAAM Metodología
 Paso 1. Desarrollo de escenarios
 Paso 2. Descripción de la
Arquitectura
 Paso 3. Clasificación de escenarios
 Paso 4. Evaluación de escenarios
 Paso 5. Interacción de escenarios
 Paso 6. Evaluación general
Evaluación de Arquitecturas de Software - Grupo 10

21. - SAAM Fortalezas
 Los interesados comprenden con
facilidad las arquitecturas
evaluadas.
 La documentación es mejorada.
 El esfuerzo y el costo de los
cambios pueden ser estimados con
anticipación.
 Analogía con el concepto de bajo
acoplamiento y alta cohesión.
Evaluación de Arquitecturas de Software - Grupo 10

22. - SAAM Debilidades
 La generación de escenarios está
basada en la visión de los interesados
 No provee una métrica clara sobre la
calidad de la arquitectura Evaluada.
 El equipo de evaluación confía en la
experiencia de los arquitectos para
proponer arquitecturas candidatas.
Evaluación de Arquitecturas de Software - Grupo 10

23. - ATAM -
Architecture Tradeoff Analysis
Method
Este método de evaluación obtiene su nombre
no solo porque nos dice cuan bien una
arquitectura particular satisface las metas de
calidad, sino que también provee ideas de
cómo esas metas de calidad interactúan entre
ellas, como realizan concesiones mutuas
(tradeoff) entre ellas.
Evaluación de Arquitecturas de Software - Grupo 10

24. - ATAM -
El método consta de nueve pasos, divididos
en cuatro grupos:
Presentación
Investigación y Análisis
Pruebas
Informes
Evaluación de Arquitecturas de Software - Grupo 10

25. - ATAM -
Presentación
Paso 1: Presentar el ATAM
Los pasos del ATAM en resumen
Las técnicas que serán utilizadas para la
obtención y análisis
Las salidas de la evaluación
Evaluación de Arquitecturas de Software - Grupo 10

26. - ATAM -
Presentación
Paso 2: Presentar las pautas del negocio
Las funciones más importantes del sistema
Toda restricción técnica
La mayoría de los stakeholders
Las guías de la arquitectura
Evaluación de Arquitecturas de Software - Grupo 10

27. - ATAM -
Presentación
Paso 3: Presentar la arquitectura
Las restricciones técnicas
Otros sistemas
Propuestas arquitectónicas
Evaluación de Arquitecturas de Software - Grupo 10

28. - ATAM -
Investigación y Análisis
Paso 4: Identificar las propuestas
arquitectónicas
El ATAM centraliza el análisis de una
arquitectura en el entendimiento de sus
propuestas arquitectónicas, en este paso son
capturadas por el equipo de evaluación pero
no son analizadas
Evaluación de Arquitecturas de Software - Grupo 10

29. - ATAM -
Investigación y Análisis
Paso 5: Generar el árbol de utilidad de los
atributos de calidad
Este paso es crucial, pues guía el resto del
análisis. Sin esta guía, los evaluadores
pueden perder su tiempo analizando aspectos
de la arquitectura que no son de interés para
los stakeholders.
Evaluación de Arquitecturas de Software - Grupo 10

30. - ATAM -
Investigación y Análisis
Paso 5: Generar el árbol de utilidad de los
atributos de calidad
Evaluación de Arquitecturas de Software - Grupo 10

31. - ATAM -
Investigación y Análisis
Paso 6: Analizar las propuestas
arquitectónicas
Evaluación de Arquitecturas de Software - Grupo 10

32. - ATAM -
Pruebas
Paso 7: Lluvia de ideas y priorización de
escenarios
Este paso consiste en la generación de
nuevos escenarios para:
• Representar los intereses de los
stakeholders que no hayan sido
comprendidos
Evaluación de Arquitecturas de Software - Grupo 10

33. - ATAM -
Pruebas
Paso 8: Analizar las propuestas
arquitectónicas
En este paso el equipo de evaluación realiza
las mismas actividades que en el paso 6,
mapeando los escenarios recientemente
generados con ranking más alto en los
artefactos arquitectónicos
Evaluación de Arquitecturas de Software - Grupo 10

34. - ATAM -
Resultados
Paso 9: Presentar los resultados
El documento de propuestas arquitectónicas
El conjunto de escenarios priorizados
El árbol de utilidad
Los riesgos descubiertos
Los no riesgos documentados
Los sensitivity points y tradeoff points
encontrados
Evaluación de Arquitecturas de Software - Grupo 10

35. - ARID -
An Evaluation Method for Partial
Architectures
Método conveniente para realizar la
evaluación de diseños parciales en las etapas
tempranas del desarrollo.
Evaluación de Arquitecturas de Software - Grupo 10

36. - ARID -
ADRs
• Revisiones de Diseños Activas
Utilizado para la evaluación de diseños
detallados de unidades del 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
Evaluación de Arquitecturas de Software - Grupo 10

37. - ARID -
Un ADR/ATAM híbrido
Características útiles para el problema de la
evaluación de diseños preliminares.
Evaluación de Arquitecturas de Software - Grupo 10

38. - ARID -
Roles en ARID
Equipo de verificación.
Arquitecto.
Stakeholders.
Evaluación de Arquitecturas de Software - Grupo 10

39. - ARID -
Método ARID
9 pasos separados en dos fases
Fase 1: Pre reunión
Fase 2: Evaluación
Evaluación de Arquitecturas de Software - Grupo 10

40. - ARID -
FASE 1
Identificar los revisores.
Preparar la preparación del diseño.
Preparar los escenarios
Preparar los materiales
Evaluación de Arquitecturas de Software - Grupo 10

41. - ARID -
FASE 2
Presentación del método.
Presentación del diseño.
Lluvia de ideas y priorización de escenarios.
Realización de la revisión
Conclusiones
Evaluación de Arquitecturas de Software - Grupo 10

42. - Conclusiones -
El método SAAM lo sugerimos
cuándo el atributo de calidad
Modificabilidad es el de mayor
interés.
El método ATAM es más profundo
para evaluar aspectos más
relacionados con la arquitectura,
como la performance o la
confiabilidad.
El método ARID evalúa mejor la
factibilidad de la arquitectura.
Evaluación de Arquitecturas de Software - Grupo 10