SlideShare una empresa de Scribd logo
1 de 14
REPÚBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA DEFENSA
UNIVERSIDAD NACIONAL EXPERIMENTAL POLITÉCNICA
DE LAS FUERZAS ARMADAS NACIONAL BOLIVARIANA
NÚCLEO TRUJILLO

METODOLOGÍA DE EVALUACIÓN
ATAM
AUTOR
ABREU VARINIA
SECCIÓN: 02
MATERIA: AQUITECTURA
DEL SOFTWARE
PROFESORA: LORENA
RÁNGEL

Valera, febrero 2014
INTRODUCCIÓN
La arquitectura del software condiciona las
características del producto final en cuanto a
cualidades como la mantenibilidad; por lo que resulta
importante evaluar el cumplimiento de los mismos en
forma temprana para corregir errores antes de pasar a
la codificación del sistema, donde es más costoso.

Esta investigación consiste en un método de
evaluación de ATAM, donde expresa que una
arquitectura particular no solo satisface las metas de
calidad, sino que también provee ideas de cómo esas
metas de calidad interactúan entre ellas, cómo realizan
concesiones mutuas entre ellas.
ARQUITECTURA TRADEOFF MÉTODO
DE ANÁLISIS (ATAM)
La Arquitectura Tradeoff Método de Análisis
(ATAM), es una metodología utilizada para las
evaluaciones de la arquitectura del software
principalmente en su ajuste. Nace de las ideas y técnicas
de tres áreas: la noción de estilos o patrones de
arquitectura, el análisis de atributos de calidad y el
método software. El método ATAM, establece que la
arquitectura de software de un programa o sistema de
computación es la estructura del sistema que contienen
componentes
de
software,
las
propiedades
externamente visibles de dichos componentes y las
relaciones entre ellos.
ARQUITECTURA TRADEOFF MÉTODO
DE ANÁLISIS (ATAM)
El propósito de ATAM es evaluar las
consecuencias de decisiones arquitectónicas a partir
de requerimientos de atributos de calidad, identificar
los riesgos creados por decisiones arquitectónicas,
generar las preguntas correctas para descubrir
decisiones de arquitecturas con problemas y proveer
un análisis preciso.
ARQUITECTURA TRADEOFF MÉTODO
DE ANÁLISIS (ATAM)
El método de evaluación ATAM comprende nueve pasos,
agrupados en cuatro fases:
FASE I. Presentación.
Presentación del ATAM: El líder de evaluación describe el
método a los participantes, trata de establecer las expectativas
y responde las preguntas propuestas.
Presentación de las metas del negocio: Se realiza la descripción
de las metas del negocio que motivan el esfuerzo, y aclara que
se persiguen objetivos de tipo arquitectónico.
Presentación de la arquitectura: El arquitecto describe la
arquitectura, enfocándose en cómo ésta cumple con los
objetivos del negocio.
ARQUITECTURA TRADEOFF MÉTODO
DE ANÁLISIS (ATAM)
FASE II. Investigación y análisis.

