Architecture tradeoff analysis method

Last updated

In software engineering, Architecture Tradeoff Analysis Method (ATAM) is a risk-mitigation process used early in the software development life cycle.

Contents

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]

ATAM process

The ATAM process consists of gathering stakeholders together to analyze business drivers (system functionality, goals, constraints, desired 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 formally consists of nine steps, outlined below: [2]

  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.

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 [3]

See also

Related Research Articles

<span class="mw-page-title-main">Software Engineering Institute</span> Federally funded research center in Pittsburgh, Pennsylvania, United States

Software Engineering Institute (SEI) is a federally funded research and development center in Pittsburgh, Pennsylvania, United States. Founded in 1984, the institute is now sponsored by the United States Department of Defense and the Office of the Under Secretary of Defense for Research and Engineering, and administrated by Carnegie Mellon University. The activities of the institute cover cybersecurity, software assurance, software engineering and acquisition, and component capabilities critical to the United States Department of Defense.

The waterfall model is a breakdown of development activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is typical for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance. The waterfall model is the earliest SDLC approach that was used in software development.

<span class="mw-page-title-main">Software architecture</span> High level structures of a software system

Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.

<span class="mw-page-title-main">Spiral model</span> Software development process model

The spiral model is a risk-driven software development process model. Based on the unique risk patterns of a given project, the spiral model guides a team to adopt elements of one or more process models, such as incremental, waterfall, or evolutionary prototyping.

The rational unified process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

<span class="mw-page-title-main">Requirements analysis</span> Engineering process

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating, and managing software or system requirements.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

In software project management, software testing, and software engineering, verification and validation is the process of checking that a software engineer system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"

The Personal Software Process (PSP) is a structured software development process that is designed to help software engineers better understand and improve their performance by bringing discipline to the way they develop software and tracking their predicted and actual development of the code. It clearly shows developers how to manage the quality of their products, how to make a sound plan, and how to make commitments. It also offers them the data to justify their plans. They can evaluate their work and suggest improvement direction by analyzing and reviewing development time, defects, and size data. The PSP was created by Watts Humphrey to apply the underlying principles of the Software Engineering Institute's (SEI) Capability Maturity Model (CMM) to the software development practices of a single developer. It claims to give software engineers the process skills necessary to work on a team software process (TSP) team.

In the context of software engineering, software quality refers to two related but distinct notions:

Business analysis is a professional discipline focused on identifying business needs and determining solutions to business problems. Solutions may include a software-systems development component, process improvements, or organizational changes, and may involve extensive analysis, strategic planning and policy development. A person dedicated to carrying out these tasks within an organization is called a business analyst or BA.

Product-family engineering (PFE), also known as product-line engineering, is based on the ideas of "domain engineering" created by the Software Engineering Institute, a term coined by James Neighbors in his 1980 dissertation at University of California, Irvine. Software product lines are quite common in our daily lives, but before a product family can be successfully established, an extensive process has to be followed. This process is known as product-family engineering.

An architectural model is a diagram created by using available standards in which the primary aim is to illustrate a specific set of tradeoffs inherent in the structure and design of a system or ecosystem. Software architects utilize architectural models to facilitate communication and obtain peer feedback.

<span class="mw-page-title-main">Design rationale</span>

A design rationale is an explicit documentation of the reasons behind decisions made when designing a system or artifact. As initially developed by W.R. Kunz and Horst Rittel, design rationale seeks to provide argumentation-based structure to the political, collaborative process of addressing wicked problems.

<span class="mw-page-title-main">View model</span> Framework for enterprise and system engineering

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.

A goal model is an element of requirements engineering that may also be used more widely in business analysis. Related elements include stakeholder analysis, context analysis, and scenarios, among other business and technical areas.

In software engineering, a software development process or software development life cycle (SDLC) is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

In software engineering, active reviews for intermediate designs (ARID) is a method to evaluate software architectures, especially on an intermediate level, i.e. for non-finished architectures. It combines aspects from scenario-based design review techniques, such as the architecture tradeoff analysis method (ATAM) and the software architecture analysis method (SAAM), as well as active design reviews (ADR).

Leonard Joel (Len) Bass is an American software engineer, Emeritus professor and former researcher at the Software Engineering Institute (SEI), particularly known for his contributions on software architecture in practice.

<span class="mw-page-title-main">Arcadia (engineering)</span>

ARCADIA is a system and software architecture engineering method based on architecture-centric and model-driven engineering activities.

References

  1. ↑ "Architecture Tradeoff Analysis Method". Carnegie Mellon Software Engineering Institute. Retrieved 2018-04-20.
  2. ↑ Bass, Len; Clements, Paul; Kazman, Rick (April 9, 2003). Software Architecture in Practice, Second Edition. Addison Wesley Professional.[ page needed ]
  3. ↑ Rick Kazman; Mark Klein; Paul Clements. "ATAM: Method for Architecture Evaluation" (PDF). Carnegie Mellon Software Engineering Institute. p. 39f. Retrieved 2018-04-20.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.