Lecture 3: Chapter 2 - Why is Software Architecture Important?

Vocabulary flashcards covering key concepts from the lecture notes on software architecture importance.

Software architecture

The fundamental organization of a software system, capturing earliest design decisions, constraining subsequent implementation, enabling analysis of qualities, and facilitating communication among stakeholders.

Quality attributes

The driving properties (e.g., performance, modifiability, security, scalability) whose achievement is largely determined by the architecture.

Earliest design decisions

Initial bindings embedded in the architecture (such as processor layout, layering, communication, OS/hardware dependencies, encryption, protocols) that constrain future development.

Constraints on implementation

The prescribed interactions and responsibilities that the architecture imposes on the implementers.

Evolutionary prototyping

Analyzing and prototyping a skeletal architecture early to reveal infrastructure needs, allowing the system to evolve with reduced risk.

Transferable, reusable model

An architecture that can be reused across multiple systems, enabling transfer of decisions, requirements, and infrastructure.

Software product line

A family of software systems built from the same reusable assets; architecture defines fixed vs. variable features and represents a strategic investment.

Architecture-based development

A development approach focusing on assembling existing components rather than creating new ones from scratch.

Restricting design vocabulary

Limiting the set of design elements and interactions to reduce complexity, improve reuse, and enhance understanding and communication.

Architectural patterns

Reusable design solutions that guide architecture and shape quality attributes by constraining the design vocabulary.

Basis for training

The architecture serves as an introduction to the system for new team members, with module views and component-and-connector views illustrating structure and behavior.

Work-breakdown structure (WBS)

The architecture informs the WBS, guiding planning, scheduling, budgeting, and inter-team communication.

Independently developed components

Architecture often uses components that are independently developed (COTS, OSS, services), improving time-to-market, reliability, and flexibility.

Incremental subset delivery

Managing inter-component usage by delivering system functionality in controlled increments.

Local changes

Changes that can be accomplished by modifying a single element; the most desirable type of change.

Nonlocal changes

Changes that require modifications to multiple elements but leave the underlying architectural approach intact.

Architectural change

Changes that affect the fundamental ways elements interact and likely require broad, system-wide modifications.

Stakeholders

All parties (customers, users, managers, developers, testers) with interests affected by the architecture; the architecture provides a common language to address their concerns.