Grupo 10 Evaluación de Arquitecturas de



Descargar 19,51 Kb.
Fecha de conversión06.01.2017
Tamaño19,51 Kb.
  • Grupo 10
  • Evaluación de Arquitecturas de
  • Software

- Í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:
  • 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

  • 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 indirecto
  • Interacció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
  • 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 los
  • artefactos 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
  • - 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.


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal