Jump to content

Architecture tradeoff analysis method

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 167.21.3.6 (talk) at 13:46, 25 June 2013 (→See also). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

In software engineering, architecture tradeoff analysis method (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 architecture for a software system by discovering trade-offs 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:[1]

  • Promotes the gathering of precise quality requirements
  • Creates an early start at architecture documentation
  • Creates a documented basis for architectural decisions
  • Promotes identification of risks early in the life-cycle
  • 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 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.

Steps of the ATAM process[2]

ATAM formally consists of nine steps, outlined below:

  1. Present ATAM – Present the concept of ATAM to the stakeholders, and answer any questions about the process.
  2. Present business drivers – everyone in the process presents and evaluates the business drivers for the system in question.
  3. Present the architecture – the architect presents the high level architecture to the team, with an 'appropriate level of detail'
  4. Identify architectural approaches – different architectural approaches to the system are presented by the team, and discussed.
  5. 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.
  6. Analyze architectural approaches – Analyze each scenario, rating them by priority. The architecture is then evaluated against each scenario.
  7. Brainstorm and prioritize scenarios – among the larger stakeholder group, present the current scenarios, and expand.
  8. Analyze architectural approaches – Perform step 6 again with the added knowledge of the larger stakeholder community.
  9. Present results – provide all documentation to the stakeholders.
    1. 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.[3]

See also

References

  1. ^ "Architecture Tradeoff Analysis Method". Carnegie Mellon Software Engineering Institute. Retrieved 2013-01-14.
  2. ^ Software Architecture in Practice, Second Edition, Len Bass; Paul Clements; Rick Kazman, Addison Wesley Professional, April 9, 2003[page needed]
  3. ^ SENG 401 Lecture 10


Stub icon

This software-engineering-related article is a stub. You can help Wikipedia by expanding it.

Retrieved from "https://en.wikipedia.org/w/index.php?title=Architecture_tradeoff_analysis_method&oldid=561517526"