Identificación de los enfoques arquitectónicos: estos
elementos son detectados, pero no analizados.
Generación del Utility Tree: Se elicitan los atributos de
calidad que engloban la utilidad del sistema
(desempeño,
disponibilidad,
seguridad,
modificabilidad, usabilidad, entre otros), especificados
en forma de escenarios. Se anotan los estímulos y
respuestas, así como se establece la prioridad entre
ellos.
Análisis de los enfoques arquitectónicos: Es este paso
se identifican riesgos arquitectónicos, puntos de
sensibilidad y puntos de balance.
ARQUITECTURA TRADEOFF MÉTODO
DE ANÁLISIS (ATAM)
FASE III. Pruebas.
Lluvia de ideas y establecimiento de prioridad de
escenarios: Con la colaboración de todos los
involucrados, se complementa el conjunto de
escenarios.
Análisis de los enfoques arquitectónicos: Este paso
repite las actividades del paso seis, haciendo uso de
los resultados del paso siete. Los escenarios son
considerados como casos de prueba para confirmar el
análisis realizado hasta el momento.
ARQUITECTURA TRADEOFF MÉTODO
DE ANÁLISIS (ATAM)
FASE IV. Reportes.
Presentación de los resultados: Basado en la
información recolectada a lo largo de la evaluación del
ATAM, se presentan los hallazgos a los participantes.
ARQUITECTURA TRADEOFF MÉTODO
DE ANÁLISIS (ATAM)
Cuándo usar ATAM:
A lo largo del ciclo de vida cuando hay una
arquitectura de software para evaluar.
Después de que una arquitectura se especificó
pero hay poco o nada de código listo.
Para evaluar alternativas arquitectónicas.
Para evaluar la arquitectura de un sistema
existente.
ARQUITECTURA TRADEOFF MÉTODO
DE ANÁLISIS (ATAM)
Beneficios de ATAM:
Requerimientos de atributos de calidad clarificados.
Documentación de arquitectura mejorada.
Identificación de riesgos de manera temprana en el ciclo de
vida.
Mejor comunicación entre los “stakeholders”.
ARQUITECTURA TRADEOFF MÉTODO
DE ANÁLISIS (ATAM)
Limitaciones:
No tiene valuaciones de costos.
No considera variaciones de escenarios e impacto en
la respuesta.
No es un método cuantitativo.
DEFINICIÓN DE TÉRMINOS
Tradeoff: Es una situación en la cual se debe perder
cierta cualidad a cambio de otra cualidad. Implica una
decisión en la cual se comprende totalmente las ventajas y
desventajas de cada elección.
Utility Tree (Árbol de Utilidad): Es un esquema en forma
de árbol que presenta los atributos de calidad de un sistema
de software, refinados hasta el establecimiento de
escenarios que especifican con suficiente detalle el nivel de
prioridad de cada uno.
Elicitar: Verbo transitivo, usado en lenguaje técnico o
psicología y sociología principalmente para indicar el acto
de extraer información de una persona o un grupo de
persona.
CONCLUSIÓN
Las decisiones arquitectónicas influyen directamente en la
calidad del software, entonces es posible evaluar dichas
decisiones con respecto a su impacto sobre dichos atributos.
Cuanto más temprano se encuentre un problema en un
proyecto del software, mucho mejor; revisar la arquitectura es
la manera más económica de evitar desastres.

El método ATAM se concentra en la identificación de los
estilos arquitectónicos o enfoques arquitectónicos utilizados.
Estos elementos representan los medios empleados por la
arquitectura para alcanzar los atributos de calidad, así como
también permiten describir la forma en la que el sistema puede
crecer, responder a cambios, e integrarse con otros sistemas.
REFERENCIAS ELECTRÓNICAS
Trade-off-Wikepedia, la enciclopedia libre. Consultado
de http://es.wikipedia.org/wiki/Trade-off
Ingeniería de Software II (2008) – Universidad de Buenos Aires.
Consultado el 4 de
enero de 2014, de http:// www-2.dc.uba.ar/...02/.../Clase19EvaluacionArquitecturasYATAM.pdf
Guías sobre Arquitecturas de Software. Consultado el 4 de enero de 2014,
de prof.usb.ve/lmendoza/Documentos/PS.../Guia%20Arquitectura
%20v.2.p...

Más contenido relacionado

La actualidad más candente

2.2 relación de cmm con psp y tsp
2.2 relación de cmm con psp  y tsp2.2 relación de cmm con psp  y tsp
2.2 relación de cmm con psp y tsp
eeelllkkk
 
MAPA CONCEPTUAL
MAPA CONCEPTUALMAPA CONCEPTUAL
MAPA CONCEPTUAL
Mali Ma
 
Object oriented methodologies
Object oriented methodologiesObject oriented methodologies
Object oriented methodologies
naina-rani
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
landeta_p
 
Atributos de calidad en el desarrollo de software
Atributos de calidad en el desarrollo de software Atributos de calidad en el desarrollo de software
Atributos de calidad en el desarrollo de software
Joan Manuel Zabala
 
Arquitectura ALMA
Arquitectura ALMAArquitectura ALMA
Arquitectura ALMA
LoloUBD
 
Arquitectura Orientada a Servicios
Arquitectura Orientada a ServiciosArquitectura Orientada a Servicios
Arquitectura Orientada a Servicios
finger10
 

La actualidad más candente (20)

Calidad del producto ISO 9126
Calidad del producto ISO 9126Calidad del producto ISO 9126
Calidad del producto ISO 9126
 
2.2 relación de cmm con psp y tsp
2.2 relación de cmm con psp  y tsp2.2 relación de cmm con psp  y tsp
2.2 relación de cmm con psp y tsp
 
Ciclo Vida del Software
Ciclo Vida del SoftwareCiclo Vida del Software
Ciclo Vida del Software
 
