CSC-210 key terms

A structured sequence of phases, from planning through retirement, used to build and maintain software. Each phase produces defined outputs that feed the next, giving teams a repeatable framework for organizing work and controlling quality.

A sequential lifecycle where each phase (requirements, design, implementation, testing, deployment) completes before the next begins. It suits stable, well-understood requirements but handles change poorly because late discoveries force costly rework.

A 2001 statement of four values and twelve principles favoring individuals, working software, customer collaboration, and response to change over process, documentation, contracts, and plans. It anchors most modern iterative methods without prescribing a specific process.

An agile framework built on short fixed-length iterations called sprints, with three roles (Product Owner, Scrum Master, Developers) and recurring events for planning, daily coordination, review, and retrospective. Work is drawn from a prioritized product backlog.

A timeboxed iteration, typically one to four weeks, during which a Scrum team builds a potentially shippable product increment. Scope is protected once the sprint starts, and progress is tracked through a sprint backlog.

An ordered, evolving list of everything that might be built into the product, maintained by the Product Owner. Items near the top are small and detailed; lower items stay coarse until they become urgent.

A shared checklist describing the quality conditions an increment must satisfy before the team counts it complete, such as code review, tests passing, and documentation updated. It prevents work from being declared finished prematurely.

Building and releasing a system in successive slices, each adding usable functionality on top of what already exists. It delivers value earlier, limits risk per release, and allows feedback to shape later increments.

The activity of gathering needs from stakeholders through interviews, workshops, observation, surveys, and document analysis. Its goal is to surface real problems and constraints before anyone commits to a solution.

A statement of what the system must do: a behavior, calculation, or service it provides to users or other systems. It is normally testable and traceable to design and test artifacts.

A constraint on how the system performs its functions, covering qualities such as performance, security, usability, availability, and maintainability. These are often expressed as measurable targets so they can be verified objectively.

Any person or group with an interest in the system or affected by it, including users, sponsors, operators, regulators, and support staff. Identifying them early prevents missed needs and late-surfacing objections.

A description of an interaction between an actor and a system that yields an observable result of value. It typically includes preconditions, main flow, alternate flows, and postconditions, and helps organize requirements around user goals.

A short, conversation-oriented statement of a need, often phrased as who wants what and why. It is a placeholder for discussion rather than a full specification, and it becomes testable through acceptance criteria.

The specific, checkable conditions a work item must satisfy to be accepted by the customer or Product Owner. They clarify scope, guide test design, and reduce ambiguity about when a requirement is truly met.

A table linking each requirement to its source, design elements, code, and test cases. It supports impact analysis when requirements change and provides evidence that all requirements were implemented and verified.

The degree to which the responsibilities inside a single module belong together and serve one purpose. High cohesion makes modules easier to understand, test, and reuse, and it usually pairs with low coupling.

The degree of interdependence between modules, measured by how much one must know about another's internals. Loose coupling lets modules change independently, while tight coupling spreads the effects of any modification.

A design guideline holding that a class or module should have one reason to change, meaning one cohesive set of responsibilities owned by one actor. It reduces ripple effects when requirements shift.

Software entities should be open for extension but closed for modification, so new behavior is added by introducing new code rather than editing stable code. Abstraction and polymorphism are the usual mechanisms.

High-level modules should not depend on low-level modules; both should depend on abstractions, and abstractions should not depend on details. This inverts typical control flow and enables substitutable implementations.

A structure that organizes software into horizontal layers, each providing services to the layer above and consuming only the layer below. It isolates concerns such as presentation, business logic, and persistence, at the cost of possible pass-through overhead.

An architectural style that decomposes a system into small, independently deployable services communicating over a network, each owning its data and business capability. It improves independent scaling and deployment but adds distributed-system complexity.

A named, reusable solution to a recurring design problem in a given context, such as Observer, Strategy, or Factory Method. Patterns provide shared vocabulary rather than ready-made code.

