Architecture tradeoff analysis method: Difference between revisions

Revision as of 13:46, 25 June 2013

Latest revision as of 10:50, 25 April 2025

(31 intermediate revisions by 25 users not shown)

Line 1:

{{Short description|Risk-mitigation process in software engineering}}

In [[software engineering]], '''architectureArchitecture tradeoffTradeoff analysisAnalysis methodMethod''' ('''ATAM''') is a risk-mitigation process used early in the [[software development life cycle]].

ATAM was developed by the [[Software Engineering Institute]] at the [[Carnegie Mellon University]]. Its purpose is to help choose a suitable [[Software architecture|architecture]] for a software system by discovering [[trade-off]]s and sensitivity points.

ATAM is most beneficial when done early in the software development life-cycle, when the cost of changing architectures is minimal.

== ATAM benefits ==

The following are some of the benefits of the ATAM process:<ref>{{cite web|url=httphttps://wwwresources.sei.cmu.edu/architecturelibrary/tools/evaluate/atamasset-view.cfm?assetid=513908|title=Architecture Tradeoff Analysis Method|accessdate=20132018-0104-1420|publisher=Carnegie Mellon Software Engineering Institute}}</ref>

* Promotes identification ofidentified risks early in the life- cycle.

* Promotes the gathering of precise quality requirements

* Encourages increased communication among stakeholders.

* Creates an early start at architecture documentation

* clarified quality attribute requirements.

* Creates a documented basis for architectural decisions

* Creates an early start atimproved architecture documentation.

* Promotes identification of risks early in the life-cycle

* Creates a documented basis for architectural decisions.

* Encourages increased communication among stakeholders

* Results in the Prioritization of Conflicting Goals

* Forces a Clear Explication of the Architecture

* Uncovers Opportunities for Cross-Project Reuse

* Results in Improved Architecture Practices

== ATAM process ==

The ATAM process consists of gathering stakeholders together to analyze business drivers (system functionality, goals, constraints, desired [[Non-functional requirement|non-functional properties]]) and from these drivers extract quality attributes that are used to create scenarios. These scenarios are then used in conjunction with architectural approaches and architectural decisions to create an analysis of trade-offs, sensitivity points, and risks (or non-risks). This analysis can be converted to risk themes and their impacts whereupon the process can be repeated. With every analysis cycle, the analysis process proceeds from the more general to the more specific, examining the questions that have been discovered in the previous cycle, until the architecture has been fine-tuned and the risk themes have been addressed.

== Steps of the ATAM process ==

==ATAM Stepsformally consists of thenine ATAMsteps, processoutlined below:<ref>{{cite book |title=Software Architecture in Practice, Second Edition, |first1=Len |last1=Bass; |author-link=Len Bass |first2=Paul |last2=Clements; |first3=Rick |last3=Kazman, |publisher=Addison Wesley Professional, |date=April 9, 2003}}{{Page needed|date=January 2013}}</ref> ==

ATAM formally consists of nine steps, outlined below:

#Present ATAM – Present the concept of ATAM to the stakeholders, and answer any questions about the process.

#Present business drivers – everyone in the process presents and evaluates the business drivers for the system in question.

#Present the architecture – the architect presents the high -level architecture to the team, with an 'appropriate level of detail'

#Identify architectural approaches – different architectural approaches to the system are presented by the team, and discussed.

#Generate quality attribute utility tree – define the core business and technical requirements of the system, and map them to an appropriate architectural property. Present a scenario for this given requirement.

Line 32 ⟶ 29:

#Present results – provide all documentation to the stakeholders.

These steps are separated into two phases: Phase 1 consists of steps 1-6 and after this phase, the state and context of the project, the driving architectural requirements and the state of the architectural documentation are known. Phase 2 consists of steps 7-9 and finishes the evaluation.<ref>{{cite web|url=https://resources.sei.cmu.edu/asset_files/TechnicalReport/2000_005_001_13706.pdf|title=ATAM: Method for Architecture Evaluation|accessdate=2018-04-20|page=39f|author1=Rick Kazman |author2=Mark Klein |author3=Paul Clements |publisher=Carnegie Mellon Software Engineering Institute}}</ref>

## Variance of Order

In many cases, the ordering and process of proceeding to each step can vary depending on the project. In his 2013 lectures at the University of Calgary, Dr. Behouz Far proposes that the process of ATAM can be iterative.<ref>SENG 401 Lecture 10</ref>

== See also ==

* [[ilities]]

*Architecture-centric design method

* [[ACDM]]

* [[Multi-criteria decision analysis]]

* [[ACDMARID]]

*[[Software architecture analysis method]], precursor to architecture tradeoff analysis method

*[[Architectural analytics]]

==References==

Line 43:

==External links==

* [httphttps://wwwresources.sei.cmu.edu/architecturelibrary/tools/evaluate/atamasset-view.cfm?assetID=513805 TheReduce ArchitectureRisk Tradeoffwith Analysis MethodArchitecture (ATAM)Evaluation]

* [httphttps://wwwresources.sei.cmu.edu/reportsasset_files/00tr004TechnicalReport/2000_005_001_13706.pdf ATAM: Method for Architecture Evaluation]

[[Category:Software architecture]]

[[Category:Enterprise architecture]]

{{soft-eng-stub}}