Factores de calidad del software
Factores de calidad del softwareFactores de calidad del software
Factores de calidad del software
 
12.diseño basado en patrones
12.diseño basado en patrones12.diseño basado en patrones
12.diseño basado en patrones
 
MAPA CONCEPTUAL
MAPA CONCEPTUALMAPA CONCEPTUAL
MAPA CONCEPTUAL
 
GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE (GCS)
GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE (GCS)GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE (GCS)
GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE (GCS)
 
Cap1 1 Introducción a los sistemas distribuidos
Cap1 1 Introducción a los sistemas distribuidosCap1 1 Introducción a los sistemas distribuidos
Cap1 1 Introducción a los sistemas distribuidos
 
CMMI
CMMICMMI
CMMI
 
1.6 Activos Informáticos
1.6 Activos Informáticos1.6 Activos Informáticos
1.6 Activos Informáticos
 
Modelo SPICE
Modelo SPICEModelo SPICE
Modelo SPICE
 
Object oriented methodologies
Object oriented methodologiesObject oriented methodologies
Object oriented methodologies
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
 
Atributos de calidad en el desarrollo de software
Atributos de calidad en el desarrollo de software Atributos de calidad en el desarrollo de software
Atributos de calidad en el desarrollo de software
 
Gestion de la configuracion del software
Gestion de la configuracion del softwareGestion de la configuracion del software
Gestion de la configuracion del software
 
Arquitectura ALMA
Arquitectura ALMAArquitectura ALMA
Arquitectura ALMA
 
Arquitectura Orientada a Servicios
Arquitectura Orientada a ServiciosArquitectura Orientada a Servicios
Arquitectura Orientada a Servicios
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientos
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
 
Gestión del Cambio del Software
Gestión del Cambio del SoftwareGestión del Cambio del Software
Gestión del Cambio del Software
 

Destacado (7)

Designing For Kids
Designing For KidsDesigning For Kids
Designing For Kids
 
O comparativo de arquiteturas de software monolíticas em relação a arquitetur...
O comparativo de arquiteturas de software monolíticas em relação a arquitetur...O comparativo de arquiteturas de software monolíticas em relação a arquitetur...
O comparativo de arquiteturas de software monolíticas em relação a arquitetur...
 
Um Levantamento de Métodos de Avaliação de Arquiteturas de Software Específicas
Um Levantamento de Métodos de Avaliação de Arquiteturas de Software EspecíficasUm Levantamento de Métodos de Avaliação de Arquiteturas de Software Específicas
Um Levantamento de Métodos de Avaliação de Arquiteturas de Software Específicas
 
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...
 
Norma iso 9126
Norma iso 9126Norma iso 9126
Norma iso 9126
 
Ingenieria De Software Para Dummies
Ingenieria De Software Para DummiesIngenieria De Software Para Dummies
Ingenieria De Software Para Dummies
 
Tipos y diseños de investigacion
Tipos y diseños de investigacionTipos y diseños de investigacion
Tipos y diseños de investigacion
 

Similar a Atam

Arquitecturas
ArquitecturasArquitecturas
Arquitecturas
enlinea70
 
Tareas de ingenieria de requerimientos(1)
Tareas de ingenieria de requerimientos(1)Tareas de ingenieria de requerimientos(1)
Tareas de ingenieria de requerimientos(1)
nenyta08
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
Zuleima
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
Zuleima
 
Dierencia entre la ingeniería de software y la arquitectura de software
Dierencia entre la ingeniería de software y la arquitectura de softwareDierencia entre la ingeniería de software y la arquitectura de software
Dierencia entre la ingeniería de software y la arquitectura de software
Enrique Torres Alarcon
 
Tareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosTareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientos
nenyta08
 
Tareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosTareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientos
Kleo Jorgee
 
Métodos de evaluación de arquitectura a un atributo específico
Métodos de evaluación de arquitectura a un atributo específicoMétodos de evaluación de arquitectura a un atributo específico
Métodos de evaluación de arquitectura a un atributo específico
Tefa Gonzaga
 
Vídeo métricas del software 1151354
Vídeo métricas del software 1151354Vídeo métricas del software 1151354
Vídeo métricas del software 1151354
Daniela Buitrago
 
Arquitectura de software
Arquitectura de softwareArquitectura de software
Arquitectura de software
Liliana Pacheco
 

Similar a Atam (20)

