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 such time as 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 in 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

Software Engineering Institute

The Software Engineering Institute (SEI) is an American research and development center headquartered in Pittsburgh, Pennsylvania. Its activities 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 project activities into linear sequential phases, 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.

Software architecture High level structures of a software system

Software architecture refers to the fundamental structures of 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. The architecture of a software system is a metaphor, analogous to the architecture of a building. It functions as a blueprint for the system and the developing project, laying out the tasks necessary to be executed by the design teams.

Spiral model 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.

Requirements analysis 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.

Systems development life cycle Systems engineering term

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 systems development life cycle 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 (V&V) is the process of checking that a software 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.

Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.

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 rich and rigorous diagram, created using available standards, in which the primary concern is to illustrate a specific set of tradeoffs inherent in the structure and design of a system or ecosystem. Software architects use architectural models to communicate with others and seek peer feedback. An architectural model is an expression of a viewpoint in software architecture.

Design rationale

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.

V-Model (software development)

In software development, the V-model represents a development process that may be considered an extension of the waterfall model, and is an example of the more general V-model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represent time or project completeness (left-to-right) and level of abstraction, respectively.

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 is the process of dividing software development work into smaller, parallel or sequential steps or subprocesses to improve design, product management. It is also known as a software development life cycle (SDLC). 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).

Business requirements, also known as stakeholder requirements specifications (StRS), describe the characteristics of a proposed system from the viewpoint of the system's end user like a CONOPS. Products, systems, software, and processes are ways of how to deliver, satisfy, or meet business requirements. Consequently, business requirements are often discussed in the context of developing or procuring software or other systems.

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.

Arcadia (engineering)

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.