Professional Documents
Culture Documents
Grupo 10
- ndice Los puntos a tratar en esta presentacin son los siguientes: Introduccin Evaluacin de Arquitecturas de Software SAMM
ATAM
ARID Conclusiones
La Arquitectura de Software de un programa o sistema de computacin 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
Como la arquitectura es abstracta, esta elimina la informacin local, los detalles de componentes privados no son arquitectnicos
Los sistemas estn compuestos por muchas estructuras (comnmente llamadas vistas)
Cmo puedo estar seguro que la arquitectura elegida es la correcta para mi software?
Si las decisiones arquitectnicas determinan los atributos de calidad del sistema, entonces es posible evaluar las decisiones arquitectnicas con respecto a su impacto sobre dichos atributos.
- Evaluacin de una Arquitectura de Software Cmo determinamos que forma parte de una Arquitectura? Debe ser un componente, relacin 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 descomposicin del sistema en partes independientemente implementables
- Evaluacin de una Arquitectura de Software Por qu evaluar una Arquitectura? Cuanto ms temprano se encuentre un problema en un proyecto de software, mejor
- Evaluacin de una Arquitectura de Software Cundo una Arquitectura puede ser evaluada?
- Evaluacin de una Arquitectura de Software Por qu cualidades puede ser evaluada una Arquitectura? Performance Availability
Security
Modifiability
- Evaluacin de una Arquitectura de Software Por qu los atributos de calidad son demasiados imprecisos para el anlisis? El sistema debe ser robusto El sistema debe ser modificable
- Evaluacin de una Arquitectura de Software Cules son las salidas de una evaluacin arquitectnica? Lista priorizada de los atributos de calidad requeridos para la arquitectura que est siendo evaluada. Riesgos y no riesgos
- Evaluacin de una Arquitectura de Software Cules son los costos y beneficios de realizar una evaluacin arquitectnica? Rene a los stakeholders Fuerza una articulacin en las metas especficas de calidad
- SAAM
Propsito Contexto y escenarios Roles Mtodo de anlisis Fortalezas Debilidades
- SAAM
Propsito
Basado en escenarios Foco modificabilidad Evaluar una arquitectura o evaluar y comparar varias
- SAAM
Contexto y escenarios
Atributos de calidad complejos y amorfos para evaluarse simplemente Dependientes del contexto Escenario. Interaccin entre un interesado y el sistema Escenario directo. El sistema no debe ser modificado para soportarlo Escenario indirecto Interaccin de escenarios. Dos o ms escenarios indirectos requieren cambios sobre el mismo componente
Evaluacin de Arquitecturas de Software - Grupo 10
- SAAM Roles
Interesados externos (Organizacin cliente, usuarios finales, administradores del sistema, etc.) Interesados internos (Arquitectos de Software, analistas de requerimientos) Equipo SAAM (Lder, expertos en el dominio de la aplicacin, expertos externos en arquitectura y secretario)
Evaluacin de Arquitecturas de Software - Grupo 10
- SAAM Metodologa
Paso 1. Desarrollo de escenarios Paso 2. Descripcin de la Arquitectura Paso 3. Clasificacin de escenarios Paso 4. Evaluacin de escenarios Paso 5. Interaccin de escenarios Paso 6. Evaluacin general
- SAAM Fortalezas
Los interesados comprenden con facilidad las arquitecturas evaluadas. La documentacin es mejorada. El esfuerzo y el costo de los cambios pueden ser estimados con anticipacin. Analoga con el concepto de bajo acoplamiento y alta cohesin.
Evaluacin de Arquitecturas de Software - Grupo 10
- SAAM Debilidades
La generacin de escenarios est basada en la visin de los interesados. No provee una mtrica clara sobre la calidad de la arquitectura Evaluada. El equipo de evaluacin confa en la experiencia de los arquitectos para proponer arquitecturas candidatas.
Este mtodo de evaluacin obtiene su nombre no solo porque nos dice cuan bien una arquitectura particular satisface las metas de calidad, sino que tambin provee ideas de cmo esas metas de calidad interactan entre ellas, como realizan concesiones mutuas (tradeoff) entre ellas.
Pruebas
Informes
- ATAM Presentacin
Paso 1: Presentar el ATAM
Los pasos del ATAM en resumen Las tcnicas que sern utilizadas para la obtencin y anlisis
- ATAM Presentacin
Paso 2: Presentar las pautas del negocio
Las funciones ms importantes del sistema Toda restriccin tcnica La mayora de los stakeholders
- ATAM Presentacin
Paso 3: Presentar la arquitectura
- ATAM Pruebas
Paso 7: Lluvia de ideas y priorizacin de escenarios Este paso consiste en la generacin de nuevos escenarios para: Representar los intereses de los stakeholders que no hayan sido comprendidos
- ATAM Pruebas
Paso 8: Analizar las propuestas arquitectnicas En este paso el equipo de evaluacin realiza las mismas actividades que en el paso 6, mapeando los escenarios recientemente generados con ranking ms alto en los artefactos arquitectnicos
- ATAM Resultados
Paso 9: Presentar los resultados
- ARID ADRs
Revisiones de Diseos Activas
Utilizado para la evaluacin de diseos detallados de unidades del software como los componentes o mdulos Las preguntas giran en torno a la calidad y completitud de la documentacin y la suficiencia, el ajuste y la conveniencia de los servicios que provee el diseo propuesto
- ARID FASE 1
Identificar los revisores. Preparar la preparacin del diseo.
- ARID FASE 2
Presentacin del mtodo. Presentacin del diseo.
- Conclusiones El mtodo SAAM lo sugerimos cundo el atributo de calidad Modificabilidad es el de mayor inters. El mtodo ATAM es ms profundo para evaluar aspectos ms relacionados con la arquitectura, como la performance o la confiabilidad. El mtodo ARID evala mejor la factibilidad de la arquitectura.
Evaluacin de Arquitecturas de Software - Grupo 10