IMPORTANCIA DEL ANALISIS DE REQUERIMIENTOS
IMPORTANCIA DEL ANALISIS DE REQUERIMIENTOSIMPORTANCIA DEL ANALISIS DE REQUERIMIENTOS
IMPORTANCIA DEL ANALISIS DE REQUERIMIENTOS
 
Fabio lópez cuadro_comparativo_actividad_2.2
Fabio lópez cuadro_comparativo_actividad_2.2Fabio lópez cuadro_comparativo_actividad_2.2
Fabio lópez cuadro_comparativo_actividad_2.2
 
Arquitecturas
ArquitecturasArquitecturas
Arquitecturas
 
Exposicion evaluacion e_arquitecturas_de_softw
Exposicion evaluacion e_arquitecturas_de_softwExposicion evaluacion e_arquitecturas_de_softw
Exposicion evaluacion e_arquitecturas_de_softw
 
Tareas de ingenieria de requerimientos(1)
Tareas de ingenieria de requerimientos(1)Tareas de ingenieria de requerimientos(1)
Tareas de ingenieria de requerimientos(1)
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
Fundamentos del diseño y Garantías de Calidad del Software
Fundamentos del diseño y Garantías de Calidad del SoftwareFundamentos del diseño y Garantías de Calidad del Software
Fundamentos del diseño y Garantías de Calidad del Software
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
Dierencia entre la ingeniería de software y la arquitectura de software
Dierencia entre la ingeniería de software y la arquitectura de softwareDierencia entre la ingeniería de software y la arquitectura de software
Dierencia entre la ingeniería de software y la arquitectura de software
 
Tareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosTareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientos
 
Tareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosTareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientos
 
Métodos de evaluación de arquitectura a un atributo específico
Métodos de evaluación de arquitectura a un atributo específicoMétodos de evaluación de arquitectura a un atributo específico
Métodos de evaluación de arquitectura a un atributo específico
 
Métodos de evaluación de arquitectura a un atributo específico
Métodos de evaluación de arquitectura a un atributo específicoMétodos de evaluación de arquitectura a un atributo específico
Métodos de evaluación de arquitectura a un atributo específico
 
Ingenieria de requisitos
Ingenieria de requisitosIngenieria de requisitos
Ingenieria de requisitos
 
Evaluación de tecnologías
Evaluación de tecnologíasEvaluación de tecnologías
Evaluación de tecnologías
 
Diferencial semántico una herramienta al servicio del diseño emocional de maq...
Diferencial semántico una herramienta al servicio del diseño emocional de maq...Diferencial semántico una herramienta al servicio del diseño emocional de maq...
Diferencial semántico una herramienta al servicio del diseño emocional de maq...
 
Dif semantici 2
Dif semantici 2Dif semantici 2
Dif semantici 2
 
Vídeo métricas del software 1151354
Vídeo métricas del software 1151354Vídeo métricas del software 1151354
Vídeo métricas del software 1151354
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
 
Arquitectura de software
Arquitectura de softwareArquitectura de software
Arquitectura de software
 

Último

Modulo-Mini Cargador.................pdf
Modulo-Mini Cargador.................pdfModulo-Mini Cargador.................pdf
Modulo-Mini Cargador.................pdf
AnnimoUno1
 

Último (11)

pruebas unitarias unitarias en java con JUNIT
pruebas unitarias unitarias en java con JUNITpruebas unitarias unitarias en java con JUNIT
pruebas unitarias unitarias en java con JUNIT
 
EVOLUCION DE LA TECNOLOGIA Y SUS ASPECTOSpptx
EVOLUCION DE LA TECNOLOGIA Y SUS ASPECTOSpptxEVOLUCION DE LA TECNOLOGIA Y SUS ASPECTOSpptx
EVOLUCION DE LA TECNOLOGIA Y SUS ASPECTOSpptx
 
Innovaciones tecnologicas en el siglo 21
Innovaciones tecnologicas en el siglo 21Innovaciones tecnologicas en el siglo 21
Innovaciones tecnologicas en el siglo 21
 
EL CICLO PRÁCTICO DE UN MOTOR DE CUATRO TIEMPOS.pptx
EL CICLO PRÁCTICO DE UN MOTOR DE CUATRO TIEMPOS.pptxEL CICLO PRÁCTICO DE UN MOTOR DE CUATRO TIEMPOS.pptx
EL CICLO PRÁCTICO DE UN MOTOR DE CUATRO TIEMPOS.pptx
 
Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...
Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...
Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...
 
