The SEI helps advance software engineering principles and practices and serves as a national resource in software engineering, computer security, and process improvement. The SEI works closely with defense and government organizations, industry, and academia to continually improve software-intensive systems. Its core purpose is to help organizations improve their software engineering capabilities and develop or acquire the right software, defect free, within budget and on time, every time.

Glossary

Active Reviews for Intermediate Designs (ARID)

A lightweight evaluation approach for software architecture that concentrates on suitability and does not require complete documentation; leverages active stakeholders' participation and helps to gain their early buy-in. Learn more about ARID.

Architectural drivers

The combination of functional, quality-attribute, and business requirements that shape the architecture or the element under consideration.

Architectural pattern

A description of element and relation types together with a set of constraints on how they are used.

Architectural style

A specialization of element and relation types, together with a set of constraints on how they can be used.

Architecture Analysis and Design Language (AADL)

A Society of Automotive Engineers (SAE) international standard established in 2004 that allows analysis of system (and system-of-systems) designs before development and supports an architecture-centric, model-based development approach throughout the system life cycle. Learn more about AADL.

Architecture description language (ADL)

A language (graphical, textual, or both) for describing a software system in terms of its architectural elements and the relationships among them.

Architecture framework

“conventions and common practices for architecture description established within a specific domain or stakeholder community” (ISO/IEC 42010)

Architecture Improvement Workshop (AIW)

A method for evaluating and improving software architectures relative to quality attribute goals. The SEI evaluates an architecture using the ATAM to expose architectural risks that potentially inhibit the achievement of an organization's business goals. Then the SEI works with the architects and managers to determine which business goals to focus on and to propose alternatives to improve and evolve the architecture, ranking these alternatives based on their expected costs, benefits, and uncertainty. Learn more about AIW.

Architecture stakeholder

Someone who has a vested interest in the architecture.

Architecture Tradeoff Analysis Method (ATAM)

A method for evaluating software architectures relative to quality attribute goals that reveals how well an architecture satisfies particular quality goals and provides insight into how those quality goals interact with each other. Learn more about ATAM.

Attribute-Driven Design (ADD) Method

A systematic method for designing the software architecture of a software-intensive system by basing the design process on the architecture’s quality attribute requirements, enabling designers to understand quality attribute tradeoffs early in the design process. Learn more about ADD.

Component

The principal computational element and data store that execute in a system.

Connector

A runtime pathway of interaction between two or more components.

Constraint

A requirement for which the design decisions are prespecified.

Cost Benefit Analysis Method (CBAM)

A method for analyzing the costs, benefits, and schedule implications of decisions about software architecture; explicitly associates costs, benefits, and uncertainty with architectural decisions as a means of optimizing the choice of such decisions.

Detailed design

A term people sometimes use to mean detailed architectural design – that is, architectural design of fine-grained elements, or fine-grained architectural design decisions such as the precise interface of an element – and sometimes use to mean non-architectural design.

Dynamic architecture

An architecture in which architecture variation points are exercised at runtime

Element

The architectural building block (component, connector, or module) that is native to a style.

Enterprise architecture

A means for describing business structures and processes that connect business structures.

Framework

An abstraction in which common code providing generic functionality can be selectively overridden or specialized by user code providing specific functionality.

Interface

See “software interface.”

Interface specification

A statement of what an architect chooses to make known about an element in order for other entities to interact or communicate with it.

Layer

A grouping of modules that together offer a cohesive set of services to other layers. The layers are related to each other by the strictly ordered relation allowed to use.

Mission Thread Workshop (MTW)

A facilitated process that brings together system-of-systems (SoS) stakeholders to augment existing mission threads with quality attribute considerations that will shape the SoS architecture and to identify SoS architectural challenges. Learn more about MTWs.

Module

An implementation unit of software that provides a coherent set of responsibilities.

Non-architectural design

Design decisions carried out subsequent to the architecture and left to downstream designers and implementers because these decisions are either constrained sufficiently by the architecture or because they are not critical to achieving the system's requirements.

Open Source AADL Tool Environment (OSATE)

A set of analysis plug-ins for the system representations developed using the industry standard Architecture Analysis and Design Language (AADL). Learn more about OSATE.

Quality attribute

A property of a work product or goods by which its quality will be judged by some stakeholder or stakeholders. Quality attribute requirements such as those for performance, security, modifiability, reliability, and usability have a significant influence on the software architecture of a system.

Quality attribute scenario

See “Scenarios.”

Quality Attribute Workshop (QAW)

A method for identifying a system's architecture-critical quality attributes, such as availability, performance, security, interoperability, and modifiability, which are derived from mission or business goals. The QAW does not assume the existence of a software architecture; aimed at eliciting, collecting, and organizing software quality attribute requirements in the form of scenarios and used before the software architecture has been created. Learn more about QAWs.

Reference architecture

A reference model mapped onto software elements that implements the functionality defined in the reference model.

Reference model

A division of functionality into elements together with the data flow among those elements.

Relation

A definition of how elements cooperate to accomplish the work of a system.

Scenarios

Descriptions of a system interaction with respect to some quality attribute. Typically, the focus would be on three kinds of scenarios: use case, anticipated uses of the system; growth, anticipated changes to the system; and exploratory, unanticipated stresses to the system (uses and/or changes).

Sensitivity point

A property of one or more components (and/or component relationships) that is critical for achieving a particular quality attribute response. Sensitivity points are places in a specific architecture to which a specific response measure is particularly sensitive (that is, a little change is likely to have a large effect). Unlike tactics, sensitivity points are properties of a specific system.

Service-Oriented Architecture (SOA)

A way of designing, developing, deploying, and managing systems, in which

A boundary across which two independent entities meet, and interact or communicate with each other.

Software product line

A set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of reusable core assets in a prescribed way. Learn more about software product lines.

Stakeholder

Someone who has a vested interest in an architecture.

Style

See “architectural style.”

Subsystem

A part of a system that (1) carries out a functionally cohesive subset of the overall system’s mission, (2) can be executed independently, and (3) can be developed and deployed incrementally.

System

A collection of entities (elements, components, models, etc.) that are organized for a common purpose.

A means for describing the elements and interactions of a complete system including its hardware elements and its software elements.

Tactic

A design decision that is influential in the control of a quality attribute response. Tactics specify how to affect a quality attribute response measure. Unlike sensitivity points, tactics are independent of any specific system.

Team Software Process (TSP)

A software development methodology that uses reviews and inspections for all artifacts produced by a team, guided by historical data on defect type and density, to help engineering teams develop software-reliant products. Learn more about the TSP.

Tradeoff

A property that affects more than one quality attribute and is a sensitivity point for more than one attribute.

Utility tree

A top-down vehicle for characterizing the driving attribute-specific requirements, in which nodes represent important quality goals and leaves represent scenarios.

Variability

The ability to quickly achieve change in planned ways.

View

A representation of a set of system elements and the relationships among them. A view shows a particular perspective of the system (e.g., code units, runtime elements) and may show the entire system or just a part. A set of views–not a single one–conveys the architecture.

Views and Beyond

An approach for documentation that holds that documenting a software architecture is a matter of documenting the relevant views and then adding information that applies to more than one view. Learn more about Views and Beyond.