<commit_before>[[ATAM]]
==== [pattern]#Atam#

Architecture Tradeoff Analysis Method. Systematic approach to find architectural 
risks, tradeoffs and sensitivity points.

===== Intent

Apply the ATAM method to evaluate the software architecture regarding the 
compliance with quality goals.

===== Description

The ATAM method consists of four phases as shown in diagram "Approach of ATAM".

[[figure-atam-approach]]
image::approach-of-atam.png["Approach of ATAM", title="Approach of ATAM"]

The phases are:

. *Preparation*:
  .. 'Identify the relevant stakeholders': 
      The specific goals of the relevant stakeholders define the primary  
      goals of the architecture. Who belongs to these _relevant_ stakeholders
      has to be determined by a <<Stakeholder-Analysis>>.  
   
. *Kickoff*:
  .. 'Present the ATAM method':
      Convince the relevant stakeholders of the significance of 
      comprehensible and specific architecture and quality goals. 
      ATAM helps identify risks, non-risks, tradeoffs and sensitivity points. 
      Calculation of quantitative attributes is not subject of this method.
    
  .. 'Present the business objectives and architecture goals':
      Present the business context to the relevant stakeholders, especially the
      _business motivation and reasons_ for the development of the system. 
      Clarify specific requirements that the architecture should meet, 
      for instance flexibility, modifiability and performance.
      
  .. 'Present the architecture of the system':
      The architect presents the _architecture_ of the system. This includes:
      
      * All other systems with interactions to the <<SuD>>,
      * building blocks of the top abstraction level,
      * runtime views of some important use cases,
      * change or modification scenarios. 

  
. *Evaluation*:
  .. 'Explain in detail the architecture approaches':
      The following questions are answered by the architect or developers:
      
      * How are the relevant quality requirements achieved within the 
        architecture or the implementation?
      * What are the structures and concepts solving the relevant problems or 
        challenges?  
      * What are the important design decisions of the architecture?
      
  .. 'Create a quality tree and scenarios':
      In the context of a creative brainstorming the stakeholders develop the 
      relevant required quality goals. These are arranged in a quality tree.
      Afterward the quality requirements and architecture goals of the 
      system are refined by scenarios which are added to the quality tree. The 
      found scenarios are prioritized regarding to their business value.
     
  .. 'Analyze the architecture approaches with respect to the scenarios':
      Based on the priorities of the scenarios the evaluation team examines 
      together with the architect or developers how the architecture approaches 
      support the considered scenario. The findings of the analysis are:
      
      * Existing risks concerning the attainment of the architecture goals.
      * Non-risks which means that the quality requirements are achieved.
      * Tradeoff points which are decisions that affect the quality attributes 
        positive and other negative.
      * Sensitivity points which are elements of the architecture that have 
        formative influence to the quality attributes.
        
. *Follow-up*:
  .. 'Present the results':
      Creation of a report with:
      
      * Architectural approaches
      * Quality tree with prioritized scenarios
      * Risks
      * Non-risks
      * Tradeoffs
      * Sensitivity points


===== Experiences

The ATAM method:

* provides operational, specific quality requirements,
* discloses important architectural decisions of the <<SuD>>,
* promotes the communication between relevant stakeholders.

[IMPORTANT]
The ATAM method does not develop concrete measures, strategies or 
tactics against the found risks. 


ATAM has been successfully applied by many organizations to a variety of systems. It is widely regarded as the most important
systematic approach to qualitative system/architecture analysisfootnote:[The original authors of ATAM call it an _evaluation_ method, whereas aim42 classifies ATAM to belong to the category of analysis practices.].

===== Applicability
<commit_msg>Word phrases enclosed in single quote characters weren't emphasized.<commit_after>[[ATAM]]
==== [pattern]#Atam#

Architecture Tradeoff Analysis Method. Systematic approach to find architectural 
risks, tradeoffs and sensitivity points.

===== Intent

Apply the ATAM method to evaluate the software architecture regarding the 
compliance with quality goals.

===== Description

The ATAM method consists of four phases as shown in diagram "Approach of ATAM".

[[figure-atam-approach]]
image::approach-of-atam.png["Approach of ATAM", title="Approach of ATAM"]

The phases are:

. *Preparation*:
  .. _Identify the relevant stakeholders_: 
      The specific goals of the relevant stakeholders define the primary  
      goals of the architecture. Who belongs to these _relevant_ stakeholders
      has to be determined by a <<Stakeholder-Analysis>>.  
   
. *Kickoff*:
  .. _Present the ATAM method_:
      Convince the relevant stakeholders of the significance of 
      comprehensible and specific architecture and quality goals. 
      ATAM helps identify risks, non-risks, tradeoffs and sensitivity points. 
      Calculation of quantitative attributes is not subject of this method.
    
  .. _Present the business objectives and architecture goals_:
      Present the business context to the relevant stakeholders, especially the
      _business motivation and reasons_ for the development of the system. 
      Clarify specific requirements that the architecture should meet, 
      for instance flexibility, modifiability and performance.
      
  .. _Present the architecture of the system_:
      The architect presents the _architecture_ of the system. This includes:
      
      * All other systems with interactions to the <<SuD>>,
      * building blocks of the top abstraction level,
      * runtime views of some important use cases,
      * change or modification scenarios. 

  
. *Evaluation*:
  .. _Explain in detail the architecture approaches_:
      The following questions are answered by the architect or developers:
      
      * How are the relevant quality requirements achieved within the 
        architecture or the implementation?
      * What are the structures and concepts solving the relevant problems or 
        challenges?  
      * What are the important design decisions of the architecture?
      
  .. _Create a quality tree and scenarios_:
      In the context of a creative brainstorming the stakeholders develop the 
      relevant required quality goals. These are arranged in a quality tree.
      Afterward the quality requirements and architecture goals of the 
      system are refined by scenarios which are added to the quality tree. The 
      found scenarios are prioritized regarding to their business value.
     
  .. _Analyze the architecture approaches with respect to the scenarios_:
      Based on the priorities of the scenarios the evaluation team examines 
      together with the architect or developers how the architecture approaches 
      support the considered scenario. The findings of the analysis are:
      
      * Existing risks concerning the attainment of the architecture goals.
      * Non-risks which means that the quality requirements are achieved.
      * Tradeoff points which are decisions that affect the quality attributes 
        positive and other negative.
      * Sensitivity points which are elements of the architecture that have 
        formative influence to the quality attributes.
        
. *Follow-up*:
  .. _Present the results_:
      Creation of a report with:
      
      * Architectural approaches
      * Quality tree with prioritized scenarios
      * Risks
      * Non-risks
      * Tradeoffs
      * Sensitivity points


===== Experiences

The ATAM method:

* provides operational, specific quality requirements,
* discloses important architectural decisions of the <<SuD>>,
* promotes the communication between relevant stakeholders.

[IMPORTANT]
The ATAM method does not develop concrete measures, strategies or 
tactics against the found risks. 


ATAM has been successfully applied by many organizations to a variety of systems. It is widely regarded as the most important
systematic approach to qualitative system/architecture analysisfootnote:[The original authors of ATAM call it an _evaluation_ method, whereas aim42 classifies ATAM to belong to the category of analysis practices.].

===== Applicability

{'fraction_non_alphanumeric': 0.0450255827174531, 'fraction_numerical': 0.00045480386583285955, 'mean_word_length': 3.350148367952522, 'pattern_counts': {'":': 0, '<': 15, '<?xml version=': 0, '>': 15, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4730205', 'n_tokens_mistral': 2017, 'n_tokens_neox': 1891, 'n_words': 1042}