Avances tecnológicos del siglo XXI y ejemplos de estos
Avances tecnológicos del siglo XXI y ejemplos de estosAvances tecnológicos del siglo XXI y ejemplos de estos
Avances tecnológicos del siglo XXI y ejemplos de estos
 
PROYECTO FINAL. Tutorial para publicar en SlideShare.pptx
PROYECTO FINAL. Tutorial para publicar en SlideShare.pptxPROYECTO FINAL. Tutorial para publicar en SlideShare.pptx
PROYECTO FINAL. Tutorial para publicar en SlideShare.pptx
 
Refrigerador_Inverter_Samsung_Curso_y_Manual_de_Servicio_Español.pdf
Refrigerador_Inverter_Samsung_Curso_y_Manual_de_Servicio_Español.pdfRefrigerador_Inverter_Samsung_Curso_y_Manual_de_Servicio_Español.pdf
Refrigerador_Inverter_Samsung_Curso_y_Manual_de_Servicio_Español.pdf
 
Avances tecnológicos del siglo XXI 10-07 eyvana
Avances tecnológicos del siglo XXI 10-07 eyvanaAvances tecnológicos del siglo XXI 10-07 eyvana
Avances tecnológicos del siglo XXI 10-07 eyvana
 
Modulo-Mini Cargador.................pdf
Modulo-Mini Cargador.................pdfModulo-Mini Cargador.................pdf
Modulo-Mini Cargador.................pdf
 
How to use Redis with MuleSoft. A quick start presentation.
How to use Redis with MuleSoft. A quick start presentation.How to use Redis with MuleSoft. A quick start presentation.
How to use Redis with MuleSoft. A quick start presentation.
 