A linear data structure with last-in, first-out access, where insertion and removal occur at the same end. It supports function call management, expression evaluation, and undo mechanisms.

A linear data structure with first-in, first-out access, where elements are added at one end and removed at the other. It models scheduling, buffering, and breadth-first traversal.

A notation describing an upper bound on how an algorithm's resource use grows as input size increases, ignoring constants. It lets engineers compare approaches, such as linear versus logarithmic search, independent of hardware.

A technique where a function solves a problem by calling itself on smaller inputs, relying on a base case to stop. It simplifies tree and divide-and-conquer algorithms but risks stack overflow on deep inputs.

A data structure mapping keys to values through a hash function, giving average constant-time lookup, insertion, and deletion. Collisions are resolved by chaining or open addressing, and worst-case behavior degrades when hashing is poor.

An automated test that exercises a single small unit of code, such as a function or class, in isolation from its dependencies. It runs fast and pinpoints failures, forming the base of the test pyramid.

A test that verifies interactions between two or more components or with external systems such as databases and APIs. It catches interface and wiring defects that isolated unit tests cannot reveal.

A stand-in object used in place of a real dependency during testing, including stubs, mocks, fakes, and spies. Doubles isolate the code under test and make otherwise slow or nondeterministic interactions controllable.

Re-running relevant tests after a change to confirm that previously working behavior still works. It guards against unintended side effects and is most effective when automated and tied to traceability records.

A practice of writing a failing test first, then the minimum code to pass it, then refactoring. The cycle produces tests as a byproduct and pushes design toward small, testable units.

Improving the internal structure of code without changing its observable behavior, guided by small, behavior-preserving steps and a safety net of tests. It controls technical debt and keeps designs adaptable.

The accumulated cost of shortcuts in design or code that make future changes harder, analogous to interest on a loan. Some debt is deliberate and useful; untracked debt slows delivery and raises defect risk.

A practice where developers merge changes into a shared mainline frequently, with each merge triggering automated build and test runs. It surfaces integration problems early and keeps the codebase in a releasable state.

An extension of continuous delivery in which every change that passes automated checks is released to production without manual approval. It demands strong automated testing, monitoring, and rollback capability.

A system that records changes to files over time so revisions can be inspected, compared, and restored. Distributed systems such as Git give every developer a full repository copy and support branching and merging.

A situation where two branches change the same lines of a file and the version control system cannot combine them automatically. A developer must resolve it manually, preserving intended behavior from both sides.

A size-estimation method that counts inputs, outputs, queries, files, and interfaces, weighted by complexity, independent of implementation language. It supports productivity and cost comparisons across technologies.

A relative unit used by agile teams to size backlog items by effort, complexity, and uncertainty rather than elapsed time. Points are compared within a team, and velocity converts them into forecasts.

A family of algorithmic cost models that estimate effort and schedule from estimated size, typically thousands of delivered source lines, adjusted by cost drivers. It is calibrated to historical project data rather than intuition.

A project control technique comparing planned value, earned value, and actual cost to measure schedule and budget performance. Derived indices reveal whether a project is ahead or behind and by how much.

A scheduling technique that identifies the longest chain of dependent tasks, which determines the minimum project duration. Any delay on the critical path delays the whole project, so it receives the most attention.

A living record of identified risks with their likelihood, impact, owner, and planned response. It makes risk management explicit and is reviewed regularly so responses are triggered before problems occur.

A structured analysis of a system's assets, entry points, and trust boundaries to identify plausible attacks and choose mitigations early in design. It is cheaper than fixing vulnerabilities after release.

An attack that inserts malicious SQL through unsanitized input so the database executes unintended commands. Parameterized queries and least-privilege database accounts are the standard defenses.

A principle that grants each user, process, or service only the permissions needed for its specific task and no more. It limits the blast radius of accidents, bugs, and compromised accounts.

A legal instrument defining how software may be used, modified, and redistributed, such as permissive, copyleft, or proprietary terms. Engineers must respect license obligations when incorporating third-party components.