Gestión de Software
Grupo 10
Evaluación de Arquitecturas deSoftware
- Índice -
Evaluación de Arquitecturas de Software - Grupo 10
Los puntos a tratar en esta presentación son los siguientes:
Introducción
SAMM
ATAM
Evaluación de Arquitecturas de Software
ARID
Conclusiones
- Introducción -
Evaluación de Arquitecturas de Software - Grupo 10
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
- Introducción -
Evaluación de Arquitecturas de Software - Grupo 10
Implicancias de la definición:
La arquitectura es una abstracción de un sistema o sistemas
Los sistemas están compuestos por muchas estructuras (comúnmente llamadas vistas)
Como la arquitectura es abstracta, esta elimina la información local, los detalles de componentes privados no son arquitectónicos
- Evaluación de una Arquitectura de Software -
Evaluación de Arquitecturas de Software - Grupo 10
¿Cómo puedo estar seguro que la arquitectura elegida es la correcta
para mi software?
- Evaluación de una Arquitectura de Software -
Evaluación de Arquitecturas de Software - Grupo 10
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 una Arquitectura de Software -
Evaluación de Arquitecturas de Software - Grupo 10
¿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 una Arquitectura de Software -
Evaluación de Arquitecturas de Software - Grupo 10
¿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 una Arquitectura de Software -
Evaluación de Arquitecturas de Software - Grupo 10
¿Cuándo una Arquitectura puede ser evaluada?
Evaluación temprana
Evaluación tardía
- Evaluación de una Arquitectura de Software -
Evaluación de Arquitecturas de Software - Grupo 10
¿Quiénes están involucrados?
Equipo de evaluación
Stakeholders
- Evaluación de una Arquitectura de Software -
Evaluación de Arquitecturas de Software - Grupo 10
¿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 una Arquitectura de Software -
Evaluación de Arquitecturas de Software - Grupo 10
¿Por qué cualidades puede ser evaluada una Arquitectura?
Performance
Availability
Security
Modifiability
- Evaluación de una Arquitectura de Software -
Evaluación de Arquitecturas de Software - Grupo 10
¿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 una Arquitectura de Software -
Evaluación de Arquitecturas de Software - Grupo 10
¿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 una Arquitectura de Software -
Evaluación de Arquitecturas de Software - Grupo 10
¿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
Propósito Contexto y escenarios Roles Método de análisis Fortalezas Debilidades
- SAAM
Evaluación de Arquitecturas de Software - Grupo 10
Basado en escenarios Foco modificabilidad Evaluar una arquitectura o
evaluar y comparar varias
- SAAM Propósito
Evaluación de Arquitecturas de Software - Grupo 10
- 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 indirectoEscenario indirecto Interacción de escenariosInteracción de escenarios. Dos o más
escenarios indirectos requieren cambios sobre el mismo componente
Evaluación de Arquitecturas de Software - Grupo 10
- 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
- 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
- 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
- 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
- ATAM -
Evaluación de Arquitecturas de Software - Grupo 10
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.
- ATAM -
Evaluación de Arquitecturas de Software - Grupo 10
Presentación
Investigación y Análisis
Pruebas
Informes
El método consta de nueve pasos, divididos en cuatro grupos:
- ATAM -
Evaluación de Arquitecturas de Software - Grupo 10
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
- ATAM -
Evaluación de Arquitecturas de Software - Grupo 10
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
- ATAM -
Evaluación de Arquitecturas de Software - Grupo 10
Presentación
Paso 3: Presentar la arquitectura
Las restricciones técnicas
Otros sistemas
Propuestas arquitectónicas
- ATAM -
Evaluación de Arquitecturas de Software - Grupo 10
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
- ATAM -
Evaluación de Arquitecturas de Software - Grupo 10
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.
- ATAM -
Evaluación de Arquitecturas de Software - Grupo 10
Investigación y Análisis
Paso 5: Generar el árbol de utilidad de los atributos de calidad
- ATAM -
Evaluación de Arquitecturas de Software - Grupo 10
Investigación y Análisis
Paso 6: Analizar las propuestas arquitectónicas
- ATAM -
Evaluación de Arquitecturas de Software - Grupo 10
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
Pruebas
- ATAM -
Evaluación de Arquitecturas de Software - Grupo 10
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 losartefactos arquitectónicos
- ATAM -
Evaluación de Arquitecturas de Software - Grupo 10
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
An Evaluation Method for Partial Architectures
- ARID -
Evaluación de Arquitecturas de Software - Grupo 10
Método conveniente para realizar la evaluación de diseños parciales en las etapas tempranas del desarrollo.
• Revisiones de Diseños Activas
- ARID -
Evaluación de Arquitecturas de Software - Grupo 10
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
ADRs
- ARID -
Evaluación de Arquitecturas de Software - Grupo 10
Un ADR/ATAM híbrido
Características útiles para el problema de la evaluación de diseños preliminares.
- ARID -
Evaluación de Arquitecturas de Software - Grupo 10
Roles en ARID
Equipo de verificación.
Arquitecto.
Stakeholders.
- ARID -
Evaluación de Arquitecturas de Software - Grupo 10
Método ARID
Fase 1: Pre reunión
Fase 2: Evaluación
9 pasos separados en dos fases
- ARID -
Evaluación de Arquitecturas de Software - Grupo 10
FASE 1
Identificar los revisores.
Preparar la preparación del diseño.
Preparar los escenarios
Preparar los materiales
- ARID -
Evaluación de Arquitecturas de Software - Grupo 10
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
- Conclusiones -
Evaluación de Arquitecturas de Software - Grupo 10
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.