Atam

  • 1. REPÚBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DEL PODER POPULAR PARA LA DEFENSA UNIVERSIDAD NACIONAL EXPERIMENTAL POLITÉCNICA DE LAS FUERZAS ARMADAS NACIONAL BOLIVARIANA NÚCLEO TRUJILLO METODOLOGÍA DE EVALUACIÓN ATAM AUTOR ABREU VARINIA SECCIÓN: 02 MATERIA: AQUITECTURA DEL SOFTWARE PROFESORA: LORENA RÁNGEL Valera, febrero 2014
  • 2. INTRODUCCIÓN La arquitectura del software condiciona las características del producto final en cuanto a cualidades como la mantenibilidad; por lo que resulta importante evaluar el cumplimiento de los mismos en forma temprana para corregir errores antes de pasar a la codificación del sistema, donde es más costoso. Esta investigación consiste en un método de evaluación de ATAM, donde expresa que una arquitectura particular no solo satisface las metas de calidad, sino que también provee ideas de cómo esas metas de calidad interactúan entre ellas, cómo realizan concesiones mutuas entre ellas.
  • 3. ARQUITECTURA TRADEOFF MÉTODO DE ANÁLISIS (ATAM) La Arquitectura Tradeoff Método de Análisis (ATAM), es una metodología utilizada para las evaluaciones de la arquitectura del software principalmente en su ajuste. Nace de las ideas y técnicas de tres áreas: la noción de estilos o patrones de arquitectura, el análisis de atributos de calidad y el método software. El método ATAM, establece que la arquitectura de software de un programa o sistema de computación es la estructura del sistema que contienen componentes de software, las propiedades externamente visibles de dichos componentes y las relaciones entre ellos.
  • 4. ARQUITECTURA TRADEOFF MÉTODO DE ANÁLISIS (ATAM) El propósito de ATAM es evaluar las consecuencias de decisiones arquitectónicas a partir de requerimientos de atributos de calidad, identificar los riesgos creados por decisiones arquitectónicas, generar las preguntas correctas para descubrir decisiones de arquitecturas con problemas y proveer un análisis preciso.
  • 5. ARQUITECTURA TRADEOFF MÉTODO DE ANÁLISIS (ATAM) El método de evaluación ATAM comprende nueve pasos, agrupados en cuatro fases: FASE I. Presentación. Presentación del ATAM: El líder de evaluación describe el método a los participantes, trata de establecer las expectativas y responde las preguntas propuestas. Presentación de las metas del negocio: Se realiza la descripción de las metas del negocio que motivan el esfuerzo, y aclara que se persiguen objetivos de tipo arquitectónico. Presentación de la arquitectura: El arquitecto describe la arquitectura, enfocándose en cómo ésta cumple con los objetivos del negocio.
  • 6. ARQUITECTURA TRADEOFF MÉTODO DE ANÁLISIS (ATAM) FASE II. Investigación y análisis. Identificación de los enfoques arquitectónicos: estos elementos son detectados, pero no analizados. Generación del Utility Tree: Se elicitan los atributos de calidad que engloban la utilidad del sistema (desempeño, disponibilidad, seguridad, modificabilidad, usabilidad, entre otros), especificados en forma de escenarios. Se anotan los estímulos y respuestas, así como se establece la prioridad entre ellos. Análisis de los enfoques arquitectónicos: Es este paso se identifican riesgos arquitectónicos, puntos de sensibilidad y puntos de balance.
  • 7. ARQUITECTURA TRADEOFF MÉTODO DE ANÁLISIS (ATAM) FASE III. Pruebas. Lluvia de ideas y establecimiento de prioridad de escenarios: Con la colaboración de todos los involucrados, se complementa el conjunto de escenarios. Análisis de los enfoques arquitectónicos: Este paso repite las actividades del paso seis, haciendo uso de los resultados del paso siete. Los escenarios son considerados como casos de prueba para confirmar el análisis realizado hasta el momento.
  • 8. ARQUITECTURA TRADEOFF MÉTODO DE ANÁLISIS (ATAM) FASE IV. Reportes. Presentación de los resultados: Basado en la información recolectada a lo largo de la evaluación del ATAM, se presentan los hallazgos a los participantes.
  • 9. ARQUITECTURA TRADEOFF MÉTODO DE ANÁLISIS (ATAM) Cuándo usar ATAM: A lo largo del ciclo de vida cuando hay una arquitectura de software para evaluar. Después de que una arquitectura se especificó pero hay poco o nada de código listo. Para evaluar alternativas arquitectónicas. Para evaluar la arquitectura de un sistema existente.
  • 10. ARQUITECTURA TRADEOFF MÉTODO DE ANÁLISIS (ATAM) Beneficios de ATAM: Requerimientos de atributos de calidad clarificados. Documentación de arquitectura mejorada. Identificación de riesgos de manera temprana en el ciclo de vida. Mejor comunicación entre los “stakeholders”.
  • 11. ARQUITECTURA TRADEOFF MÉTODO DE ANÁLISIS (ATAM) Limitaciones: No tiene valuaciones de costos. No considera variaciones de escenarios e impacto en la respuesta. No es un método cuantitativo.
  • 12. DEFINICIÓN DE TÉRMINOS Tradeoff: Es una situación en la cual se debe perder cierta cualidad a cambio de otra cualidad. Implica una decisión en la cual se comprende totalmente las ventajas y desventajas de cada elección. Utility Tree (Árbol de Utilidad): Es un esquema en forma de árbol que presenta los atributos de calidad de un sistema de software, refinados hasta el establecimiento de escenarios que especifican con suficiente detalle el nivel de prioridad de cada uno. Elicitar: Verbo transitivo, usado en lenguaje técnico o psicología y sociología principalmente para indicar el acto de extraer información de una persona o un grupo de persona.
  • 13. CONCLUSIÓN Las decisiones arquitectónicas influyen directamente en la calidad del software, entonces es posible evaluar dichas decisiones con respecto a su impacto sobre dichos atributos. Cuanto más temprano se encuentre un problema en un proyecto del software, mucho mejor; revisar la arquitectura es la manera más económica de evitar desastres. El método ATAM se concentra en la identificación de los estilos arquitectónicos o enfoques arquitectónicos utilizados. Estos elementos representan los medios empleados por la arquitectura para alcanzar los atributos de calidad, así como también permiten describir la forma en la que el sistema puede crecer, responder a cambios, e integrarse con otros sistemas.
  • 14. REFERENCIAS ELECTRÓNICAS Trade-off-Wikepedia, la enciclopedia libre. Consultado de http://es.wikipedia.org/wiki/Trade-off Ingeniería de Software II (2008) – Universidad de Buenos Aires. Consultado el 4 de enero de 2014, de http:// www-2.dc.uba.ar/...02/.../Clase19EvaluacionArquitecturasYATAM.pdf Guías sobre Arquitecturas de Software. Consultado el 4 de enero de 2014, de prof.usb.ve/lmendoza/Documentos/PS.../Guia%20Arquitectura %20v.2.p...