You are on page 1of 42

Gestin de Software

Evaluacin de Arquitecturas de Software

Grupo 10

- ndice Los puntos a tratar en esta presentacin son los siguientes: Introduccin Evaluacin de Arquitecturas de Software SAMM

ATAM
ARID Conclusiones

Evaluacin de Arquitecturas de Software - Grupo 10

- Introduccin Definicin de una Arquitectura de Software:

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

Evaluacin de Arquitecturas de Software - Grupo 10

- Introduccin Implicancias de la definicin:

La arquitectura es una abstraccin de un sistema o sistemas

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)

Evaluacin de Arquitecturas de Software - Grupo 10

- Evaluacin de una Arquitectura de Software -

Cmo puedo estar seguro que la arquitectura elegida es la correcta para mi software?

Evaluacin de Arquitecturas de Software - Grupo 10

- Evaluacin de una Arquitectura de 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 Arquitecturas de Software - Grupo 10

- 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 Arquitecturas de Software - Grupo 10

- Evaluacin de una Arquitectura de Software Por qu evaluar una Arquitectura? Cuanto ms temprano se encuentre un problema en un proyecto de software, mejor

Realizar una evaluacin de la arquitectura es la manera ms econmica de evitar desastres

Evaluacin de Arquitecturas de Software - Grupo 10

- Evaluacin de una Arquitectura de Software Cundo una Arquitectura puede ser evaluada?

Evaluacin temprana Evaluacin tarda

Evaluacin de Arquitecturas de Software - Grupo 10

- Evaluacin de una Arquitectura de Software Quines estn involucrados?

Equipo de evaluacin Stakeholders

Evaluacin de Arquitecturas de Software - Grupo 10

- Evaluacin de una Arquitectura de Software Qu resultado produce la evaluacin de una Arquitectura?

La evaluacin de una arquitectura no produce resultados cuantitativos

La evaluacin ayuda a encontrar debilidades

Evaluacin de Arquitecturas de Software - Grupo 10

- Evaluacin de una Arquitectura de Software Por qu cualidades puede ser evaluada una Arquitectura? Performance Availability

Security
Modifiability

Evaluacin de Arquitecturas de Software - Grupo 10

- 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

El sistema debe ser seguro


El sistema debe tener una performance aceptable
Evaluacin de Arquitecturas de Software - Grupo 10

- 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 Arquitecturas de Software - Grupo 10

- 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

Fuerza una explicacin clara de la arquitectura

Evaluacin de Arquitecturas de Software - Grupo 10

- SAAM
Propsito Contexto y escenarios Roles Mtodo de anlisis Fortalezas Debilidades

Evaluacin de Arquitecturas de Software - Grupo 10

- SAAM

Propsito

Basado en escenarios Foco modificabilidad Evaluar una arquitectura o evaluar y comparar varias

Evaluacin de Arquitecturas de Software - Grupo 10

- 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

Evaluacin de Arquitecturas de Software - Grupo 10

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

Evaluacin de Arquitecturas de Software - Grupo 10

- ATAM Architecture Tradeoff Analysis Method

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.

Evaluacin de Arquitecturas de Software - Grupo 10

- ATAM El mtodo consta de nueve pasos, divididos en cuatro grupos:

Presentacin Investigacin y Anlisis

Pruebas
Informes

Evaluacin de Arquitecturas de Software - Grupo 10

- ATAM Presentacin
Paso 1: Presentar el ATAM

Los pasos del ATAM en resumen Las tcnicas que sern utilizadas para la obtencin y anlisis

Las salidas de la evaluacin

Evaluacin de Arquitecturas de Software - Grupo 10

- ATAM Presentacin
Paso 2: Presentar las pautas del negocio

Las funciones ms importantes del sistema Toda restriccin tcnica La mayora de los stakeholders

Las guas de la arquitectura

Evaluacin de Arquitecturas de Software - Grupo 10

- ATAM Presentacin
Paso 3: Presentar la arquitectura

Las restricciones tcnicas Otros sistemas Propuestas arquitectnicas

Evaluacin de Arquitecturas de Software - Grupo 10

- ATAM Investigacin y Anlisis


Paso 4: Identificar las propuestas arquitectnicas El ATAM centraliza el anlisis de una arquitectura en el entendimiento de sus propuestas arquitectnicas, en este paso son capturadas por el equipo de evaluacin pero no son analizadas

Evaluacin de Arquitecturas de Software - Grupo 10

- ATAM Investigacin y Anlisis


Paso 5: Generar el rbol de utilidad de los atributos de calidad Este paso es crucial, pues gua el resto del anlisis. Sin esta gua, los evaluadores pueden perder su tiempo analizando aspectos de la arquitectura que no son de inters para los stakeholders.

Evaluacin de Arquitecturas de Software - Grupo 10

- ATAM Investigacin y Anlisis


Paso 5: Generar el rbol de utilidad de los atributos de calidad

Evaluacin de Arquitecturas de Software - Grupo 10

- ATAM Investigacin y Anlisis


Paso 6: Analizar las propuestas arquitectnicas

Evaluacin de Arquitecturas de Software - Grupo 10

- 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

Evaluacin de Arquitecturas de Software - Grupo 10

- 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

Evaluacin de Arquitecturas de Software - Grupo 10

- ATAM Resultados
Paso 9: Presentar los resultados

El documento de propuestas arquitectnicas


El conjunto de escenarios priorizados El rbol de utilidad

Los riesgos descubiertos


Los no riesgos documentados Los sensitivity points y tradeoff points encontrados

Evaluacin de Arquitecturas de Software - Grupo 10

- ARID An Evaluation Method for Partial Architectures


Mtodo conveniente para realizar la evaluacin de diseos parciales en las etapas tempranas del desarrollo.

Evaluacin de Arquitecturas de Software - Grupo 10

- 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

Evaluacin de Arquitecturas de Software - Grupo 10

- ARID Un ADR/ATAM hbrido

Caractersticas tiles para el problema de la evaluacin de diseos preliminares.

Evaluacin de Arquitecturas de Software - Grupo 10

- ARID Roles en ARID

Equipo de verificacin. Arquitecto. Stakeholders.

Evaluacin de Arquitecturas de Software - Grupo 10

- ARID Mtodo ARID

9 pasos separados en dos fases


Fase 1: Pre reunin Fase 2: Evaluacin

Evaluacin de Arquitecturas de Software - Grupo 10

- ARID FASE 1
Identificar los revisores. Preparar la preparacin del diseo.

Preparar los escenarios


Preparar los materiales

Evaluacin de Arquitecturas de Software - Grupo 10

- ARID FASE 2
Presentacin del mtodo. Presentacin del diseo.

Lluvia de ideas y priorizacin de escenarios.


Realizacin de la revisin Conclusiones

Evaluacin de Arquitecturas de Software - Grupo 10

- 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

You might also like